メニュー
Side-route skill for planning refactors as safe, tiny-commit RFCs. Use when the user wants a structured refactor plan before implementation. Feeds approved refactor work back into /execute. Not for new-feature shaping or already-concrete implementation tasks.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | request-refactor-plan |
| description | Side-route skill for planning refactors as safe, tiny-commit RFCs. Use when the user wants a structured refactor plan before implementation. Feeds approved refactor work back into /execute. Not for new-feature shaping or already-concrete implementation tasks. |
| sources | {"primary":["Refactoring — Martin Fowler"]} |
This is a side-route skill for work that is primarily about restructuring code safely rather than shaping a new feature.
Use /request-refactor-plan when the user wants a refactor RFC, a tiny-commit migration path, or a safer way to reorganize code without jumping straight into implementation.
Do not use it when the work is still a product-shaping problem for /write-a-prd, or when the refactor task is already concrete enough to execute directly in /execute.
This skill will be invoked when the user wants to create a refactor request. You should go through the steps below. You may skip steps if you don't consider them necessary.
Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
Explore the repo to verify their assertions and understand the current state of the codebase.
Ask whether they have considered other options, and present other options to them.
Interview the user about the implementation. Be extremely detailed and thorough.
Hammer out the exact scope of the implementation. Work out what you plan to change and what you plan not to change.
Look in the codebase to check for test coverage of this area of the codebase. If there is insufficient test coverage, ask the user what their plans for testing are.
Break the implementation into a plan of tiny commits. Remember Martin Fowler's advice to "make each refactoring step as small as possible, so that you can always see the program working."
Each commit should be a trivially safe step. Work backward from the final state — ask "what would make the last step trivially safe?" and plan commits that create those preconditions.
Use these strategies to decompose safely:
Create a GitHub issue with the refactor plan. Use the following template for the issue description:
The problem that the developer is facing, from the developer's perspective.
The solution to the problem, from the developer's perspective.
A LONG, detailed implementation plan. Write the plan in plain English, breaking down the implementation into the tiniest commits possible. Each commit should leave the codebase in a working state.
A list of implementation decisions that were made. This can include:
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
A list of testing decisions that were made. Include:
A description of the things that are out of scope for this refactor.
Any further notes about the refactor.
/improve-codebase-architecture when the refactor opportunity emerged from architecture exploration/execute once the refactor plan is approved and ready to executeSide-route skill that renders a finished diff, PR, or branch as a single self-contained interactive HTML recap — file-tree + change flags, annotated split diffs with line-anchored callouts, schema/API contract cards, UI wireframes for rendered-UI changes, labeled before/after columns, CSS-first flow diagrams (Mermaid opt-in for complex graphs), and a copy-text feedback loop. Use when a reviewer who didn't author the change needs to grasp its shape before reading lines. Optional and never auto-invoked; skip for small or obvious diffs. Not a defect finder (that's /pre-merge), not free-form diagramming (that's /excalidraw-diagram), not a committed artifact (the HTML is transient).
Side-route skill for an interactive, commit-by-commit comprehension walkthrough of a finished branch before merge. Use when the person about to merge didn't author the diff — or hasn't internalized it — and needs to understand each commit's intent, riskiest line, deliberate oddities, and what's absent by design, with per-commit sign-off. Not a defect finder (that's /pre-merge), not a behavioral check (that's /verify), not an acceptance-criteria checklist (that's /execute Step 5). Optional and never auto-invoked.
Side-route skill for explicit backtracking when an upstream artifact becomes untrustworthy. Use when research, PRD, or slice decomposition has been invalidated by new information and you need to clean up stale artifacts before re-running an earlier pipeline step. Not for forward progress, fresh shaping, or routine bug fixes.
Side-route orientation skill. Use when the user asks 'what's next', 'where am I', or is returning to a repo mid-pipeline and wants to know which skill to run next. Reads repo state (branch, PRs, issues, research archive, milestones) and recommends one next step with a one-line reason. Not for executing work — only for routing.
Optional meta-skill for improving `chrislacey89/skills` from real-world friction or breakdowns discovered while using the pipeline in another repo. Use when the main lesson is about the pipeline itself, not the downstream project. Grounds proposals in established software-engineering guidance from `/library`. Produces a GitHub issue in `chrislacey89/skills` and only moves to implementation after review.
Infrastructure skill for setting up Ralph loop scripts for Claude-driven AFK execution. Use when a repo wants a HITL-to-AFK runner around /execute with bounded iterations, GitHub-native durable state, and explicit feedback loops. Not a normal feature-delivery stage; it prepares the repo for safer autonomous execution.