fix-issue

報告された問題を修正する

バグ報告は仕様ではありません。報告者の推測をそのまま受け入れると、報告者が調べた場所を調べ、症状が止まったところで調査を終えてしまいます。サブエージェントに報告を読ませ、観察できる事実だけを返してもらいます。コードから独自に仮説を立ててください。

自分でイシューを読んではいけません — gh issue view も、WebFetch も、そのファイルに対する Read も使わず、後で詳細を確認するために読むことも禁止です。抽出内容が不十分な場合は、SendMessage で抽出担当のエージェントに連絡してください。そのエージェントのコンテキストには、引き続き報告が残っています。

1. 事実を抽出する

general-purpose エージェントを1つ起動し、run_in_background: false を指定して、引数を変更せずに渡します。

にあるバグ報告を読んでください。GitHub のイシューの場合は gh issue view <n> --comments を使用してください。 パスが指定されている場合は、そのファイルを読んでください。

事実に基づく概要を返してください。エンジニアが目にするのは、あなたの出力だけです。

報告に記載されている場合に限り、以下をそれぞれ含めてください。

• 症状 — ユーザーが観察したことを、1〜2文で記述します。
• 期待される動作 — ユーザーが期待していた動作を記述します。
• 再現手順 — 正確な手順、入力、データを記載します。原文のまま記載し、決して短縮しないでください。
• 証拠 — エラー、トレースバック、ログ、レスポンスボディを記載します。原文のまま、省略せず記載してください。
• 環境 — バージョン、ブランチ、データベース、ブラウザー、デプロイの種類を記載します。
• 範囲 — 常時発生するか、断続的か、1人のユーザーか全員か、いつ発生し始めたかを記載します。

以下は除外してください。提案された修正、パッチ、PR へのリンク、原因や報告者が疑っているファイル、関数、コミットに関する推測、「私は思う」「おそらく」「〜のようです」といった表現、重大度、緊急度、非難、賛同のコメント、挨拶、ボットのコメント、症状の繰り返し。

トレースバックは証拠です — ファイル名が含まれていても、そのまま残してください。コメント投稿者が「バグは x.py にある」と書いている場合、それは推測なので除外してください。

最後に 不足情報 を記載してください。再現に必要だが報告に記載されていない情報を挙げます。情報がそろっている場合は「なし」としてください。

コードベースを読んだり、何かを検証したり、意見を述べたりしないでください。400語以内とし、引用ブロックは除きます。

2. 修正前に再現する

概要に基づいて症状を再現します。次のいずれかに該当する場合は、ここで作業を終えます。どれも報告してよい結果です。再現できず、概要に不足情報が記載されている。再現できず、概要に必要な情報がそろっている（ログを検索して、すでに修正したコミットがないか確認する）。または、再現できたが動作は正しい。

3. 原因を自分で見つける

失敗箇所からコードをさかのぼって調べます。報告が示すのは症状が表面化した箇所であり、欠陥の場所ではありません。原因を修正してください。症状にしかたどり着けない場合は、黙ってパッチを当てるのではなく、その旨を伝えてください。

4. 修正して検証する

原因を取り除くための最小限の変更にとどめます — リファクタリングや、隣接する問題の修正は行いません。変更がなければ失敗する回帰テストを追加し、変更の有無の両方で実行します。次に、関連するテストモジュールと pre-commit run --files <changed files> を実行します。

5. 別のエージェントでレビューする

general-purpose エージェントを1つ起動し、run_in_background: false を指定します。

frappe-code-review スキルを読み込み、作業中の差分（git diff と、追加した未追跡ファイル）をレビューしてください。この変更は次のバグを修正するものです。

<ステップ1の「症状」と「期待される動作」の行を貼り付ける>

次の2点を判断してください。この変更は症状を覆い隠すのではなく、原因を取り除いてバグを止めているか。スキルのチェックリストを満たしているか。対処する価値のある指摘のみを、重要度の高い順に報告してください — ファイルと行、何が誰に影響するか、修正方法を記載します。差分の概要は不要です。対処する価値のある指摘がなければ、その旨を1行で述べてください。

指摘に対応し、テストを再実行します。

6. 報告する

4〜6行で、原因、変更内容、テスト、レビュー結果、未解決事項を報告します。求められた場合にのみコミットしてください。コミットする場合は、コミットメッセージの作成に technical-writing を読み込み、共著者のトレーラーは追加しないでください。