Menu
Verify phase — confirm the change actually works: tests run, gate passes, acceptance criteria met, claims grounded in output.
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
Start an Agent Smith ticket the right way — read the ticket, its dependencies, the PRD Decision Log, and the affected architecture/docs before editing. Use when picking up an AS-NNN ticket, deciding what to work on next, or before touching code for a backlog item. Triggers: "work on AS-", "start a ticket", "implement the ticket", "what should I work on next", "pick a ticket".
Agent Smith pull-request lifecycle — open a PR, subscribe to activity, reply to and resolve every review thread, handle the Gemini/Copilot review order, and auto-merge when clean. Use when work on a branch is committed and pushed, when a PR exists for the branch, or when handling review comments or CI on a PR. Triggers: "open a PR", "PR review", "review comment", "CI failed on the PR", "merge the PR", "is the PR ready".
Reflect phase — produce the three success artifacts (a measurable success metric, an instrumentation diff, a check-back ticket draft) without ever reading shipped-app runtime data.
Analyse phase — trace what else the change touches: callers, shared state, persisted formats, and cross-package contracts.
Analyse phase — interrogate the request for missing requirements, unstated assumptions, and unhandled cases before any code is written.
Plan phase — pressure-test the proposed plan: smallest viable change, ordering, and the test that will prove it.
| name | verify-checklist |
| description | Verify phase — confirm the change actually works: tests run, gate passes, acceptance criteria met, claims grounded in output. |
You are in the verify phase of Coding Mode. Confirm the change does what it claims — by evidence, not assertion.
Walk the checklist and report the result of each:
./scripts/agent-quality-gate.sh (fmt, test, vet, lint)
pass? Report failures verbatim.Every "done" must point at evidence — a test name, a command's output, a file/line. Claiming success without a concrete anchor is a verify failure. Never report "looks good" or "should be fine".
Good (grounded):
go test ./internal/codingskills/ passes (4 tests); the Pack() count test
pins the five-skill set.TestPhaseSkillsOnlyWhenActive asserts
no skill block is appended without an active mode.Bad (rejected — no anchor):