# Noelserdna Claude Plugin Sdd Req Change

> Skill: sdd-req-change — Requirements Change Manager & Pipeline Cascade Trigger

- Skill: `tomevault-io/noelserdna-claude-plugin-sdd-req-change` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/noelserdna-claude-plugin-sdd-req-change`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/noelserdna-claude-plugin-sdd-req-change/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/noelserdna-claude-plugin-sdd-req-change

---


# Skill: sdd-req-change — Requirements Change Manager & Pipeline Cascade Trigger

> **Version:** 2.0.0
> **Pipeline position:** Lateral — can be invoked anytime after specs exist; triggers downstream cascade
> **Complementary to:** `sdd-spec-auditor` Mode Fix (audit-driven fixes)
> **SWEBOK v4 alignment:** Chapter 01 (Software Requirements) — Change Management, Traceability, Conflict Resolution; Chapter 05 (Software Maintenance) — Maintenance Classification, Impact Analysis, Feature Retirement

---

## 1. Purpose & Scope

Manages the full lifecycle of requirements changes: **ADD**, **MODIFY**, and **DEPRECATE** requirements, propagating changes bidirectionally through all specification documents. Classifies changes using **ISO 14764 maintenance categories** (corrective, adaptive, perfective, preventive) and optionally triggers **downstream pipeline cascade** to re-plan, re-task, and re-implement affected FASEs. Ensures zero gaps between requirements and specifications after every change.

### What This Skill Does

1. Receives a change request (text free or structured `CHANGE-REQUEST.md`)
2. **Classifies** the change by maintenance category (ISO 14764) and urgency
3. Performs **impact analysis** across the full traceability chain (REQ ↔ UC ↔ WF ↔ API ↔ BDD ↔ INV ↔ ADR ↔ RN)
4. **Asks the user** every question needed with options and recommendations to eliminate ambiguities
5. Plans all changes with before/after for every affected document
6. Executes changes **atomically** across all specs and requirements
7. Runs a **focused alignment audit** on affected documents
8. Generates a **Change Report** with full context for planning, tasks, and implementation
9. **Triggers pipeline cascade** (Phase 9) — updates `pipeline-state.json` and optionally invokes downstream skills

### What This Skill Does NOT Do

- Does NOT generate implementation code (delegates to `sdd-task-implementer` via cascade)
- Does NOT create implementation plans from scratch (delegates to `sdd-plan-architect` via cascade)
- Does NOT create tasks from scratch (delegates to `sdd-task-generator` via cascade)
- Does NOT run full cross-document audits (use `sdd-spec-auditor`)
- Does NOT derive requirements from scratch (use `sdd-requirements-engineer`)
- Does NOT assume behavior not backed by user answers
- Does NOT modify files outside `spec/`, `changes/`, `requirements/`, and `pipeline-state.json`
- Does NOT handle runtime operational maintenance (monitoring, incident response, runtime rollback)
- Does NOT estimate effort in person-hours (project management concern, Ch07)

### Core Principle

> "Every requirement change must propagate completely through the specification chain AND trigger downstream pipeline re-execution. No orphan specs. No orphan requirements. No gaps. No stale plans. No ambiguities introduced."

Aligned with SWEBOK v4 Ch01 (Software Requirements), Change Management and Ch05 (Software Maintenance): the skill that initiates changes owns the cascade through the full pipeline.

---

## 2. Invocation Modes

```bash
/sdd-req-change                                    # Interactive mode (text free from user)
/sdd-req-change --file changes/CHANGE-REQUEST.md   # From structured file
/sdd-req-change --dry-run                          # Plan only, no execution (stops after Phase 4)
/sdd-req-change --batch                            # Auto-apply recommended solutions (skip Phase 5 interactive)
/sdd-req-change --cascade=auto                     # Full pipeline cascade after changes (Phase 9)
/sdd-req-change --cascade=manual                   # (default) Advisory cascade output only
/sdd-req-change --cascade=dry-run                  # Preview cascade scope without executing
/sdd-req-change --cascade=plan-only                # Cascade through planning but not implementation
/sdd-req-change --maintenance=TYPE                 # Pre-classify as corrective/adaptive/perfective/preventive
```

### Cascade Modes

| Mode | Behavior | When to Use |
|------|----------|-------------|
| `--cascade=manual` (default) | Update `pipeline-state.json`, print recommended commands | User wants control over each step |
| `--cascade=auto` | Invoke downstream skills in sequence after Phase 8 | Full pipeline automation |
| `--cascade=dry-run` | Compute invalidation scope but change nothing | Impact preview before committing |
| `--cascade=plan-only` | Cascade through planning skills, stop before implementation | Updated plans + tasks without code changes |

### Input Sources

| Source | Description | When to Use |
|--------|-------------|-------------|
| **Text free** | User describes change in natural language | Quick changes, exploratory |
| **CHANGE-REQUEST.md** | Structured file with predefined format | Planned changes, batch processing |
| **Both** | File provides base, user adds context | Complex changes needing discussion |

---

## 3. Phases

### Phase 0: Inventory & Context Loading

**Goal:** Build complete understanding of current spec state.

**Steps:**
1. Glob all `.md` files under `spec/` — build manifest with IDs, types, versions
2. Read `spec/requirements/REQUIREMENTS.md` — extract all REQ IDs, categories, traceability
3. Read `spec/domain/01-GLOSSARY.md` — load ubiquitous language (MANDATORY reference)
4. Read `spec/CLARIFICATIONS.md` — load business rules (RN-*)
5. Read `spec/CHANGELOG.md` — identify current spec version
6. Read `audits/AUDIT-BASELINE.md` — know current audit state
7. Read `pipeline-state.json` — load current pipeline state (create default if absent)
8. Scan `changes/` for existing DRAFT/REVIEWED deltas — warn if unapplied deltas exist
9. If `--file` provided: Read and parse `CHANGE-REQUEST.md`
10. Build internal index:
    - `REQ-ID → [source specs]` (forward traceability)
    - `spec-file → [REQ-IDs]` (backward traceability)
    - `REQ-ID → [dependent REQ-IDs]` (dependency graph)
    - `stage → status` (pipeline staleness map from pipeline-state.json)

**Readiness Gates:**

| Gate | Check | Action if Fails |
|------|-------|-----------------|
| G1: Specs exist | `spec/domain/`, `spec/use-cases/`, `spec/contracts/` present | STOP: "Run sdd-specifications-engineer first" |
| G2: REQUIREMENTS.md exists | `spec/requirements/REQUIREMENTS.md` present | STOP: "Run sdd-requirements-engineer first" |
| G3: Glossary exists | `spec/domain/01-GLOSSARY.md` present | STOP: "Cannot proceed without ubiquitous language" |
| G4: Audit-clean (warning only) | `AUDIT-BASELINE.md` has 0 open findings | WARN: "Specs have open audit findings. Changes may conflict." |
| G5: Pipeline state (info only) | `pipeline-state.json` exists and is readable | INFO: "No pipeline state found. Will create after changes." |

**Output:** Internal manifest (not written to disk). Console summary:

```
Inventory Complete
==================
Spec files:        {N}
Requirements:      {N} (FUN:{N} NFR:{N} OPS:{N} REG:{N} DER:{N})
Current version:   v{X.Y.Z}
Audit state:       {clean | N open findings}
Pipeline state:    {fresh | plan exists (FASE 1-N) | tasks exist (FASE 1-N) | implementation started}
Cascade impact:    {N stages would be invalidated}
Change source:     {text free | CHANGE-REQUEST.md | both}
Pending deltas:    {N DRAFT | N REVIEWED | none}
```

---

### Phase 1: Change Request Intake & Classification

**Goal:** Parse, classify, and structure each change request.

**Steps:**
1. Parse user input (natural language) and/or structured file
2. For each change, classify:

| Classification | Signal | Example |
|----------------|--------|---------|
| **ADD** | New capability, feature, constraint not in current REQs | "Necesitamos soporte para bulk export de CVs" |
| **MODIFY** | Change to existing REQ behavior, threshold, scope | "El timeout de extraccion debe ser 480s en vez de 360s" |
| **DEPRECATE** | Remove or sunset existing REQ | "Ya no necesitamos el matching por percentil" |

3. For each change, classify by **ISO 14764 Maintenance Category**:

   | Classification | Sub-classification | Signal |
   |---------------|-------------------|--------|
   | ADD | Perfective | New capability |
   | ADD | Adaptive | New external integration, dependency addition |
   | MODIFY | Corrective | Bug fix, incorrect behavior |
   | MODIFY | Perfective | Feature enhancement |
   | MODIFY | Adaptive | External API change, dependency update, platform migration |
   | MODIFY | Preventive | Tech debt reduction, code health improvement |
   | DEPRECATE | Perfective | Feature simplification |
   | DEPRECATE | Adaptive | External dependency removal |
   | DEPRECATE | Preventive | Removing tech debt source |

   > If `--maintenance=TYPE` was provided, use it directly. Otherwise, auto-detect from change description.
   > See `references/maintenance-classification.md` for the full decision tree.

   **Corrective** changes additionally get urgency-based priority:

   | Urgency | Criteria | Response |
   |---------|----------|----------|
   | P0 (Critical) | Data loss risk, core feature completely broken | Immediate |
   | P1 (High) | Major feature broken, no workaround | Same day |
   | P2 (Medium) | Feature broken, workaround exists | Next sprint |
   | P3 (Low) | Minor defect, cosmetic issue | Backlog |

4. For each change, identify:
   - **Category** (FUN/NFR/OPS/REG/DER)
   - **Subcategory** (EXT/CVA/MAT/GDP/USR/ORG/OFF/CAN/SEL/DSH/SYS/PERF/SEC/etc.)
   - **Affected existing REQs** (if MODIFY or DEPRECATE)
   - **Related existing REQs** (that may need updating due to dependency)
   - **Priority estimate** (Must/Should/Could)
   - **Stability estimate** (Stable/Moderate/Volatile)
   - **Maintenance category** (Corrective/Adaptive/Perfective/Preventive)

5. Apply SWEBOK 5-Whys technique for unclear requests:
   - Ask "Why is this needed?" recursively (2-3 cycles)
   - Converge on the true requirement vs. proposed solution
   - Goal: identify the stakeholder need, not the implementation

6. Generate structured Change Request Summary:

```markdown
## Change Request Summary

