Edit Spec.prompt

---
agent: agent
description: "Modify existing feature specifications with change tracking"
---

# You are executing the Edit Spec command.

You MUST follow these instructions exactly. Do NOT describe this process — execute it.

Your mission: Modify an existing feature specification safely and precisely using a contract-first approach. Establish complete alignment on the modifications before updating any files.

### Phase 1: Specification Loading & Change Contract (No File Modifications)

#### Step 1.1: Specification Discovery & Loading

**Locate Target Specification:**
1. **SCAN** `.code-captain/specs/` directory for all existing specifications
2. **IF** spec-identifier provided:
   - **SEARCH** for exact folder name match: `[DATE]-{spec-identifier}`
   - **SEARCH** for partial name match in folder names
   - **SEARCH** for identifier in spec.md titles/content
3. **IF** spec-identifier is "latest":
   - **FIND** most recent folder by date prefix
4. **IF** no spec-identifier provided:
   - **LIST** all available specifications for user selection
5. **IF** multiple matches found:
   - **PRESENT** options for user disambiguation

**Load Current State:**
1. **READ** primary specification file (`spec.md`)
2. **READ** user stories overview (`user-stories/README.md`)
3. **READ** all individual story files in `user-stories/` directory
4. **READ** all sub-specifications in `sub-specs/` directory
5. **SCAN** codebase for any implementation progress related to this spec
6. **OUTPUT:** Current specification summary with story status (no modifications yet)

#### Step 1.2: Impact Analysis & Change Assessment

**Internal Process (not shown to user):**
- Analyze proposed changes against current specification
- Identify affected individual story files and task groups
- Note potential ripple effects on:
  - Existing implementation (if any)
  - Specific user story files in user-stories/ folder
  - Story dependencies and sequencing
  - Technical architecture
  - Acceptance criteria within affected stories
  - Project timelines and story priorities
- Catalog modification domains:
  - Scope changes (adding/removing/splitting stories)
  - Technical approach modifications
  - Individual story adjustments or combinations
  - Task group reorganization (keeping 5-7 tasks max)
  - Performance/security requirement changes
  - Integration point modifications
  - Success criteria updates within stories

#### Step 1.3: Change Clarification Loop

**Rules:**
- Ask ONE focused question at a time about the proposed changes
- After each answer, re-analyze the existing spec and codebase for new context
- Continue until reaching 95% confidence on modification impact
- Each question should target the highest-impact unknown or risk
- **Never declare "final question"** - let the conversation flow naturally
- **Challenge changes that could break existing functionality or create technical debt**

**Critical Analysis Responsibility:**
- If proposed changes conflict with existing implementation, explain impact and suggest migration strategies
- If scope changes affect other dependent specifications, identify and discuss dependencies
- If modifications introduce technical complexity, assess if benefits justify the cost
- If changes affect user stories that may already be in progress, surface timeline implications
- If proposed changes contradict original business value, question the modification rationale

**Risk Assessment Categories:**
- **Breaking Changes**: Will this break existing functionality?
- **Implementation Impact**: How much existing work needs to be modified/discarded?
- **Architecture Consistency**: Do changes align with existing patterns?
- **Scope Creep**: Are we expanding beyond the original contract boundaries?
- **Business Value**: Do changes improve or compromise original user value?

#### Step 1.4: Modification Contract Proposal

When confident about changes, present a modification contract:

**Format:**