request-refactor-plan

About request-refactor-plan

request-refactor-plan is a Chinese-language (translated) planning skill from the mattpocock-skills-zh-cn collection (deprecated path) that interviews the user to produce a detailed refactoring plan broken into small commits, then files it as a GitHub issue. The problem it addresses is that large refactors are risky when done in big steps; the skill enforces incremental, always-working steps in the spirit of Martin Fowler's advice to make each refactoring step as small as possible so you can always see the program working.

The procedure (steps are skippable) is: have the user describe the problem and candidate solutions; explore the repo to verify their assertions and understand the current state; surface alternative options; interview the user thoroughly about implementation; nail down exact scope including what will and will not change; check test coverage in the affected area and ask about testing plans if it is thin; break the implementation into a plan of tiny commits each leaving the codebase in a working state; and finally create a GitHub issue using a provided template with sections for Problem Statement, Solution, Commits, Decision Document, Testing Decisions, Out of Scope, and optional Further Notes. The template deliberately avoids concrete file paths and code snippets because they go stale quickly.

It targets developers and tech leads planning refactors or writing refactor RFCs who want a rigorous, interview-driven, safely incremental plan captured as a durable issue. Its behavior is repo exploration plus issue authoring—no destructive or sensitive operations.

FAQ

What does this skill create?

A detailed refactoring plan captured as a GitHub issue, using a template with Problem Statement, Solution, Commits, Decision Document, Testing Decisions, Out of Scope, and optional Further Notes.

How does it keep the refactor safe?

It breaks the work into tiny commits, each of which leaves the codebase in a working state, following Martin Fowler's guidance to make each refactoring step as small as possible.

Does the plan reference specific files or code?

No. The template intentionally omits concrete file paths and code snippets because they become stale quickly; it focuses on decisions, modules, interfaces, and behavior.

What does it do about testing?

It checks test coverage in the affected area and, if coverage is insufficient, asks the user about their testing plans, then records testing decisions in the issue.

What are the prerequisites?

A repository to explore and interview against, and the ability to create a GitHub issue for the finished plan.

All Files