This skill is invoked when the user wants to create a refactoring request. You should proceed with the following steps. If you think some steps are unnecessary, you may skip them.
-
Ask the user to describe in detail, at length, the problem they want to solve, as well as any potential solution ideas.
-
Explore the repository to verify the user's assertions and understand the current state of the codebase.
-
Ask the user whether they have considered other approaches, and show them other options.
-
Interview the user about implementation details. Be extremely detailed and thorough.
-
Nail down the exact scope of the implementation. Determine what you plan to modify and what you plan to leave unchanged.
-
Check whether that area has test coverage in the codebase. If test coverage is insufficient, ask the user what their testing plan is.
-
Break the implementation into a series of tiny commits. Remember Martin Fowler's advice: "Make each refactoring step as small as possible, so that you can always see the program working."
-
Create a GitHub Issue containing the refactoring plan. Use the following template as the Issue description:
Problem Statement
Describe the problem the developer faces from the developer's perspective.
Solution
Describe the solution to the problem from the developer's perspective.
Commit Plan
Adetailedimplementation plan. Write the plan in plain, easy-to-understand English, breaking the implementation into the smallest possible commits. Each commit should keep the codebase in a working state.
Decision Document
A list of implementation decisions that have been made. It may include:
- Modules to be built/modified
- Module interfaces to be modified
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
Do not include specific file paths or code snippets. They may quickly become outdated.
Testing Decisions
A list of testing decisions that have been made. Include:
- A description of what counts as a good test (test only external behavior, not implementation details)
- Which modules will be tested
- Reference precedents for tests (i.e., similar types of tests in the codebase)
Out of Scope
Describe what this refactoring does not involve.
Additional Notes (Optional)
Any additional notes about the refactoring.