Update Requirement Rules

直近N日（デフォルト1日）のIssue（cc-triage-scope / cc-pr-created）から仕様・要件レベルの判断ロジックを抽出し、.claude/requirements/ 配下のタイプ別ルールファイルへ集約するスキル。収集 → 抽出 → ルール化 → 統合・整理 → PR作成まで一貫して実行する。

なぜこれをやるのか

同じ判断が Issue ごとに毎回ゼロから再検討されると、判断がブレて仕様が非一貫になり、確認事項として人へ差し戻されて着手が止まり、過去の決定を掘り起こす調査コストが毎回かかる。判断の結論と条件をルールとして固定すれば、後続の create-issue / create-issue-from-issue-number / answer-issue-questions がそれを前提として読み込み、同じ問いを再び人へ投げずに済む。裏を返すとルールが増えすぎたり古びたりすると逆効果（読み込みコストが上がり、現実と食い違うルールが誤った仕様を生む）なので、「追加」と同じ重みで「統合・削除・圧縮」を行う。

このスキルがやること・やらないこと

やること:

• 直近N日に更新された cc-triage-scope / cc-pr-created ラベル付きIssueの description と全コメントの横断収集
• 複数Issueで共通する仕様判断・要件決定のロジックの抽出とクラスタリング
• .claude/requirements/ 配下への要件タイプ別マークダウンの作成・更新（重複統合・冗長圧縮・陳腐化ルールの削除を含む）
• commit-push skill でのコミット・push（必要なら専用feature branchへ切替）
• create-pr skill でのPR作成 + Assignee（自分自身）と cc-triage-scope ラベルの付与
• 追加・統合・削除の差分サマリ報告

絶対にやらないこと:

• 収集対象の Issue / PR への書き込み（コメント・ラベル・クローズなど。収集は読み取りのみ。フェーズ5で自分が作成したPRへラベル・Assigneeを付けるのはこの制限の対象外）
• .claude/requirements/ 配下以外のファイルの編集（ソースコード・CODING_GUIDELINES.md・docs/ を含む。claude-task-worker.json の lastRun は claude-task-worker ワーカーが別PRで更新するため、本スキルは同ファイルに一切触らない）
• コーディング規約のルール化 — 命名・型・テストの書き方・レビュー指摘由来の実装作法は update-coding-guidelines の責務。境界の判定はフェーズ2の「update-coding-guidelines との境界」の1問（descriptionの書き分けが変わるか）で機械的に行う
• 1件しか根拠のない判断のルール化（採用基準の例外条件を満たす場合を除く）
• 特定Issueの経緯・議論の記録（ルールは再利用可能な判断基準であって議事録ではない。特定Issueの実装詳細・PR番号を書かない）
• デフォルトブランチ上での直接コミット（必ずfeature branchに切り替えてから commit-push を呼ぶ）

---

Instructions

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

実行モードの制約

本スキル固有のリスク: 本スキルは claude-task-worker の update-requirement-rules ワーカーから24時間おきに自動起動され、ワーカーは起動時刻を claude-task-worker.json の lastRun へ記録する別PRを作ったうえで、次の24時間の実行を抑止する。処理が未完のままターンを終えると、その日の分の収集・ルール化が行われないまま実行済みとして扱われ、取りこぼしたIssueは二度と対象期間に入らない（対象期間は常に直近N日で、遡らない）。

フェーズ0: 事前チェック・引数パース

• git rev-parse --show-toplevel の出力とカレントディレクトリが一致することを確認する。一致しない場合は「リポジトリルートで実行してください」と返して終了する
• .claude/requirements/ の有無を確認し、存在すれば ls でファイル一覧を取り、README.md（インデックス）と各カテゴリファイルを Read で全文読み込んで現在のカテゴリ構成・ルール数・記法を把握する

引数パース

$ARGUMENTS を空白区切りで最大2トークンに分解する。

• 1番目: 期間（日数）。省略時または非数値の場合は 1
• 2番目: 関連Issue番号（任意）。# プレフィックスは除去して数値部分のみ保持

例: /update-requirement-rules → 日数=1, Issue番号=なし ／ /update-requirement-rules 14 #123 → 日数=14, Issue番号=123

Issue番号はフェーズ5で create-pr に渡す。指定なしの場合はPR本文の Closes #N 行を省略する。

