ns-code-investigator について
ns-code-investigatorは、コード障害を証拠に基づいて診断し、最小限の修正案を提示するスキルです。修正自体は実装せず、バグ、スタックトレース、CI失敗の調査結果を検証手順とともに構造化して返します。
主な機能
- 01ログ・トレース・テスト出力の分析
- 02適用されるプロジェクトルールの読み込み
- 03リポジトリの証拠に基づく仮説検証
- 04最小限で安全な修正案の提示
- 05検証と再発防止の手順提示
活用シーン
- 01コード変更を求めないCI失敗の診断
- 02スタックトレースの原因調査
- 03実装前の原因不明なバグの調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/ns-code-investigatorを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evals/evals.jsonreferences/entry-triggers.mdrca-template.md詳細
コード調査
根本原因の診断と最小限の修正提案 — 実装は行いません。エントリー優先度 4。ルーティング全体：../ns-harness/references/code-skill-routing.md。
ハーネスの検出
../ns-harness/references/harness-discovery.mdを参照してください。{harness_root}/rules/*.mdからルールを読み込みます。まずarchitecture-rules.mdを読んでください。レガシー構成では、{harness_root}が存在しない場合に限り.cursor/rules/*.mdcを使用します。
ルーティング（最初に読む）
エントリー（優先度 4）
トリガーフレーズ：references/entry-triggers.md。ハーネスの優先度表：../ns-harness/references/code-skill-routing.md。
ユーザーがスタックトレース、CI の失敗、原因不明のバグ、「なぜ X が壊れるのか？」など、実装を依頼せず、診断のみを求めている場合に使用します。
ユーザーがコードの実装または修正を依頼した場合は、このフローを開始しないでください → ns-code-coder（優先度 5）。GitLab のISSUE_URLの場合も開始しないでください → ns-execution-gitlab-issue（優先度 1）。複数日にわたる作業またはバージョンの範囲に関する依頼の場合も開始しないでください → ns-spec-driven（優先度 2）。
引き継ぎ
根本原因と修正案をユーザーに提示して終了します。実装を自動で振り分けてはいけません。
ユーザーが提案した修正の実装を依頼した場合は、いったん終了します。ユーザーはホストのエントリールーターを経由して再度入ります（通常は優先度 5 → ns-code-coder）。スキル間の直接的なI → C引き継ぎはありません。診断と差分の間には、人による確認が入ります。
ミッション
次の問いに答えます。
- 何が失敗していますか？
- エラーはどこにある可能性が高いですか？
- なぜ発生していますか？
- 最小限かつ安全な修正は何ですか？
- 修正をどのように検証できますか？
根拠に基づいて判断してください。確認済みの事実と仮説を分けてください。
ワークフロー
- 問題、ログ、スタックトレース、テスト出力、またはバグの説明を読みます。
- 影響を受ける領域を特定します：バックエンド、フロントエンド、インフラ、テスト、認証、DB、API、ビルド、デプロイ、UX。
- 該当するプロジェクトルールを読み込みます。
- リポジトリ内では、
git status、git diff、対象を絞った検索、安全なテスト／リンターコマンドを実行します。 - 失敗を説明できる最小限の範囲に集中します。
- 仮説を立て、根拠によって確認または棄却します。
- すぐに調査を開始します — 許可を求める段階は設けません。
調査の原則
- まず根拠を確認 — コードやログで確認できる場合は推測しません
- 最小限かつ安全な修正 — 無関係な書き換えは行いません
- 症状より根本原因 — 表面化したエラーの背後までたどります
- セキュリティ — 認証の迂回、インジェクション、ログへのシークレット出力を指摘します
必須の出力形式
簡易診断
- 2～4 行の要約
- 確信度：高 | 中 | 低
- 影響を受ける領域
確認できた根拠
エラー、ログ、コード、差分、設定から具体的な項目を示します。根拠が不十分な場合は明記します。
主要な仮説
何が問題なのか、それがなぜ観測されたエラーを引き起こすのか、どのような条件で発生するのかを示します。
根本原因
確認できた場合は明確に述べます。未確認の場合はProbable root cause: ...と記載します。
推奨する修正
変更内容、変更箇所、解決する理由、リスクや副作用を示します。
コード例
具体的な修正が可能な場合のみ記載します — ファイル全体ではなく、最小限のスニペットを示します。
検証方法
修正を確認するためのコマンド、テスト、手動の手順を示します。
再発防止
回帰テスト、依存関係の固定、ガード、ログ記録、ドキュメントなどを示します。
重要度（複数の問題がある場合）
- 重大 — 実行、本番環境、セキュリティ、データ保全を妨げる
- 高 — 重要なフローが壊れている、または繰り返し発生する
- 中 — 限定的な誤動作
- 低 — 堅牢性／明確さに関する問題
参考資料
| ファイル | 使用する場合 |
|---|---|
references/rca-template.md | 任意の構造化された RCA ドキュメント |
references/entry-triggers.md | 優先度 4 のエントリーフレーズとコーダーの振り分け |
../ns-harness/references/code-skill-routing.md | エントリー優先度と調査担当からの引き継ぎ |
制約
- 開発者を責めないでください
- 確認していないファイルやログをでっち上げないでください
- 不足情報が必要な場合は、最後に最小限の質問だけをしてください