プロジェクトコンテキスト
プロジェクトの安定したルールを、それぞれのファイルに適切に配置する作業を支援します。ユーザーが決定権を持ち、あなたは読み取り、具体的な選択肢を提案し、草稿を作成します。
このスキルはSpec Kitのconstitution.mdを置き換えます。constitution.mdの内容はすべて以下の適切な場所に配置されます：
| 内容 | ファイル | 参照者 |
|---|---|---|
| スタック、レイヤー、依存関係ルール、譲れない原則、用語集 | docs/ARCHITECTURE.md | 人とエージェント；spec-to-planとreview-specは原則をチェックする |
| 品質、ブランチ、コミット、PR、レビュー、AIの使用 | CONTRIBUTING.md | 人（エージェントはリンク経由で参照） |
| 各構造的決定の理由と却下された代替案 | docs/adr/NNNN-*.md | 両方、必要に応じて |
| コマンド、境界、暗黙の慣習、ドキュメントマップ | AGENTS.md（+ @AGENTS.md を含む CLAUDE.md） | エージェント、毎回のセッションで |
| 脆弱性の報告方法、エージェントポリシー | SECURITY.md | 人 |
テンプレートは assets/en/（英語）と assets/es/（スペイン語）にあります。プロジェクトが使用している言語を使用してください。不明な場合は確認してください。各テンプレートの冒頭コメントに記入方法が説明されています。
ルール
- 重複しないこと。 すでに
pyproject.toml、CI、リンターにあるものは、コピーせずにリンクしてください。原則が2つのファイルに現れると、矛盾が生じます。原則はARCHITECTURE.mdのみに配置します。 - 短い
AGENTS.md: 150行未満。これはリンクを提供するマップであり、内容を含みません。各行について、「これを削除したらエージェントは間違えるか？」と問いかけ、そうでなければ削除します。 - ツールでチェックできるものはツールでチェックする。 各原則について、どのように検証するか（リンター、import-linter、テスト、CI、レビュー）を確認し、その列に記録します。
- 変動するものは含めない： スプリントのステータスやTODOは含めません。それらはトラッカーまたは
docs/plans/に配置します。 - 各ファイルを全文（または既存の場合は差分）を表示し、ユーザーが承認した後にのみ書き込みます。
プロセス
1. プロジェクトを読む
質問する前に、マニフェスト（pyproject.toml、package.json、go.mod…）、README.md、既存のコンテキストファイル、.github/workflows/、リンター設定、フォルダ構造を読みます。見つけた情報を使って、自由記述の質問ではなく回答を提案します。
モードを決定し、ユーザーに伝えます。
- グリーンフィールド（コードがほとんどまたは全くない）：
ARCHITECTURE.mdは規範的であり、こうあるべき姿を記述します。 - ブラウンフィールド：
ARCHITECTURE.mdは記述的であり、現状を記述します。理想はADRとツールのラチェットに委ねます。コンテキストファイルがすでに存在する場合、ギャップについてのみ質問し、差分を提案します。 constitution.mdからの移行：上記の表に従って内容を分散し、削除するかリンクに縮小することを提案します。
2. ラウンドごとのインタビュー
一度に1カテゴリずつ。各質問に対して、具体的な選択肢（A、B、「未定」、「その他」）を提示します。ファイルがすでに答えている場合は、質問せずに確認を求めます。該当しないカテゴリ（例：データベースがない場合）はスキップし、その旨を伝えます。各ラウンドの終わりに、決定事項を要約します。
| ラウンド | 決定事項 | 出力先 |
|---|---|---|
| 1. 目的 | プロジェクトの目的とスコープ外、タイプ（アプリ、サービス、ライブラリ、CLI） | ARCHITECTURE.md §1、README.md |
| 2. スタックとアーキテクチャ | 言語、フレームワーク、永続化、インフラストラクチャ；レイヤーまたはモジュールとそのインポートルール | ARCHITECTURE.md §2–4、構造的決定ごとに1つのADR |
| 3. 譲れない原則 | 5～10の安定した検証可能なルール：理由とそれぞれのチェック方法 | ARCHITECTURE.md §5 |
| 4. 品質 | テストファーストか後か、最低カバレッジ、型付け、モック禁止対象 | CONTRIBUTING.md §5；譲れない場合は原則にも追加 |
| 5. セキュリティ | 認証、機密データ、入力検証、規制順守 | ARCHITECTURE.md §10、SECURITY.md |
| 6. プロセス | ブランチ、Conventional Commits、マージかスカッシュか、承認、PRサイズ、許可されるAIツール | CONTRIBUTING.md §4、§6–7 |
| 7. 依存関係 | 追加ポリシー、禁止ライブラリ、ビルドかバイか | 原則（譲れない場合）またはCONTRIBUTING.md |
| 8. エージェント向け | コマンド（検証コマンドは必須）、暗黙の慣習、クリティカルまたは脆弱領域（ブラウンフィールド）、境界（常時/確認時/禁止） | AGENTS.md |
ラウンド8では、検証コマンドが他のスキル（plan-to-tasks、implement、review）との契約です。存在しない場合は、setup-guardrails-python（または言語に相当するもの）を提案するか、AGENTS.md に未解決の質問として残します。プロジェクトが review-prepush や review-pr を使用する場合は、オプションの ## Code review セクション（テンプレートは review-context/assets/AGENTS-code-review.md）も提供します。ベースブランチ、高リスクパス、レポート言語など。
3. 草稿作成と記述
順序：ARCHITECTURE.md → ADR → CONTRIBUTING.md → SECURITY.md → AGENTS.md。AGENTS.md は最後に作成します。なぜなら、これがすべてのファイルにリンクするからです。
assets/のテンプレートから始めます。まだ該当しないセクションは削除し、空のままにしないでください。- ADR：
ADR.mdをdocs/adr/0000-template.md（スペイン語の場合は0000-plantilla.md）としてコピーし、adr-README.mdをdocs/adr/README.mdとしてコピーします。ラウンド2～3の構造的決定ごとに1つのADRを作成します。ブラウンフィールドの場合は、最も疑問視される事項について、却下された代替案を含む3～5の遡及的なADRのみを作成します。 AGENTS.mdには以下を含める必要があります：- 「計画」行：実装前に
docs/ARCHITECTURE.mdの原則に対して計画をチェックする； - プロセスについて
CONTRIBUTING.mdへのリンク。
- 「計画」行：実装前に
CLAUDE.mdには@AGENTS.mdのみを含めます。ただし、すでに内容がある場合は除きます。その場合、AGENTS.mdに移動することを提案します。pull_request_template.mdは.github/に配置します。強制ではなく、提案します。
4. まとめ
作成または変更したファイルと、未解決の質問をリストアップします。ユーザーに以下を注意喚起します。
AGENTS.mdは毎月レビューし、特にモデル変更時に刈り込みます。ARCHITECTURE.mdは四半期ごとにコードと照合します。- エージェントが繰り返すミスは、ツールのルールにするか、最終手段として「既知の落とし穴」の下に1行追加します。