This skill will be invoked when the user wants to create a refactoring request. You should perform the following steps. You may skip some steps if you deem them unnecessary.
-
Ask the user for a detailed description of the problem they want to solve, as well as any potential ideas for a solution.
-
Explore the repository to verify their assertions and understand the current state of the codebase.
-
Ask them whether they have considered other options, and show them other options.
-
Interview the user about the implementation approach. Be extremely detailed and thorough.
-
Nail down the precise scope of the implementation. Determine what you plan to change and what you will not change.
-
Check the test coverage for this area in the codebase. If the test coverage is insufficient, ask the user what their testing plan is.
-
Break the implementation down into a plan composed 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
The problem the developer faces, described from the developer's perspective.
Solution
The solution to the problem, described from the developer's perspective.
Commits
A long and detailed implementation plan. Write the plan in plain English, breaking the implementation down into the smallest possible commits. Each commit should leave the codebase in a working state.
Decision Document
A list of implementation decisions that have been made. It may include:
- The modules to be built/modified
- The interfaces within these modules that will 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 makes 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
A description of what this refactoring does not involve.
Additional Notes (Optional)
Any further notes about the refactoring.