# 1natsu Pair Debug

> 原因不明のバグや、コードだけでは判断がつかない問題を人間と二人三脚で調査する協調デバッグスキル。ユーザーが「二人三脚デバッグ」「ペアデバッグ」「一緒にデバッグしよう」「一緒に調査しよう」「実際に動かして確認したい」等と言った時に使用する。また、AIがコード分析だけでは原因を特定できないと判断した場合（ランタイム依存の挙動、環境固有の問題、再現条件が不明なバグ等）にも、このスキルの利用を提案すること。推測で結論を出そうとしている自分に気づいたら、このスキルを思い出すこと。

- Skill: `1natsu-vacation/1natsu-pair-debug` (Agent Skill)
- Install (CLI): `npx skillmds@latest add 1natsu-vacation/1natsu-pair-debug`
- Raw SKILL.md: https://api.skillmd.com/api/skills/1natsu-vacation/1natsu-pair-debug/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: 1natsu-vacation (https://skillmd.com/u/1natsu-vacation)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/1natsu-vacation/1natsu-pair-debug

---


# Pair Debug（二人三脚デバッグ）

コードの静的分析だけでは原因を特定できない問題を、人間の「目」と「手」を借りて解決する協調デバッグモード。

AIは仮説の立案・検証コードの仕込み・結果の分析を担当し、人間はアプリの実行・画面の確認・ログの報告を担当する。推測で結論に飛びつくのではなく、観測事実に基づいて原因を絞り込む。

## 対話ルール

ユーザーに選択肢を提示する場面では、プラットフォームが提供する対話型の選択UIを使うこと。

## モードの開始

### ユーザーからの明示的な起動

以下のようなフレーズでユーザーがモードを要求した場合、即座にモードに入る：

- 「二人三脚デバッグしよう」「ペアデバッグしよう」「一緒にデバッグして」「pair debug」
- 「一緒に調査しよう」「実際に動かして確認したい」「ログ仕込んで調べたい」

### AIからの提案

以下の状況を検知した場合、モードへの移行を**提案する**（勝手に入らない）：

- コードを読んだが、複数の原因仮説があり静的分析だけでは絞れない
- 環境依存・タイミング依存の問題が疑われる
- 同じ修正を試しても解決しない（堂々巡りの兆候）
- ランタイムの実際の値・状態を見ないと判断できない

提案の例：

> コードを見る限り原因の候補が複数あり、実際のランタイムの挙動を確認しないと絞り込めません。二人三脚デバッグモードに入って、一緒に調査しませんか？

以下の選択肢を提示する：

- 「はい、一緒に調査しましょう」→ モードに入る
- 「いいえ、通常モードで進めて」→ 通常の自律モードで最善を尽くす

## デバッグループ

モード中は以下のサイクルを繰り返す。1ステップずつ着実に進め、飛躍しない。

### 1. 仮説を立てる

現時点で考えられる原因候補を列挙する。各仮説に「何が観測できればこの仮説を確認/棄却できるか」を添える。

### 2. 観測ポイントを仕込む

仮説を検証するための最小限の計装コード（console.log、一時的なUI表示、try-catchでの詳細エラー出力等）を仕込む。

- デバッグ用コードには `// [PAIR-DEBUG]` コメントをつけ、後から識別・除去しやすくする
- 既存のビジネスロジックは変更しない（観測コードの追加のみ）
- 一度に仕込む観測ポイントは必要最小限に絞る（大量のログは人間の負担になる）

### 3. 人間に実行と報告を依頼する

何を実行し、何を報告してほしいかを具体的な手順で伝える。曖昧な依頼はしない。「確認してください」ではなく「Xを開いてYをクリックし、Consoleに出る `[PAIR-DEBUG]` ログを教えてください」のように書く。

### 4. 結果を分析して仮説を絞り込む

人間から報告された観測結果を受けて、どの仮説が確認/棄却されたかを明示し、次に何を確認すべきかを提案する。新たな仮説が浮上した場合はそれも述べる。

### 5. 原因が特定できたら修正を提案する

原因が観測事実から特定できた段階で、初めて修正を提案する。修正提案時にも：

- なぜこの修正で解決するのかを説明する
- 可能であれば修正後に再度動作確認を依頼する

## モードの終了

問題が解決したとAIが判断した場合、またはユーザーが明示的に終了を要求した場合（「デバッグモード終了」「pair debug 終了」等）に終了する。

終了時は以下の選択肢を提示する：

1. **終了 & クリーンアップ** — `[PAIR-DEBUG]` コメント付きのデバッグコードをすべて除去（除去前に対象一覧を提示して確認）
2. **終了のみ** — デバッグコードはそのまま残す（後で手動除去）
3. **まだ続ける** — 別の問題も引き続き調査

## 核心ルール

- **観測事実が根拠にないなら仮説と明示する** — 「おそらくこれが原因です」「これで直るはずです」は禁止。観測に基づかない判断は仮説であることを常に示す
- **人間の報告を受けるまで次の仮説検証に進まない** — 報告された事実が自分の仮説と矛盾しても、事実を優先する
- **人間の時間を尊重する** — 1回の依頼で得られる情報を最大化し、不必要な往復を減らす