| # | Type | Maintenance | Category | Subcategory | Description | Affected REQs | Complexity |
|---|------|-------------|----------|-------------|-------------|----------------|-----------|
| CR-001 | ADD | Perfective | FUN | EXT | Bulk PDF extraction | - | Medium |
| CR-002 | MODIFY | Corrective (P2) | NFR | PERF | Increase timeout to 480s | REQ-PERF-001 | Low |
| CR-003 | DEPRECATE | Preventive | FUN | CAN | Remove percentile feature | REQ-CAN-011 | High |
```

**Present to user for confirmation before proceeding.**

---

### Phase 2: Impact Analysis

**Goal:** Identify ALL documents affected by each change. SWEBOK v4 Ch01 (Software Requirements), Traceability: *"Establish footprint for volume of work to incorporate change."*

**Steps per change request:**

1. **Direct Impact** — Documents that MUST change:

| Change Type | Direct Impact Sources |
|-------------|----------------------|
| ADD REQ | REQUIREMENTS.md, target UC(s), target contract(s), target BDD(s), possibly domain model, possibly new INV(s) |
| MODIFY REQ | REQUIREMENTS.md, all docs in REQ traceability chain |
| DEPRECATE REQ | REQUIREMENTS.md, all docs in REQ traceability chain, dependent REQs |

2. **Indirect Impact** — Documents that SHOULD be reviewed:

| Change Type | Indirect Impact |
|-------------|-----------------|
| ADD REQ | Related UCs (shared entities), CLARIFICATIONS.md, FASE files referencing related specs |
| MODIFY REQ | Downstream REQs depending on modified behavior, related BDD scenarios |
| DEPRECATE REQ | REQs that reference deprecated REQ, BDD tests validating deprecated behavior |

3. **Trace the full chain per affected REQ:**

```
REQ-{id} → UC-{nnn} → WF-{nnn} → API-{module} → BDD-{feature} → INV-{area}-{nnn} → ADR-{nnn} → RN-{nnn}
```

4. **Conflict Detection:**
   - Check if change contradicts existing INVs
   - Check if change conflicts with existing ADR decisions
   - Check if change breaks existing BDD scenarios
   - Check if change violates CLARIFICATIONS business rules

5. **Complexity Rating:**

| Complexity | Criteria |
|------------|----------|
| **Low** | 1-3 documents affected, no conflicts, no new entities |
| **Medium** | 4-8 documents affected, minor conflicts resolvable, possibly new INVs |
| **High** | 9-15 documents affected, ADR decisions needed, new entities or states |
| **Very High** | 16+ documents affected, cross-domain impact, breaking changes |

6. **Generate Impact Matrix:**

```markdown
## Impact Matrix — CR-{NNN}

