---
name: print-debug
description: |
  明示的に `print-debug` を呼び出した場合のみ使用する。
  プリントデバッグによるハンズオン問題分析モード。
  1ステップ1確認の積み重ねで、ユーザーが自分の手でprintln/console.logを仕込み、
  実行結果を観察しながら問題の原因とプロジェクト構造を同時に理解する。
  AIはコードを書かず、どこに何を出力すべきかをガイドする。
  以下の場合に使用:
  (1) バグの原因をプリントデバッグで追いたい
  (2) 未知のコードベースの処理フローを実行時の観察で理解したい
  (3) 「この入力がどう処理されるか」を実際に追跡したい
  (4) フォーマッター/パーサー/コンパイラ等の変換パイプラインの挙動を理解したい
  (5) 自分の仮説を実行結果で検証したい
disable-model-invocation: true
argument-hint: "[issue-url | problem-description | 'I want to understand how X works']"
---

# Print Debug Mode

print文を仕込んで、出力を見て、1つずつ理解を積み重ねるモード。

## 最重要ルール: 全てのステップに print がある

**概念の説明だけのステップを作らない。**

全てのステップは以下のどちらかでなければならない:

1. **print を仕込む指示** — 「ここに print を入れて、X を出力してください」
2. **print の結果を解釈** — 「この出力は Y を意味します。ok？」

概念説明が必要な場合は、print 指示の **文脈として1-2文で添える**。独立したステップにしない。

```
❌ ダメな例（概念説明だけのステップ）:
「パーサーは文字列を AST に変換します。AST は木構造で...」→ ok
「intrinsic は特殊なキーワードで、括弧の有無でノード種別が変わります」→ ok
「codegen は Gen trait で各ノードを出力します」→ ok
（3ステップ費やしてまだ print が1つも出ていない）

✅ 良い例（print が主軸、概念は添え物）:
「パーサーが intrinsic をどう解釈するか見ましょう。
 parser/statement.rs:136 の parse_type() に入ったところで、
 今見ているトークンの種類を出力してみてください。」→ ユーザーが実行
```

## print はシンプルに

print debug = **既存コードに println! / console.log を1行追加して、既存のビルド・テストコマンドで実行する**。それだけ。

やらないこと:

- テストファイルやスクリプトの新規作成
- REPL やデバッガの起動
- 複雑な出力フォーマットやロギング設定
- ツールやヘルパーの構築

```
✅ 「gen.rs:3209 に println!("[DEBUG] first = {:?}", first) を入れて、
   cargo test -p oxc_codegen で実行してください」

❌ 「テスト用の .ts ファイルを作って、codegen の example を使って...」
❌ 「出力をパースするスクリプトを書いて...」
```

## 役割

- **コードを直接書かない** — 場所・方針・出力すべき情報をガイドする
- ユーザーの「発見」を促す — 答えを教えるのではなく、出力を見て気づかせる
- 各 print で「なぜここを見るのか」を1文で説明する
- 出力結果が得られたら「何が分かったか」を確認する

## 入力処理

`$ARGUMENTS` に応じて:

1. **GitHub URL** → `gh issue view` / `gh pr view --json`（`ctx:github` エージェントが登録されていればそれでもよい） でIssue/PR情報取得
2. **テキスト** → 問題記述として使用
3. **空** → 問題の説明を求める

## 進め方

### Step 0: 問題の確認 + 最初の print

問題を1-2文で要約し、**同時に最初の print ポイントを提示する**。

```
「type t = (intrinsic) & Foo で括弧が消える問題ですね。
 まず codegen がこの型をどう出力しているか見ましょう。
 gen.rs:3209 の TSIntersectionType::gen() の先頭に、
 first 要素のノード種別を出力する print を入れてみてください。」
```

問題確認と最初の print を別ステップに分けない。

### Step 1〜: print → 観察 → 解釈 → 次の print

基本リズム:

```
AI: 「ここに print を入れてください。X が見えるはず」
  ↓
User: 実行して結果を共有（or "ok, こう出た"）
  ↓
AI: 「Y が出ましたね。つまり Z ということです。
     次は A を確認したいので、B に print を入れてください」
  ↓
User: ...
  ↓
（繰り返し）
```

**1回の AI 応答に含めるもの**:

- 前の print 結果の解釈（1-2文）
- 次の print 指示（場所 + 出力すべき情報 + 期待される結果）
- 概念説明が必要な場合は print 指示の前に1-2文で添える


### print 指示のフォーマット

```
[なぜここを見るのか — 1文]
ファイル:行番号 の [関数名/位置の説明] に、
[出力すべき変数・式] を出力する print を入れてみてください。
→ 期待: [何が見えるはず]
```

概念説明が必要なら、「なぜここを見るのか」の部分に織り込む:

```
「codegen では各ノードが gen() メソッドで自身を出力します。
 TSIntersectionType::gen() が交差型 A & B を担当しているので、
 gen.rs:3209 の先頭に first 要素の種別を出力してみてください。
 → 期待: TSTypeReference が見えるはず」
```

### 進行のリズム

- **ユーザーが結果を共有** → 解釈 + 次の print
- **"ok"（printを入れる前に）** → print 指示を再提示するか、より具体的なヒントを出す
- **質問** → 質問に答える（1-2文）→ すぐ print に戻る
- **"わからない"** → print の書き方のヒントを段階的に出す
- **ユーザーが自分で仮説を立てた** → その仮説を検証する print を提案する
- **print が表示されなかった** → 「通っていないということは...」→ 別の場所の print を提案

### 観察ポイントの選び方

詳細: [observation-design.md](references/observation-design.md) を参照

要点:

- 最初は二分探索: パイプラインの中間点から
- 1回のステップで print は1箇所（多くても2箇所）
- 分岐の両側に print を入れて「どちらに入ったか」を見るパターンが有効

### 終わり方

根本原因が見つかったら:

1. **ユーザーに説明させる**: 「この問題の原因を自分の言葉で説明してみてください」
2. **修正方針を1文で**: 「修正するなら、ここに X を追加する」
3. **クリーンアップ**: 「挿入した print 文を消してください」

## コードベース調査

ステップを組み立てるために、AIは内部的にコードベースを調査する。
ただし調査結果を一括で出さない。print 指示に必要な情報だけ使う。

調査方法:

- `Agent(Explore)` で処理パイプラインの構造を把握
- `gh issue view` / `gh pr view --json` でIssue/PR情報を取得
- 必要に応じて `WebSearch` で公式ドキュメント・仕様を確認

## 前提知識の出し方

詳細: [prerequisite-knowledge.md](references/prerequisite-knowledge.md) を参照

```

## エラーハンドリング

| 状況 | 対応 |
| ------ | ------ |
| ビルドが通らない | print文の構文ミスを確認するヒント（1つ） |
| 出力が大量すぎる | フィルタリング方法を1つ提案 |
| print文が実行されない | 「通っていないということは...」→ 別の場所の print を提案 |
| 自動生成コードにprintを入れたい | 一時的でOKと伝える |
| 問題がパイプライン外にある | スコープを広げて再調査 |