blueprint-derive-rules

/blueprint:derive-rules

git のコミット履歴からプロジェクトの決定事項を抽出し、Claude のルールとして明文化します。競合する場合は、新しいコミットの決定事項が古い決定事項に優先します。

ユースケース：git の履歴から暗黙のプロジェクトパターンを導き出し、一貫性のある AI 支援開発ガイドラインを確立します。

使い方：/blueprint:derive-rules [--since DATE] [--scope SCOPE]

このスキルを使うタイミング

次のような場合にこのスキルを使います	次のような場合は別の方法を使います
git の履歴から暗黙の決定事項を抽出したい	要件からルールを作成する場合（代わりに PRD を使います）
プロジェクトに十分なコミット履歴がある	履歴がほとんどない新しいプロジェクトの場合
プロジェクトのコーディング規約を確立する	すぐに手動でルールを作成する場合

コンテキスト

• Git リポジトリ：!git rev-parse --git-dir
• Blueprint の初期化状況：!find . -path '*/docs/blueprint/*' -maxdepth 3 -name 'manifest.json' -type f
• コミット総数：!git rev-list --count HEAD
• Conventional Commits の割合：!git log --format="%s"
• デフォルトの場所にある既存のルール：!find . -path '*/.claude/rules/*' -maxdepth 3 -name "*.md" -type f
• Blueprint サブディレクトリにある既存のルール：!find . -path '*/.claude/rules/blueprint/*' -maxdepth 4 -name "*.md" -type f

パラメーター

$ARGUMENTS を解析します：

• --since DATE：指定した日付以降のコミットを分析します（例：--since 2024-01-01）
• --scope SCOPE：特定の領域に絞って分析します（例：--scope api、--scope testing）

実行

git からルールを導き出すワークフローをすべて実行します：

ステップ 0：出力先のパスを解決する

docs/blueprint/manifest.json から structure.generated_rules_path を読み込みます（デフォルトは .claude/rules/）：

RULES_DIR=$(jq -r '.structure.generated_rules_path // ".claude/rules/"' docs/blueprint/manifest.json)
mkdir -p "$RULES_DIR"

以降の読み込み、書き込み、競合チェックには $RULES_DIR を使います。親ディレクトリの .claude/rules/ にある手書きのファイルは、このスキルでは意図的に参照しません（issue #1043）。

ステップ 1：前提条件を確認する

1. git リポジトリでない場合 → エラー：「This directory is not a git repository」
2. Blueprint が初期化されていない場合 → 先に /blueprint:init を実行するよう提案します
3. コミット数が少ない（20 件未満）場合 → 警告：「Limited commit history; derived rules may be incomplete」

ステップ 2：git 履歴の品質を分析する

1. 対象範囲のコミット総数を計算します
2. Conventional Commits の割合を計算します
3. 品質を報告します：割合が高いほど、抽出したルールの信頼度も高くなります
4. --since と --scope フラグを解析し、分析範囲を決定します

ステップ 3：決定事項を含むコミットを抽出する

並列エージェントを使って git の履歴を効率的に分析します（REFERENCE.md を参照）：

• エージェント 1：refactor: コミットを分析し、コードスタイルのパターンを特定します
• エージェント 2：fix: コミットを分析し、繰り返し発生する問題の種類を特定します
• エージェント 3：feat!: と BREAKING CHANGE: コミットを分析し、アーキテクチャ上の決定事項を特定します
• エージェント 4：chore: と build: コミットを分析し、ツールに関する決定事項を特定します

調査結果をドメイン（code-style、testing、api-design など）ごとに、新しい順に時系列で、頻度順（最も多いものを優先）にまとめます。

ステップ 4：競合を解決する

複数のコミットが同じトピックを扱っている場合：

1. パターンマッチングを使って競合を検出します：git log --format="%H|%ai|%s" | grep "{topic}"
2. 次の解決方針を適用します：
   • 新しいものが古いものに優先：最新の決定事項を採用します
   • 頻度の高いものを優先：X とするコミットが 5 件、Y とするコミットが 1 件の場合、X を採用します
   • 破壊的変更を優先：feat!: は通常のコミットより優先されます
3. 上書きされた決定事項には「superseded」と、新しい決定事項への参照を付けます
4. 重要な決定事項については、AskUserQuestion を使ってユーザーに確認します

ステップ 5：$RULES_DIR にルールを生成する

各判断について、REFERENCE.md のテンプレートを使ってルールファイルを生成します。各ファイルを $RULES_DIR/<filename>.md（設定された structure.generated_rules_path）に書き込みます。

1. ソースコミット、日付、種類を抽出する

2. 信頼度（コミット頻度と明確さに基づく High／Medium／Low）を決定する

3. 実行可能なルール文を生成する

4. コミット差分からコード例を含める

5. 置き換えられた以前の判断があれば参照する