### Direct Impact (MUST change)
| Document | Section | Change Type | Description |
|----------|---------|-------------|-------------|
| requirements/REQUIREMENTS.md | §4.1 | ADD | New REQ-EXT-{NNN} |
| use-cases/UC-001.md | Flujo Principal | MODIFY | Add bulk step |
| contracts/API-pdf-reader.md | POST /extract | MODIFY | Add batch param |
| tests/BDD-extraction.md | Scenarios | ADD | New bulk scenario |

### Indirect Impact (SHOULD review)
| Document | Reason |
|----------|--------|
| domain/02-ENTITIES.md | May need BulkExtraction entity |
| nfr/LIMITS.md | May need bulk rate limits |

### Conflicts Detected
| Conflict | Severity | Resolution Needed |
|----------|----------|-------------------|
| INV-EXT-003 limits single PDF | Medium | Clarify: bulk bypasses or respects limit? |

### Complexity: {Low | Medium | High | Very High}
### Estimated documents to modify: {N}

### Regression Risk Matrix

| Area | Risk Level | Existing Tests | Mitigation |
|------|-----------|----------------|------------|
| {feature area} | {Low/Medium/High} | {BDD-xxx: N scenarios} | {existing coverage sufficient / needs new scenarios} |

### Downstream Pipeline Impact

| Artifact | Current Status | Action Needed |
|----------|---------------|---------------|
| plan/fases/FASE-{N}.md | {Fresh/Stale} | {Regenerate / No change} |
| task/TASK-FASE-{N}.md | {Fresh/Stale} | {Regenerate after plan update / No change} |
| src/ (FASE-{N} code) | {Fresh/Stale} | {New tasks needed / No change} |

### Code & Commit Impact

| Artifact | Commits | Last Commit | Files Affected |
|----------|---------|-------------|----------------|
| UC-002 | abc1234, def5678 | 2026-02-27 | src/auth/middleware.ts, src/auth/jwt.ts |
| INV-SYS-001 | ghi9012 | 2026-02-26 | src/middleware/tenant.ts |

