レガシースタイル継承
AIによるコードスタイルの逸脱を防止します。コードベースをスキャンして暗黙的な規則を4つのメタアーキテクチャ次元にわたって抽出し、ユーザーと1件ずつ合意を形成し、合意内容を強制力のある .ai-style-rules.md に結晶化します。言語・フレームワークに依存しません。
アクティベート条件
- ユーザーが
/inherit-legacy-styleと入力した - ユーザーがAIを手書きのレガシープロジェクトにオンボーディングする話をした
- ユーザーがAI生成コードの「既存プロジェクトの規則からの逸脱」を懸念している
- ユーザーがプロジェクトの暗黙的なコーディング規則を抽出・文書化したい
使用すべき場面
レガシープロジェクトのスタイルを維持し、AIによるスタイル逸脱を防止したいときにこのスキルを使用します。トリガー条件については上記 アクティベート条件 を参照してください。
前提条件
- Git(推奨。Gitがないプロジェクトでは、増分モードでファイルのタイムスタンプにフォールバックします)
- プロジェクトルートへの読み書き権限(
.ai-style-rules.mdおよびオプションでCLAUDE.mdを生成します)
ワークフロー
ステップ 0 — 自動検出モード
プロジェクトルートに .ai-style-rules.md が存在するかを静かに確認します:
| ファイルの有無 | モード |
|---|---|
| なし | ブランチ A — 初回フルスキャン |
| あり | ブランチ B — 増分スニフ |
モードを一行で告知し、そのまま進みます。ユーザーに選択させることはありません。
ブランチ A — 初回フルスキャン
1. 規模を測定し、スキャンティアを選択
git ls-files | grep -cE '\.(js|ts|jsx|tsx|vue|py|go|rs|java|kt|rb|php|cs|swift|c|cpp|h)$'
| ティア | ソースファイル数 | 戦略 |
|---|---|---|
| 小 | ≲ 50 | すべてのソースを完全に精読 |
| 中 | 50–500 | インフラ層は全読、ビジネス層は次元ごとに2~3ファイルをサンプリング |
| 大 | ≳ 500 | 厳密なサンプリング+予算制限。まず --stat で概要を確認し、その後対象を絞って読み取り |
2. 4つの次元でスキャン
- ファイル構造 — ファイル内の宣言順序(import → 型 → メインロジック → ヘルパー → export)
- 状態と制御フロー — 非同期状態、ページネーション、フラグの命名規則
- インフラ — 横断的なユーティリティ(インターセプター、フォーマッター、ミドルウェア)の配置場所
- エラーハンドリング — try/catch かグローバルインターセプターか Result 戻り値か。nullチェックの習慣
3. シグナル閾値によるノイズ低減を適用
ユーザーに割り込む前に、シグナルの強さを評価します:
- 弱いシグナル → 自動抑制:マイノリティが5%未満 かつ 件数が10未満 → マジョリティが勝ち、マイノリティはDONTsに
- 強いシグナル → グリル(詳細確認):ほぼ半々の割合、またはコア次元での意味論的な分岐がある
- 小規模プロジェクトの例外:ソース≲50で「3対2」はマジョリティと見なさない → グリルする
4. 競合を1件ずつ解決(グリリングプロトコル)
強いシグナルの競合ごとに、正確に1つの質問を4つの選択肢付きで提示します:
証拠:
pathAはスタイルXを使用、pathBはスタイルYを使用 警告: リスク: 両方を混在させるとプロジェクトスタイルが崩れる 選択:1Xに従う2Yに従う3これは進化だ、ルールを更新する4新しいルールを提示する
ユーザーが回答するまで保留し、その後次の競合に進みます。質問を重ねてはいけません。
5. .ai-style-rules.md を生成 — 必須3セクション:
- [黄金ファイル] — 実際の模範ファイルのパスと、それらが示している内容の注釈
- [命名規則と状態制御のルール] — 具体的でチェック可能な規則
- [DONTs] — 絶対に広まってはいけないアンチパターン
6. 永続フックをインストール
強制力のレベルをユーザーに尋ねます(AskUserQuestion を使用):
| オプション | メカニズム |
|---|---|
| 1 ソフトフック(推奨) | @.ai-style-rules.md への参照をプロジェクトの CLAUDE.md に書き込む |
| 2 ハードフック | ソフトフック + settings.json の `PreToolUse[Write |
| 3 フックなし | ルールファイルはそのまま。ユーザーが手動で参照 |
ブランチ B — 増分スニフ
- 既存の
.ai-style-rules.mdを読み取ります。コミットフィンガープリントがあれば、git diff <last_hash> HEAD --statでデルタを特定します - 最近のGit変更を読み取ります(
git log -3 --stat→ 疑わしいファイルをオンデマンドで検査) - 巨大な差分(数百ファイル)の場合:
--statの概要のみ + 最大の変更をサンプリング - 新しいコードを記録済みルールと比較 → 競合があればグリリングプロトコルを実行
.ai-style-rules.mdの末尾に進化ログを追記します(古いルールは上書きしない)
ターンごとの強制
.ai-style-rules.md がコンテキストにある場合(CLAUDE.md 経由でロード)、すべてのコード記述タスクは推論チェーンの中で コンプライアンス宣言 で始まり、従っている模範ファイルと回避しているDONTsを明示します。
仕組み
このスキルは、.ai-style-rules.md の有無によって初回実行か増分実行かを自動検出します:
- 初回(ブランチ A) — プロジェクト規模を測定し、コードベースを4つのメタアーキテクチャ次元(ファイル構造、状態・制御フロー、インフラ、エラーハンドリング)でスキャンし、シグナル閾値によるノイズ低減で弱い競合を抑制し、強いシグナルの競合をユーザーと1件ずつ解決し、黄金ファイル・命名規則・DONTsを含む
.ai-style-rules.mdを生成し、オプションの強制フックを提供します。 - 増分(ブランチ B) — 既存のルールを読み取り、最近のGit差分をチェックして新しいパターンや競合パターンを探し、見つかった競合に対して同じ1件ずつのグリリングプロトコルを実行し、既存ルールを上書きせずに進化ログを追記します。
- ターンごとの強制 —
CLAUDE.mdを介してフックされている場合、すべてのコード記述タスクは、従っている模範ファイルと回避しているDONTsを明示するコンプライアンス宣言で始まります。
出力仕様
- プロジェクトルートに
.ai-style-rules.md(ヘッダーにコミットフィンガープリントとスケールティアを含む) - オプションで
CLAUDE.md(@.ai-style-rules.md参照を含む) - 進化ログは
### [YYYY-MM-DD] Style Evolution Logエントリとして追記
アンチパターン
- 失敗: 規模測定ステップをスキップしてはいけません — 30ファイルのプロジェクトをサンプリングすると「情報不足」になり、5,000ファイルのリポジトリをフルスキャンすると爆発します
- 失敗: 複数の競合質問を一度に重ねてはいけません — グリリングは厳密に1件ずつです
- 失敗: 増分モードで古いルールを上書きしてはいけません — 常に進化ログを追記します
- 失敗: 確認なしに「ハードフック」をデフォルトにしてはいけません — 強制力のレベルはユーザーが決めることです
- 失敗: 構文や技術スタックの品質を判断してはいけません — このスキルはメタアーキテクチャのみを調整します
- 失敗: 模範ファイルからバグをコピーしてはいけません — 構造を再利用し、欠陥は報告します
ベストプラクティス
- スキャン前に検出したモード(初回か増分か)とスケールティアを一行で告知します
- 大規模プロジェクトでは、まず
--statの概要を読み、その後対象を絞ってReadを実行します - シグナル閾値にノイズ処理を任せます — 843対8の命名規則の分裂は、ユーザーに割り込まず自動解決させるべきです
- シグナルの強さに迷ったときは、質問する方向に倒します
CLAUDE.mdのソフトフック(@.ai-style-rules.md)で通常は十分です。ハードフックはユーザーが機械的な強制を望む場合のみにします。
関連スキル
init— コードベースのドキュメントとともに新しいCLAUDE.mdを初期化するcode-review— 差分を正確性とスタイルの問題についてレビューするsimplify— コードを再利用と簡素化の機会についてレビューする
例
-
初回オンボーディング
- ユーザー: 「この古いコードベースにAIをオンボーディングするのを手伝って。スタイルは変えないで。」
- アクション: ブランチAのフルスキャンを実行 → 規模測定 → 4次元スキャン → 競合グリル →
.ai-style-rules.md生成 → フック強度(ソフト/ハード/なし)を提供。
-
チーム変更後の増分更新
- ユーザー: 「新しいモジュールを追加したんだ。既存のスタイルルールはそのままにしてほしい。」
- アクション: ブランチBの増分スニフを実行 → Git差分を記録済みルールと比較 → 新たな競合をグリル → 上書きせずに進化ログを追記。
-
CLAUDE.md を介したDONTsの強制
- ユーザー: 「新しいコードがすべてプロジェクトのルールと一貫していることを確認して。」
- アクション: ソフトフックがインストールされる →
.ai-style-rules.mdがセッションごとに自動ロード → すべてのコード記述タスクがコンプライアンス宣言で始まり、模範ファイルのパターンを再利用しDONTsを回避する。