QAセッション は何をしますか？
インタラクティブなQAセッションを実行します。ユーザーが遭遇している問題を説明します。あなたは質問を明確にし、コードベースを探索してコンテキストを把握し、耐久性があり、ユーザーに焦点を当て、プロジェクトのドメイン言語を使用したGitHub Issueを作成します。
ユーザーが報告する各Issueについて
1. 聞いて、軽く明確にする
ユーザーに自分の言葉で問題を説明させます。最大2〜3の短い明確化の質問を、以下に焦点を当てて行います。
- 期待した動作と実際の動作の違い
- 再現手順（自明でない場合）
- 一貫して発生するか、断続的に発生するか
過剰に質問しないでください。説明がIssueを作成するのに十分明確であれば、次に進みます。
2. バックグラウンドでコードベースを探索する
ユーザーと話している間に、バックグラウンドでエージェント（subagent_type=Explore）を起動し、関連する領域を理解します。目的は修正を見つけることではありません。以下のことを行います。
- その領域で使用されているドメイン言語を学ぶ（UBIQUITOUS_LANGUAGE.mdを確認）
- その機能が何をするべきかを理解する
- ユーザー向けの振る舞いの境界を特定する
このコンテキストはより良いIssueを書くのに役立ちますが、Issue自体には特定のファイル、行番号、内部実装の詳細を参照しないでください。
3. 範囲を評価する：単一のIssueか、分割か？
Issueを作成する前に、これが単一のIssueであるか、複数のIssueに分割する必要があるかを判断します。
以下の場合は分割します：
- 修正が複数の独立した領域にまたがる場合（例：「フォームのバリデーションが間違っている AND 成功メッセージが表示されない AND リダイレクトが壊れている」）
- 複数の人が並行して作業できる、明確に分離可能な懸念事項がある場合
- ユーザーが説明する内容に複数の異なる障害モードや症状がある場合
以下の場合は単一のIssueとして維持します：
- 1つの場所で1つの振る舞いが間違っている場合
- すべての症状が同じ根本的な振る舞いに起因している場合
4. GitHub Issueを作成する
gh issue create でIssueを作成します。最初にユーザーにレビューを依頼しないでください。作成してURLを共有するだけです。
Issueは耐久性がなければなりません。大規模なリファクタリング後も意味をなす必要があります。ユーザーの視点から記述します。
単一のIssueの場合
以下のテンプレートを使用します：
## 発生したこと
[ユーザーが経験した実際の動作を平易な言葉で説明]
## 期待したこと
[期待した動作を説明]
## 再現手順
1. [開発者が従える具体的で番号付きの手順]
2. [コードベースのドメイン用語を使用。内部モジュール名は使用しない]
3. [関連する入力、フラグ、設定を含める]
## 追加コンテキスト
[ユーザーまたはコードベース探索からの、問題の枠組みを理解するのに役立つ追加の観察事項。例：「これはDockerレイヤーを使用した場合にのみ発生し、ファイルシステムレイヤーでは発生しない」— ドメイン言語を使用するが、ファイルは引用しない]
分割する場合（複数のIssue）
依存関係の順序でIssueを作成します（ブロッカーを先に）。これにより、実際のIssue番号を参照できます。
各サブIssueに以下のテンプレートを使用します：
## 親Issue
#<親Issue番号>（トラッキングIssueを作成した場合）または「QAセッション中に報告」
## 問題点
[この特定の振る舞いの問題を説明 — レポート全体ではなく、このスライスのみ]
## 期待したこと
[この特定のスライスに対する期待される動作]
## 再現手順
1. [このIssueに固有の手順]
## ブロックされているもの
- #<Issue番号>（このIssueが解決されるまで修正できない場合）
または、ブロッカーがない場合は「なし — すぐに開始可能」。
## 追加コンテキスト
[このスライスに関連する追加の観察事項]
分割する場合：
- 少数の厚いIssueよりも、多数の薄いIssueを優先 — それぞれが独立して修正可能かつ検証可能であるべき
- ブロック関係を正直にマークする — Issue BがIssue Aの修正なしでは本当にテストできない場合は、そのように明記する。独立している場合は、両方を「なし — すぐに開始可能」とマークする
- 依存関係の順序でIssueを作成する — 「ブロックされているもの」に実際のIssue番号を参照できるようにするため
- 並列性を最大化する — 目標は、複数の人（またはエージェント）が同時に異なるIssueを取得できるようにすること
すべてのIssue本文のルール
- ファイルパスや行番号は記載しない — これらは古くなるため
- プロジェクトのドメイン言語を使用する（UBIQUITOUS_LANGUAGE.mdが存在する場合は確認する）
- コードではなく、振る舞いを説明する — 「同期サービスがパッチの適用に失敗する」と記述し、「applyPatch() が42行目で例外をスローする」とは記述しない
- 再現手順は必須 — 判断できない場合はユーザーに質問する
- 簡潔に保つ — 開発者が30秒でIssueを読めるようにする
作成後、すべてのIssue URL（ブロック関係を要約して）を表示し、「次のIssue、または終了しますか？」と質問します。
5. セッションを続行する
ユーザーが終了したと言うまで続けます。各Issueは独立しています。まとめて処理しないでください。