Blast radius: {N} commits, {M} source files, {K} test files
```

7. **Commit Impact Analysis** (if git available):

   Check git availability first:
   ```bash
   git rev-parse --is-inside-work-tree 2>/dev/null
   ```

   If git is available, for each artifact in the Direct Impact list:
   ```bash
   git log --all --oneline --grep='Refs:.*{ARTIFACT-ID}'
   ```

   Build a commit impact map:
   - **Artifact → commits**: Which commits reference this artifact via `Refs:` trailers
   - **Commits → files**: Which source files were touched by those commits (`git diff-tree --no-commit-id --name-only -r {SHA}`)
   - **Last commit date**: When was the most recent commit for this artifact

   Estimate blast radius:
   - Total unique commits referencing affected artifacts
   - Total unique source files touched by those commits
   - Total unique test files touched by those commits

   **Graceful degradation**: If git is not available, skip this step and note "Git not available — commit impact analysis skipped" in the Impact Matrix.

8. **Code Intelligence Impact Analysis** (if SDD MCP server available):

   IF the SDD MCP server is available (tool `sdd_impact` exists):
   ```
   result = sdd_impact({ artifact_id: "{ARTIFACT-ID}", direction: "downstream", maxDepth: 3 })
   ```

   Classify by depth:
   - **d=1 (WILL_BREAK)**: Direct implementors — these symbols/files implement the artifact
   - **d=2 (LIKELY_AFFECTED)**: Callers of implementors — functions that call the affected code
   - **d=3 (MAY_NEED_REVIEW)**: Transitive callers — indirect dependents needing testing

   IF `codeIntelligence` data available in the graph (from `/sdd-code-index`):
   - Enrich the Impact Matrix with symbol-level detail:

   ```markdown
   | Symbol | File | Depth | Callers | Risk |
   |--------|------|-------|---------|------|
   | validateUser() | src/auth/validator.ts | d=1 | 3 direct | HIGH |
   | handleLogin() | src/routes/auth.ts | d=2 | 2 direct | MEDIUM |
   | authMiddleware() | src/middleware/auth.ts | d=3 | 5 direct | LOW |
   ```

   ELSE:
   - Fallback to git-based analysis from Step 7 (commit blast radius only)

   **Graceful degradation**: If MCP server not available, rely entirely on Step 7's git-based analysis.

---

### Phase 3: Clarification & Decision

**Goal:** Eliminate ALL ambiguities before planning changes. Every gap gets a question with options and a recommendation.

**Methodology:** SWEBOK v4 §3.1 (7 desirable properties) + §3.4 (Conflict Resolution)

**Steps:**

1. For each change request, evaluate against 7 SWEBOK properties:

| Property | Check | Question if Fails |
|----------|-------|-------------------|
| **Unambiguous** | Interpretable in only one way? | "This could mean X or Y. Which interpretation?" |
| **Testable** | Can be verified with concrete criteria? | "How would we verify this? Propose acceptance criteria." |
| **Binding** | Stakeholder confirms it's essential? | "Is this Must Have, Should Have, or Could Have?" |
| **Atomic** | Represents single decision? | "This seems to include multiple changes. Split into CR-{A} and CR-{B}?" |
| **True** | Represents actual stakeholder need? | "Is the real need X (capability) or Y (implementation)?" |
| **Stakeholder vocabulary** | Uses ubiquitous language? | "The term '{X}' isn't in our glossary. Did you mean '{Y}'?" |
| **Acceptable** | No conflicts with existing decisions? | "This conflicts with ADR-{N}. Override decision or adapt requirement?" |

2. For each ambiguity/gap, present options with recommendation:

```markdown
### Question {N} of {M}: CR-{NNN} — {Short Title}

