investigation-ruleslisted

# 調査レポート作成ルール 不具合調査・データ調査・仕様調査でレポートを作成する際のルール。コード読解だけに頼らず、必ず実行結果・出力・実データで裏取りする。 ## この Skill を使う場面 **レポート・報告文を書くとき**に使う。原因を突き止める作業そのものは扱わない。 | 依頼 | 使う Skill | | --- | --- | | 調査結果をレポートにまとめる / 「ない」ことを結論に書く | この Skill | | 不具合の原因を突き止めて直す | `problem-solving` | | 期待どおり動かない理由を切り分ける | `problem-solving` | | 原因が分かったので修正する | `problem-solving` → `tdd-cycle`（再現テストから） | `problem-solving` で原因を特定し、その結果を文章にする段でこの Skill の裏取り規則が効く。 両方に該当する依頼（「原因を調べてレポートにして」）では両方を使う。 トリガ語は「調査」のような広い語を置かない。ほぼ全セッションに一致してしまい、他の Skill の 発動を埋もれさせる。 ## 否定的結論にはエビデンス必須 「カラムがない」「データがない」「関数が呼ばれていない」「該当コードがない」等の **否定的な結論** を書く場合、**必ず実行結果をエビデンスとして添付すること**。 ### なぜこのルールが必要か AIは「もっともらしいが間違った推論」をしがちで、コード読解だけで「ない」と断定して誤判断を招きやすい。事例として、外部テーブルの一部カラムだけを見て「該当カラムなし」と結論づけたが、実際には別名のカラムにデータが存在していた、という判断ミスが典型。 ### 具体的な裏取り方法 | 主張の種類 | 必須エビデンス | |-----------|--------------| | DB: カラムが存在しない | `SHOW COLUMNS FROM table_name` / `DESCRIBE` の結果 | | DB: データが存在しない | `SELECT COUNT(*) FROM table WHERE ...` の結果 | | DB: テーブルが存在しない | `SHOW TABLES LIKE '%keyword%'` の結果 | | コード: 関数/シンボルが存在しない | `grep -rn 'name' .` / LSP検索 / Serena `find_symbol` の結果 | | コード: 呼び出し箇所がない | `find_referencing_symbols` / `grep` の結果 | | 設定: 値が存在しない | 設定ファイルのdiff / `env` / `config` コマンド出力 | | ログ: エラーが出ていない | `grep` / 検索ツールのクエリと結果期間 | ### レポートへの記載例 ```markdown ### 残課題 | 課題 | 概要 | エビデンス | 優先度 | |------|------|-----------|--------| | 外部API の retry 未実装 | Xクライアントで retry ハンドリングが無い | `grep -rn "retry\|Retry" src/client/x/` → 0件 | 中 | | status=deleted の件数 | 論理削除レコードが残存 | `S