easysdd-refactor-fastforward
When a user says "optimize this function" and the changes are obviously minor (e.g., a single function is lengthened, a composable is extracted from a component, a section of duplicate code is merged), following the full three-stage workflow is overkill. Fastforward does one thing: allows AI to modify directly as usual, but adheres to the bottom line of refactor - behavioral equivalence, using classic methods, and self-validation via running tests.
This skill is extremely lightweight. No scan checklist, no design doc, no checklist - just a one-sentence report after modification.
3 Hard Entry Checks (Exit to Full Workflow If Any Fails)
Ask yourself 3 questions before starting; exit to the full
workflow if any fails:
- Is behavior truly unchanged? If the user's description includes "also support X / change to Y" - this is a behavioral change, not a refactor. Ask the user to split it into a feature/issue workflow.
- Is the scope truly small? If changes involve more than 1 file, over 100 lines in a single file, or more than 3 expected modification points - exit to the full workflow.
- Are there tests for self-validation? The target code has covering tests (unit tests / integration tests / type checks can catch issues) - exit to the full workflow if no tests exist, or create a characterization test first before returning.
The full scan phase of entry checks has 7 items, which are compressed to the 3 most critical ones here - the remaining 4 items (cross-module, full scenarios, generated code, incomplete scan) are already implicitly excluded in "Is the scope truly small?".
Use Classic Methods, No Improvisation
Fastforward doesn't require reading the full method library, but must adhere to: "Every change must correspond to a classic refactoring method". If AI can't identify which classic method (e.g., Extract Function / Memoization / Guard Clauses / ...) the modification belongs to, it means this isn't a simple refactor - exit to the full workflow to check the method library.
Common methods (covering 80% of fastforward scenarios):
- Extract Function: A cohesive, namable fragment of >5 lines → extract into an independent function
- Extract Variable: Complex expressions → name as variables or queries
- Guard Clauses: Multi-layer nested if checks at the start → return early to flatten structure
- Decompose Conditional: Complex if conditions → name as boolean functions
- Extract Composable / Hook: Encapsulated state + side effects in components → extract into independent composable/hook
- Memoization: Repeated calculations → use computed / useMemo
- Cancellation: Missing cleanup for side effects → add onUnmounted / useEffect return
If the intended action isn't in these methods or isn't an out-of-the-box classic method (e.g., involving Parallel Change / Strangler Fig / layered correction) - exit to the full workflow.
Workflow
1. One-Time Alignment
After receiving the request, reply to the user in one sentence: "I plan to use {method name}, modify {specific file/function}, with {N} change points, expected impact {scope}. Confirm to start."
Proceed to the next step if the user confirms. If the user says "also need to change X" - evaluate whether X violates the 3 entry checks; if yes, exit to the full workflow.
2. Modify
Modify following the steps of classic methods. No design doc or checklist is produced. Code changes are directly committed.
3. Self-Validation
- Run tests (unit / integration / type checks / lint)
- Use grep to verify old references are cleaned up (if Extract Function / Inline Function is performed)
- If frontend state logic is modified, run type checks + existing tests; no UI visual verification - UI visual checks should not use fastforward
4. One-Sentence Report
Format:
✓ Completed. Method: {method name}. Changes: {file path: line number range}. Validation: {tests run / pass status}.
If there are deviations or additional changes are discovered during application - stop and ask the user, do not improvise.
Output Files
By default,
do not create a directory under - the value of fastforward lies in not leaving archives.
Exception: If the user explicitly says "keep a record of this small refactor" - create
easysdd/refactors/{YYYY-MM-DD}-{slug}/{slug}-refactor-note.md
, containing the above report plus a section on "what was done / why". No design doc or checklist is written.
When to Exit Fastforward
Stop and inform the user "It's more complex than expected, suggest switching back to the full refactor workflow" if any of the following occurs during modification:
- Change points increase from 3 to 5+
- More than 1 file needs to be modified
- An action not in the common method list emerges
- No tests cover the changes
- The user adds "also change X" which introduces behavioral changes
- AI self-validation fails after modification (tests fail) and cannot be fixed with simple adjustments
Switchback method: Trigger
and start from the scan phase. The modified part can either be committed or restored to a clean state with
, depending on the user's decision.
What Not to Do
- Do not write scan checklists / design docs / checklists - writing them violates the purpose of fastforward
- Do not modify across multiple files - cross-file changes are not "small refactors"
- Do not make changes requiring HUMAN visual verification - frontend rendering / interaction / performance perception that requires human review should use the full workflow
- Do not touch public interfaces - modifying public interfaces requires Parallel Change, which cannot be done via fastforward
Common Pitfalls
- Defining "small" too broadly: The user says "small refactor" but actually needs to modify 3 files - AI should honestly say "This isn't small, suggest using the full workflow"
- Skipping the 3 entry checks before starting: The value of this skill lies in these 3 checks
- Cutting corners on self-validation: Only running type checks without unit tests, or not using grep to check old references at all
- Improvising during modification: "Fixing" neighboring code on the fly - the scope of fastforward is locked at the time of confirmation and cannot be expanded later
- Disguising behavioral changes as refactors: Adding new parameters, changing return value formats - these are behavioral changes and cannot be disguised
Related
easysdd-refactor/SKILL.md
easysdd-refactor/reference/methods.md
- - Root skill of the easysdd family