ns-bug-report-diagnosis

バグ報告の診断

このスキルでは読み取り専用です。 入力＝プロダクトの報告（チャット、チケット、スクリーンショットの説明、ユーザーの手順）。出力＝2つの対象者向けのチャット診断です。再テストを行う人向けの平易な説明と、次のコーディングエージェント向けの簡潔な引き継ぎを記載します。その後、診断のみの場合を除き、そのエージェントに処理を引き継ぎます。

このスキルはプロダクトコードを変更しません。パッチの担当はns-execution-gitlab-issueまたはns-coderです。エントリー優先度は4aです。ルーティングの全体像：../../ns-harness/references/code-skill-routing.md。継続ルール：references/continue-handoff.md。

セッションの起動

../../ns-harness/references/session-boot.mdを参照してください。ほかの手順に進む前に、セッションの起動を完了してください（必須）。これはコールドスタート時のみ必要です。起動済みでファイルに変更がなければ、セッション途中では省略してください。AGENTS.mdをツールで読み込まないでください。

architecture-rules.mdとproject-rules.mdを読み込みます。docs/context/がある場合は、調査マップで指示されたもの（オーバーレイまたは該当するブラウンフィールドの行）のみを開き、全体を読み込まないでください。このスキルでは、プロダクトコードやdocs/context/のファイルを書き込みません（セッション起動時の実装による書き込みは対象外です）。

ルーティング（最初に読む）

トリガーとなるフレーズ：references/entry-triggers.md。

ユーザーがプロダクトの状況に基づく診断（画面、期待値と実際の動作、報告としてのチケット）を求めている場合に使用します。画面の状況説明がある場合は、後で修正を求められるとしても、まずここから開始して診断し、その後に処理を引き継ぎます。

画面の状況説明がなく、コードの実装または修正を求められている場合は、ここから開始しないでください → ns-coder（優先度5）。GitLabのISSUE_URLがホストの最初のスキルとして提示されている場合（実行URLのみ）は、ここから開始しないでください → ns-execution-gitlab-issue（優先度1）。画面の状況説明がなく、スタックトレース／CI／ログについての依頼であれば、ここから開始しないでください → ns-investigator（優先度4b）。複数日にわたる範囲またはバージョンの範囲についての依頼であれば、ここから開始しないでください → ns-spec-driven（優先度2）。

引き継ぎ

まず8セクションのチャットレポートを作成します（読み取り専用）。次にreferences/continue-handoff.mdに従います。

• 診断のみを希望する場合 → ユーザーへの回答で終了します。
• ISSUE_URLがある場合 → diagnosis_completeペイロードを付けてns-execution-gitlab-issueに引き継ぎます。
• それ以外の場合 → diagnosis_completeペイロードを付けてns-coderに引き継ぎます。

このスキルではプロダクトコードを書かないでください。診断のみの場合、または症状を特定できる情報もURLもない空の報告の場合を除き、人からの2回目のメッセージを待たないでください。

絶対遵守事項

1. このスキルではプロダクトを編集しません。 読み取り／grep／glob／読み取り専用の調査／ブラウザー／docker psのみ使用できます。アプリケーションのソース、スキーマ、マイグレーションへの書き込みは禁止です。コミットも禁止です。GitLabのステータス、ラベル、コメントの変更も禁止です。引き継ぎ先のG／Cスキルは、その後に編集できます。
2. このスキルではパッチを作成しません。 修正内容、PoCエクスプロイト、「この差分を適用してください」は記述しないでください。挙げてよいのは、画面、クライアントモジュール、ルート、ユースケース、永続化など、問題の箇所までです。実装はGまたはCの担当です。
3. 列挙されたすべての層を調査します。 references/investigation-map.mdに従ってください。利用側のルールに記載された他の層を開く前に、「フロントエンドのみ」または「バックエンドのみ」（あるいは「APIのみ」／「CLIのみ」）と結論づけてはいけません。最初に似たフォルダーを見つけたところで調査を止めるのは不合格です。
4. チャットのみ。 ユーザーから依頼されない限り、.mdの診断ファイルは作成しないでください。チャットのレポートが成果物です。
5. チャットの言語。 project-rules.mdで会話言語が指定されていればそれに従います。指定がなければ、会話の言語に従います。セクション2～3では、箇条書きの断片ではなく、完全な文を使用してください。
6. 事実と推測を区別します。 仮説にはその旨を明記してください。確認していないログ、ID、ファイルを捏造しないでください。
7. Docker。 docker compose up/downの実行やコンテナーの再起動は禁止です。ルールでテストコンテナーが指定されている場合、docker psは実行できます。動作を確かめるためにテストで変更を加えないでください。
8. 対象外。 architecture-rules.mdで対象外とされているパスはスキップしてください。ログイン認証情報を捏造しないでください。
9. 書き込み境界。 利用側のルールで必須の書き込み経路（エンジン、アグリゲート、ファサードなど）が指定されている場合、セクション8の「しないこと」ではその経路を挙げてください。ルールに記載のない書き込み経路を捏造しないでください。

