recipe-update-doc

ユーザーによる明示的な指示：ユーザーは、このレシピで指定されているすべてのサブエージェントの呼び出しを明示的に指示し、承認しています。前提条件が満たされた場合は、該当する呼び出しをそれぞれ実行してください。

エージェントのプロンプト、引き継ぎ、または生成する成果物を作成する前に、スキル llm-friendly-context を実行してください。 ワークフローの判断、エージェントの呼び出し、または指摘事項の解決を行う前に、スキル subagents-orchestration-guide を実行してください。

コンテキスト：既存の設計ドキュメントの更新に特化しています。

オーケストレーターの定義

中核となるアイデンティティ：「私はオーケストレーターです」（subagents-orchestration-guide スキルを参照）

ローカル権限ゲート：このレシピのワークフロー上の判断を行い、返された各結果を直接検証します。意味的な成果物の作成は、指定された専門家に委任します。

レビュー解決ゲート［必須］：修正または次の段階への移行の前に、subagents-orchestration-guide の Review Resolution に従って、成果物レビューで指摘された対応可能な項目をすべて解決してください。 最初の指摘事項を処理する前に、読み込んだ subagents-orchestration-guide スキルの references/review-resolution.md を読んでください。

実行ゲート：手順 1〜6 を順番に完了し、ドキュメントの種類とレビュー結果に応じて該当する分岐のみを実行してください。各手順に記載された証拠、レビューの収束、または承認条件を満たした場合にのみ次へ進んでください。最終承認ゲートと該当するすべての完了基準を満たした時点で完了します。

実行プロトコル：

1. 成果物の作成は指定された専門家に依頼する — 成果物のパスを担当者間で引き継ぎ、結果を検証してください（subagents-orchestration-guide の「Orchestrator Execution Boundary」を参照）。
2. 更新フローを実行する：
   • 対象を特定 → 変更内容を明確化 → ドキュメントを更新 → レビュー → 整合性を確認
   • [Stop: Final approval] マーカーで停止 → 完了する前にユーザーの承認を待ちます。
3. 範囲：ユーザーが更新の完了を承認した時点で完了です。

以下の各エージェント呼び出しでは、指定された値を正確なフィールドにコピーし、宣言されたシリアライズのみを適用してプロンプトを機械的に作成し、直ちに呼び出してください。

重要：document-reviewer を必ず実行してください。これはドキュメントの正確性を担保する品質ゲートです。

ワークフローの概要

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]

対象範囲

このスキルに含まれるもの：

• 既存ドキュメントの特定と選択
• 変更内容の明確化
• 適切なエージェントによるドキュメントの更新（更新モード）
• document-reviewer によるドキュメントのレビュー
• design-sync による整合性の検証（設計ドキュメントのみ）

対象外（適切なスキルに振り分けてください）：

• 新しい要件の分析
• 作業計画や実装

責任の境界：ユーザーが更新の完了を承認した時点で、このスキルは完了します。

対象ドキュメント：$ARGUMENTS

実行フロー

ステップ 1：対象ドキュメントの特定

docs/design/、docs/prd/、および docs/adr/ にある既存のドキュメントを検索します。

判断フロー：

状況	対応
$ARGUMENTS にパスが指定されている	指定されたドキュメントを使用
$ARGUMENTS にトピックが記述されている	トピックに一致するドキュメントを検索
候補が複数見つかった	AskUserQuestion で選択肢を提示
ドキュメントが見つからない	報告して終了（ドキュメントの新規作成は対象外）

ステップ 2: ドキュメントタイプとレイヤーの判定

ドキュメントのパスからタイプを判定し、次にレイヤーを判定して、適切な更新エージェントを選択します:

