القائمة
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.