完了条件: リポジトリルートにいることが確認でき、既存の .claude/requirements/ の内容を把握済みで、日数と任意Issue番号が確定していること。

フェーズ1: Issueの収集

GitHub MCP が使える場合は下記「MCP経路の output_file 契約」に従って同等の収集を行い、output_file を自分で作る。以下のスクリプトは MCP 利用不可時のフォールバックとして使う。

スクリプトが認証エラー（401 / 403）で落ちた場合は、同じスクリプトを再試行せず MCP 経路へ切り替える（スクリプトは中で gh を呼ぶ「gh 経路」そのもの。クラウドセッションでは gh issue list / gh api graphql が必ず 403 になる）。スクリプトの失敗を「対象期間に該当Issueなし」に読み替えてはならない。 MCP 経路でも取得できなかった場合に限り、取得失敗とその原因を報告して終了する（ファイルは更新しない）。

bash ${CLAUDE_SKILL_DIR}/scripts/fetch-recent-requirement-issues.sh <フェーズ0で確定した日数>

第1引数には日数のみを渡す（$ARGUMENTS をそのまま渡すとIssue番号トークンが余計な引数になる）。

stdout に返るのはインデックスJSONのみで、Issue本文とコメントの全文は output_file のパスに書き出されている（本文をそのまま stdout に流すとコンテキストを食い潰すため）。インデックスの構造:

• period_since / repo / issue_count / output_file
• issues[]: issue_number / issue_title / issue_state / labels / updated_at / comment_count / body_chars / comment_chars

issue_count が0の場合は「対象期間に該当Issueなし」と報告して終了する（ファイルは更新しない）。

MCP経路の output_file 契約

MCP 経路でも下記「本文の読み出し」以降は同じ jq コマンドで読むため、output_file に書き出すJSONの構造（キー名・値の意味）をフォールバックスクリプトと完全に一致させる。

1. search_issues（query に repo:{owner}/{repo} label:<ラベル> updated:>=<収集起点の日付>）をラベル（cc-triage-scope / cc-pr-created）ごとに実行し、番号を和集合にする（ラベルをAND条件にしない）。番号降順で最大80件
2. Issueごとに issue_read（get）で本文・メタデータ、issue_read（get_comments）で全コメントを取得する（コメントはページングが尽きるまで取得しきる）
3. Issueごとに次のオブジェクトを組み立てる（スクリプトの fetch_issue が生成する構造と同一）:
   • issue_number / issue_title / issue_url / issue_state / issue_author（作成者ログイン、不明なら "unknown"）/ labels（名前の配列）/ created_at / updated_at / body（なければ ""）
   • comments[]: 非表示（minimized）でないコメントを {author, body, url, created_at} へ展開
4. 全Issue分を issue_number 降順に並べ、{period_since, repo, issue_count, output_file, issues: [...]} の形に組んで Write ツールでファイル（例: スクラッチパス配下の一時ファイル）へ書き出す。period_since はフェーズ0で確定した日数から算出したISO8601、output_file は書き出し先自身の絶対パス、issue_count は issues の件数
5. 以降の手順は、この output_file を <output_file> として同じ jq コマンドでそのまま使う

本文の読み出し

output_file から必要なIssueだけを jq で取り出す（<output_file> はインデックスJSONに載っていた実パスに置き換える）。

# 1件だけ読む
jq '.issues[] | select(.issue_number == 123)' <output_file>

# 複数件をまとめて読む（本文とコメント本文のみ）
jq -r '.issues[] | select(.issue_number | IN(101,102,103)) |
  "=== #\(.issue_number) \(.issue_title)\n\(.body)\n--- comments ---\n" +
  ([.comments[] | "[\(.author)] \(.body)"] | join("\n\n"))' <output_file>

# 親Issue（Epic）を確認する。採用基準の「同一Epicは1件と数える」判定に使う
# Issue Dependencies（parent）はMCP側の対応が不定のため gh-compat.sh 経由（REST優先・失敗時のみ gh フォールバック）で取得する
bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh issue-parent <番号>

分割して読む場合の制約

原則として自分で全件を読む。フェーズ2のクラスタリングは「別々のIssueで表現が違うだけの同じ判断」を1つにまとめる作業であり、全Issueが1つの文脈に載っていないと成立しない。分割して要約だけを受け取ると、チャンクをまたいだ同一判断を「別の判断」として二重登録する（実測: 3件のIssueにまたがる判断が3つの別ルールになりかけた）。