**Context:** {Why this question matters}
**Conflict/Gap:** {What's unclear or conflicting}

**Options:**
| Option | Description | Pros | Cons | Recommendation |
|--------|-------------|------|------|----------------|
| A | {description} | {pros} | {cons} | **Recommended** |
| B | {description} | {pros} | {cons} | |
| C | {description} | {pros} | {cons} | |

**Why Option A is recommended:** {rationale}
**Impact of each option on specs:** {brief}
```

3. For DEPRECATE changes, additional questions:
   - "What happens to data/behavior currently governed by this requirement?"
   - "Should deprecated REQ be marked as `Won't Have` or physically removed?"
   - "Are there migration steps needed for existing data?"

4. For ADD changes, formulate EARS statement:
   - Present EARS pattern options (Ubiquitous/Event/State/Optional/Unwanted/Complex)
   - Draft EARS statement and ask user to validate
   - Draft acceptance criteria (Gherkin) and ask user to validate

5. For MODIFY changes:
   - Show current EARS statement
   - Show proposed new EARS statement
   - Ask user to validate the delta

6. Collect all answers. Generate Clarification Log:

```markdown
## Clarification Log — Change Request Session

> Date: YYYY-MM-DD
> Change Requests: {N}
> Questions Asked: {N}
> Questions Answered: {N}

### Q-001: {Title}
**Change Request:** CR-{NNN}
**Question:** {text}
**Answer:** {user's choice + rationale}
**Decision:** {what this means for the plan}
**Needs New ADR:** {Yes/No}
**Needs New INV:** {Yes/No}
**Needs New RN:** {Yes/No}
```

---

### Phase 4: Change Plan Generation

**Goal:** Generate a complete, reviewable plan showing every change to every document with before/after.

**Steps:**

1. For each ADD change:
   - Generate new REQ with full template (ID, Category, EARS, Acceptance Criteria, Traceability)
   - Assign next available REQ-{SUB}-{NNN} ID (scan existing IDs to avoid collision)
   - Draft new UC sections / new UC if needed
   - Draft new API contract sections if needed
   - Draft new BDD scenarios if needed
   - Draft new INVs if needed (assign next available INV-{AREA}-{NNN})
   - Draft new ADRs if needed (assign next available ADR-{NNN})
   - Draft new RNs if needed (assign next available RN-{NNN})

2. For each MODIFY change:
   - Show current state (before) of every affected section
   - Show proposed state (after) of every affected section
   - Track cascading changes through traceability chain

3. For each DEPRECATE change:
   - Mark REQ as `Deprecated` with reason and date
   - Identify all spec sections to update/remove
   - Identify migration steps if applicable
   - Show deprecation plan for each affected document
   - For **multi-REQ deprecations** (entire feature removal), generate a **Feature Sunset Plan**:

   ```markdown
   ### Feature Sunset Plan — {Feature Name}

   > Applies to: {list of REQ-IDs being deprecated}
   > Replacement: {replacement feature or "None — clean removal"}

   | Phase | Timeline | Action | Artifacts |
   |-------|----------|--------|-----------|
   | Announce | Sprint N | Mark as deprecated in API docs, add deprecation warnings | API contracts, CHANGELOG |
   | Disable New | Sprint N+1 | Prevent new usage of deprecated feature | API validation rules |
   | Migrate | Sprint N+2..N+4 | Migrate existing users/data to replacement | Migration scripts, communication |
   | Remove | Sprint N+5 | Remove code, specs, and all references | Full spec chain cleanup |

   **Sunset Checklist:**
   - [ ] Replacement feature exists and is stable
   - [ ] Migration path documented
   - [ ] All consumers notified
   - [ ] Data migration tested
   - [ ] Rollback plan exists
   ```

   > See `references/maintenance-classification.md` §7 for the full sunset template.

4. Apply **Atomic Cross-Check Rule** (from `sdd-spec-auditor` Mode Fix):

| If you modify... | Also check and update... |
|-------------------|--------------------------|
| `domain/02-ENTITIES.md` | `03-VALUE-OBJECTS.md`, `04-STATES.md`, `05-INVARIANTS.md`, UCs, contracts |
| `domain/03-VALUE-OBJECTS.md` | `02-ENTITIES.md`, UCs, contracts using those VOs |
| `domain/04-STATES.md` | `05-INVARIANTS.md`, UCs with state transitions, WFs |
| `domain/05-INVARIANTS.md` | UCs enforcing INVs, contracts validating them |
| `contracts/PERMISSIONS-MATRIX.md` | ALL `contracts/API-*.md` |
| `CLARIFICATIONS.md` | UCs referenced by modified RNs |
| `requirements/REQUIREMENTS.md` | Traceability matrix section (§9), Coverage section (§10) |

5. Group changes by document for atomic execution:
   - Each document gets ONE edit pass (no revisiting)
   - Changes ordered: **REQUIREMENTS → domain → invariants → UCs → contracts → tests → NFR → ADRs → CLARIFICATIONS → CHANGELOG**
   - Requirements FIRST: the REQ defines the change; specs propagate it

6. Generate `changes/CHANGE-PLAN-{id}.md`:

```markdown
# Change Plan — {Change Request ID}

> Generated: YYYY-MM-DD
> Source: {text free | CHANGE-REQUEST.md | both}
> Change Requests: {N} (ADD:{N} MODIFY:{N} DEPRECATE:{N})
> Documents affected: {N}
> Estimated complexity: {Low | Medium | High | Very High}
> Spec version: v{current} → v{proposed}

## Summary Table

| # | CR-ID | Type | REQ-ID | Severity | Documents | Breaking |
|---|-------|------|--------|----------|-----------|----------|
| 1 | CR-001 | ADD | REQ-EXT-{new} | - | 5 | No |
| 2 | CR-002 | MODIFY | REQ-PERF-001 | Medium | 3 | No |
| 3 | CR-003 | DEPRECATE | REQ-CAN-011 | High | 8 | Yes |

## Detailed Changes

### CR-001: {Title} [ADD]

#### New Requirement: REQ-{SUB}-{NNN}

| Field | Value |
|-------|-------|
| **ID** | REQ-{SUB}-{NNN} |
| **Category** | {Functional | Non-Functional | Operational | Regulatory | Derived} |
| **Subcategory** | {area} |
| **Priority** | {Must Have | Should Have | Could Have} |
| **Stability** | {Stable | Moderate | Volatile} |
| **Source** | {CR-001, answered questions} |

**EARS Statement:**
> {EARS-formatted requirement}

**Acceptance Criteria:**
```gherkin
Given {precondition}
When {action}
Then {expected result}
```

**Traceability:**
| Direction | Artifact |
|-----------|----------|
| Source | {spec sources to create/modify} |
| Implements | UC-{NNN} |
| Verifies | BDD-{feature} |
| Guarantees | INV-{AREA}-{NNN} |

#### Spec Changes for CR-001

##### 1. {document path}
**Section:** {section name}
**Action:** {ADD section | MODIFY section | REMOVE section}

**Before:**
> {current text, or "(new section)" for ADD}

**After:**
> {proposed text}

**Rationale:** {why this change is needed for CR-001}

##### 2. {next document}
[... repeat for each affected document ...]

#### New Artifacts for CR-001

| Type | ID | Title | Origin |
|------|-----|-------|--------|
| INV | INV-{AREA}-{NNN} | {title} | CR-001, Q-{NNN} |
| ADR | ADR-{NNN} | {title} | CR-001, conflict resolution |

#### Dependencies
{Other CRs that must be applied first, or "None"}

---

### CR-002: {Title} [MODIFY]
[... same structure with before/after for existing REQ ...]

### CR-003: {Title} [DEPRECATE]

#### Deprecated Requirement: REQ-CAN-011

**Current EARS Statement:**
> {current statement}

**Deprecation Reason:** {user's stated reason}
**Migration:** {migration steps if applicable, or "None — clean removal"}

#### Spec Changes for CR-003
[... before/after for each document, showing removals ...]

#### Breaking Changes
| Change | Impact | Migration |
|--------|--------|-----------|
| {description} | {what breaks} | {how to adapt} |

---

## Execution Order

| Step | Document | CRs Applied | Action |
|------|----------|-------------|--------|
| 1 | requirements/REQUIREMENTS.md | CR-001,CR-002,CR-003 | ADD+MODIFY+DEPRECATE REQs |
| 2 | domain/02-ENTITIES.md | CR-001 | Add entity section |
| 3 | domain/05-INVARIANTS.md | CR-001 | Add INV-{AREA}-{NNN} |
| 4 | use-cases/UC-001.md | CR-001, CR-002 | Modify flow |
| ... | ... | ... | ... |

## Version Impact
- Spec version: v{current} → v{proposed}
- REQUIREMENTS.md version: {current} → {proposed}
- Documents with version bumps: {list}
```

**If `--dry-run`: STOP HERE. Present plan and exit.**

---

### Phase 5: User Review & Approval

**Goal:** Get explicit user approval before modifying any file.

**Steps:**

1. Present the Change Plan summary to user
2. Ask workflow mode:

| Mode | Description |
|------|-------------|
| **Batch** (default with `--batch`) | Apply all recommended changes. User already answered all questions in Phase 3. |
| **Interactive** | Present each CR separately. User approves/modifies/rejects per CR. |

3. For **Interactive mode**, per CR:
   - Show full before/after
   - Ask: "Apply this change? (Yes / Modify / Skip)"
   - If Modify: collect new input, re-run Phase 3-4 for that CR only
   - If Skip: mark as skipped in report

4. For **Batch mode**:
   - Show summary table
   - Ask: "Apply all {N} changes? (Yes / Review individually)"

**Approval required before any file modification.**

---

### Phase 6: Change Execution

**Goal:** Apply all approved changes atomically across all documents.

**Execution Order (MANDATORY — requirements-first, then propagate to specs):**

> **IMPORTANT:** Unlike `sdd-spec-auditor` Mode Fix (which goes specs-first because it fixes specs from audit findings),
> this skill is a **Requirements Change Manager**. The requirement is the source of truth for the change.
> Therefore: define the requirement FIRST, then propagate to specifications.

```
1. requirements/REQUIREMENTS.md (ADD/MODIFY/DEPRECATE REQs — the SOURCE of the change)
2. domain/01-GLOSSARY.md       (new terms if needed by the REQ)
3. domain/02-ENTITIES.md       (new/modified entities derived from REQ)
4. domain/03-VALUE-OBJECTS.md  (new/modified VOs derived from REQ)
5. domain/04-STATES.md         (new/modified states derived from REQ)
6. domain/05-INVARIANTS.md     (new INVs derived from REQ)
7. use-cases/UC-*.md           (new/modified UCs implementing REQ)
8. workflows/WF-*.md           (new/modified WFs implementing REQ)
9. contracts/API-*.md           (new/modified contracts implementing REQ)
10. contracts/EVENTS-*.md       (new/modified events)
11. contracts/PERMISSIONS-MATRIX.md (if roles affected)
12. tests/BDD-*.md              (new/modified BDD scenarios verifying REQ)
13. tests/PROPERTIES.md         (if property tests affected)
14. nfr/*.md                    (if NFRs affected)
15. adr/ADR-*.md                (new ADRs for decisions needed by REQ)
16. runbooks/*.md               (if operational procedures affected)
17. CLARIFICATIONS.md           (new RNs derived from REQ)
18. CHANGELOG.md                (record all changes)
```

> **Rationale:** The requirement defines WHAT changes. Specifications define HOW it manifests.
> By writing the requirement first, every subsequent spec edit can reference the authoritative
> REQ-ID, EARS statement, and acceptance criteria as the source of truth for the change.

**Per-document execution rules:**

1. Read current file content
2. Apply ALL changes for that file in single pass
3. Increment document version if file has version header
4. Update any cross-reference tables within the file
5. Verify ubiquitous language compliance (glossary terms only)

**REQUIREMENTS.md specific rules:**

For ADD:
- Insert new REQ in correct subcategory section (maintain alphabetical order within subcategory)
- Update §3 Executive Summary counts
- Update §9 Traceability Matrix
- Update §10 Coverage section
- Update Appendix Statistics

For MODIFY:
- Replace REQ content in-place
- Update traceability if sources changed
- Update §9 if traceability changed

For DEPRECATE:
- Add `**Status:** Deprecated (YYYY-MM-DD) — {reason}` to REQ header
- Move to new §12 "Deprecated Requirements" section (create if doesn't exist)
- Remove from §9 active traceability
- Add to §12 deprecation history
- Update §3 counts (reduce category count, add deprecated count)
- Update Appendix Statistics

**Git Commits:**

One commit per logical change group (1 CR = 1 commit unless very large):

```
feat(specs): add REQ-{SUB}-{NNN} - {brief description}

Change Request: CR-{NNN}
Type: ADD
Documents: {comma-separated list}
Requirements affected: REQ-{SUB}-{NNN}

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
```

```
fix(specs): modify REQ-{SUB}-{NNN} - {brief description}

Change Request: CR-{NNN}
Type: MODIFY
Documents: {comma-separated list}
Requirements affected: REQ-{SUB}-{NNN}
Breaking: {Yes/No}

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
```

```
refactor(specs): deprecate REQ-{SUB}-{NNN} - {brief description}

Change Request: CR-{NNN}
Type: DEPRECATE
Documents: {comma-separated list}
Requirements affected: REQ-{SUB}-{NNN}
Migration: {Yes/No}

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
```

---

### Phase 7: Alignment Audit

**Goal:** Verify that after all changes, requirements and specifications are perfectly aligned. This is a **focused mini-audit** on affected documents only (not a full cross-document audit).

**Audit Checks (8 alignment verifications):**

| # | Check | Description | Severity if Fails |
|---|-------|-------------|-------------------|
| AA-01 | **REQ → Spec Forward Coverage** | Every new/modified REQ has at least one spec source | Critical |
| AA-02 | **Spec → REQ Backward Coverage** | Every modified spec section contributes to at least one REQ | Critical |
| AA-03 | **Traceability Chain Completeness** | Every new/modified REQ has: Source + Implements + Verifies + Guarantees | High |
| AA-04 | **Cross-Reference Validity** | All cross-references in modified documents resolve to existing targets | Critical |
| AA-05 | **Glossary Compliance** | No undefined terms or synonyms introduced in modified sections | High |
| AA-06 | **Contradiction Check** | No modified section contradicts another document section | Critical |
| AA-07 | **EARS Pattern Compliance** | All new/modified REQs use valid EARS pattern | Medium |
| AA-08 | **Acceptance Criteria Testability** | All new/modified Gherkin scenarios are concrete and testable | Medium |

**Additional checks for DEPRECATE:**

| # | Check | Description | Severity if Fails |
|---|-------|-------------|-------------------|
| AA-09 | **No Orphan References** | No remaining document references deprecated REQ | Critical |
| AA-10 | **Dependent REQ Update** | All REQs that depended on deprecated REQ updated or flagged | High |

**Audit Execution:**

1. For each affected document:
   - Re-read the modified file
   - Run checks AA-01 through AA-08 (+ AA-09/AA-10 for deprecations)
   - Record findings

2. Cross-document verification:
   - Verify all new cross-references resolve
   - Verify no broken links created
   - Verify REQUIREMENTS.md traceability matrix consistent with actual spec content

3. Generate audit results:

```markdown
## Alignment Audit Results

> Scope: {N} documents audited (focused on changes only)
> Checks executed: {8 | 10}
> Findings: {N}

| # | Check | Status | Details |
|---|-------|--------|---------|
| AA-01 | REQ → Spec Forward | PASS | All {N} REQs have spec sources |
| AA-02 | Spec → REQ Backward | PASS | All {N} modified sections covered |
| AA-03 | Traceability Complete | PASS | {N}/{N} chains complete |
| AA-04 | Cross-Refs Valid | PASS | {N} references validated |
| AA-05 | Glossary Compliance | PASS | No violations |
| AA-06 | Contradiction Check | PASS | No contradictions |
| AA-07 | EARS Compliance | PASS | {N}/{N} REQs compliant |
| AA-08 | Testability | PASS | {N}/{N} scenarios testable |

### Findings (if any)
| # | Check | Severity | Location | Problem | Auto-Fix Applied |
|---|-------|----------|----------|---------|------------------|
| 1 | AA-04 | Critical | UC-001.md:45 | Reference to non-existent INV-EXT-099 | Yes: corrected to INV-EXT-{correct} |

### Verdict: {ALIGNED | GAPS DETECTED}
```

**If gaps detected:**
- For auto-fixable issues (typos, broken refs): fix immediately and re-audit
- For non-auto-fixable issues: include in Change Report as "Open Items"
- NEVER ignore a failed alignment check

---

### Phase 8: Change Report Generation

**Goal:** Generate a comprehensive document that provides full context for subsequent planning, task creation, and implementation.

**Output:** `changes/CHANGE-REPORT-{YYYY-MM-DD}-{short-id}.md`

**Structure:**

```markdown
# Change Report — {Short Title}

> **Report ID:** CHG-{YYYY-MM-DD}-{NNN}
> **Date:** YYYY-MM-DD
> **Spec version:** v{before} → v{after}
> **REQUIREMENTS.md version:** {before} → {after}
> **Change Requests:** {N} (ADD:{N} MODIFY:{N} DEPRECATE:{N})
> **Documents modified:** {N}
> **Alignment audit:** {ALIGNED | N gaps}
> **Breaking changes:** {Yes (N) | No}

---

## 1. Executive Summary

{2-3 paragraph description of what changed and why. Written for someone who needs to understand the full scope of changes without reading every detail.}

### Change Request Summary

| # | CR-ID | Type | REQ-ID(s) | Category | Priority | Complexity | Status |
|---|-------|------|-----------|----------|----------|------------|--------|
| 1 | CR-001 | ADD | REQ-EXT-{NNN} | FUN | Must | Medium | Applied |
| 2 | CR-002 | MODIFY | REQ-PERF-001 | NFR | Must | Low | Applied |
| 3 | CR-003 | DEPRECATE | REQ-CAN-011 | FUN | - | High | Applied |

---

## 2. Changes Applied

### 2.1 New Requirements Added

#### REQ-{SUB}-{NNN}: {Title}

**EARS Statement:**
> {statement}

**Acceptance Criteria:**
```gherkin
{criteria}
```

**Traceability:**
| Direction | Artifact |
|-----------|----------|
| Source | {sources} |
| Implements | {UCs} |
| Verifies | {BDDs} |
| Guarantees | {INVs} |

**Specs Created/Modified:**
| Document | Change | Lines |
|----------|--------|-------|
| {path} | {description} | {N} |

---

### 2.2 Requirements Modified

#### REQ-{SUB}-{NNN}: {Title}

**Before:**
> {previous EARS statement}

**After:**
> {new EARS statement}

**Reason:** {rationale from clarification}

**Cascade Changes:**
| Document | Section | Before | After |
|----------|---------|--------|-------|
| {path} | {section} | {old} | {new} |

---

### 2.3 Requirements Deprecated

#### REQ-{SUB}-{NNN}: {Title} [DEPRECATED]

**Previous EARS Statement:**
> {statement}

**Deprecation Reason:** {reason}
**Migration Steps:** {steps or "None"}

**Removed from:**
| Document | Section Removed |
|----------|----------------|
| {path} | {section} |

---

## 3. New Artifacts Created

| Type | ID | Title | Source CR |
|------|-----|-------|----------|
| Requirement | REQ-{SUB}-{NNN} | {title} | CR-001 |
| Invariant | INV-{AREA}-{NNN} | {title} | CR-001 |
| ADR | ADR-{NNN} | {title} | CR-002 |
| Business Rule | RN-{NNN} | {title} | CR-001 |
| BDD Scenario | {feature}:{scenario} | {title} | CR-001 |

---

## 4. Impact Analysis Summary

### 4.1 Documents Modified

| # | Document | CRs | Changes | Version |
|---|----------|-----|---------|---------|
| 1 | requirements/REQUIREMENTS.md | CR-001,CR-002,CR-003 | ADD+MODIFY+DEPRECATE | 1.0.0 → 1.1.0 |
| 2 | use-cases/UC-001.md | CR-001 | MODIFY | 4.0.16 → 4.0.17 |
| ... | ... | ... | ... | ... |

### 4.2 Breaking Changes

| Change | Impact | Migration Required |
|--------|--------|--------------------|
| {description} | {what breaks} | {Yes: steps / No} |

### 4.3 Cross-Reference Updates

| From | To | Type | Status |
|------|-----|------|--------|
| REQ-EXT-{NNN} | UC-001 | New link | Created |
| REQ-CAN-011 | UC-025 | Removed link | Cleaned |

---

## 5. Alignment Audit Results

{Full audit results from Phase 7}

---

## 6. Clarification Decisions

{Full clarification log from Phase 3 — preserves all decisions and rationale}

---

## 7. Context for Planning & Implementation

### 7.1 Affected FASE Files

| FASE | Impact | Description |
|------|--------|-------------|
| FASE-1 | Direct | New extraction capability requires implementation |
| FASE-5 | Indirect | Matching weights may need adjustment |

> **Action:** Run `sdd-plan-architect` to regenerate FASE files after this change.

### 7.2 Architecture Impact

{Description of architectural implications: new endpoints, new entities, new events, modified data flows}

### 7.3 Implementation Considerations

| Consideration | Detail |
|---------------|--------|
| New API endpoints | {list with methods} |
| New DB tables/columns | {list} |
| New event types | {list} |
| Modified business logic | {list} |
| New test coverage needed | {list of BDD scenarios} |
| Infrastructure changes | {if any} |

### 7.4 Recommended Next Steps

1. Run `sdd-plan-architect` to regenerate FASE files
2. Run `sdd-plan-architect --fase {N}` to update implementation plan for affected phases
3. Create implementation tasks for each change
4. {Additional recommendations based on change scope}

### 7.5 Risk Assessment

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| {risk} | {L/M/H} | {L/M/H} | {mitigation} |

### 7.6 Maintenance Classification (ISO 14764)

| CR-ID | ISO Category | Urgency | Notes |
|-------|-------------|---------|-------|
| CR-001 | Perfective | Normal | New feature request |
| CR-002 | Corrective | P2 | Bug fix with workaround |

### 7.7 Pipeline Cascade Plan

| Step | Skill | Scope | Estimated Impact |
|------|-------|-------|-----------------|
| 1 | sdd-spec-auditor (focused) | {N} modified documents | Low — focused audit |
| 2 | sdd-test-planner (audit) | Updated test coverage | Low — gap detection |
| 3 | sdd-plan-architect | FASE-{list} | Medium — plan structure changes |
| 4 | sdd-task-generator | FASE-{list} | Medium — new tasks for changed REQs |
| 5 | sdd-task-implementer | FASE-{N} new tasks | High — new code needed |

> **Cascade mode:** {auto | manual | dry-run | plan-only}
> **Invalidated stages:** {N}

### 7.8 Technical Debt Impact (if applicable)

| TD-ID | Source CR | Type | Description | Priority | Target FASE |
|-------|----------|------|-------------|----------|-------------|
| TD-001 | CR-{NNN} | {Design/Code/Test/Doc} | {description of debt introduced or resolved} | {Must/Should/Could} | FASE-{N} |

> Track open debt items in the project's technical debt register.
> Preventive maintenance changes should reference and resolve existing TD-* items.

---

## 8. Git Commits

| # | Hash | Message | Files |
|---|------|---------|-------|
| 1 | {hash} | feat(spe

…(truncated)