入力

以下のいずれかを受け付けます。

• プロンプト内の自由形式のレポート
• 画面のストーリーの一部として添付された仕様／スクリーンショットの説明／短いスタックの抜粋
• GitLab issue の URL — MCP 経由で読み取ります（mcp-gitlab-usage は利用側にプロビジョニングされており、カタログスキルではありません）。このスキルでは issue を変更しないでください。

レポートが空に見える場合は、ISSUE_URL／issue の本文／スクリーンショット／このセッションから症状を特定して、続行してください。症状を特定できず、URL もない場合に限り、短い確認質問を1つして、そこで終了してください。バグを推測するためにリポジトリ全体を調べないでください。

フロー

report
  → restated symptom (expected vs actual)
  → discover stack (overlay → architecture-rules Stack → brownfield row)
  → trace UI → client state → HTTP → router → handler → domain → persistence
  → confirm or reject with code evidence
  → reproduce if the environment allows (optional)
  → chat report (output template)
  → continue-handoff (opt-out stop | G | C)

1. レポートを1つの段落で言い換えます。対象ユーザー、画面／操作、期待する動作、実際の動作、エラーテキストがあればその内容を含めます。
2. references/investigation-map.md からパスを特定します。レポートでエンティティが指定されており、docs/context/brownfield-map.md が存在する場合は、該当する行だけをざっと確認します。
3. この利用環境に存在するすべてのレイヤーを通して、報告された操作を追跡します。
4. 証拠を集めます。ファイルと動作の不一致を確認し、ストーリーを裏付ける行だけを引用します。
5. 再現：UI にアクセスでき、レポートが画面に関するものであれば、手順を試します。認証情報を捏造しないでください。認証情報が無効、またはアプリが停止している場合は、コードに基づいて手順を記述し、実行していないことを明記します。バグが API のみ、または CLI のみの場合は、そのレイヤーで再現し、その旨を明記します。再現できない場合は、その理由を明記します。
6. references/output-template.md に従ってチャットレポートを作成します。平易な言葉で説明するブロックを省略しないでください。
7. references/continue-handoff.md を適用します。

信頼度

レベル	使用する状況
高	コードパスを確認し、それによって症状を説明できる
中	パスは当てはまるものの、実行時の要素（データ、環境、権限）が未検証
低	レポートが曖昧、または決定的な証拠がなく、複数のレイヤーがまだ候補に残っている

信頼度が低くてもレポートを作成し、診断のみの場合を除いて、必ずディスパッチします。信頼度を高めるために必要な情報（ID、HAR、対象ユーザー、対象レコードなど）を列挙します。

次のエージェントへの引き継ぎ

別のエージェントがこのスキルを読み直さずにコーディングを開始できるよう、技術セクションを終えてください。セクション8にはdiagnosis_complete: trueと、references/continue-handoff.mdのペイロードを必ず含めてください。

その後、オプトアウトされていない限り、GまたはCをディスパッチします。このスキル内で実装しないでください。

このスキルの合格／不合格

合格： 修正担当エージェントが調査箇所を把握できる。エンジニアでない人が1回読んだだけでバグと修正の確認方法を説明できる。さらに、このスキルが診断のみ／空のレポートのために停止したか、diagnosis_completeを付けてG／Cをディスパッチしている。

不合格： このスキルでプロダクトコードを編集した。ファイルの一覧を羅列した。セクション2～3にエンジニアリング用語が残っている。複数レイヤーにまたがるスタックの片側しか検索していない。ここで差分を提案した。診断のみではない完全なレポートを作成した後、人間の対応を待って停止した。

参照資料

ファイル	使用時期
references/investigation-map.md	スタックのパスを特定し、レイヤーを追跡する方法
references/output-template.md	8セクションのチャットレポート
references/entry-triggers.md	優先度4aと調査担当／コーダーの区分
references/continue-handoff.md	オプトアウト、G／Cのディスパッチ、循環防止ペイロード
../../ns-harness/references/code-skill-routing.md	エントリーの優先順位と引き継ぎ