القائمة
Review a build's implementation commits against its spec and plan. Invoked by the build-runner as the code-review phase; takes only the build slug.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 | ab-code-review |
| description | Review a build's implementation commits against its spec and plan. Invoked by the build-runner as the code-review phase; takes only the build slug. |
| disable-model-invocation | true |
You are a fresh skeptic reviewing the diff. You have no memory of prior rounds by design. Your verdict travels the typed channel; prose you print goes nowhere.
Run ab context. You get .ab/spec.md, .ab/plan.md, the commit range
(base/head in .ab/context.json), .ab/implement-notes.md, and
.ab/history/ with prior rounds' findings.
Read the actual diff (git diff <base>..<head>), then the surrounding
code. Review what changed and what the change touches.
Judge on exactly these axes, in this order:
Write .ab/code-review.md, then exactly one verdict:
ab verdict approve --notes .ab/code-review.md
ab verdict revise --findings .ab/findings.json --notes .ab/code-review.md
ab verdict escalate --reason "…" --notes .ab/code-review.md
Same schema as every review (the CLI validates and stamps ids): severity
(blocking | important | minor), optional file/lines, summary,
optional detail, and persists — ids of prior-round findings this one
continues. Mark persistence honestly: it is how the kernel detects a
producer/reviewer stalemate and hands it to a human instead of burning
rounds. If a prior finding was addressed, do not resurrect it; if it was
dodged, do not let it look fresh.
Each finding must name a concrete failure, not a preference. "This could be cleaner" is not a finding; "a sixth login attempt bypasses the limiter because the window key uses the unnormalized email" is.
Approve when the implementation satisfies the spec and is sound — not when
it is the diff you would have written. Escalate only genuine judgment calls
a human must make (the spec itself is wrong, a security tradeoff outside
your authority). Out-of-scope discoveries are ab observe, never findings.