request-refactor-plan
by mattpocockrequest-refactor-plan helps turn a vague refactor request into a detailed plan with tiny commits, repo verification, scope boundaries, test coverage review, and a GitHub issue. Use it for refactoring RFCs, incremental change plans, and safer implementation prep.
This skill scores 67/100, which means it is listable but best treated as a limited, workflow-oriented helper rather than a polished end-to-end package. Directory users can expect a real refactor-planning flow with enough detail to guide an agent, but they should also expect some adoption friction because the repo is deprecated and ships without supporting files or install guidance.
- Clear trigger and use case: the description says it is for planning refactors, RFCs, and safe incremental steps.
- Concrete workflow: the body outlines an interview, repo verification, test-check, tiny commits, and GitHub issue creation.
- Operationally specific enough to reduce guesswork versus a generic refactor prompt, including an issue template and scope discipline.
- The repository sits under `skills/deprecated/request-refactor-plan`, so users may hesitate to adopt it as a current default.
- No scripts, references, resources, or install command are provided, which limits trust and makes execution more manual.
Overview of request-refactor-plan skill
What request-refactor-plan does
The request-refactor-plan skill helps you turn a vague refactor request into a structured plan with tiny commits, then package that plan as a GitHub issue. It is built for request-refactor-plan for Refactoring when the goal is to improve code safely, not to redesign from scratch.
Who should use it
Use this request-refactor-plan skill if you are an engineer, tech lead, or agent preparing a refactor RFC, an implementation plan, or an issue that needs clear scope. It is most useful when the codebase is real, the change is non-trivial, and you want fewer surprises before editing.
What makes it different
This skill does more than draft a generic prompt. It pushes for a user interview, repo verification, scope boundaries, test coverage review, and a commit-by-commit breakdown. That makes the output better for planning incremental refactors where reversibility and reviewability matter.
How to Use request-refactor-plan skill
Install and activate it
Use the request-refactor-plan install flow from your skills manager, or install from the repository path if your tooling requires a direct source. The repo location is mattpocock/skills under skills/deprecated/request-refactor-plan, so confirm your local loader can still resolve deprecated skills before relying on it in production work.
Give it a refactor-ready brief
The skill works best when your starting input includes: the problem you want to solve, the current behavior, the parts of the codebase involved, constraints, and any ideas you already considered. A strong prompt looks like: “Refactor the billing retry flow to reduce coupling, keep API responses unchanged, preserve existing tests, and avoid database schema changes.”
Follow the workflow the skill expects
The request-refactor-plan usage pattern is: describe the problem in detail, verify the repo state, discuss alternatives, define exact scope, review tests, then split the work into tiny commits. If you skip these inputs, the plan usually becomes too broad or too cautious to be useful.
Read these files first
Start with SKILL.md, then inspect README.md, AGENTS.md, metadata.json, and any rules/, resources/, references/, or scripts/ folders if they exist in your environment. In this repository, the main decision value is concentrated in SKILL.md, so there is little supporting material to cross-check.
request-refactor-plan skill FAQ
Is this for ordinary feature work?
No. The request-refactor-plan skill is aimed at refactoring and scope control, not feature discovery. If you need a feature spec, architecture proposal, or roadmap, a different planning skill or a plain prompt may fit better.
Do I need strong technical detail to use it?
You do not need a perfect design, but you do need enough context to interview the problem well. If your brief is only “clean this up,” the output will likely be generic; if you can name files, behaviors, risks, and constraints, the plan becomes much more actionable.
When should I not use it?
Do not use it when the change is tiny, obvious, or already fully scoped. It is also a weaker fit when you cannot inspect the repo, cannot confirm test coverage, or do not want the overhead of a formal issue and stepwise plan.
How does it compare with a normal prompt?
A normal prompt may give you a refactor checklist, but request-refactor-plan adds process discipline: verification, alternative review, scope locking, testing questions, and tiny commits. That reduces the risk of over-refactoring or missing hidden coupling.
How to Improve request-refactor-plan skill
Provide sharper input for the first pass
The fastest way to improve results is to state the current pain, desired end state, and explicit non-goals. For example: “Reduce duplicated validation logic in src/payments/*, keep public APIs stable, do not rename exported functions, and preserve current error messages.” That gives the request-refactor-plan guide enough structure to avoid guesswork.
Include test and risk context
The skill asks about coverage for a reason: weak tests change the plan. Tell it which tests already protect the area, which failures would be unacceptable, and whether you can add tests before or after the refactor. If you omit this, the plan may be too aggressive or too conservative.
Watch for common failure modes
The biggest failures are under-scoping, over-scoping, and vague end states. If the first output feels broad, respond by narrowing the target files, naming the exact behavior that must stay unchanged, and asking for a smaller commit sequence. If it feels too timid, add the business reason for the refactor and the acceptance criteria that justify change.
Iterate using the issue draft
Treat the generated GitHub issue as a working draft, not the final word. Improve request-refactor-plan for Refactoring results by revising the problem statement, removing speculative steps, and tightening the commit list until each step can be reviewed independently.