CLAUDE.mdのルールから、シタデルによるインフラストラクチャー強制への移行

ルール蓄積の問題点

Claudeが指示を無視したとき、直感的な対応はCLAUDE.mdにさらにルールを追加することでした。45行から始まり、3か月で190行にまで増加しましたが、コンプライアンスは悪化しました。100行を超える指示は、ルールではなく提案として扱われるようになりました。フォレンジック監査により、40%の冗長性が明らかになりました。つまり、同じことを異なる言葉で言い換えたルール、互いに矛盾するルール、古くなったルールが存在していたのです。123行にまで削減すると、コンプライアンスは即座に改善しました。

インフラストラクチャへの転換

真の解決策は、CLAUDE.mdを（プロジェクトの規約、技術スタック、重要な優先事項などの）オリエンテーションの受け入れポイントとして認識し、すべてのルールの恒久的な置き場所ではないと理解することでした。それ以外のものは、必要なときにのみロードされるべきです。重要な転換点は、強制を指示から環境に移行することです。

例えば、Claudeが一貫して従わなかった「ファイル編集後は常に型チェックを実行する」というルールの代わりに、ライフサイクルフックスクリプトがすべてのファイル保存時に自動的に実行されます。これにより、エージェントの選択に関係なく型チェックが行われ、20回後の編集ではなく、すぐにエラーが表面化します。これにより、レビュー時間が劇的に短縮され、型エラーの追跡ではなく、意図と設計に集中できるようになりました。

進化システム

著者は5段階の進化を概説しています：

• レベル1: 生のプロンプティング（何も持続せず、同じミスが繰り返される）
• レベル2: CLAUDE.md（ルールは役立つが、約100行で限界に達する）
• レベル3: スキル（オンデマンドでロードされるモジュラーな専門知識、非アクティブ時はゼロトークン）
• レベル4: フック（環境が品質を強制し、指示ではない）
• レベル5: オーケストレーション（並列エージェント、持続的なキャンペーン、調整された波）

ほとんどのプロジェクトはレベル2または3で十分です。重要な洞察は、CLAUDE.mdが機能しなくなったとき、答えはより多くのルールではなく、強制をインフラストラクチャに移行することです。

具体的な実装

著者は3つの主要なシステムを実装しました：

• スキル: 特定のドメイン向けのパターン、制約、例を記述したマークダウンファイル。エージェントは現在のタスクに関連するスキルをロードし、無関係なコンテキストでのトークンの浪費を避けます。
• キャンペーンファイル: 何が構築されたか、どのような決定がなされたか、何が残っているかを追跡する構造化ドキュメント。これらはセッションをまたいで持続し、毎日の再説明を排除します。
• 自動化されたフック: すべての編集での型チェック、セッション終了時のアンチパターンスキャン、同じ問題で3回連続して失敗した後にエージェントを停止するサーキットブレーカー、Claudeがコンテキストを圧縮する前に状態を保存する圧縮保護。

Citadel: オープンソースシステム

完全なシステムはCitadelと呼ばれ、https://github.com/SethGammon/Citadelでオープンソース化されています。これには、スキルシステム、フック、キャンペーンの持続性、およびタスクを適切なオーケストレーションレベルに自動的にルーティングする/doコマンドが含まれています。668K行のコードベースで198のエージェントにわたる27の文書化された失敗から構築され、すべてのルールは何かが壊れたものに遡ります。