jira-cr

Jira 変更リクエスト（CR）スキル

このスキルでは、指定された Jira チケットの変更リクエスト（CR）概要をエージェントが作成し、依頼された場合はコメントとして投稿します。現在のタスクからリポジトリと Jira サイトを特定してください。このスキルは単独でインストールして使用できます。

トリガー

ユーザーによる呼び出し：/jira-cr — Jira チケットの CR 概要の作成を依頼された場合（例：「PROJ-001 の CR を作成して」、「[Ticket ID] で jira-cr を実行して」）、このスキルを明示的に使用してください。

ワークフローの手順

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

   • 機能ごとに利用可能な Jira ツールを特定してください：サイトの検出、課題の取得、コメントの一覧表示、コメントの作成。ツール名はエージェントによって異なります。固定の MCP 名前空間やシェルツール名を想定せず、設定されている同等のツールを使用してください。
   • ユーザーとプロジェクトのコンテキストから、対象サイトと課題キーを特定してください。候補となるサイトが複数残る場合は、選択する前に確認してください。
   • 課題と既存のコメントを取得してください。該当する過去の概要が見つかるか、利用可能なコメントをすべて確認するまで、コメントのページネーションを続けてください。アクセスが不完全な場合は、その制限を明示し、過去の概要が存在しないと断言しないでください。
   • 課題から 概要、説明、受け入れ条件（AC） を抽出してください。

2. 以前の CR 概要を検出する：

   • 既存のコメントを確認し、過去に投稿された CR 概要がないか探してください。バナー行（初回の概要では「AI-generated CR summary」、更新では「Updated CR summary」）または任意のレベルの Story & CR 見出しを手がかりに検出します。コメント本文は異なるマークアップ形式で返される場合があるため、文字列の先頭に # があることを前提にしないでください。該当するものが複数ある場合は、最も新しいものを使用してください。
   • 以前の概要のコメント ID、投稿日時、言語、および差分から再生成できない情報（スクリーンショットなど）を記録してください。

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

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

