メニュー
Use before claiming work is done, fixed, passing, implemented, reviewed, or ready; when verification fails; or when the user asks to skip checks but still wants a completion claim.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | verify-work |
| description | Use before claiming work is done, fixed, passing, implemented, reviewed, or ready; when verification fails; or when the user asks to skip checks but still wants a completion claim. |
Do not claim completion without fresh evidence.
Before saying work is done, fixed, passing, implemented, reviewed, or ready, verify the claim.
Good evidence can be:
Use the smallest verification that proves the claim.
A happy-path check does not prove graceful failure, fail-closed behavior, recovery, retry safety, or readiness for failure states. Those claims need failure-path evidence.
Match the claim to the evidence.
Never convert "I changed the code" into "it works" without evidence. Never convert "the happy path passed" into "failure handling is graceful" without failure evidence.
If verification fails or only proves a weaker claim than requested, stop and report the evidence.
Do not patch randomly. Decide whether the failure means:
If the failure challenges the spec, plan, docs, policy, or tests, re-enter the interview gate before changing direction.
Use this shape:
Changed: ...
Verified: ...
Not verified: ...
Next: ...
For completed consequential work, include Next: because completion leaves a route decision. Omit it only for direct question answers, mid-task status, clarification-only turns, or direct owner-decision questions.
For pure questions, include Next: only when a concrete next route helps.
Keep it short.
Use when coordinating Freeflow Pi/cmux pane delegation, orchestrator/planning-parent/execution-parent workflows, task packets, child results, context locality, capability reroutes, multi-agent execution, work packages, worktrees, routing fresh-reviewer/subagent requests, or when the user asks to spawn/manage visible pane agents.
Use when shaping, reviewing, implementing, or diagnosing work where module/interface/seam/state/role-boundary choices affect complexity, locality, testability, future change, or repeated edge-case churn. Use for architecture direction, state machines, event systems, tool interfaces, prompt/result serialization, delegation/context boundaries, role ownership, failure contracts, growing scope, shallow modules, bad seams, broad refactors, and review loops that keep finding new edge cases.
Use for pre-work thinking before consequential work, including codebase exploration, brainstorming, planning direction, shaping ideas/features/specs, conceptual/design/routing/interface/state/context-boundary questions, workflow/tool-surface questions, "should we" / "how should we" / "what do you think" prompts, vague requests, and work that needs evidence before spec, plan, build, review, verification, or durable memory.
Use when implementing an approved plan, executing planned slices, resuming planned work, handling planned verification failures, adjudicating review findings during execution, or encountering scope/source conflicts while carrying out a plan.
Use when context is low, scope is ambiguous, implementation/review/verification reveals unknowns, the user asks a question or suggests a path that could be misread as correction/permission, or the agent may be about to make a user-owned decision.
Use when asked to review whether a spec, plan, decision note, discovery checkpoint, handoff, or other durable artifact is fit to guide future work; also use when adjudicating artifact-review findings or repeated review loops.