自分の残コンテキストで全件を読み切れないときだけ分割する。その場合は general-purpose-assistant サブエージェントへ5〜8件ずつ担当させ、output_file のパスと担当Issue番号リストを渡す（本文をプロンプトへ貼り付けない）。Agent ツールの effort は毎回指定する（general-purpose-assistant は定義に effort を持たない。基準は ${CLAUDE_PLUGIN_ROOT}/references/agent-effort.md）。逐語引用を返させる読み取り分担なので medium。このとき必ず次を要求する:

• フェーズ2の抽出フォーマットで返すこと
• 各クラスタに、判断が書かれている箇所の逐語引用を1〜2行添えること（要約ではなく原文）

逐語引用がないと、親は別チャンクのクラスタと同一の場面かどうかを判定できない。全チャンクの返却が揃ってから、引用を突き合わせてクラスタを再統合する。

完了条件: 対象Issueの description とコメントの内容を把握し、判断ロジック抽出の材料が手元にあること。

フェーズ2: 判断ロジックの抽出とクラスタリング

何を「判断ロジック」とみなすか

Issue の description と確認事項への回答コメントから、「この状況ではこう決める」という再利用可能な判断を拾う:

• 確認事項への回答で確定した仕様（「〜の場合は〜とする」「既存の〜に倣って〜を既定にする」）
• スコープの線引き（「〜は本Issueの対象外とし別Issueに切る」の判断基準）
• 既定値・フォールバックの選び方（値そのものではなく選び方の根拠）
• エラー時・境界値・権限なし時のふるまいの決め方
• どの層・どのモジュールに責務を置くかの仕様上の取り決め
• 「人へ確認すべきか、自動で決めてよいか」の切り分け

拾わないもの: そのIssue固有の事実（対象ファイル名・関数名・PR番号）／まだ決まっていない議論・保留事項／根拠のない好みの表明。

update-coding-guidelines との境界（迷ったらこの1問で決める）

「責務をどの層に置くか」「エラー時にどうふるまうか」のような判断は、仕様にも実装作法にも読めて境界が引けない。次の1問で判定する:

このルールを知っていると、Issueのdescription（要件・実装プラン・影響範囲）の書き分けが変わるか？

• 変わる → 要件ルール（本スキルの対象）。例: 「終了判断はCLIエントリ層に集約する」は、実装プランのステップ分割と影響範囲のファイル一覧が変わる
• コードを書く段階でしか効かない → CODING_GUIDELINES.md の対象（本スキルでは拾わない）。例: 命名規約、テストの書き方、型注釈の付け方、レビュー指摘由来の実装作法

境界上にあると感じた時点でこの問いに戻る。両方に載せない（同じ内容が2箇所にあると、片方だけ更新されて食い違う）。

抽出フォーマット

クラスタごとに以下を言語化する（サブエージェントに委譲する場合も同じ形式で返させる）。

- 判断の場面: <どういう状況で問われる判断か>
- 結論: <その状況でどう決めるか>
- 根拠: <なぜそう決まったか。1〜2行>
- 出典: #<Issue番号>（複数あれば列挙。親Issue（Epic）が分かれば併記）
- 逐語引用: <判断が書かれている箇所の原文1〜2行>

採用基準

以下のいずれかを満たすものを採用する:

1. 独立した反復: 同じ判断の場面が2件以上のIssueで現れ、同じ結論に落ちている。ただし同一Epic（同じ親Issue）配下の兄弟Issue群は、何件あっても「1件」として数える
2. 明示された一般方針: 1件しか出現していなくても、コメント本文が「今後は〜」「以降すべての〜では〜」のようにそのIssueを超える適用範囲を明示している
3. 共有語彙・契約に触れる判断: 1件しか出現していなくても、ラベル語彙・ワーカー間の契約・設定ファイルのスキーマ・ディレクトリ規約など、リポジトリ全体で共有される取り決めを確定させている

なぜ同一Epicを1件に数えるのか: 分割されたサブIssueは同じ設計議論を相互参照しながら繰り返すため、形式的には「異なる2件のIssue」を簡単に満たしてしまう。実質1回の議論を2回の独立した観測と数えると、その場限りの取り決めがルールとして固定される。逆に、時間や文脈が離れた2箇所で同じ結論に達しているなら本物の反復とみなせる（updated_at が30日以上離れた2件も独立とみなしてよい）。