パスパターン	タイプ	更新エージェント	備考
docs/design/*.md	設計ドキュメント	technical-designer または technical-designer-frontend	以下のレイヤー検出を参照
docs/prd/*.md	PRD	prd-creator	-
docs/adr/*.md	ADR	technical-designer または technical-designer-frontend	以下のレイヤー検出を参照

レイヤー検出(設計ドキュメントおよび ADR 向け): ドキュメントを読み、内容のシグナルからレイヤーを判定します:

• フロントエンド(→ technical-designer-frontend): ドキュメントのタイトルやスコープに React、コンポーネント、UI、フロントエンドへの言及がある、またはファイルにコンポーネント階層、状態管理、UI インタラクションが含まれる
• バックエンド(→ technical-designer): その他すべてのケース(API、データレイヤー、ビジネスロジック、インフラストラクチャ)

ADR 更新のガイダンス:

• 軽微な変更(明確化、誤字修正、小さなスコープ調整): 既存の ADR ファイルを更新する
• 重大な変更(決定の撤回、大幅なスコープ変更): 元の ADR を置き換える新しい ADR を作成する

ステップ 3: 変更内容の明確化

どのセクションを更新する必要があるか、変更の理由、更新後に期待される結果を判定します。これらはリクエストと対象ドキュメントから導き出します。AskUserQuestion は、リクエストとドキュメントでは未確定の項目にのみ使用し、かつ、回答が異なれば更新するセクションや更新で達成すべき内容が変わる場合にのみ使用します。

得られた項目、対象となるセクション、および明示された合計サイズの予算があればそれを、更新エージェントまたはリビジョンエージェントに渡します。次の承認ゲートの前に、すべての差分ハンクを承認済み項目または必要な一貫性更新に対応付けます。偶発的な未対応の変更は削除し、必要な変更が要求されたドキュメントの結果や明示的なサイズ制約を変えてしまう場合は、リクエスト明確化ゲートに戻ります。

ステップ 4: ドキュメントの更新

ステップ 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 to reflect the specified changes.
  Add change history entry.

ステップ 5: ドキュメントのレビュー

設計ドキュメントの更新の場合のみ: document-reviewer の前に、code-verifier を呼び出します:

subagent_type: code-verifier
description: "Verify updated Design Doc"
prompt: |
  doc_type: design-doc
  document_path: [path from Step 1]
  Verify the updated Design Doc against current codebase.

  Verification focus: Pay special attention to literal identifier referential
  integrity in the updated sections (paths, endpoints, type names, config keys).

出力を次のように保存します: $CODE_VERIFICATION_OUTPUT

該当する正確な形式で document-reviewer を呼び出します:

• 設計ドキュメント: doc_type: DesignDoc、target: [ステップ 1 のパス]、review_context: update、および verification_evidence: $CODE_VERIFICATION_OUTPUT。
• PRD: doc_type: PRD および target: [ステップ 1 のパス]。
• ADR: doc_type: ADRBatch、targets: [ステップ 1 のパス]、および review_context: update。

各タイプについて、変更されたセクションとその依存する記述、統制要件、変更履歴の一貫性をレビューします。

出力を次のように保存します: $STEP_5_OUTPUT

レビュー結果に応じて:

• 合格 → ステップ 6 へ進む
• 修正が必要 → レビュー解決ゲートを適用します。apply の指摘が存在する場合は、次のプロンプトを使用してステップ 4 に戻ります:

  subagent_type: [Update Agent from Step 2]
  description: "Revise [Type from Step 2]"
  prompt: |
    Operation Mode: update
    Existing Document: [path from Step 1]
  
    ## Adjudicated Review Findings
    [complete reviewer finding objects verbatim, with only their orchestrator dispositions added]
  
    Treat these findings as the complete revision scope and preserve adjacent content.
  

• 再レビューでは prior_feedback を [{id, disposition, reason?, evidence}] として渡す
• すべての実行可能な指摘が decline → ステップ 6 へ進む

ステップ 6: 一貫性の検証と最終承認 [Stop: Final approval]

設計ドキュメントの場合のみ、まず design-sync を呼び出します:

subagent_type: design-sync
description: "Verify consistency"
prompt: "source_design: [path from Step 1]"

競合が検出された場合は、レビュー解決ゲートを適用し、その有界な verifier ハンドオフと収束ルールに従って、選択された修正を所有ドキュメントのステップ 4 に戻します。

すべてのドキュメントタイプについて、更新されたドキュメント、レビュー結果、解決された decline、および sync が実行された場合はその結果を提示します。これはフロー内で唯一の承認ゲートです: 完了する前にユーザーの決定を待ちます。

エラー処理

エラー	対応
対象ドキュメントが見つからない	報告して終了する(ドキュメント作成はスコープ外)
サブエージェントの更新が失敗する	失敗を記録し、ユーザーにエラーを提示し、1 回再試行する

完了条件

• 対象ドキュメントを特定した
• リクエスト、ドキュメント、または回答によって更新内容が変わる質問に基づいて、変更内容を決定した
• 適切なエージェントを使用してドキュメントを更新した（更新モード）
• document-reviewer の実行前に code-verifier を実行した（設計ドキュメントのみ）
• document-reviewer を実行し、フィードバックに対応した
• 整合性を検証するために design-sync を実行した（設計ドキュメントのみ）
• 更新を完了することについてユーザーの承認を得た

出力例

ドキュメントの更新が完了しました。

• 更新したドキュメント：docs/design/[document-name].md
• 承認：ユーザーが更新の完了を承認しました

レビュー中に指摘事項が却下された場合は、そのID、却下の根拠、および証拠をこの完了報告に追記してください。