メニュー
Use after execution is complete, before declaring work ready to ship. Unified verification through multiple lenses: correctness, code quality, review, and architectural feel.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use before any code change — new feature, bug fix, refactor, or tech debt. Explores the problem, builds understanding through concrete artifacts, and produces a spec that gates the transition to execution.
Use when you have an approved spec from the Discover phase. Orchestrates implementation — parallel or serial — with autonomy and guardrails.
Use at the start of every conversation and when deciding how to approach a task. Routes to the appropriate phase of the Discover → Execute → Verify flow.
Use when creating, switching, syncing, or cleaning up git branches. Enforces naming conventions and the branching flow.
Use at the start of a new conversation or when working in an unfamiliar codebase. Generates a ranked map of the repository structure to orient before diving into code.
Use when creating a git commit. Guides intelligent staging, conventional commit message authoring, and pre-commit validation.
| name | verify |
| description | Use after execution is complete, before declaring work ready to ship. Unified verification through multiple lenses: correctness, code quality, review, and architectural feel. |
Confirm the work is correct, clean, and ready to ship. Verification is a single phase with multiple lenses — not separate steps. Even when Discover was compressed to a single sentence, Verify always runs fully.
Core principle: Evidence before claims.
If you were dispatched as a subagent or teammate for a specific task, stop here. Do not activate the full workflow. You have a focused job — do it and report back.
The claim must match the evidence. If tests show 33/34 passing, don't say "all tests pass." State exactly what you ran and what the output was.
Dispatch the code-simplifier agent (or review manually for small changes):
Dispatch the code-reviewer agent with:
The reviewer categorizes issues by severity:
Act on feedback:
After the other lenses pass, a gut check:
TECH-DEBT.md and ship. Not everything needs to be perfect now.The threshold: would you be comfortable explaining this code to someone in a week? If yes, ship it. If you'd feel the need to apologize, fix it.
Present a clear summary to the user:
## Verification Summary
**Correctness:**
- [Exact commands run and output]
- [Acceptance criteria: N/N met]
**Code Quality:**
- [Issues found and fixed, or "Clean"]
**Review:**
- [Critical: N, Important: N, Minor: N]
- [Issues addressed or noted]
- **Ready to ship:** [Yes / No / With fixes]
**Tech Debt Noted:**
- [Any items added to TECH-DEBT.md, or "None"]
When verification passes and the work is ready to ship:
SPRINT-N-SPEC.md) should be deleted in the merge commit. The spec is ephemeral — it served its purpose. The code is the lasting artifact.CLAUDE.md to reflect the completed sprint.TECH-DEBT.md.Verify is done when you can state "ready to ship" with evidence. Code-flow's job ends here. What happens next (PR, merge, deploy) is outside code-flow's scope — the user decides.