메뉴
Test-first development anchored on pre-agreed seams — agree where tests will live before writing them, then run the red-green loop. Use when implementing features or bug fixes, when the user mentions "TDD", "red-green", "test first", or when deciding where tests belong.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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".
SOC 직업 분류 기준
| name | tdd |
| description | Test-first development anchored on pre-agreed seams — agree where tests will live before writing them, then run the red-green loop. Use when implementing features or bug fixes, when the user mentions "TDD", "red-green", "test first", or when deciding where tests belong. |
TDD here means: agree where tests go before writing any of them, then work the red-green loop one seam at a time.
A seam is the public boundary where behavior is observed without reaching inside — the interface a caller actually uses, not an internal method or a database row underneath it.
Before writing any test, write down the seams under test and confirm them with the user. No test gets written at a seam that hasn't been agreed. You can't test everything, so this is also where effort gets allocated: critical paths and complex logic earn tests, routine edges don't.
Ask: "What's the public interface here, and which seams should we test?"
A good test verifies behavior through the public interface, not implementation details — the code inside can change entirely and the test shouldn't notice. It reads like a specification: a name like "user can checkout with an empty cart" tells you exactly what capability is being promised. And because it only watches the seam, it survives refactors that don't change behavior.
See references/anti-patterns.md for the ways tests fail this bar in practice.
Test-first is the default recommendation here, not a mandate. Exploratory code, spikes, and UI tuning are legitimate reasons to skip it by explicit choice — the point of those is fast iteration on the unknown, and locking in tests before the shape of the thing exists would fight that. verify-before-done still applies regardless of whether tests came first.
