refactor
Use when updating requirements, design, or tasks after implementation learnings.
- License 许可
- MIT
- 最近更新
- 2026-08-19
- Stars
- ★ 4
- Forks
- 0
01 前言 Front Matter
- name
- refactor
- description
- Use when updating requirements, design, or tasks after implementation learnings.
- allowed-tools
- Read Write Edit Agent Bash AskUserQuestion
- argument-hint
- [spec-name] [--file=requirements|design|tasks]
- disable-model-invocation
- true
03 SKILL.md 正文
Refactor Spec
Update specification files after execution. You are a coordinator, not a writer -- delegate actual updates to the refactor-specialist subagent.
Coordinator Checklist
Complete these coordination steps in order; do not create user-facing implementation tasks from this checklist:
- Gather context -- resolve spec, read existing files and learnings
- Determine scope -- which files to refactor (from --file flag or all)
- File-by-file review -- section-by-section review with user for each file
- Delegate updates -- dispatch refactor-specialist for each file
- Handle cascades -- propagate changes downstream if needed
- Finalize -- update state, commit
Step 1: Gather Context
- Resolve the target spec with the runtime CLI:
- With an argument:
curdx-flow specs resolve "$ARGUMENTS" - Without an argument:
curdx-flow specs resolve
- With an argument:
- If no active spec, error: "No active spec. Run /curdx-flow:new <name> first."
- Use the returned
path/fsPathas the resolved spec directory and check it exists - Read
.curdx-state.jsonif exists - Identify which spec files exist:
requirements.md,design.md,tasks.md - If no spec files exist, error: "No spec files found. Run /curdx-flow:start first."
- Read
.progress.mdto understand implementation learnings
Step 2: Determine Scope & Present Overview
Check $ARGUMENTS for --file= flag:
--file=requirements: Only requirements.md--file=design: Only design.md--file=tasks: Only tasks.md- No flag: All files in order (requirements -> design -> tasks)
Present overview to user:
Spec: $spec
Files to review:
- requirements.md: [exists/missing] - [brief summary: X user stories, Y requirements]
- design.md: [exists/missing] - [brief summary: X components, Y decisions]
- tasks.md: [exists/missing] - [brief summary: X tasks, Y completed]
Implementation learnings from .progress.md:
- [Key learning 1]
- [Key learning 2]
Step 3: File-by-File Review
Process files in order: requirements -> design -> tasks. For each file in scope:
Ask About This File
Use AskUserQuestion: "Do you want to update [filename]?" with options:
- Yes, review sections -- go through section by section
- Skip this file -- move to next
- Major rewrite needed -- note for specialist
If "Skip", move to next file.
Section-by-Section Review
For each major section in the file, use AskUserQuestion to determine if it needs changes:
Requirements sections: Goal, User Stories (keep/add/modify/remove), Functional Requirements, Non-Functional Requirements, Out of Scope, Dependencies, Success Criteria.
Design sections: Architecture overview (keep/update diagram/major restructure), Components (keep/add/modify/remove), Data Flow, Technical Decisions, File Structure, Interfaces, Error Handling, Test Strategy.
Tasks sections: Completed tasks (all good/some need rework), New tasks (none/add), Phase Structure, Task Dependencies, Verification Steps.
Gather Update Details
For sections marked for update, ask: "What specific changes for [section]?" with options:
- I'll describe changes -- wait for text input
- Based on learnings -- use implementation learnings to guide updates
- Remove outdated parts -- clean up obsolete content
Step 4: Delegate to Specialist
<mandatory>
Use Agent(agent_type: refactor-specialist) for each file update.
Include in prompt:
- Full current file content
- Relevant
.progress.mdlearnings - Sections to update with user's specific instructions
- Guidelines: minimal focused changes, preserve valuable content, update cross-references
Specialist reports: REFACTOR_COMPLETE: [filename] and CASCADE_NEEDED: [downstream files] with reasons.
</mandatory>
Step 5: Handle Cascade Updates
After specialist completes, check for CASCADE_NEEDED:
If requirements changed and cascade includes design: Ask user "Requirements changed. Update design.md to match?" (Yes / Skip / Regenerate)
If design changed and cascade includes tasks: Ask user "Design changed. Update tasks.md to match?" (Yes / Skip / Regenerate)
If "Regenerate" selected, delegate to the original agent (architect-reviewer for design, task-planner for tasks) instead of refactor-specialist.
Step 6: Finalize
Update State
- Update
.curdx-state.jsonviacurdx-flow state mergewith'{"completed":false,"awaitingApproval":true,"$unset":["completedAt"]}'(per design §11) -- keep existing phase, resettaskIndexto 0 if tasks modified - Append refactoring summary to
.progress.md
Commit (if enabled)
Read commitSpec from .curdx-state.json. If true:
git add ./specs/$spec/
git commit -m "spec($spec): refactor specifications"
git push -u origin $(git branch --show-current)
If commit or push fails, display warning but continue.
Output
Refactoring complete for '$spec'.
Updated files:
- [list of files updated with brief change summary]
Cascade updates:
- [any cascade updates made]
[If commitSpec: "Changes committed and pushed."]
Next steps:
- Review updated spec files
- Run /curdx-flow:implement to continue execution (if tasks were modified)
04 同仓库更多 Skills
help
Fixture help skill
verification-before-completion
Use when checking fixes, phase exits, completion evidence, or mock-heavy tests before claiming success.
triage
Use when a large feature should be decomposed into dependency-aware specs.
tasks
Use when a spec has design.md and needs implementation tasks.
switch
Use when changing the active spec by name or path.
status
Use when inspecting curdx-flow specs, active state, progress, or index status.