4. 分析して比較する：

   • Jira チケットで定義された受け入れ条件と、選択したコード変更を比較します。
   • すべての AC を根拠とステータスに対応付けます。ステータスは「実装済み・検証済み」「実装済み・未検証」「一部実装」「調査対象の範囲では未実装」「不明」とします。変更が存在しない場合と、周辺コードにすでに存在する機能を区別します。
   • 以前の AC のステータスや履歴は履歴上の根拠として保持し、ステータスを変更する場合は、その変更理由を説明します。黙って置き換えてはいけません。
   • コードベース内の影響を受ける領域（Configurations、Modules、Features、Components）を特定し、チームのテンプレート例に沿って製品の用語で説明します。Modules はモジュール名（例：Order）、Features は画面上の機能名、Components は画面またはウィジェットのパス（例：Worklist > Inpatients widget）、Configurations は適用対象のサイトを含む設定切り替え名です。テンプレートにはファイル名やクラス名を含めないでください。
   • 実際に実行したチェックとその結果、および実行していないチェックを報告します。コードの調査だけでは、実行時の正確性や受け入れ条件を完全に満たしていることは確認できません。
   • API に関する作業では、コードから確認できる範囲で、エンドポイント／メソッド、関連するリクエストフィールド、認可、処理とソースデータの解決方法、重複時の動作、レスポンスステータス、適用範囲を説明します。契約が不明な場合は、明示的に不明と記載します。

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

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

   # Story & CR
   
   **Summary** - [Brief one-line summary of what was implemented, noting if it fully meets AC.]
   
   **Affected Areas** - [Comma-separated list of major areas impacted]
   
   | Summary                   | Screenshots |
   | :------------------------ | :---------- |
   | 1. [What the change does for this criterion, with status] | [Image or evidence status] |
   | 2. [What the change does for this criterion, with status] | [Image or evidence status] |
   
   | Affected Areas | Descriptions     |
   | :------------- | :--------------- |
   | Configurations | [Details or N/A] |
   | Modules        | [Details or N/A] |
   | Features       | [Details or N/A] |
   | Components     | [Details or N/A] |
   

   • 行には番号を付けますが、AC1 や AC2 のラベルは記載しません。チーム向けの例では、各基準を直接説明します。
   • **Atlassian Document Format（ADF）**は公開用の形式です。Markdownテンプレートで定義するのは内容と順序であり、本文の構文そのものではありません。version: 1、type: "doc"、順序付きのcontentノードを含むJSONドキュメントを作成します。
     • セクションにはheadingノードとparagraphノードを使用します。両方の表にはtable、tableRow、tableHeader、tableCellノードを使用し、Summary表では行ごとに番号付きの基準を1つ記載します。
     • レベル1のStory & CR見出しには、#36b37eを使用してstrongとtextColorの両方のマークを適用します。
     • 表のセルの内容は、有効なADFブロックノードにします。ADFドキュメント構造、ADFテーブルノード、ADF textColorマークを参照してください。
   • ADFを使用してAtlassian MCP経由で公開する：contentFormatがadfを受け付けるAtlassian MCPのコメントツール（例：addCommentToJiraIssue）を使用します。まずライブスキーマを確認し、contentFormat: "adf"を設定して、commentBodyが期待する形式でADFドキュメントを渡します。commentBodyが文字列の場合は、シリアライズしたJSONドキュメントを送信します。
     • このSummaryには、markdownまたはhtmlしか受け付けないコメントツール（例：addOrEditJiraIssueComment）を使用しないでください。
     • ADFを受け付けるAtlassian MCPのコメントツールが利用できない場合は、公開しないでください。ADFの下書きを返し、確認したツール名をユーザーに伝えてください。
   • チーム全体（開発者、BA、QA）に向けて書く：コードを読まなくても、読者が各行の内容を理解できるようにします。
     • 各行はユーザーの視点から説明します。画面名を使い、ユーザーが行う操作と表示される内容を記載します。避けられない技術用語は説明してください。
     • ステータスはそれぞれ、Summaryの言語で平易に記載します。タイ語ではทำแล้ว ทดสอบผ่าน、ทำแล้ว ทดสอบไม่ผ่าน、ทำแล้ว ยังไม่ได้ทดสอบ、ทำบางส่วน、มีอยู่เดิมก่อนการ์ดนี้、ยังยืนยันไม่ได้を使用します。テスト済みのステータスは、実際にチェックが実行または報告された場合にのみ使用し、必ず結果も記載します。単にทดสอบแล้วとは記載しません。コードを読むことはテストではありません。範囲を数語で添え、別の人が実行した場合は実施者も記載します。例：ทดสอบผ่านบน UAT โดย QA (comment 170406)。
     • BeforeとAfterのスクリーンショットが両方ある場合は、Screenshotsセルにセットで掲載します。
     • Featuresセルに、変更の影響を受ける可能性のある関連画面や機能を呼び出し元の確認によって特定し、ควรทดสอบซ้ำ:の行に記載します。呼び出し元を確認していない場合は、この行を省略します。
     • チケットで求められていない動作には、BAとQAが確認できるようにFeaturesセル内で(เพิ่มนอกเกณฑ์)を付けます。
     • 投稿する前にコメントを読み直し、冗長な表現、重複した内容、機械が書いたような表現を削除します。

6. 下書きと公開：

   • チケットに初めて CR サマリーを投稿する場合：冒頭に、確認した変更範囲に基づく AI 生成の CR サマリーであることを簡潔に記載します。

   • 以前の CR サマリーがすでにある場合：新しいコメントから以前のサマリーを参照し、読者が更新履歴を追えるようにします。

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

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

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

   • 公開前に、対象の課題を確認し、関連する以前のサマリーを読み直して、重複や新しい更新の上書きを避けます。分析中に選択した変更箇所が移動していた場合は、証拠を更新してから下書きを作り直します。

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

   • 上記で選択した Atlassian MCP コメントツールを使用して、確認済みの課題に ADF コメントを投稿します。

7. 結果を確認する：

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