jira-bug

Jira バグコードレビューのスキル

このスキルは、指定された Jira チケットのバグコードレビュー（Bug CR）サマリーを生成し、要求された場合にコメントとして投稿できるようエージェントをガイドします。現在のタスクからリポジトリと Jira サイトを特定してください。このスキルは単独でインストールして使用できます。

トリガー

ユーザーが実行：/jira-bug — Jira チケットのバグ CR サマリーの生成を依頼された場合（例：「PROJ-001 のバグ CR を作成して」、「[Ticket ID] に対して jira-bug を実行して」）、このスキルを明示的に使用します。

ワークフローの手順

1. Jira チケット情報を取得する：

   • 機能に基づいて、利用可能な Jira ツールを特定します。サイトの特定、課題の取得、コメントの一覧表示、コメントの作成が対象です。ツール名はエージェントによって異なるため、固定の MCP 名前空間やシェルツール名を想定せず、設定済みの同等ツールを使用します。
   • ユーザーとプロジェクトのコンテキストから、対象のサイトと課題キーを特定します。候補となるサイトが複数残る場合は、いずれかを選ぶ前に確認します。
   • 課題と既存のコメントを取得します。関連する過去のサマリーが見つかるか、利用可能なコメントをすべて確認するまで、コメントのページネーションを続けます。アクセスが不完全な場合は、その制限を明記し、過去のサマリーが存在しないと断言しないでください。
   • 課題からサマリー、説明、およびバグの再現手順や期待される結果を抽出します。

2. 過去のバグサマリーを検出する：

   • 既存のコメントを調べ、以前に投稿されたバグ CR サマリーを探します。バナー行（初回サマリーの場合は「AI-generated Bug CR summary」、更新の場合は「Updated Bug CR summary」）または任意のレベルの Bug 見出しを手掛かりに検出します。コメント本文のマークアップ形式が異なる場合があるため、文字どおりの # 接頭辞に依存しないでください。「Bug」という単語だけで始まるコメントは該当しません。複数見つかった場合は、最も新しいものを使用します。
   • 過去のサマリーのコメント ID、投稿日時、言語、および差分から再生成できない詳細（スクリーンショット、ホットフィックスのバージョン一覧など）を記録します。

3. 変更範囲を特定して確認する：

   • リポジトリの指示、Git の状態、ブランチ、リモートを確認します。ユーザーがステージ済みの変更、コミット、ブランチ、MR、PR の範囲を明示している場合は、まずそれに従います。
   • ステージ済みの変更では git diff --cached を確認します。特定のコミットでは、そのパッチと親コミットを調べます。コミット範囲では、指定されたすべてのコミットと結果の差分を調べます。ブランチでは、ベースを確認し、ブランチ全体の差分を比較します。MR／PR では、関連する参照を取得したうえで、検証済みのソース／ターゲット参照と完全な差分を読みます。
   • 範囲が指定されていない場合は、現在のタスク、該当するチケットブランチ、既存の MR／PR から推定します。ステージ済み差分が空であることは、実装が存在しない証拠にはなりません。候補となる範囲が複数あり、サマリーの内容が異なる場合は、焦点を絞った質問を一つだけします。
   • 該当する場合は、リポジトリ、範囲のモード、ベース／ヘッド SHA、変更ファイル数を記録します。ステージ済みの作業には新しいコミット SHA がありません。コミット済みであるかのように示さず、ステージ済みのスナップショットと現在の HEAD を特定します。
   • 動作を理解するため、関連する周辺コード、呼び出し元、テストを確認します。このサマリーを生成する目的だけで、ファイルをステージしたりコミットしたりしないでください。無関係な変更と機密情報は除外します。

4. 分析して比較する：

   • 選択したコード変更を、Jira チケットに記載されたバグの詳細と期待される動作に照らして比較します。
   • トリガー、期待される動作と実際の動作、確認された原因または残っている仮説、そして変更が問題にどう対処するかを説明します。コードの調査結果と、再現確認および回帰テストの証拠は分けて記載します。
   • コードベースで影響を受ける領域（Configurations、Modules、Features / Issues、Components）を特定し、チームのテンプレート例にならって、製品上の名称で説明します。Modules はモジュール名（例：Order）、Features / Issues は画面上の機能名または確認された問題、Components は画面またはウィジェットのパス（例：Worklist > Inpatients widget）、Configurations は適用されるサイトを含む設定の切り替え名です。テンプレートにはファイル名とクラス名を記載しません。
   • 実際に実行した確認項目とその結果、未実施の確認項目を報告します。コードの調査だけでは、実行時の正しさや受け入れ条件をすべて満たすことは証明できません。
   • API に関する作業では、コードから確認できる範囲で、エンドポイント／メソッド、関連するリクエストフィールド、認可、処理およびソースデータの解決方法、重複時の動作、レスポンスステータス、対象範囲を説明します。仕様が不明な箇所は、その旨を明示します。