6. 必須：ルールが本当にすべての範囲に適用される場合を除き、生成するすべてのルールを paths: フロントマターでスコープ指定します。 paths: のないルールはすべてのセッションで読み込まれ、無関係な作業のコンテキストを汚染します。ソースの根拠に基づいて paths: を選びます。

   根拠	ソース	paths: の値
   ルール本文で「<path> から抽出したパターン」を使い、特定のファイルを参照している	ステップ 3／4 の競合解決	そのファイルのディレクトリを対象とする Glob：<dir>/**/*.<ext>
   chore(deps)／build: コミットから導出されたルール	ツール選定エージェント	ロックファイルとマニフェスト：package.json、pyproject.toml、Cargo.toml、go.mod、*.lock、biome.json など
   言語に関するルール（refactor: ＋ JS のみのコードブロック）	コードスタイルエージェント	言語別 Glob：**/*.{js,jsx,ts,tsx}、**/*.py、**/*.rs
   テストに関するルール	テスト戦略エージェント	**/*.{test,spec}.*、tests/**/*、test/**/*
   API エンドポイントに関するルール	API 設計エージェント	src/{api,routes}/**/*、**/*controller*、**/*handler*
   ドキュメントに関するルール	ドキュメントエージェント	docs/**、**/*.md
   プロジェクト全体のコンテキストを言い換えたルール（すでに CLAUDE.md に記載）	任意	出力しない — これは CLAUDE.md の役割です。ルールの生成を中止します
   すべてのファイルに本当に適用されるルール（例：普遍的なエラー処理の考え方、セキュリティ意識）	まれ	意図的に paths: を省略し、ルール本文に「グローバルルール」と記載します

   スコープ指定を基本とします。自動導出の出発点として、ルール本文のすべてのコードブロックから、参照されているファイル拡張子／ディレクトリのルートを集め、それらを paths: として出力します。書き込む前に、生成した glob の集合が実際に作業ツリー内のファイルに一致することを確認します。一致するファイルがない場合は、推定したスコープが誤っているため、再導出します。

カテゴリごとに別々のルールファイルを生成します（正式なファイル名とカテゴリごとのデフォルト paths: は REFERENCE.md を参照してください）。

• code-style.md、testing-standards.md、api-conventions.md、error-handling.md、dependencies.md、security-practices.md

ステップ 6：既存のルールとの競合に対処する

既存のルールとの競合を $RULES_DIR 内のみ で確認します（親の .claude/rules/ は、blueprint と無関係な手作業の内容が含まれている可能性があるため、確認しません）。

1. 競合が見つかった場合 → Git から導出したルールで既存のルールを上書きするか、既存のルールを維持するかをユーザーに確認します
2. ユーザーの選択を適用します：更新、マージ、または分けて保持
3. 競合の解決方法をルールファイルに記録します

ステップ 7：タスクレジストリを更新する

docs/blueprint/manifest.json のタスクレジストリ項目を更新します。

jq --arg now "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --arg sha "$(git rev-parse HEAD 2>/dev/null)" \
  --argjson processed "${COMMITS_ANALYZED:-0}" \
  --argjson created "${RULES_DERIVED:-0}" \
  '.task_registry["derive-rules"].last_completed_at = $now |
   .task_registry["derive-rules"].last_result = "success" |
   .task_registry["derive-rules"].context.commits_analyzed_up_to = $sha |
   .task_registry["derive-rules"].stats.runs_total = ((.task_registry["derive-rules"].stats.runs_total // 0) + 1) |
   .task_registry["derive-rules"].stats.items_processed = $processed |
   .task_registry["derive-rules"].stats.items_created = $created' \
  docs/blueprint/manifest.json > tmp.json && mv tmp.json docs/blueprint/manifest.json

ステップ 8：マニフェストを更新して結果を報告する

1. docs/blueprint/manifest.json を更新し、導出したルールのメタデータ（タイムスタンプ、分析したコミット、生成したルール、ソースコミット）を記録します
2. 次の項目を含む完了レポートを生成します：
   • 分析したコミット（件数と日付範囲）
   • Conventional Commits の割合
   • カテゴリ別に生成したルール
   • ルールごとの信頼度スコア
   • 解決した競合
3. 次のアクションをユーザーに確認します：ルールをレビューする、導出した開発ワークフローを実行する、または完了する

エージェント向け最適化

コンテキスト	コマンド
git の状態を確認	git rev-parse --git-dir 2>/dev/null && echo "YES" || echo "NO"
コミット総数をカウント	git rev-list --count HEAD 2>/dev/null || echo "0"
Conventional Commits の割合	git log --format="%s" | grep -c "^(feat|fix|refactor)" || echo 0
意思決定に関するコミットを抽出	git log --format="%H|%s|%b" | grep -E "(always|never|must|prefer)"
素早く推論	複数領域の分析には並列エージェント（Explore）を使用

---

git 分析のパターン、ルールのテンプレート、競合の解決、詳細な手順については、REFERENCE.md を参照してください。