메뉴
Runs the relevant verification and reads its output before any claim that work is done, fixed, or passing. Use when about to report completion of a code change, bug fix, refactor, or task, or before committing and creating a PR.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
A relentless one-question-at-a-time interview that sharpens a plan, decision, or idea until shared understanding is reached — not limited to software. Use when the user wants requirements or a decision clarified before acting, wants to stress-test their thinking, or asks to "grill me", "詰めて", "brainstorm this".
Executes an implementation plan or agreed work by orchestrating fresh subagents — one implementer per task, a reviewer between tasks — while the main model plans, briefs, and evaluates without writing code itself. Use when the user asks to "implement the plan", "start implementation", "実装して", or hands over a plan or spec to execute.
A feedback-loop-first discipline for diagnosing hard bugs and performance regressions. Use when the user reports something broken, throwing, failing, flaky, or slow, or asks to "diagnose", "debug this", "原因を調べて".
Builds a clearly-marked throwaway prototype to answer a design question before committing to an implementation. Use when the user wants to sanity-check whether logic or a state model feels right, explore what a UI should look like, or asks to "prototype this", "試作して".
Creates an Architecture Decision Record for a decision that is hard to reverse, surprising without context, and the result of a real trade-off. Use when such a decision has just been made, or the user asks to "record this decision", "ADRにして", or mentions decision records.
Reviews the diff since a fixed point along two axes run as parallel subagents — Spec (does the change match what was asked?) and Standards (repo conventions plus a code-smell baseline) — and reports them side by side. Use when the user asks to review a branch, work-in-progress changes, a diff, or "review since X".
| name | verify-before-done |
| description | Runs the relevant verification and reads its output before any claim that work is done, fixed, or passing. Use when about to report completion of a code change, bug fix, refactor, or task, or before committing and creating a PR. |
Before claiming a change is done, fixed, or passing, run the verification appropriate to it — build, tests, lint, or the actual behavior — and read what it printed.
Evidence precedes assertion: the claim quotes or summarizes what the command actually output, not what it's expected to output.
Report failures as failures, with the output that shows them. If a verification was skipped, say so — don't imply it ran. No hedged success claims ("should work now", "this probably fixes it") in place of a result.