5. 次のテンプレートを使用して要約します：

   • 以下のバグテンプレートの見出しと表を維持し、ほかのセクションは追加しません。各行のステータス、結果、簡潔な対象範囲を表に記載します。コメントではなく、返信でユーザーに実行したコマンドとログを報告します。

   # Bug
   
   **Summary** - [Provide a brief one-line summary of the change or issue fixed.]
   
   **Affected Areas** - [List the specific configurations, modules, features, or components that are impacted by this change or issue.]
   
   | Summary                                                             | Screenshots |
   | :------------------------------------------------------------------ | :---------- |
   | 1. [Provide a brief one-line summary of the change or issue fixed.] | [Image or evidence status] |
   
   | Affected Areas    | Descriptions                                                 |
   | :---------------- | :----------------------------------------------------------- |
   | Configurations    | [Details or N/A]                                             |
   | Modules           | [Details or N/A]                                             |
   | Features / Issues | [Details or N/A]                                             |
   | Components        | [Details or N/A]                                             |
   | Version           | The list of versions must be hotfix after this card is done. |
   

   • テンプレートの Version 行の文言は開発者向けの指示であり、記載内容ではありません。チケット、ユーザー、または前の要約で提供された場合は、ホットフィックスを適用するバージョンの一覧に置き換えてください。一覧が不明な場合は指示文をそのまま残し、返信で一覧が提供されていないことをユーザーに伝え、バージョンを推測しないでください。
   • Atlassian Document Format（ADF）：Markdown テンプレートが定義するのは内容と順序であり、本文のリテラルな構文ではありません。コメントツールが ADF を受け付ける場合は、version: 1、type: "doc"、順序付きの content ノードを含む JSON ドキュメントを送信してください。
     • セクションには heading ノードと paragraph ノードを使用してください。両方の表に table、tableRow、tableHeader、tableCell ノードを使用してください。
     • レベル1の Bug 見出しには、#ff5630 を指定した strong と textColor の両方のマークを適用してください。
     • 各バグ行の番号は、Summary の tableCell 内の段落に記載してください。その後に、詳細ごとに1つの listItem を含む bulletList を続けてください。ADF ドキュメント構造、ADF テーブルノード、ADF textColor マークを参照してください。
   • コメント本文の形式：公開する前に、実際のコメントツールのスキーマを確認してください。ツールが ADF を受け付ける場合に限り、ADF オブジェクトを送信してください。contentFormat: adf を前提としたり、ADF を文字列としてシリアライズしたりしないでください。
     • 現在の Atlassian MCP コメントツールが受け付けるのは Markdown または HTML 文字列であり、生の ADF オブジェクトではありません。
     • HTML テーブルを使用する場合は、addOrEditJiraIssueComment に対するそのツールの getContentFormatGuide に従ってください。必要な表の構造と書式がガイドでサポートされている場合に限り、HTML を使用してください。
   • Markdown へのフォールバック：ツールが ADF を受け付けず、HTML ガイドでも必要な書式がサポートされていない場合は、Markdown を使用してください。Markdown の表のセルは1行にしてください。バグごとに1行とし、セルの各部分は / でつないでください。セル内に入れ子のリストや改行を使用しないでください。書式が失われた場合はユーザーに伝えてください。ユーザーが ADF を明示的に要求しており、ADF を受け付けるツールがない場合は、Markdown を公開せず、ADF の下書きを返してください。
   • バグ行：Summary の各行は、番号付き項目1つと、短い箇条書き4つで記述してください。項目は 何が起きたか、原因、何を修正したか、修正後どうなったか です。ADF ではセル内に入れ子の箇条書きを使用してください。Markdown にフォールバックする場合は、4項目を1行にまとめ、たとえば 何が起きたか：... / 原因：... / 何を修正したか：... / 修正後どうなったか：... のように記述してください。確認済みの原因を明記してください。原因が未確認の場合は 推定 と明記し、まだ確認していないことを説明してください。エラーを隠すだけのガードは、ドメインの契約に合致しない限り、修正として提示しないでください。
   • チーム全体（開発者、BA、QA）向けに記述する：読者がコードを読まなくても各行を理解できるようにしてください。
     • 各行はユーザーの視点で記述し、ユーザーが何を操作し、何を目にするかを画面名とともに説明してください。避けられない技術用語は説明してください。
     • 各ステータスは、要約と同じ言語で平易に記述してください。タイ語では テスト合格、テスト不合格、未テスト、未確認 を使用してください。再現の再実行、UAT の結果、テスト実行など、実際に確認または報告された場合にのみ、テスト済みのステータスを使用し、必ず結果を明記してください。対象範囲を短く記載し、他の人が実施した場合は情報源も記載してください。例：QA が UAT でテスト合格（comment 170406）。単に テスト済み とだけ書かないでください。コードを読むことはテストではありません。
     • 修正前と修正後のスクリーンショットが両方ある場合は、Screenshots セルに両方を記載してください。
     • Features / Issues セルには、呼び出し元を確認して、修正の影響を受ける可能性がある関連画面または機能を記載する 再テスト推奨： の行を追加してください。呼び出し元を確認していない場合は、この行を省略してください。
     • バグの要求に含まれていない動作は、BA と QA が確認できるよう、Features / Issues セルで (このバグの範囲外で追加) と明記してください。
     • 投稿前にコメントを読み直し、不要な記述、重複した内容、機械的に聞こえる表現を削除してください。

