← ClaudeAtlas

integratelisted

Integrate finished branches one at a time into an integration branch cut from main — per-branch 4-lens review → merge → conflicts resolved by the implementer → verifier PASS → next (merge queue); /ship then ships that branch
jaewhi-park/GARAGISTE · ★ 1 · Code & Development · score 77
Install: claude install-skill jaewhi-park/GARAGISTE
Integrate branches: $ARGUMENTS (if empty, the completed entries of the "Awaiting integration" list in docs/STATUS.md, in order) 0. Branch: apply the branches-and-sync rule (on main, synced) and create the integration branch — `git switch -c integrate/<YYYY-MM-DD>` (suffix `-2`, `-3`… when it exists) — or stay on the integrate/* branch you are already on (a resumed integration). On a plan/* branch, or not synced, stop and ask the CEO. Record it in docs/STATUS.md (`Plan: integration of <n> plans · Branch: integrate/<date> · Shipped: —`, `Step: none`). Main never receives the merges directly: /ship opens the integration's PR or merges it locally, and the guardrail keeps blocking pushes to main. For each branch, strictly one at a time: 1. Review `git diff <current>...<branch>` with team-reviewer across 4 lenses. If there are blockers/majors, have team-implementer fix and commit inside that branch's worktree (`cd <worktree path> && ...`), then re-review only the fix diff with the lenses that objected (max 3 rounds, as in /review); past that, leave the branch out of the integration and report it to the CEO. 2. `git merge --no-ff <branch>`. On conflict, hand team-implementer the conflicting files and both sides' intent (each plan file, and the shared spec section if the plans reference one) to resolve and commit; then review the resolution diff once more with the correctness lens (on REQUEST_CHANGES, the same fix loop, max 3). 3. Note the merge commit's hash M (`git log -1 --forma