recipe-update-doc

Update existing design documents (Design Doc / PRD / ADR) with review

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "recipe-update-doc" with this command: npx skills add shinpr/claude-code-workflows/shinpr-claude-code-workflows-recipe-update-doc

Context: Dedicated to updating existing design documents.

Orchestrator Definition

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

First Action: Register Steps 1-6 using TaskCreate before any execution.

Execution Protocol:

  1. Delegate all work to sub-agents — your role is to invoke sub-agents, pass data between them, and report results
  2. Execute update flow:
    • Identify target → Clarify changes → Update document → Review → Consistency check
    • Stop at every [Stop: ...] marker → Wait for user approval before proceeding
  3. Scope: Complete when updated document receives approval

CRITICAL: Execute document-reviewer and all stopping points — each serves as a quality gate for document accuracy.

Workflow Overview

Target document → [Stop: Confirm changes]
                        ↓
              technical-designer / prd-creator (update mode)
                        ↓
              document-reviewer → [Stop: Review approval]
                        ↓ (Design Doc only)
              design-sync → [Stop: Final approval]

Scope Boundaries

Included in this skill:

  • Existing document identification and selection
  • Change content clarification with user
  • 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 → /recipe-design
  • Work planning or implementation → /recipe-plan or /recipe-task

Responsibility Boundary: This skill completes with updated document approval.

Target document: $ARGUMENTS

Execution Flow

Step 1: Target Document Identification

# Check existing documents
ls docs/design/*.md docs/prd/*.md docs/adr/*.md 2>/dev/null | grep -v template

Decision flow:

SituationAction
$ARGUMENTS specifies a pathUse specified document
$ARGUMENTS describes a topicSearch documents matching the topic
Multiple candidates foundPresent options with AskUserQuestion
No documents foundReport and end (suggest /recipe-design instead)

Step 2: Document Type Determination

Determine type from document path:

Path PatternTypeUpdate AgentNotes
docs/design/*.mdDesign Doctechnical-designer-
docs/prd/*.mdPRDprd-creator-
docs/adr/*.mdADRtechnical-designerMinor changes: update existing file; Major changes: create new ADR file

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 [Stop]

Use AskUserQuestion to clarify what changes are needed:

  • What sections need updating
  • Reason for the change (bug fix findings, spec change, review feedback, etc.)
  • Expected outcome after the update

Confirm understanding of changes with user before proceeding.

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
  [Changes clarified in Step 3]

  Update the document to reflect the specified changes.
  Add change history entry.

Step 5: Document Review [Stop]

Invoke document-reviewer:

subagent_type: document-reviewer
description: "Review updated document"
prompt: |
  Review the following updated document.

  doc_type: [Design Doc / PRD / ADR]
  target: [path from Step 1]
  mode: standard

  Focus on:
  - Consistency of updated sections with rest of document
  - No contradictions introduced by changes
  - Completeness of change history

Store output as: $STEP_5_OUTPUT

On review result:

  • Approved → Proceed to Step 6
  • Needs revision → Return to Step 4 with the following prompt (max 2 iterations):
    subagent_type: [Update Agent from Step 2]
    description: "Revise [Type from Step 2]"
    prompt: |
      Operation Mode: update
      Existing Document: [path from Step 1]
    
      ## Review Feedback to Address
      $STEP_5_OUTPUT
    
      Address each issue raised in the review feedback.
    
  • After 2 rejections → Flag for human review, present accumulated feedback to user and end

Present review result to user for approval.

Step 6: Consistency Verification (Design Doc only) [Stop]

Skip condition: Document type is PRD or ADR → Proceed to completion.

For Design Doc, invoke design-sync:

subagent_type: design-sync
description: "Verify consistency"
prompt: |
  Verify consistency of the updated Design Doc with other design documents.

  Updated document: [path from Step 1]

On consistency result:

  • No conflicts → Present result to user for final approval
  • Conflicts detected → Present conflicts to user with AskUserQuestion:
    • A: Return to Step 4 to resolve conflicts in this document
    • B: End and address conflicts separately

Error Handling

ErrorAction
Target document not foundReport and end (suggest /recipe-design instead)
Sub-agent update failsLog failure, present error to user, retry once
Review rejects after 2 revisionsStop loop, flag for human intervention
design-sync detects conflictsPresent to user for resolution decision

Completion Criteria

  • Identified target document
  • Clarified change content with user
  • Updated document with appropriate agent (update mode)
  • Executed document-reviewer and addressed feedback
  • Executed design-sync for consistency verification (Design Doc only)
  • Obtained user approval for updated document

Output Example

Document update completed.

  • Updated document: docs/design/[document-name].md
  • Approval status: User approved

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

coding-principles

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

integration-e2e-testing

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

ai-development-guide

No summary provided by upstream source.

Repository SourceNeeds Review