setup-solid

SOLID のセットアップ

リポジトリに永続的な指示を 1 つ追加します。ボーイスカウトルールに従って、アーキテクチャレベルで SOLID を適用します。

このセットアップの要点は、ボーイスカウトルールです。SOLID を適用するのは、現在書いているコードと、現在のフローがすでに通過するコードに限り、リポジトリ全体には適用しません。コードベースは変更を重ねるごとに改善されます。

このセクションは言語に依存しません。フレームワークの DI コンテナや言語の interface キーワードではなく、モジュール、境界、依存関係の方向について説明します。このセクションを書く価値があるのは、ステップ 1 で調査を行い、このリポジトリに実在するレイヤーとパスを明記するためです。

リポジトリの文章がどの言語で書かれていても、このセクションは他のコード規約と同様、常に英語で記述します。

プロセス

1. 調査

草案を書く前に、リポジトリを読みます。次のことを決めつけないでください。

• 言語とコードのグループ分け（パッケージ、フォルダー、サービス）。どのフォルダーにポリシー（ドメイン／ビジネスルール）があり、どのフォルダーに詳細（DB、HTTP、SDK、ファイルシステム）があるか。
• ルートにある CLAUDE.md と AGENTS.md：どちらかが存在するか。一方がもう一方へのシンボリックリンクか。すでに SOLID のセクション（見出しレベルや大文字小文字を問わない）、または重複するアーキテクチャ／コーディング規約のセクションがあるか。
• モノレポの兆候：pnpm-workspace.yaml、package.json の workspaces フィールド、パッケージごとの CLAUDE.md ファイルがある packages/*。パッケージ間でレイヤー構成が実際に異なる場合に限り関係します。そうでなければルートファイルでカバーできます。
• GLOSSARY.md：このリポジトリの概念について、セクションで使うべきドメイン用語。
• ADR（.agents/adr/、docs/adr/）：セクションで矛盾してはならないアーキテクチャ上の決定。
• 依存関係を現在どのように注入しているか（コンストラクター引数、関数パラメーター、コンテナ、モジュールのインポート）と、テストでどのように置き換えているか。セクションには新しい規約を持ち込まず、既存の規約を記述してください。

このリポジトリ固有のパスを使って、ポリシーがどこにあり、詳細がどこにあり、両者が現在どのようにつながり、テストで詳細をどのように置き換えるかを説明できれば完了です。

ポリシーと詳細の分離がない場合は、そこで終了します。 ドキュメント用リポジトリ、薄いスクリプト用リポジトリ、プロンプトファイルのリポジトリには、形づくるべき IO 境界がありません。このセクションで名前を挙げるレイヤーがリポジトリにないことをユーザーに伝え、セクションは書かないでください。分離はあるものの規模が小さい場合（小さなドメインフォルダーが 1 つだけで、インターフェースがまだない場合）は、縮小版のセクションを提案します。SRP と OCP のみとし、### In this repo ブロックは含めず、何を省いたかを伝えてください。

2. 草案を作成して確認する

ステップ 1 で調査した内容を反映し、プレースホルダーを埋めた、書き込む予定のセクション全体をユーザーに提示します。本当に選択が分かれる点だけを尋ねてください。

• 書き込み先のファイル。CLAUDE.md と AGENTS.md のどちらもない場合に限ります。
• 調査で曖昧さが残った点。例：ポリシーのフォルダーとして妥当な候補が 2 つある場合。

次の点は、黙って判断せず、明示してください。

• 重複する規約セクション。 アーキテクチャやコーディング規約のセクションですでに依存関係の方向や抽象化について定められている場合、そのことを伝え、SOLID をそこに統合するか、SOLID 側からその規約を参照するかを提案してください。同じファイル内で同じ問題に関するルールが 2 組あるのは、ルールがないより悪い状態です。/review-axes は両方を文書化された規約として読み取ります。
• ADR との矛盾。 ADR が原則と矛盾している場合は、該当する ADR と箇条書きを明示してください。原則を黙って省いてはいけません。DIP の箇条書きがないと、説明のつかない欠落になります。

書き込む前に、ユーザーが草案を編集できるようにします。

3. 記述する

編集するファイルを選びます。CLAUDE.md があればそれを編集し、なければ AGENTS.md、それもなければユーザーが選んだファイルを編集します。片方がすでに存在する場合、もう片方を新規作成してはいけません。また、一方がもう一方へのシンボリックリンクの場合、どちらに書き込んでも両方に書き込むことになるため、片方を選び、もう一方のパスには触れないでください。

SOLID セクションがすでに存在する場合は、見出しレベルや大文字・小文字にかかわらず、2つ目を追記せず、既存の箇所を更新してください。周囲のセクションはそのまま残してください。

セクション：

## SOLID

Apply SOLID at the **architecture** level: module boundaries, dependency direction, and the interfaces between them. It is a way to shape seams, not a naming ritual. "Module" means whatever this codebase groups behaviour into: a class, a package, a file of functions, a service.

### Scope: boy scout rule

SOLID applies to:

- code written new in the current change, and
- the existing code the current flow already passes through, when a small local edit clears friction that change is hitting.

The rest of the codebase stays as it is. Keep a change's blast radius on the flow being built or fixed: a repo-wide SOLID refactor is its own piece of work, and happens only when explicitly asked for. The codebase converges one change at a time.

When applying a principle would require reshaping modules outside the current flow, leave them alone and say so in the summary of the change.

### In this repo

- **Policy**: [POLICY PATHS]
- **Details**: [DETAILS PATHS]
- **Wiring**: [INJECTION CONVENTION]
- **Test substitution**: [TEST SUBSTITUTION CONVENTION]

### The principles, as architecture rules

- **SRP**: a module has one reason to change. When one flow forces edits in a module that other flows also own for unrelated reasons, that module is holding two responsibilities.
- **OCP**: new behaviour arrives as a new implementation behind an existing interface, rather than another branch in a growing conditional over kinds of thing.
- **LSP**: every implementation of an interface is substitutable through that interface: same contract, same error behaviour, no "this one also needs X called first".
- **ISP**: a consumer depends on the narrow interface it actually uses. Interfaces are shaped by the caller's need, not by everything the implementation can do.
- **DIP**: policy does not depend on details (see *In this repo* above for both). The interface belongs to the policy side; the detail implements it and is passed in.

### Applying it

- When a new flow crosses an IO boundary, define the interface from the policy side and inject the implementation.
- One production implementation is enough **when a test substitutes it**: the test double is the second implementation, and the interface is the test surface. An adapter behind an interface with a single caller and no substitution is a hypothetical seam: drop the interface until something real needs it.
- Use this repo's domain vocabulary (`GLOSSARY.md`) when naming modules and interfaces.

ステップ 1 で確認したこのリポジトリの実際のパスと規約を使って、[POLICY PATHS]、[DETAILS PATHS]、[INJECTION CONVENTION]、[TEST SUBSTITUTION CONVENTION] を埋めてください。カテゴリではなく、具体的な glob（src/domain/** など）を記載してください。リポジトリに GLOSSARY.md がない場合は、その行を削除してください。ADR が原則に優先する場合は、箇条書きを残し、ADR を引用して例外を項目内に追加してください。

次に、記述した内容を読み返して、[PLACEHOLDER] が残っていないことと、ファイル内に SOLID セクションがちょうど1つだけあることを確認してください。プレースホルダーが残ると、このファイルを後から読むすべてのスキルに、不要な記述としてずっと残ります。

4. 完了

ユーザーに次の内容を伝えてください。

• 編集したファイル。
• SOLID が新規コードと、変更のたびにすでに触れるコードの両方に適用されること。別途リファクタリングの工程は行われません。
• これによって他のスキルの動作も変わったこと。 /review-axes は、文書化されたリポジトリ標準を独自のベースラインより優先するため、今後はこの項目に違反する差分を、このセクションを引用して指摘します。/implement はコードの記述中にこれらの項目を読み込みます。これが厳しすぎる場合は、今が項目を緩和するタイミングです。

このスキルを再実行する必要があるのは、セクション自体の形を変える場合だけです。直接編集してもかまいません。