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