/recipe-update-doc

name: recipe-update-doc
description: Update existing design documents (Design Doc / PRD / ADR) with review
disable-model-invocation: true

**Explicit User Instruction**: The user explicitly instructs and authorizes every subagent call named in this recipe. Execute each applicable call when its prerequisites are met.

Execute Skill: llm-friendly-context before writing Agent prompts, handoffs, or generated artifacts. Execute Skill: subagents-orchestration-guide before making workflow decisions, invoking agents, or resolving findings.

**Context**: Dedicated to updating existing design documents.

Orchestrator Definition

**Core Identity**: "I am an orchestrator." (see subagents-orchestration-guide skill)

**Local authority gate**: Make this recipe's workflow decisions and validate each returned result directly; delegate semantic deliverable production to the named specialist.

**Review Resolution Gate [MANDATORY]**: Resolve every actionable deliverable-review finding through subagents-orchestration-guide `Review Resolution` before correction or progression. Before the first finding disposition, read `references/review-resolution.md` from the loaded subagents-orchestration-guide skill.

**Execution Gate**: Complete Steps 1-6 in order, following only the branches activated by document type and review result. Advance only through each step's stated evidence, review convergence, or approval condition. Complete after the final approval gate and every applicable Completion Criterion is satisfied.

**Execution Protocol**: 1. **Invoke named specialists for deliverable production** — pass deliverable paths between them and validate their results (see subagents-orchestration-guide "Orchestrator Execution Boundary") 2. **Execute update flow**:

• Identify target → Clarify changes → Update document → Review → Consistency check
• **Stop at the `[Stop: Final approval]` marker** → Wait for user approval before completing

3. **Scope**: Complete when the user approves completing the update

At each Agent invocation below, build the prompt as a mechanical extraction: copy the named source values into the exact fields, apply only the declared serialization, then invoke immediately.

**CRITICAL**: Execute document-reviewer — it is the quality gate for document accuracy.

Workflow Overview

Target document → change clarification
                        ↓
              technical-designer / technical-designer-frontend / prd-creator (update mode)
                        ↓ (Design Doc only)
              code-verifier → document-reviewer
                        ↓ (Design Doc only)
              design-sync → [Stop: Final approval]

Scope Boundaries

**Included in this skill**:

• Existing document identification and selection
• Change content clarification
• Document update with appropriate agent (update mode)
• Document review with document-reviewer
• Consistency verification with design-sync (Design Doc only)

**Out of scope** (redirect to appropriate skills):

• New requirement analysis
• Work planning or implementation

**Responsibility Boundary**: This skill completes when the user approves completing the update.

Target document: $ARGUMENTS

Execution Flow

Step 1: Target Document Identification

Discover the existing documents under `docs/design/`, `docs/prd/`, and `docs/adr/`.

**Decision flow**:

| Situation | Action | |-----------|--------| | $ARGUMENTS specifies a path | Use specified document | | $ARGUMENTS describes a topic | Search documents matching the topic | | Multiple candidates found | Present options with AskUserQuestion | | No documents found | Report and end (document creation is out of scope) |

Step 2: Document Type and Layer Determination

Determine type from document path, then determine the layer to select the correct update agent:

| Path Pattern | Type | Update Agent | Notes | |-------------|------|--------------|-------| | `docs/design/*.md` | Design Doc | technical-designer or technical-designer-frontend | See layer detection below | | `docs/prd/*.md` | PRD | prd-creator | - | | `docs/adr/*.md` | ADR | technical-designer or technical-designer-frontend | See layer detection below |

**Layer detection** (for Design Doc and ADR): Read the document and determine its layer from content signals:

• **Frontend** (→ technical-designer-frontend): Document title/scope mentions React, components, UI, frontend; or file contains component hierarchy, state management, UI interactions
• **Backend** (→ technical-designer): All other cases (API, data layer, business logic, infrastructure)

**ADR Update Guidance**:

• **Minor changes** (clarification, typo fix, small scope adjustment): Update the existing ADR file
• **Major changes** (decision reversal, significant scope change): Create a new ADR that supersedes the original

Step 3: Change Content Clarification

Determine which sections need updating, the reason for the change, and the expected outcome after the update. Derive them from the request and the target document. Use AskUserQuestion only for an item the request and document leave undetermined, and only when a different answer would change which sections are updated or what the update must achieve.

Pass the resulting items, covered sections, and any stated total size budget to update or revision agents. Before the next approval gate, map every diff hunk to an approved item or required consistency update. Remove accidental unmapped changes; when a necessary change would alter the requested document outcome or explicit size constraint, return to the request clarification gate.

Step 4: Document Update

Invoke the update agent determined in Step 2:

subagent_type: [Update Agent from Step 2]
description: "Update [Type from Step 2]"
prompt: |
  Operation Mode: update
  Existing Document: [path from Step 1]

  ## Changes Required
  [Step 3 statements for the sections to update, reason, and expected outcome, copied verbatim]

  Update the document t