architecture-decision について
architecture-decisionは、技術的な決定をADRとして共同で文書化するClaudeスキルです。通常の作成、既存決定の記録、受け入れの各モードに対応し、プロジェクトのエンジン情報と設定に基づいて内容の深さや検証を調整します。
主な機能
- 01ADRを共同で作成
- 02既存決定の記録と受け入れに対応
- 03次のADR番号を特定
- 04docs.densityに応じて本文の詳しさを調整
- 05終了時に前提となるADRを確認
活用シーン
- 01新しい技術的決定の文書化
- 02既存アーキテクチャのADR化
- 03提案済みADRの受け入れ
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ donchitos/ claude-code-game-studios --skill architecture-decisionインストール後、Claude Code で/architecture-decisionを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
CONTRACT.mdreferences/0-accept.md0-retrofit.md1-engine-context.md3-gather-context.md4-decide.md5-generate.md詳細
!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow,docs.density,team.size
上記で解決済みです。そのまま使用してください。--review は review_mode を上書きします。ブロックがない場合は →
.claude/docs/config-resolution.md のデフォルトを使用します。
アーキテクチャ決定
このスキルが呼び出されたとき:
0. 引数を解析する — レトロフィット/受け入れモードを検出する
チェックパターン全体については .claude/docs/director-gates.md を参照してください。個々のゲート定義は .claude/docs/director-gates/[gate-id].md にあります。起動されたエージェントが自身のゲートファイルを読みます。親セッションでは読み込まないでください。
すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います
(共同作業モードでは常に質問し、ガイド付きモードでは主要な項目のみ質問し、自律モードでは記録して続行します。
automation_always_ask カテゴリでは常に質問します)。
team.size:この ADR を検証するエージェントを指定します(review_mode/workflow とは独立しています)。
individual(デフォルト):technical-director(TD-ADR)+エンジン専門家。smallとstudio:同じ2つのエージェントです。このスキルは、どの規模でもエンジンのサブ専門家や敵対的レビュー担当者を起動しません。
docs.density — ADR の散文セクションの詳しさを制御します。スケルトンが出力するセクション(これは固定です)は制御しません。modes.rigor は workflow とともにこの値を設定します。ADR の詳細度だけを変更するには、docs.density を明示的に設定してください。
terse(デフォルト。rigor: minimal による)=決定と代替案を箇条書きで示し、それぞれの根拠を1行で記述します。
balanced =各セクションを、簡潔な根拠を添えた段落にします(rigor: standard)。
thorough =決定、代替案、結果の各セクションで、トレードオフと詳しい根拠を含む完全な文章にします。
散文セクションに適用してください。エンジン互換性、ADR 依存関係、GDD 要件の各表は構造要素であり、どの詳細度でも全体を維持します。
workflow(.claude/docs/workflow-modes.md を参照):
full— 必須 ADR リストにあるすべての ADR を完了する必要があります。standard— 重要な ADR のみ(Foundation レイヤーのシステム)。minimal— 必須ではありません。任意で実行できます。
引数が retrofit で始まり、その後にファイルパスが続く場合
references/0-retrofit.md を今すぐ読み、記載の手順に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された場合、または再開された場合は、もう一度読み込んでください。
引数が accept で始まり、その後に ADR ID が続く場合
references/0-accept.md を今すぐ読み、記載の手順に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された場合、または再開された場合は、もう一度読み込んでください。
レトロフィットモードでも受け入れモードでもない場合は、以下のステップ1(通常の ADR 作成)に進みます。
引数なしの場合のガード:引数が指定されていない(タイトルが空である)場合は、フェーズ0を実行する前に質問してください。
「どの技術的決定を文書化しますか?短いタイトルを入力してください (例:
event-system-architecture、physics-engine-choice)。」
ユーザーの回答をタイトルとして使用し、ステップ1に進みます。
1. エンジンのコンテキストを読み込む(必ず最初に行う)
references/1-engine-context.md を今すぐ読み、記載の手順に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された場合、または再開された場合は、もう一度読み込んでください。
2. 次の ADR 番号を決定する
docs/architecture/ 内の既存 ADR を調べ、次の番号を確認します。
3. コンテキストを収集する
references/3-gather-context.md を今すぐ読み、記載の手順に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された場合、または再開された場合は、もう一度読み込んでください。
4. 共同で決定を導く
references/4-decide.md を今すぐ読み、記載の手順に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された場合、または再開された場合は、もう一度読み込んでください。
5. ADR を生成する
references/5-generate.md を今すぐ読み、記載の手順に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された場合、または再開された場合は、もう一度読み込んでください。
6. 次のステップ
ADRを作成した後(レジストリは必要に応じて更新し)、AskUserQuestion で締めくくります。
ウィジェットを生成する前に:
docs/architecture/architecture.mdの## Required ADRsセクションを(セクション単位で)読み、docs/architecture/adr-*.mdを一覧にします。必須ADRに対応するファイルがない場合は、まだ作成されていません。architecture.mdがない場合は、technical-preferences.md または systems-index.md で前提条件として指定されているADRを探します- 前提となるADRがすべて作成済みか確認します。作成済みであれば、「GDDの作成を開始する」オプションを含めます。
- 残っている優先度の高いADRをすべて個別のオプションとして一覧にします。次の1つか2つだけにしないでください。
ウィジェットの形式:
ADR-[NNNN] written and registry updated. What would you like to do next?
[1] Write [next-priority-adr-name] — [brief description from prerequisites list]
[2] Write [another-priority-adr] — [brief description] (include ALL remaining ones)
[N] Start writing GDDs — run `/design-system [first-undesigned-system]` (only show if all prerequisite ADRs are written)
[N+1] Stop here for this session
優先度の高いADRが残っておらず、設計されていないGDDシステムもない場合は、「ここで停止」のみを提示し、新しいセッションで /architecture-review を実行するよう提案します。
締めくくりの出力には、必ず次の固定通知を含めてください(省略しないでください):
GDDに対するADRの網羅性を検証するには、新しいClaude Codeセッションを開き、
/architecture-reviewを実行してください。
/architecture-reviewを/architecture-decisionと同じセッションで実行しないでください。 公平な評価を行うには、レビューエージェントを作成時のコンテキストから独立させる必要があります。ここで実行すると、レビューが無効になります。
ここでストーリーのブロックを解除しないでください。 このADRは Proposed です。ステップ5でその状態が保証されており、この決定が保留中のストーリーは、引き続き保留中です。作成時にブロックを解除すると、ガードが必要になるタイミングで機能しなくなり、誰も承認していない決定でパイプラインが進んでいるように見えてしまいます。
代わりに、承認待ちの項目をユーザーに伝えます。
「ADR-NNNNを作成し、
Proposedにしました。これを保留中のストーリーが[N]件、引き続きBlockedです。 決定が確定したら/architecture-decision accept ADR-NNNNを実行してください。これにより、ストーリーがReadyに移行します。」
Proposed のままにすることによる影響が分かるよう、ブロックされているストーリーをパスで一覧にします。
(承認は多くのスキルにわたって適用されますが、その権限の記録は一部に限られています。そのため、両者を結ぶ手順を明示しておく必要があります。)