AIRULES: GitHub repo の詳細を見にいく時の top-down 手順を追加

[ikuwow]

背景

セッション中に、socktainer の docker context 自動登録機能を「設計上ない」と断定したが、実際は README に明記された機能だった。同じ session 内で brew abbreviator バグの fix PR の存在も確認せず source code から自力 diagnosis を始めた。どちらも GitHub repo の中身を見に行く時にいきなり source / 個別ファイルから入り、上位の README / release / issue を見るより先に詳細レイヤーで結論を出した結果、user に誤った情報を提供した。

根本原因

GitHub repo の詳細を見にいく時に top-down の手順を踏まず、source code や formula 等の個別ファイルから直接読み始めた。詳細から入ると category prior で空白を埋めるしかなくなり、上流の設計意図が抜けたまま結論を出す事故が起こる。

提案する countermeasure

AIRULES.md「AIツール・外部サービス利用における考慮」セクションに以下を追加:

- GitHub repository の中身を見に行く時（実装詳細・source code・formula・config ファイル等の確認）は、いきなり個別ファイルから入らず、まず全体像を把握してから詳細に入る。手順:
  1. README（top-level の設計意図・主要機能）
  1. 直近 release tag + main 差分（`gh api repos/.../releases`、`gh search commits`）— README が main 向けで stable に未搭載のケース検出
  1. Open / closed の既知 issue・PR 検索（`gh search issues/prs`）— 既知バグや fix PR の存在確認
  1. source code / formula / 個別実装ファイル（詳細仕様の最終確認）
  この手順は repo 内部の詳細を見にいく時に限定。CLI の使い方や挙動を `--help` / man page / 一次的な実機実行で確認する段階では適用不要。順序を逆転すると、設計意図が欠落したまま実装詳細だけで結論を出す事故が起こる

検討事項

• AIRULES.md への追加で済ますか、独立した skill にするか未決。手順が固定的でツール呼び出しも具体的なので skill 化した方が確実に走る可能性あり。要検討
• skill 化する場合のトリガー: 「GitHub repo を Read / fetch しようとする時」「gh api repos/... を叩く時」等