change-management

name	change-management
description	Structured change management process that gathers requirements via questions, produces a formal specification, and gets approval before implementation. Use when the user invokes /change-management or /spec, or asks to "write a spec", "create a specification", "plan a change", or wants a structured approval process before making changes. Triggers on demand only.

Change Management

Enforce a structured discover-spec-approve-act workflow before implementing changes. Act as Project Manager throughout.

Workflow

Step 1: Discovery

Use AskUserQuestion to gather requirements. Focus questions on filling the spec template sections:

• Role — What role should Claude take when executing this work?
• Context — What is the background and motivation?
• Goal — What specific outcome is desired?
• Inputs — What information, files, or resources are needed?
• Outputs — What deliverables should be produced?
• Done — What does "done" look like? Acceptance criteria.
• Constraints — What limitations, rules, or boundaries apply?

Ask focused questions — gather what's needed without over-asking. Batch related questions together (2-4 per round). Iterate until all sections can be meaningfully filled.

Step 2: Write the Spec

1. Read the spec template from assets/spec-template.md (bundled with this skill).
2. Fill all sections with gathered information.
3. Determine the spec file name: YYYY-MM-DD-task-name-spec.md using today's date and a kebab-case task name.
4. Ensure docs/specs/ directory exists in the project (create if needed).
5. Write the completed spec to docs/specs/YYYY-MM-DD-task-name-spec.md.

Step 3: Approval

Present the completed spec to the user and ask for explicit approval using AskUserQuestion:

• Approved — Proceed to Step 4.
• Needs changes — Gather feedback, revise the spec, and ask again.

Do not proceed past this step without approval.

Step 4: Post-Approval

Ask the user using AskUserQuestion:

• Implement now — Claude proceeds to execute the spec.
• Hand off — Stop here; the user will implement.

Step 5: Versioning (as needed)

If scope changes after approval and implementation has begun:

1. Keep the original spec file intact.
2. Create a new version: YYYY-MM-DD-task-name-spec-v2.md (increment for subsequent revisions).
3. Note what changed from the previous version at the top of the new spec.
4. Get approval on the revised spec before continuing.

Key Rules

• Never implement before spec approval.
• All spec template sections must be populated.
• Use AskUserQuestion for all user interactions during the workflow.
• Date in filenames uses the current date, not a future or past date.
• Keep specs self-contained — a reader should understand the full scope without external context.