設計: $ARGUMENTS
docs/design-process.md のすべての手順に従ってください。このファイルがルールです。このスキルはワークフローの順序を定義するだけであり、矛盾がある場合は docs/design-process.md を優先します。
- 設計が必要かどうか —
docs/design-process.mdのセクション1の表と比較します。- 不要な場合：理由を1行で説明し、
new-featureに戻ります。 - 不明な場合：まず人間に質問します。
- 不要な場合：理由を1行で説明し、
- 開始 (セクション3.0): epic issue (ラベル
design) を作成し、ブランチdocs/<id>-design-<slug>を切り、docs/design/template.mdをdocs/design/<slug>.md(system.mdまたは<epic番号>-<slug>.md) にコピーし、status: draftを設定して、docs/design/README.mdに行を追加します。 - 質問前に読む:
CONTEXT.md、docs/adr/、docs/architecture.md、docs/design/内の他の設計ドキュメント — 自分で見つけられる事実は自分で見つけ、質問してはいけません。 - ラウンド形式でインタビュー (セクション3.1) 形式
Qn — トピック: 質問+提案: …を各項目に、各ラウンドに1～2件のエッジケースを含めます — 分岐A～H (セクション3.2) をすべて網羅し、承認ポイント1、2 (システム)、3で人間の入力を待ちます。 - 各ラウンド後にファイルを更新: 設計ファイル内のセクション、
CONTEXT.mdの新しい用語、docs/adr/内のproposed状態のADR (＋インデックス)、コンテナ/外部システムが変更された場合はdocs/architecture.md内のC4図を更新します。 - チェック (セクション3.3):
make docs-checkを実行してパスする必要があります (リポジトリにMakefileがない場合:python3 <web-templateのパス>/scripts/check-docs.py <repo>— Hermesチーム:/home/opc/projects/web-template) さらに、自分でチェックリストを確認し、status: proposedを設定します。 - ドキュメントのみのPR:
docs(design): <slug>、本文にRefs #<epic>、未解決の選択肢の概要、## CHANGELOGセクションには-のみを含めます — コードを含めず、マージもしないでください。 - 承認 (セクション3.4): 人間が承認したら、同じPR内で
status: approved+approved-byをコミットし、ADRをacceptedに設定します (make docs-checkはパスする必要があります)。その後、人間にマージしてもらいます。 - マージ後 (セクション3.5): セクション13に従ってサブイシューを1つずつ作成し、各イシューはepicと設計ファイルにリンクします — コード作業は
new-featureで開始します。