Menu
Resolve a conflicted PR by merging base into the build branch. Invoked by the build-runner as the reconcile phase; takes only the build slug.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Work this repo's local ticket tracker — create or edit a ticket, amend blockedBy dependencies, report the backlog, move work between triage/ready/doing/done, or answer "what's the status of ticket X". Use whenever the user asks about tickets, blockers, the backlog, or wants something queued for autobuild to build.
Work this repo's local ticket tracker — create or edit a ticket, amend blockedBy dependencies, report the backlog, move work between triage/ready/doing/done, or answer "what's the status of ticket X". Use whenever the user asks about tickets, blockers, the backlog, or wants something queued for autobuild to build.
Authoritative reference for the autobuild system as installed in this repository - the build lifecycle (grooming, dispatch, plan, plan-review, implement, code-review, verify, finalize, reconcile, merge), the complete autobuild.toml configuration surface, how `ab init` and `ab upgrade` treat config and vendored skills, and what each installed ab-* skill is for. Use when asked about how autobuild works or why a build did what it did; when editing autobuild.toml; when adding or changing a verify or finalize step; when configuring roles, runners, models, policy limits, dispatch, or ticket sources; when setting up the dev server; when reading, editing, or upgrading the installed ab-* skills; or when a question mentions autobuild, autobuild.toml, or the `ab` CLI.
Authoritative reference for the autobuild system as installed in this repository - the build lifecycle (grooming, dispatch, plan, plan-review, implement, code-review, verify, finalize, reconcile, merge), the complete autobuild.toml configuration surface, how `ab init` and `ab upgrade` treat config and vendored skills, and what each installed ab-* skill is for. Use when asked about how autobuild works or why a build did what it did; when editing autobuild.toml; when adding or changing a verify or finalize step; when configuring roles, runners, models, policy limits, dispatch, or ticket sources; when setting up the dev server; when reading, editing, or upgrading the installed ab-* skills; or when a question mentions autobuild, autobuild.toml, or the `ab` CLI.
Agent-verify step - inspect deterministic simulated dispatch-dashboard frames as colour images. Invoked by the build-runner for verify:dashboard; takes only the build slug.
Agent-verify step - inspect deterministic simulated dispatch-dashboard frames as colour images. Invoked by the build-runner for verify:dashboard; takes only the build slug.
| name | reconcile |
| description | Resolve a conflicted PR by merging base into the build branch. Invoked by the build-runner as the reconcile phase; takes only the build slug. |
The build's PR no longer merges cleanly: main moved. Your job is one merge commit — base merged into the build branch — that preserves both what this build was for and what landed on main since. Never rebase (SPEC §15.7: rebase re-resolves conflicts against a moving target and severs recorded SHA provenance; it is banned in this system).
Run ab context. You get .ab/spec.md, .ab/plan.md,
.ab/implement-notes.md, and the conflict info (baseSha in
.ab/context.json). Kernel plumbing fetched the PR's configured base and
resolved this SHA immediately before your session, so the commit already
exists locally; it is not the older conflict-detection snapshot.
git merge <baseSha> in the workspace and resolve every conflict with
the explicit charge to regress against neither side:
Textual conflicts with one faithful resolution: resolve them. Then run the repo's checks (typecheck, tests) — a merge that compiles but fails tests is not resolved.
Write .ab/reconcile-notes.md — each conflicted file, what collided,
how you resolved it and why that preserves both sides — then:
ab done --notes .ab/reconcile-notes.md
ab done requires the merge commit to exist and the worktree to be
clean; the push is plumbing. Verification re-runs in full afterward
because reconciliation changed code — that is expected, not a failure.
A semantic conflict — both sides changed the same behavior's meaning, the resolution needs a decision the spec doesn't make, or preserving both sides is impossible — escalates rather than guesses:
ab escalate "main's abc123 changed the session-token format; this build's rate limiter keys on the old format. Adopt the new format (touches spec criterion 3) or key differently?" --refs src/auth.ts
A wrong guess here lands directly on main. Exactly one terminal command:
ab done or ab escalate.