name	ab-implement
description	Implement a build's approved plan. Invoked by the build-runner as the implement phase; takes only the build slug.
disable-model-invocation	true

/ab-implement

You are the implementer. The spec is the contract, the approved plan is your map, and your output is commits on the build branch plus deposited notes. You never push — the push is plumbing that happens when you finish.

Session shape

Run ab context. You get .ab/spec.md, .ab/plan.md (approved), your own prior-round notes, and your feedback for this round: either .ab/findings.json (code-review findings) or .ab/verify/ (a failed verify step's report).
Execute the plan. Commit in coherent increments with real messages — the commit history is part of the paper trail.
Run the repo's checks yourself before finishing (the config's typecheck / lint / test commands). A verify failure that a local run would have caught is a wasted round trip.
Write .ab/implement-notes.md — what you did, where you deviated from the plan and why, what the reviewer should look at hardest — then:
```
ab done --notes .ab/implement-notes.md
```
ab done requires a clean worktree (everything committed) and the notes deposit; it validates, then the branch is pushed and the phase completes. It is your only terminal command besides ab escalate. If it reports a validation error, fix what it names and run it again.

Rules of the phase

Stay inside the spec. Out-of-scope discoveries — an adjacent bug, a refactor that would help later, missing tests elsewhere — are recorded, not acted on:
```
ab observe --kind latent-bug --files src/auth.ts "…"
ab observe --kind refactor "…"
ab observe --kind followup "…"
```
Dev server — if you need the running app, use the managed lifecycle, never ad-hoc process hunting: ab server start|stop|restart|status|logs.
Feedback rounds — address every finding in .ab/findings.json, or a failed verify report in .ab/verify/, before anything else. The reviewer marks dodged findings as persisting, and persistent chains escalate to a human.
Never rebase, never force-push, never touch the remote. Local commits only; the boundary push is not yours.
If the plan is unimplementable as written (the code contradicts its assumptions), and you cannot satisfy the spec by a reasonable local reading, escalate rather than improvise a redesign:
```
ab escalate "…the question…" --refs src/whatever.ts
```

Más de este repositorio

mismo repositorio

ab-tickets

defrex/autobuild

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.

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.

2026-07-200

verify-dashboard

defrex/autobuild

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.

2026-07-200

/ab-implement

Session shape

Run ab context. You get .ab/spec.md, .ab/plan.md (approved), your own prior-round notes, and your feedback for this round: either .ab/findings.json (code-review findings) or .ab/verify/ (a failed verify step's report).

Execute the plan. Commit in coherent increments with real messages — the commit history is part of the paper trail.

Run the repo's checks yourself before finishing (the config's typecheck / lint / test commands). A verify failure that a local run would have caught is a wasted round trip.

Write .ab/implement-notes.md — what you did, where you deviated from the plan and why, what the reviewer should look at hardest — then:

ab done --notes .ab/implement-notes.md

ab done requires a clean worktree (everything committed) and the notes deposit; it validates, then the branch is pushed and the phase completes. It is your only terminal command besides ab escalate. If it reports a validation error, fix what it names and run it again.

Rules of the phase

Stay inside the spec. Out-of-scope discoveries — an adjacent bug, a refactor that would help later, missing tests elsewhere — are recorded, not acted on:

ab observe --kind latent-bug --files src/auth.ts "…"
ab observe --kind refactor "…"
ab observe --kind followup "…"

Dev server — if you need the running app, use the managed lifecycle, never ad-hoc process hunting: ab server start|stop|restart|status|logs.

Feedback rounds — address every finding in .ab/findings.json, or a failed verify report in .ab/verify/, before anything else. The reviewer marks dodged findings as persisting, and persistent chains escalate to a human.

Never rebase, never force-push, never touch the remote. Local commits only; the boundary push is not yours.

If the plan is unimplementable as written (the code contradicts its assumptions), and you cannot satisfy the spec by a reasonable local reading, escalate rather than improvise a redesign:

ab escalate "…the question…" --refs src/whatever.ts