| name | reverse-questions |
| description | コードや設計について逆質問を行い、理解度をテストする。「逆質問して」「理解を確認して」「質問して」などの表現で使用する。 |
| argument-hint | ["対象（ファイルパス、モジュール名、概念名）"] |
| allowed-tools | Read, Grep, Glob, Agent |
逆質問スキル
ユーザが指定したトピック・ファイル・モジュールについて、1問ずつ対話形式で逆質問を行い、理解度をテストする。
逆質問とは
通常の「教える」方向ではなく、「質問する」ことで理解のギャップを浮き彫りにする手法。
- 表面的な知識ではなく、なぜそうなっているかを問う
- エッジケースや暗黙の前提を突く
- 設計上のトレードオフを考えさせる
対象の特定
$ARGUMENTS が指定された場合:
- ファイルパスなら、そのファイルを読んで内容を理解する
- モジュール名や概念名なら、関連するコードを探して理解する
- 何も指定されていなければ、現在のプロジェクト全体について質問する
実行手順
- 対象を分析する: ファイルを読み、設計意図・アルゴリズム・データ構造・エッジケースを把握する
- 質問を1問だけ出す: 最初は基礎的な質問から始める
- ユーザの回答を待つ: 回答が来るまで次の質問は出さない
- フィードバックを返す: 正解/不正解だけでなく、なぜそうなのか・何が足りないかを説明する
- 次の質問を出す: 前の回答を踏まえて難易度を調整する。理解が深ければより難しく、浅ければ基礎に戻る
- 5-6問で終了: 最後に理解度のまとめを出す
- 会話内容をmarkdownで保存する:
~/Project/q/%Y%m%dT%H%M%S--description.md 形式で質問/回答内容/解説を保存する（例: 20251008T013000--aws.md）
質問の種類（この順序で出す）
- 基礎: 「この処理は何をしている？」「このデータ構造を選んだ理由は？」
- 仕組み: 「この部分が失敗したらどうなる？」「このパラメータを変えると何が変わる？」
- エッジケース: 「入力が空の場合は？」「同時アクセスがあったら？」「データが巨大だったら？」
- 設計判断: 「別の方法で実装するとしたら？」「このトレードオフの代償は？」
- 応用: 「この仕組みを使って〇〇を実現するには？」「実際のプロダクトではどう改善する？」
重要なルール
- 1問ずつ出す。まとめて複数問出さない
- 回答を待ってから次に進む
- 回答が間違っていても責めない。正しい理解に導く
- ヒントを求められたら段階的に出す
- コードの具体的な行番号を示して「この部分は何をしている？」と聞くのも有効
- 質問は日本語で行う
