You are helping the user modify an existing spec-driven change artifact.
Prerequisites
The .spec-driven/ directory must exist at the project root. Before proceeding, verify:
ls .spec-driven/If this fails, the project is not initialized. Run /spec-driven-init first.
Steps
- Select the change — run
node {{SKILL_DIR}}/scripts/spec-driven.js modifyto list active changes. Ask the user which change they want to modify. If they already specified one, use it. - Understand the requested change — ask the user what changes they want to make if not already specified. Focus on the *content* of the change, not which files to edit.
- Determine affected artifacts — based on the change request, decide which files need modification. A single change may affect multiple artifacts: Read all relevant artifact files before making changes.
- proposal.md — scope, goals, or requirements changes - specs/ — delta specs describing observable behavior changes, mirroring .spec-driven/specs/ by file path - design.md — implementation approach or architecture decisions - tasks.md — task breakdown, additions, or removals - questions.md — new questions or resolved answers - If the request affects specs/, also read .spec-driven/config.yaml, .spec-driven/specs/INDEX.md, and each relevant main spec file before editing.
- Apply modifications:
- For proposal.md and design.md: edit freely - For specs/: preserve the delta spec format. Keep the matching file path under changes/<name>/specs/, use ## ADDED Requirements, ## MODIFIED Requirements, and ## REMOVED Requirements section markers as needed, and keep ### Requirement: headings intact. Write observable behavior only — do not turn specs into implementation notes, architecture details, or API design docs. - For tasks.md: preserve all - [x] completed task state — only add, remove, or reword - [] incomplete tasks unless the user explicitly asks to change completed ones - For questions.md: add new questions under ## Open, or move questions to ## Resolved with an A: answer line when the human provides answers
- Show a summary — briefly describe what changed across all modified files and confirm with the user.
Rules
- Never uncheck a completed task (
- [x]) unless the user explicitly asks - Don't restructure a file wholesale when a targeted edit is sufficient
- Keep the same heading structure unless changing structure is the explicit goal
- One change request may span multiple files — edit all relevant artifacts together
- When editing
specs/, follow.spec-driven/config.yamlrules and keep each delta file aligned with the corresponding main spec file