なぜ基準3が要るのか: 適用範囲の明示（基準2）は書き手の筆致に依存しすぎて取りこぼす。ラベル語彙やワーカー間の契約は、次に同種の実装をする人が必ず必要とするうえ、知らずに実装すると壊れる種類の取り決めなので、出現1件でも拾う価値が反復の有無を上回る。

基準1〜3のいずれにも当てはまらず判定に迷う場合は採用しない。次に同じ判断が現れたときに改めて拾えばよく、根拠の薄いルールを置くほうが害が大きい（後続スキルがそれを前提として仕様を組み立ててしまう）。

既存ルールとの突き合わせ

.claude/requirements/ が存在しない初回実行では、この突き合わせを丸ごとスキップする（全件が自明に「新規」になる）。スキップした旨をフェーズ6の報告に1行残す。

既存ルールがある場合は、抽出した各クラスタをフェーズ0で読み込んだ内容と照合し、次のいずれかに分類する:

• 新規: 既存ルールに対応するものがない
• 統合: 既存ルールと同じ判断の場面を扱っている → 既存ルールを一般化して内包させる（新規ルールとして追加しない）
• 上書き: 既存ルールと逆の結論が新しいIssueで確定している → 既存ルールを新しい結論へ書き換え、出典を差し替える
• 不採用: 採用基準を満たさない

完了条件: クラスタごとに「判断の場面 / 結論 / 根拠 / 出典 / 逐語引用 / 新規・統合・上書き・不採用の別」が確定していること（初回実行では全件「新規」）。

フェーズ3: .claude/requirements/ の更新

ディレクトリ構成

.claude/requirements/
├── README.md          # インデックス（カテゴリ一覧と1行説明）
├── <category>.md      # 要件タイプ別のルールファイル
└── ...

カテゴリ分類

カテゴリはリポジトリの実態から決める。カテゴリは「後続スキルが自分のタスクに関係する束を1発で引ける」ための索引なので、そのリポジトリで実際に問われる判断の軸で切る。業務Webアプリなら domain-rules.md / ui-ux.md / data-model.md / auth-permission.md のような軸になるが、CLIツール・ライブラリ・インフラのリポジトリでは軸がまるごと変わる（例: 責務配置・外部連携のエラー判定・スコープの線引き）。例に引きずられず、抽出したクラスタを並べてから軸を決める。

制約:

• カテゴリファイルは最大8個。9個目が必要に見えたら、最も近い既存カテゴリへ寄せるか、既存2カテゴリを統合して枠を空ける
• 2回目以降の実行では、ルール1件のカテゴリファイルを新設しない。最も近い既存カテゴリへ入れておき、2件目が来た時点で切り出す
• 初回実行に限り、ルール1件でもカテゴリを立ててよい（「最も近い既存カテゴリ」が存在せず、性質の違うルールを無理に同居させると索引としての引きやすさが落ちるため）。ただし8個の上限は初回でも守る
• ファイル名は英小文字ケバブケース。カテゴリ名の変更（リネーム・統合）を行った場合は README.md を必ず同時に更新する

ルールの記法

各カテゴリファイルは次の構造で書く。

# <カテゴリの日本語名>

<このファイルが扱う判断の範囲を1行で>

## <ルールタイトル（判断の場面が分かる短文）>

**適用条件**: <このルールが効く場面>

<結論と根拠を2〜4行。「〜の場合は〜とする。理由は〜」の形で、判断の分かれ目と選ぶ側、なぜそちらかを書く>

出典: #<Issue番号>, #<Issue番号>

書き方の原則:

• 判断基準として書く（「〜の場合は〜とする」）。事実の記述（「〜になっている」）ではルールとして使えない
• 「なぜ」を必ず含める。理由のないルールは、状況が変わったときに適用すべきか判断できず、盲従か無視かの二択になる
• 本文は最大4文（見出し・**適用条件** 行・出典: 行は数えない）。超えるならルールが2つに分かれている
• 出典は最大3件。増えたら updated_at が古い順に落とす（Issue番号順ではない。番号が小さくても更新が新しいIssueがある）
• コード断片は原則書かない（実装は変わるがルールは残る。書くなら3行以内）

README.md（インデックス）

README.md は後続スキルが「どのファイルを読むべきか」を判断する入口なので、カテゴリ名・ファイル名・1行説明・ルール件数だけを持つ。ルール本文をここに書かない。

# Requirements