6. 下書きと公開：

   • チケットの最初のバグ概要：確認した変更範囲に基づく AI 生成のバグ CR 概要であることを示す短い一文を冒頭に追加します。

   • 以前のバグ概要がすでにある場合：読者が更新履歴をたどれるよう、新しいコメントで以前の概要に言及する必要があります。

     • 初回投稿用の一文ではなく、更新を示すバナーで始めます。例：> 🔄 Updated Bug CR summary — supersedes the previous summary posted on 2026-08-19 (comment 400128). 可能であれば、以前のコメントへのリンクを付けます：https://<site>.atlassian.net/browse/<TICKET>?focusedCommentId=<commentId>#comment-<commentId>。
     • 変更点のセクションは追加しません。表をその場で更新します。以前の概要に記載された内容が現在のコードと矛盾する場合は、表を修正し、バナーの一文でその修正について述べます。
     • 差分から再生成できない情報（例：スクリーンショット、ホットフィックスの Version リスト）のうち、引き続き有効なものは引き継ぎ、黙って削除するのではなく、引き続き有効であることを明記します。
     • ユーザーが別の言語を指定しない限り、以前の概要と同じ言語を使います。

   • 言語とスクリーンショット：初回の概要では、ユーザーまたはリポジトリの指示で別の指定がない限り、チームテンプレートの例の言語（英語の製品名と UI 名を含むタイ語）を使います。画像がある場合は追加します。画面のない修正の場合は、修正前後のテスト出力、API レスポンス、またはデータベースレコードを使用します。各行に画像を付ける必要はありませんが、セルを空欄にしないでください。画像が必要でまだ添付されていない場合は、รอแนบภาพ と記入し、添付する内容（例：รอแนบภาพ: ผลรัน test）を明記します。画像が不要な場合は、ไม่มีภาพ と記入します。画像を引き継ぐ場合は、ภาพเดิมใน comment <id> と記入します。Summary セルには合格または不合格の結果を記載し、このテキストに色を付けないでください。

   • コメント全体を先に作成します。要約またはレビューの依頼は、公開が明示的に依頼されていない限り、ローカルの下書きで終了します。ユーザーがすでに投稿を依頼している場合は、再度確認せずに続行します。公開が必要でまだ承認されていない場合は、完成してレビュー可能な下書きのみについて承認を求めます。

   • 公開前に、重複投稿や新しい更新の上書きを避けるため、対象の課題を確認し、関連する過去の概要を読み直します。分析後に対象の変更内容が更新されている場合は、根拠を再確認してから下書きを更新します。

   • 既存のコメントは保持します。このワークフローでは、履歴を削除または上書きせず、リンク付きのフォローアップコメントを作成します。

   • 利用可能な Jira のコメント作成ツールと、そこでサポートされる本文形式を使って、確認済みの課題に投稿します。

7. 結果を確認する：

   • 投稿後、作成したコメントを取得し、対象の課題、本文、リンクを確認します。書き込み結果が不確かな場合は、重複投稿を避けるため、再試行する前に既存のコメントを調べます。
   • コメントへのリンクと公開状況を返すか、下書きとして明示します。確認やテストの制約は明記し、証拠なしに公開が成功したと主張しないでください。