bug-capture

bug-capture

会話を、メジャーリファクタリング後も正しく読めるイシューに変換します。

フロー

1. まず話を聞き、必要最低限の確認をします

ユーザーに自分の言葉で問題を説明してもらいます。次の中から、短い確認質問を最大2つまで尋ねます。

• 期待される動作と実際の動作。
• まだ説明から明らかでない場合は、具体的な再現手順。
• 発生頻度：常に発生するか、断続的に発生するか、一度きりか。

説明ですでに回答されている場合は、質問を省略してそのままイシューを作成します。質問しすぎると、あなたの不確実さによる負担を報告者に押しつけることになります。

2. 並行して調査します

ユーザーの回答を待つ間に、関連する領域の調査をバックグラウンドで開始します。目的は修正案を提案することではありません。機能についてコードベースで使われている名詞や動詞、つまりプロジェクト独自の用語を把握し、メンテナーが書いたようなイシューにすることです。

リポジトリに用語集ファイル（よくある名前：GLOSSARY.md、UBIQUITOUS_LANGUAGE.md、docs/domain.md）がある場合は、まずそれを読みます。

3. 作成前に重複を確認します

gh issue list --search "<key phrase>" --state all --limit 10 を実行します。該当する未解決、または最近クローズされたイシューが見つかった場合は、ユーザーに提示し、新しいイシューを作成する代わりにコメントを追加するか尋ねます。黙って作成を省略してはいけません。

4. 単一のイシューにするか、分割するかを決めます

異なるコントリビューターが並行して修正できる独立した障害モードが2つ以上報告に含まれている場合は、分割します。すべての症状が単一の誤った動作に起因する場合は、1つにまとめます。

分割する場合は、各子イシューが実在する親番号を参照できるよう、依存関係の順に作成し、妥当な Blocked by リンクを付けます。ツリーを整えるために、存在しない依存関係を作ってはいけません。

5. gh issue create で作成します

下書きをユーザーに確認してもらわずに作成します。作成したイシューのURLを返します。

単一イシューのテンプレート

## What happened
<observed behavior, in domain terms>

## What I expected
<expected behavior>

## Reproduction
1. <step>
2. <step>
3. <step>

## Context
<anything that narrows where the bug lives, in domain terms — e.g.
"only affects the import path, not the export path">

子イシューのテンプレート

## Parent
#<parent-number>

## What is wrong
<one behavior, narrow slice>

## What I expected
<expected for this slice>

## Reproduction
1. <step>

## Blocked by
<#issue or "none — independent">

## Context
<notes that apply only to this slice>

6. すべてのイシュー本文に適用されるルール

• ファイルパス、行番号、関数名、PR番号は記載しません。これらは古くなるためです。コードではなく動作を説明します。
• 一般的な技術用語ではなく、プロジェクトのドメイン用語を使います。「applyPatch() が例外をスローする」より「同期ワーカーがパッチを破棄する」と表現します。
• 再現手順は必須です。導き出せない場合は、作成前に一度だけユーザーに確認します。
• 30秒で読める長さを目指します。メンテナーが対応するかどうかを判断する助けにならない内容は削ります。

7. 続けます

各イシューの作成後にURLを表示し、次のイシューがあるか尋ねます。複数の報告をまとめて一度に作成してはいけません。それぞれのバグに、個別に範囲を絞ったイシューが必要です。