過去のIssueで確定した仕様・要件レベルの判断ロジックをタイプ別に集約したものです。
`create-issue` / `create-issue-from-issue-number` / `answer-issue-questions` が仕様作成・回答の前提として読み込みます。

## カテゴリ

| ファイル | 扱う範囲 | ルール数 |
|---|---|---|
| [domain-rules.md](domain-rules.md) | ドメイン・業務ルールの判断 | 5 |

## メンテナンス

- 更新は `/update-requirement-rules [日数]` で行う（手動編集も可）
- 採用基準: 独立した2件以上のIssueで同じ判断が反復している（同一Epic配下は1件と数える）／一般方針として明示されている／ラベル語彙・契約などリポジトリ全体の共有語彙を確定させている
- 扱うのは「descriptionの書き分けが変わる判断」。コードを書く段階でしか効かない作法は `CODING_GUIDELINES.md` の担当
- 現実と食い違うルールは削除・上書きする。増やすことより一貫していることを優先する

整理・圧縮（既存ルールがある場合は毎回必ず適用）

初回実行（既存ファイルなし）では対象が存在しないためスキップし、その旨を報告に1行残す。2回目以降は、追加だけを繰り返すとドキュメントが死蔵するため、更新のたびに以下を点検して手を入れる:

• 重複: 同じ判断の場面を扱うルールが複数あれば1つに統合する（カテゴリをまたぐ場合は、より本質的な側へ寄せて他方から削除する）
• 冗長表現: 前置き・言い換え・「なお」「また」で継ぎ足された文を削る。本文最大4文を守る
• ファイル内のルール数: 1ファイル20ルールを超えたら、最も近いルール同士を抽象度を1段上げて統合する。それでも超えるならカテゴリの分割を検討する（ただしファイル数上限8を守る）
• 陳腐化: 以下のいずれかを確認できた場合のみ削除・上書きする。「最近言及がない」は削除理由にならない（安定して守られているルールほど再言及されないため）
  • より新しいIssueで逆の結論が確定している → 新しい結論へ上書きし、出典を差し替える
  • ルールが前提としている機能・画面・データ構造がコードベースから消えている（Grep / Glob で確認する）→ 削除する
  • ルールの内容が CODING_GUIDELINES.md や docs/ の記述と重複している → こちらから削除し、README に参照先を1行残す

完了条件: .claude/requirements/ が更新され、追加・統合・上書き・削除した件数と各ファイルのルール数が把握できていること。README.md のカテゴリ表が実ファイルと一致していること。

git status で差分が発生していなければ「要件ルール更新差分なし」と報告してこのスキルを終了する（フェーズ4以降は実行しない。空コミット・空PRを作らない）。

フェーズ4: feature branch への切替

commit-push はカレントブランチにコミット・pushするため、デフォルトブランチ上で実行すると本番ブランチへ直コミットが入る。必ずfeature branchへ切り替える。

DEFAULT_BRANCH=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh default-branch)
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)

• CURRENT_BRANCH = DEFAULT_BRANCH の場合: chore/update-requirement-rules-$(date +%Y%m%d-%H%M%S) 形式のブランチを git checkout -b で作成して切り替える（同名が存在する場合はサフィックスでユニーク化）
• CURRENT_BRANCH ≠ DEFAULT_BRANCH の場合: そのまま使用する

切替後に git status で .claude/requirements/ 配下の差分が残っていることを確認する。

完了条件: デフォルトブランチではない、かつ差分が見えるブランチ上にいること。

フェーズ5: commit-push + create-pr

5-1. commit-push skill の呼び出し

Skill ツールで commit-push を引数なしで呼び出す（commit-push 側がカレントブランチの差分と履歴を見て戦略を選ぶ）。

5-2. create-pr skill の呼び出し

Skill ツールで create-pr を呼び出す。create-pr は context: fork のサブエージェントとして起動され本スキルの文脈を引き継がないため、渡せるのはIssue番号文字列のみ。

• フェーズ0でIssue番号が指定されていた場合: そのIssue番号を引数として渡す（PR本文に Closes #<番号> が入る）
• 指定されていない場合: 引数なしで呼び出す（空展開の Closes # 行が残るため 5-4 で後処理する）

PR作成後、返却されたPR URLを記録する。以降のフェーズでPR番号が必要な箇所は、この記録済みURLの末尾から抽出する（PR_NUMBER="${PR_URL##*/}"）。URLを取得できなかった場合はフェーズ5-3・5-4を実行せず、フェーズ6の出力に「PR URL未取得」と明記して終了する。

