Claude Code御一行様用個人的設定

この記事は99%手書きです。

自分はClaude(Opus)を基本は使用しつつ、レビューにCodex(5.3)とGitHub Copilotを混ぜて使ってます。よくあるやつです。

最近はユーザー側であれこれ設定しなくてもそれなりに良い感じに動きます。とはいえ設定した方が効率よく進むのも事実なので、最低限の整備はしておいて損はありません。新しい盆栽感がありますね。

汎用的なやつ

汎用的なPlugin、例えばコミットルールだとかは、Anthropicの公式Pluginと everything-claude-code で基本十分だと思っています。ただサードパーティ製のものはネットワーク周り気をつけましょう。アウトバウンドはよほど信頼できるドメイン以外はユーザーの承認を得る様にした方が良いとは思います。

あとは↓を参考にしていけばとりあえず使う分にはまあ十分な気はします。

code.claude.com

とはいえ色々やっていくとチームとしてのルールや個人としてのこだわりを別途定義していくことになるとは思うので、その辺を簡単に紹介します。

とにかく編集するファイルを少なくする

自分はこの方針でやってます。特段特別なことはしていません。

各Agentがはじめに読み込むファイル(Claude.mdとかAGENTS.mdとか)は短く保つ、基本は絶対に読んでほしいdocsへの参照のみにする
各ベンダーのAgentが使うファイルはシンボリックリンクでまとめる
プロジェクト固有のdocsは1つのfolderに集約し、SSoTとし重複するドキュメントを残さない
ユースケースに応じてskillsを定義しdocsを参照させる(基本は各skills内で絶対に読んでほしいdocsへの参照のみ)

一応Claudeの公式ドキュメントにもCLAUDE.md 短く保て~ドメイン知識はskillsを~みたいなことは書いているので、方針としては間違ってはないんじゃないかなとは思います。

CLAUDE.md はすべてのセッションで読み込まれるため、広く適用されるもののみを含めます。ドメイン知識またはときどきのみ関連するワークフローについては、代わりに skills を使用します。Claude はオンデマンドで読み込み、すべての会話を膨らませません。

簡潔に保ちます。各行について、次のように尋ねます。「これを削除すると Claude が間違いを犯しますか？」そうでない場合は、削除します。膨らんだ CLAUDE.md ファイルは Claude があなたの実際の指示を無視する原因になります。

kwsk

docs フォルダをSSoTとする
- すべての設計ドキュメント、ガイドライン、仕様はここに集約してます。一応人間が読めるものにしておきたいので階層化しています。
Agents.md と .agents フォルダをskillsの実体の置き場にする
- claude.md や .claude/ .codex/ はそれぞれシンボリックリンクとして参照させます。これが詳しいです。
skills / Agents.md / copilot instructionは参照ルールのみを記載する
- 中身は概要とdocs/ 内のファイルへのリンクのみを記載しシンプルに保ちます。コンテンツの実体は常に docs/ に置くという原則を徹底します。
- ただ必ずしもdocsを全部読んでくれないこともあるのでベタ書きした方が精度?は上がるような気がしています。気がしているだけかもしれません。
Agents.md` は行動の指針のみを書く
- 前項通り具体的な技術仕様やドメイン知識は docs/ に委ね、Agents.md にはエージェントがどう振る舞うべきかの方針だけを記載します。
docsを常に最新に保つskillsを定義する
- ドキュメントが陳腐化しないよう、更新を促すskillsを用意しておきます。
Git Hooksでコミット時に最低限の静的解析を走らせる
- 自分はlefthookを使っていますが、コミット時に最低限の品質チェックが動くようにしておきます。TypeScriptであればtscとeslintとknipを回しておく、といった感じです。ルールベースの仕組みは品質担保のために最低限必要です。ただ勝手にバイパスしやがることがあるのでどうにかならんのでしょうか。
譲れない個人の思想を載せる
- あとは自分の設計思想を載せれば完成です。最終的にレビューするのは自分なので自分の思想にあった実装にさせます。
  - TypeScriptでアプリケーションを構成する場合、コンパニオンオブジェクトベースの関数型Likeな設計にしつつ、ドメイン集約における~~
  - TerraformのState管理はライフサイクル単位でstateを分離し、機能凝縮を意識したmodule設計に~
- こうした思想 docs/ に書き、review用のskillsから参照させます。