メニュー
Use when restructuring existing code without changing behavior — extracting functions, splitting modules, or addressing tech debt and code smells
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when asked to implement an epic, a backlog of issues, or "/epic-implement N" — autonomous multi-agent execution of a GitHub epic's sub-issues, safe under a permission-bypassed session. Pass the epic number as the argument; if omitted, asks which open epic to run. A single issue goes to issue-implement.
Use when asked to implement a single GitHub issue end to end — "implement #171", "fix issue N", "pick up that bug" — where the deliverable is a reviewed PR. Epics and multi-issue backlogs go to epic-implement.
Use when capturing a feature, remediation, port/resurrection of old functionality, or any multi-issue program of work as a GitHub epic with sub-issues for later execution by separate agents — including when asked to "create an epic", "file this as issues", or "plan this so a lesser model can execute it". Single-issue-scale work (one bug/feature/chore) goes to issue-plan.
Use when capturing a single unit of work as a GitHub issue for later execution by a separate session — a bug found while debugging, a feature request, a chore, or a discovery out of scope for the current task. Triggers include "file an issue", "create an issue", "write this up as a bug". Multi-issue programs of work go to epic-plan.
Use when starting work in an unfamiliar module, when a module's `.context.md` is missing or stale, or when asked to document or understand a module's role
Use when auditing the project for OWASP issues, secrets, vulnerable dependencies, auth gaps, or misconfigured infrastructure
| name | refactor |
| description | Use when restructuring existing code without changing behavior — extracting functions, splitting modules, or addressing tech debt and code smells |
Refactoring changes HOW code works without changing WHAT it does. The test suite is the contract. Big-bang rewrites lose the safety net; incremental commits keep it.
REQUIRED BACKGROUND:
superpowers:test-driven-development — tests are the contract; without them, write characterization tests first.superpowers:using-git-worktrees — refactors run in their own worktree.See catalog.md for common refactoring moves and characterization-tests.md for testing code you don't fully understand yet.
0. Worktree — refactor-[scope]
1. Goal — what smells, what structural improvement is the goal
2. Baseline green — make check must pass before touching anything
3. Coverage check — run coverage on the target
>= 80% → proceed
< 80% → write characterization tests first
4. Plan — list each refactoring move as a separately committable step
(`superpowers:writing-plans`)
5. Execute one step at a time:
change → make check
green → commit with descriptive message
red → fix or revert this step
6. Review — built-in /code-review; dispatch architecture-reviewer for structural moves
If the project uses per-module .context.md files, read them before starting and update them after structural changes.
/refactor [file or module] — targeted/refactor — interactivecatalog.md — common refactoring moves, step-by-stepcharacterization-tests.md — pinning behavior of code you don't fully understand