design

name	design
description	GitHub Issue をもとに設計書（docs/design/）を更新し、レビューと修正まで自律実行する。Issue番号を引数に指定すること（例: /design 15）
argument-hint	<Issue番号>

/design

Issue番号: $ARGUMENTS

設計書更新（Phase 1）→ 設計書レビュー（Phase 2）→ レビュー結果に基づく修正（Phase 3）を順次実行する。
人間への確認なしに自律的に実行する。

実行手順

1. Phase 0（Issue読み込み）: gh issue view $ARGUMENTS --json number,title,body,labels でIssue情報を取得し、以降のPhaseで参照できるよう保持する
2. Phase 1: update-design スキルを Skill ツールで Issue番号 $ARGUMENTS を渡して起動し、設計書更新をこの場（インライン）で実行する
3. Phase 2: Phase 1 完了後、Phase 1 で更新された設計書を対象に doc-reviewer-agent を Task ツールで起動し、完了を待つ。その際、Phase 0 で取得したIssue情報（番号・タイトル・スコープ）をプロンプトに含め、「このIssueの意図に基づいて設計書が更新されている」ことを伝えること。あわせて、更新後の設計書が docs/requirements.md の要件（機能・非機能・SLO を含む）を満たしているかを照合し、未充足・矛盾があれば指摘するよう指示すること（設計が要件を満たすことの検証。とくに SLO はアーキテクチャの構造が目標を満たせるかに直結する）
4. Phase 3: Phase 2 のレビュー結果をもとに、再度 update-design スキルの手順で設計書の修正をインライン実行し、指摘事項を反映する。その際以下を反映すること：
   • Phase 2 の出力（レビュー結果）をそのまま含める
   • Phase 0 で取得したIssue情報を含める
   • 「Issueの意図に反する修正は行わないこと。レビュー指摘がIssueの計画と矛盾する場合は、Issueの意図を優先し、該当指摘はスキップすること」 という指示を明記する
5. 各フェーズの出力をそのまま全文表示する（要約・加工・コメント追加は禁止）

エラーハンドリング

• Phase 1 失敗 → Phase 2, 3 を実行しない。/update-design $ARGUMENTS で個別実行を案内する
• Phase 2 失敗 → Phase 1 の変更は適用済み。/doc-review で個別実行を案内する
• Phase 3 失敗 → Phase 2 のレビュー結果は出力済み。手動での修正を案内する