qa

QA セッション

対話型 QA セッションを実行します。ユーザーが問題を説明します。あなたは状況を明確にし、コードベースを調べてコンテキストを把握し、プロジェクトのドメイン用語を使用した、長期的に有用でユーザー視点の GitHub イシューを作成します。

ユーザーが報告する各イシューについて

1. 話を聞き、必要に応じて簡潔に確認する

ユーザー自身の言葉で問題を説明してもらいます。焦点を絞った短い確認質問を 2～3 個まで尋ねます。確認する内容は次のとおりです。

• 期待する動作と、実際に起きている動作
• 再現手順（明らかでない場合）
• 安定して再現するか、断続的に発生するか

詳しく聞きすぎないでください。説明が十分に明確であれば、そのままイシューを作成します。

2. バックグラウンドでコードベースを調べる

ユーザーと対話しながら、関連領域を理解するための Agent（subagent_type=Explore）をバックグラウンドで起動します。目的は修正方法を見つけることではなく、次のことを把握することです。

• その領域で使われているドメイン用語を学ぶ（UBIQUITOUS_LANGUAGE.md を確認する）
• その機能が本来どのように動作するべきかを理解する
• ユーザーに見える動作の境界を特定する

これらのコンテキストを活用して、より良いイシューを作成します。ただし、イシュー本文で具体的なファイル、行番号、内部実装の詳細に言及してはいけません。

3. スコープを判断する：単一のイシューにするか、分割するか

作成前に、これは単一のイシューか、複数のイシューに分割する必要があるかを判断します。

分割する条件：

• 修正が複数の独立した領域にまたがる（例：「フォームのバリデーションが誤っている AND 成功メッセージが表示されない AND リダイレクトが機能しない」）
• 明確に分離できる懸念事項があり、別々の担当者が並行して対応できる
• ユーザーが複数の異なる障害モードや症状を説明している

単一のイシューにする条件：

• 1 か所の動作に問題がある
• すべての症状が同じ根本的な動作に起因する

4. GitHub イシューを作成する

gh issue create を使ってイシューを作成します。先にユーザーにレビューを求めず、直接作成して URL を共有します。

イシューは、major refactors の後も意味が変わらない長期的に有用なものでなければなりません。ユーザーの視点で記述します。

単一のイシューの場合

次のテンプレートを使用します。

## What happened

[用普通语言描述用户经历的实际行为]

## What I expected

[描述期望行为]

## Steps to reproduce

1. [developer 可执行的具体编号步骤]
2. [使用 codebase 的 domain terms，不用 internal module names]
3. [包含相关 inputs、flags 或 configuration]

## Additional context

[来自用户或 codebase exploration 的额外观察，用来帮助 framing — 例如 “this only happens when using the Docker layer, not the filesystem layer” — 使用 domain language，但不引用 files]

分割する場合（複数のイシュー）

依存関係の順序（先にブロッカー）でイシューを作成し、実際のイシュー番号を参照できるようにします。

各サブイシューでは、次のテンプレートを使用します。

## Parent issue

#<parent-issue-number>（如果你创建了 tracking issue）或 "Reported during QA session"

## What's wrong

[描述这个 specific behavior problem — 只描述这个 slice，而非整个 report]

## What I expected

[这个 slice 的 expected behavior]

## Steps to reproduce

1. [只针对这个 issue 的步骤]

## Blocked by

- #<issue-number>（如果必须等另一个 issue 解决）

如果没有 blockers，写 "None — can start immediately"。

## Additional context

[与这个 slice 相关的额外观察]

分割する場合：

• 少数の大きなイシューより、細分化したイシューを多く作成する — それぞれを独立して修正・検証できるようにします
• ブロッカーの関係を正確に示す — B をテストするのに本当に A の完了が必要な場合は、その旨を記載します。独立している場合は、両方に「None — start immediately」と記載します
• 依存関係の順序でイシューを作成する — 「Blocked by」に実際のイシュー番号を記載できるようにします
• 並行作業を最大化する — 複数の人（またはエージェント）が別々のイシューに同時に取り組めるようにします

すべてのイシュー本文に適用するルール

• ファイルパスや行番号は記載しない — いずれ古くなるためです
• プロジェクトのドメイン用語を使用する（存在する場合は UBIQUITOUS_LANGUAGE.md を確認する）
• コードではなく動作を説明する — 「applyPatch() が 42 行目で例外を発生させる」ではなく、「同期サービスがパッチの適用に失敗する」と記述します
• 再現手順は必須 — 特定できない場合はユーザーに尋ねます
• 簡潔にまとめる — 開発者が 30 秒以内に読める長さにします

作成後、すべてのイシュー URL を出力し、ブロッカーの関係を要約してから、「次のイシューに進みますか、それともここで終了しますか？」と尋ねます。

5. セッションを続ける

ユーザーが終了を伝えるまで続けます。各イシューを個別に扱い、まとめて処理しないでください。