メニュー
Improve code structure without changing behavior, verifying with tests at every step. Use this when you want to restructure, extract, rename, or simplify existing code that already works.
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 | refactor |
| description | Improve code structure without changing behavior, verifying with tests at every step. Use this when you want to restructure, extract, rename, or simplify existing code that already works. |
| user-invocable | true |
Improve code structure without changing behavior. Every step verified by tests, with quality gates passing before and after each change.
When ## Auto Mode Active is present in context: do not pause for confirmation. Plan the steps using reasonable defaults, surface the plan and assumptions inline, then execute step by step with per-step quality gates. When the refactor's scope or target is genuinely ambiguous — what to restructure into what — ask, following the shared recommendation convention (godmode:recommend-convention) in rules/godmode-recommend.md: lead with your best-inferred answer to override, not a blank prompt (e.g. "I'll extract X into Y unless you'd scope the boundary differently"), then let the user redirect. Treat user course-corrections as normal input.
config/quality-gates.txt). They must pass.a. Apply one refactoring
b. Run quality gates
c. If GREEN → commit: "refactor: [what was done]"
d. If RED → revert immediately, try smaller step
| Refactoring | When to use |
|---|---|
| Extract function | >40 lines, mixed responsibilities |
| Rename | Name doesn't describe purpose |
| Inline | Abstraction adds complexity without value |
| Move | Code in wrong module/file |
| Split file | >300 lines or mixed responsibilities |
| Simplify conditional | Nested if/else, complex booleans |
| Replace magic values | Hardcoded numbers/strings |
| Improve types | any, loose types where precise ones exist |
.planning/STANDARDS.md is present, the code you restructure must honor it as authoritative project context over the generic defaults where it has spoken (see "Project Standards Precedence" in rules/godmode-coding.md)| Step | Agent | Purpose |
|---|---|---|
| IDENTIFY | MUST spawn @researcher | Explore affected files, find all callers/consumers, map dependencies before planning |
| PLAN | Always spawn @architect when >5 files affected | Validate refactoring approach and step ordering for large-scope changes |
| VERIFY | MUST run /verify (5 parallel review lenses) | Review each completed refactoring step for correctness and regressions |
Rule: Never explore the codebase inline when @researcher can do it in parallel.
After the PLAN step, decide how the refactoring re-enters the workflow spine:
.planning/missions/<mission_id>/ROADMAP.md describing the area and the planned steps, then pick it up with /brief N. The brief captures the why + what, /plan N re-derives the steps, and /build N executes them with the same per-step verification.In Auto Mode, execute now for small refactorings; for large ones, append a work unit and say so inline.
Appended work-unit note (for .planning/missions/<mission_id>/ROADMAP.md):
- Refactor: [area] — N steps, structure only, no behavior change.
Steps: [short list]. Quality gates must pass before AND after each step.
Refactoring: [what and why]
Steps completed: N
1. [step] — gates pass ✓
2. [step] — gates pass ✓
Tests: [before] → [after]
Coverage: [before] → [after]
Spine: plan the steps, then either execute now (/ship) or append a work unit to .planning/missions/<mission_id>/ROADMAP.md and resume the spine at /brief N.