bug

バグ

壊れている事象の説明を、種類が Bug の GitHub Issue に変換します。ユーザーからの情報とリポジトリのコンテキストをもとにレポートを下書きし、承認を求めてから Issue を登録します。リポジトリが Issue の種類に対応している場合は Bug として登録し、対応していない場合は bug ラベルを付けます。

確認なしで Issue を登録することはなく、ユーザーが提供していない再現手順や事実を捏造することもありません。不明な点はその旨を記載します。

契約

入力：

• バグの説明（自由記述、エラー／スタックトレース、またはタイトルと詳細）
• 対象リポジトリ（現在のディレクトリのリモートから自動検出）
• 任意：ユーザーが指定するラベル、担当者、マイルストーン、重要度

出力：

• 構造化されたバグレポート（タイトル＋本文）。作成前に表示します
• Issue が Bug として登録されるか、bug ラベルが付くか（およびその理由）
• 作成された Issue の番号と URL

作成／変更するもの：

• gh を使用して、種類が Bug の GitHub Issue を 1 件作成します（または bug ラベルを付けます）
• ユーザーが指定したラベル／担当者／マイルストーンのみを適用します
• フォールバックとして bug ラベルを使用し、まだ存在しない場合は作成します
• コードの編集、他の Issue のクローズ、リポジトリ設定の変更は行いません

外部への副作用：

• GitHub からリポジトリ、ラベル、Issue の種類のメタデータを読み取ります
• GitHub Issue を作成します（リポジトリへのアクセス権を持つ全員が閲覧できます）

確認が必要な操作：

• Issue の作成前：必ず下書きのタイトルと本文をすべて表示し、明示的な「はい」を求めます
• フォールバックとして新しい bug ラベルを作成する前：まだ存在しない場合は確認を求めます

委譲先：

• ユーザーがバグの登録ではなく修正を望んでおり、バグが CI チェックの失敗である場合は github-fix-ci
• ユーザーが登録前に根本原因の特定を望む場合は debug（修正の試みがすでに失敗している場合は、独自に 4 フェーズのループへ移行します）

使用する場面

• 大まかな説明やエラーメッセージから、整理されたバグレポートを登録するとき
• ターミナルを離れずに、セッション中に見つけたバグを記録するとき
• ユーザーが「open a bug」「file this」「create a bug issue」と言うか、/bug を実行したとき

バグの修正、機能リクエストやタスク（これらは別の Issue の種類です）の登録、既存の Issue のトリアージには、このスキルを使用しないでください。

フェーズ 1：リポジトリと種類の検出

gh auth status -h github.com
gh repo view --json nameWithOwner,hasIssuesEnabled --jq '{repo:.nameWithOwner, issues:.hasIssuesEnabled}'

Issue が無効になっている場合は停止します。リポジトリの所有者が Issue の種類を定義しているか、また Bug の種類が存在するかを検出します。

gh issue create --help | grep -q -- '--type' && echo "type-flag: supported"
gh api "repos/{owner}/{repo}" --jq '.owner.type' 2>/dev/null

次の方法を選択します。

• Bug Issue の種類 — 組織／リポジトリで Bug の種類が公開されている場合に優先します。--type Bug を使用します。
• bug ラベル — Issue の種類が存在しない場合のフォールバックです。ラベルを確認し、必要な場合にのみ作成するようにします。

gh label list --search bug --json name --jq '.[].name'

フェーズ 2：バグレポートの下書き

ユーザーが提供した情報からレポートを構成します。事実に基づいて記述し、手順、バージョン、挙動を決して捏造しないでください。不明な点には _not provided_ と記載します。

タイトル： 症状を具体的かつ簡潔にまとめます（「bug」や「it's broken」ではなく）。

本文（実際に該当しないセクションは省略します）：

## Summary
<one or two sentences: what is broken>

## Steps to Reproduce
1. …
2. …

## Expected
<what should happen>

## Actual
<what happens instead — include the error/stack trace verbatim if provided>

## Environment
<app/service, version or commit, OS/browser, anything relevant — or _not provided_>

## Notes
<links, related issues, suspected area — only if the user gave them>

ユーザーがスタックトレースやエラーを貼り付けた場合は、Actual の下にフェンス付きコードブロックで一字一句そのまま引用します。レポートの作成に不可欠な場合（例：症状がまったくない場合）に限り、簡潔な追加質問を 1 つだけします。それ以外は、現在ある情報で下書きを作成し、不足している点を記載します。

フェーズ 3：プレビューと確認

下書きした Issue の全内容（タイトル、本文、種類／ラベルの選択、そのほか適用するラベル／担当者／マイルストーン）を表示してから停止し、明示的な「はい」を待ちます。読み取り専用またはドライランのリクエストの場合はここで終了し、何も登録しません。

フェーズ 4：Issue の作成

確認を得てから、書式を保つために本文を現在のリポジトリの .tmp/ に書き込み、Issue を作成します。

推奨 — Bug Issue の種類：

REPO_TMP="$(git rev-parse --show-toplevel)/.tmp"
mkdir -p "$REPO_TMP"
gh issue create --title "<title>" --body-file "$REPO_TMP/bug_body.md" --type Bug

フォールバック — bug ラベル（ラベルが存在せず、ユーザーが同意した場合にのみ先に作成します）：

gh label create bug --color d73a4a --description "Something isn't working" 2>/dev/null || true
gh issue create --title "<title>" --body-file "$REPO_TMP/bug_body.md" --label bug

ユーザーが指定した値に限り、--assignee、--label、--milestone、または --project を追加します。--type Bug が種類の不在を理由に失敗した場合は、ラベルを使う方法に切り替え、その旨を伝えます。処理を失敗として終了してはいけません。

モード

• bug / bug <description> — フェーズ 1～4。下書きを作成し、確認して、課題を登録します。（デフォルト）
• bug draft — フェーズ 1～3。レポートの下書きを作成して表示するだけです。何も作成しません。

ユーザーがラベル、担当者、マイルストーン、重大度を指定した場合は、その指定に従います。バグではなく機能やタスクを依頼された場合は、このスキルではバグを登録すると伝え、適切な課題の種類を案内してください。

最終ステータス

以下を報告します。

• リポジトリと、課題が Bug として作成されたか、bug ラベルが付けられたか
• 作成した課題の番号と URL
• 適用したラベル、担当者、マイルストーン
• 次に行うこと（例：debug で根本原因を調査する、または github-fix-ci で失敗したチェックを修正する）