coding-rules: 書く時点で規約を守る

cq-review が「書いた後のレビュー」なのに対し、これは「書く前・書く最中」の適用。 レビューで指摘されることを最初から書かない。

ルールの読み込み

コーディング開始前に $SKILL/rules/ の *.md をファイル名順にすべて読む。 $SKILL はこの Skill のディレクトリで、ホーム導入なら ~/.claude/skills/coding-rules、 プロジェクト導入なら <repo>/.claude/skills/coding-rules。

• 読むのは *.md のみ。*.template.md は読まない (デフォルトの参照原本。 対応する .md をチームが削除している場合、そのルールは「無効化された」とみなす)
• ファイル間で矛盾したら、番号の大きいファイルが優先 (後勝ち)
• ルールの追加・変更・削除は rules/*.md を直接編集して git commit で共有する。 書式は 90-rule-format.md を見る
• install.sh はスキル更新時に *.md を保持し *.template.md だけ更新するので、 チームの編集は消えない

優先順位 (上ほど強い)

1. プロジェクトの CLAUDE.md
2. $SKILL/rules/*.md (番号の大きい順)
3. 周囲の既存コードの流儀
4. 一般的な良識

ただし、既存コードとルールが矛盾したときは矛盾の種類で扱いが変わる:

• 細部 (命名スタイル・記法・フォーマット・コメントスタイル): 周囲の既存コードを優先する。ルールとの矛盾はレビューパックで報告する
• 構造 (関数化・重複排除・ネスト深さ・引数の数・エラー処理・結合度): ルールを優先する。既存コードが違反していても新規コードは準拠して書く。 既存部分の修正はスコープ外 — 気づいた違反は TODO.md 行きを提案するにとどめる

実装の流れ

1. rules/*.md を読む (このセッションでまだ読んでいない場合)
2. 変更対象の周囲コードを読み、細部の流儀 (命名・フォーマット) を把握する
3. 実装する。構造ルール (関数化・ネスト・重複) は書きながら適用する
4. セルフチェック:
   • 適用対象のルールを 1 つずつ確認する
   • cq-review Skill の cq-metrics.py を変更ファイルに実行し、新たなフラグ (長い関数・深いネスト・重複) を自分で作っていないか機械確認する
5. 提示時のレビューパック (self-review Skill) に準拠メモを含める:
   • 読み込んだルールファイルと、特に効いたルール
   • 既存流儀を優先してルールから外れた箇所 (あれば)
   • 従えなかったルールと理由 (あれば。黙って逸脱しない)
   • 各項目に根拠を 1 つ添える (実行したコマンド・確認した file:line・grep 結果)。 添えられないなら「該当なし」ではなく「未確認」と書く。根拠の無い「該当なし」は 見ていない印で、空欄より悪い — 見た欄と見ていない欄の区別を消すため

ルール

• rules/ の実ファイルを必ず読む。「読んだことにして」進めない
• ルールに従えない事情があるときは、準拠メモに理由を書く (無言の逸脱が最悪)
• チェック項目を記憶で埋めない。項目を読んだその場で確認する (コマンドを打つ・ ファイルを開く)。実装が終わってから思い出して書くと「該当なし」が機械的に並ぶ — それは中身が無い合図
• ルール準拠を口実に、依頼されていない既存コードの書き直しを始めない