메뉴
Build new behavior test-first using strict Red-Green-Refactor cycles. Use this when you want to drive a new feature or behavior from failing tests before writing the implementation.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Check a built unit goal-backward: classify every brief acceptance criterion COVERED / PARTIAL / MISSING with concrete evidence, so you know what is truly done. Use when: verify N, check whether unit N is done, confirm the goals for roadmap unit N are met.
Turn a numbered roadmap unit into a single brief — why + what + spec — so implementation is unambiguous. Use when: brief N, write the brief for N, capture requirements for roadmap unit N before building.
"Execute a plan in dependency-ordered waves — run independent steps concurrently in isolated worktrees, one atomic, quality-gated commit per step. Use when: build N, execute the plan for N, run the build for roadmap unit N."
Pre-mission discovery: discuss and think out candidate directions for the next feature mission, converge on one concrete proposal, and capture the reasoning as a durable artifact that /mission later reads as its seed. Use when: ideate, what should the next mission be, explore options before committing to a charter. Does not start or mutate any mission — it stops at a proposal.
Start or switch to a named feature mission and capture its purpose, constraints, and numbered roadmap, so every later step shares the same context. Use this to begin a new feature cycle or update its direction — it drives bin/godmode-mission, maintains the project-global .planning/PROJECT.md, and writes the mission's .planning/missions/<mission_id>/ROADMAP.md.
Turn a brief into an ordered, dependency-aware tactical plan plus a per-criterion verification plan, so building is mechanical. Use when: plan N, break down the brief for N, produce the build plan for roadmap unit N.
| name | tdd |
| description | Build new behavior test-first using strict Red-Green-Refactor cycles. Use this when you want to drive a new feature or behavior from failing tests before writing the implementation. |
| user-invocable | true |
Implement features using strict Red-Green-Refactor cycles. Implements the testing protocol in rules/godmode-testing.md.
Auto Mode suppresses confirmation prompts, not the clarifying questions that decide what the tests assert. If a target behavior is genuinely ambiguous — the expected output, an edge case's contract — don't ask blank: lead with the contract you'd assert and invite the override (e.g. "I'll assert this edge case returns an empty list rather than throwing — correct me before I write the red test"), because the tests encode it and guessing bakes the wrong contract into red-green. This is the clarifying rendering of the shared recommendation convention (godmode:recommend-convention) defined in rules/godmode-recommend.md. For low-stakes decomposition choices, use reasonable defaults and surface the behavior list + assumptions inline, then run the cycles. Treat course-corrections as normal input.
Break the feature into small behaviors. For each behavior, run one Red-Green-Refactor cycle.
should [expected behavior] when [condition].planning/STANDARDS.md is present, the code you write must honor it as authoritative project context over the generic defaults where it has spoken (see "Project Standards Precedence" in rules/godmode-coding.md)config/quality-gates.txt)After each cycle:
Cycle N: [test name]
RED: Test written, fails as expected
GREEN: [approach taken], all tests pass
REFACTOR: [what was cleaned up] (or "none needed")
Tests: X passing / X total
| Step | Agent | Purpose |
|---|---|---|
| Before first RED | MUST spawn @researcher | Find test framework, utilities, naming conventions, fixtures, and existing test patterns |
| REFACTOR | Always run /verify (5 parallel review lenses) when >3 files changed | Review refactored code for correctness and adherence to project patterns |
Rule: Never explore the codebase inline when @researcher can do it in parallel.
After the behavior list is generated (end of "Workflow Per Feature" step 1), decide how the work re-enters the workflow spine:
.planning/missions/<mission_id>/ROADMAP.md describing the feature and its behaviors, then pick it up with /brief N. The brief captures the why + what, /plan N breaks it down into the same behavior list, and /build N drives the cycles.In Auto Mode, run all cycles now unless the feature clearly needs its own planning pass — then append a work unit and say so inline.
Appended work-unit note (for .planning/missions/<mission_id>/ROADMAP.md):
- TDD: [feature name] — N behaviors, each one RED-GREEN-REFACTOR cycle.
Behaviors: [short list]. Drive test-first; quality gates per cycle.
The Progress Report above narrates each Red-Green-Refactor cycle as it runs; close the whole run with one consolidated result block. It leads with the terminal state, summarizes the cycles, and names one next move:
"Implemented [N] behaviors test-first; [X]/[X] tests pass and all quality gates are green. Run
/shipto take the feature to a PR."
When the remaining behaviors are deferred instead of driven now, the next-step names the work-unit handoff:
"Drove [N] behaviors; appended the rest as a work unit to
.planning/missions/<mission_id>/ROADMAP.md. Run/brief Nto plan it."
Spine: decompose into behaviors, then either run the cycles now (/ship) or append a work unit to .planning/missions/<mission_id>/ROADMAP.md and resume the spine at /brief N.