5-3. Assignee・ラベルの付与確認（毎回必ず実行）

create-pr 側でも付与手順はあるが、context: fork で結果を検証できないため本スキル側で確認・補完する。

GitHub MCP が使える場合は pull_request_read（method: get）/ get_me を使う。以下は MCP 利用不可時のフォールバック。

PR_URL="<create-prが返却したPR URL>"
PR_NUMBER="${PR_URL##*/}"
[ -n "$PR_NUMBER" ] || exit 1  # PR_URL未取得時は実行せず中断（前掲の方針どおり）
GH_USER=$(gh api user --jq '.login')

gh pr view "$PR_NUMBER" --json assignees,labels \
  --jq '{assignees: [.assignees[].login], labels: [.labels[].name]}'

gh pr edit "$PR_NUMBER" --add-assignee "$GH_USER" --add-label "cc-triage-scope"

• --add-assignee / --add-label は付与済みでもエラーにならないため、確認結果によらず実行してよい
• cc-triage-scope ラベルが存在せず失敗する場合は gh label create cc-triage-scope を実行してから再試行する
• Assignee付与が権限等で失敗してもPR作成自体は成功しているため、フェーズ6の出力に「Assignee付与失敗」と理由を明記して続行する

5-4. Issue番号なしのケースの後処理（Issue番号未指定の場合のみ）

GitHub MCP が使える場合は pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。

PR_URL="<create-prが返却したPR URL>"
PR_NUMBER="${PR_URL##*/}"
[ -n "$PR_NUMBER" ] || exit 1  # PR_URL未取得時は実行せず中断（前掲の方針どおり）
gh pr view "$PR_NUMBER" --json body --jq '.body' \
  | sed -E '/^Closes #[[:space:]]*$/d' \
  | gh pr edit "$PR_NUMBER" --body-file -

行末（$）まで数字がないことを条件にしているため、正常な Closes #123 は削除されない。

完了条件: PRが作成され、URLが手元にあり、Assignee と cc-triage-scope ラベルが付与済みで、Issue番号未指定ケースでは空の Closes # 行が削除されていること。

フェーズ6: 出力

## 収集結果
- 期間: <period_since> 〜 現在（<日数>日）
- 対象Issue数: <n>（重複を除いた実数。内訳は「両ラベル付き: <n> / cc-triage-scope のみ: <n> / cc-pr-created のみ: <n>」）
- 抽出した判断クラスタ数: <m>（うち採用 <k> 件。採用根拠の内訳: 独立反復 <n> / 一般方針の明示 <n> / 共有語彙・契約 <n>）
- 初回実行（既存ルールなし）の場合はその旨と、突き合わせ・整理圧縮をスキップした旨

## 要件ルール更新サマリ
- 新規ルール: <n>件
  - `<ファイル>`: <ルールタイトル>（出典: #<num>, #<num>）
- 既存ルールへの統合: <n>件
  - `<ファイル>`: <既存ルールタイトル> ← <新しい判断> を内包
- 上書き: <n>件
  - `<ファイル>`: <ルールタイトル>（旧結論 → 新結論、根拠: #<num>）
- 削除: <n>件
  - `<ファイル>`: <ルールタイトル>（理由: 対象機能が削除済み / CODING_GUIDELINES.md と重複 等）
- ファイル構成: <n>カテゴリ / 合計 <n>ルール（前回: <n>カテゴリ / <n>ルール）

## 採用しなかったクラスタ（参考）
- <判断の場面>: <理由（同一Epic内の反復で実質1件 / description の書き分けが変わらず update-coding-guidelines の責務 等）>

## PR
- ブランチ: <feature branch名>
- PR URL: <URL>
- Assignee: <ログインユーザー名>（失敗時はその旨と理由）
- ラベル: cc-triage-scope（失敗時はその旨と理由）
- 関連Issue: #<num>（指定なしなら「なし」）

---

注意事項

• クラスタリングは意味ベース: 表現が違っても同じ判断の場面なら同一クラスタ、同じ用語でも判断の場面が違えば別クラスタ。だから原則として分割せず全件を1つの文脈で読む
• 統合を追加より優先: ルール数の単調増加は後続スキルの読み込みコストを上げ、結局読まれなくなる