jira-sprint-dashboard

Jira スプリントダッシュボード

エンジニアリングマネージャー、テックリード、またはシニアエンジニアが、注意が必要な項目を判断できるよう、現在の Jira の作業状況をすばやく確認できる、焦点を絞ったダッシュボードを作成します。出力はダッシュボードであり、文章形式のレポートでも、汎用的な健全性スコアでもありません。

このスキルは、デフォルトでは読み取り専用です。ユーザーがダッシュボードを確認した後で書き込み操作を明示的に依頼しない限り、Jira の作業項目を作成、更新、トランジション、割り当て、コメントしないでください。

出力モード

現在の環境でサポートされている、最も充実したダッシュボードレンダラーを使用します。レンダラーが異なっても、ダッシュボードの内容、主張、件数、ソースの付録は一貫させてください。変わるのは表示方法だけです。

次の順にレンダラーを選択します。

1. Canvas に対応した Cursor で実行している場合は、Cursor Canvas。
2. 現在のエージェントが HTML、React、または同様のアーティファクト出力に対応している場合は、インタラクティブアーティファクト。
3. ファイルを作成でき、それが有用な場合は、静的 HTML ファイル。
4. それ以上に優れたビジュアルレンダラーが利用できない場合は、Markdown ダッシュボード。
5. ビジュアルレンダリングが不可能な場合に限り、構造化 JSON と簡潔な概要。

ユーザーが Cursor Canvas を明示的に求めていない限り、Cursor Canvas を利用できないことに言及しないでください。ユーザーが一般的なダッシュボードを求めている場合は、環境について謝罪せず、利用可能な最適なレンダラーを使用してください。

Cursor Canvas レンダラー

Canvas に対応した Cursor で実行している場合にのみ、このセクションを使用してください。

Canvas のコードを書く前に ~/.cursor/skills-cursor/canvas/SKILL.md を読んでください。エクスポートやプロパティの正確な形状を確認する必要がある場合は、~/.cursor/skills-cursor/canvas/sdk/ 内のファイルを読んでください。

Canvas の制約：

• Cursor の canvases ディレクトリに .canvas.tsx ファイルを 1 つ作成してください。
• cursor/canvas からのみインポートしてください。react、CSSProperties、JSX、Atlaskit、その他のパッケージはインポートしないでください。
• Jira のデータを Canvas 内に直接埋め込んでください。Canvas からデータを取得しないでください。
• 生の HTML よりも、Stack、Grid、Card、Stat、Table、Pill、Callout、UsageBar、BarChart、LineChart、PieChart、Code などの Canvas プリミティブを優先してください。
• カスタムスタイルには useHostTheme() を使用してください。16 進数カラー、グラデーション、ボックスシャドウ、ADS 変数、未対応の CSS フレームワーク、@atlaskit/* をハードコードしないでください。
• ユーザーから依頼されない限り、Canvas を公開または共有しないでください。

ポータブルレンダラー

Cursor Canvas が利用できない場合は、このセクションを使用してください。

インタラクティブアーティファクトレンダラーの場合：

• 同じダッシュボードモデルをインタラクティブアーティファクトとしてレンダリングしてください。
• テーブル、コンパクトなチャート、統計行、折りたたみ可能なソース詳細を優先してください。
• 操作は軽量なものにしてください。フィルタリング、詳細の展開、チャートとテーブルの表示切り替えは問題ありません。アーティファクトから Jira へのライブ取得を必須にしないでください。

静的 HTML の場合：

• データを埋め込んだ自己完結型のダッシュボードファイルを作成してください。
• チャートライブラリが利用できない場合は、レスポンシブなレイアウト、アクセシブルなテーブル、シンプルなチャート風のビジュアルを使用してください。
• HTML ファイルから Jira のデータを取得しないでください。

Markdown の場合：

• ダッシュボードの順序を維持してください。
• 統計、担当者の負荷、リスク、優先度の高い作業、ソースの付録には、コンパクトなテーブルを使用してください。
• 件数、割合、シンプルなバーなど、正確性を保てる場合に限り、テキストによるチャート表現を使用してください。
• 出力が長文のレポートにならないようにしてください。

JSON フォールバックの場合：

• 正規化されたダッシュボードモデルを返してください。
• 最も重要なリスクとソースの範囲を含む、人が読みやすい簡潔な概要を添えてください。

対象範囲の特定

Jira の対象範囲を推測しないでください。ユーザーがプロジェクトキー、スペースキー、ボード、スプリント、フィルター、JQL、作業項目キー、または Jira の URL を指定していない場合は、処理を止めて確認してください。たまたま表示されているプロジェクトや、推測したチームのコンテキストに基づくダッシュボードは、ダッシュボードがないよりも悪い結果になります。

ユーザーがプロジェクトキーまたはスペースキーを指定していて、スプリント、ボード、フィルターを指定していない場合は、Jira JQL の project フィールドとユーザーのキーを使って開始します。

project = "SPACE_KEY" AND sprint in openSprints() ORDER BY Rank ASC

オープンスプリントの結果が空、古い、または誤解を招く場合は、スナップショットモードに切り替え、その旨をトップバーの下に簡潔な注意書きとして記載してください。

project = "SPACE_KEY" AND statusCategory != Done ORDER BY priority DESC, updated ASC
project = "SPACE_KEY" AND updated >= -60d ORDER BY updated DESC

ユーザーが別の期間を指定しない限り、デフォルトでは直近 60 日間の変動を対象にします。

すべてのボードがスプリントに対応しているわけではありません。タイプが simple のチーム管理ボードにはスプリントがありません。sprint in openSprints() は何も返さず、ボードのスプリント検索は「The board does not support sprints」というエラーになります。これを再試行すべきエラーではなく、スナップショットモードに直接切り替えるべき合図として扱ってください。

Jira のクエリ

読み取り専用の Jira 検索を使用します。ダッシュボードに必要なフィールドのみを要求し、フィールドが欠落していても処理できるようにします。

有用なフィールド：key、summary、status、statusCategory、assignee、 priority、issuetype、created、updated、resolutiondate、duedate、 parent、issuelinks、labels、components、fixVersions、sprint、および 利用可能な見積もり／ストーリーポイントのフィールド。

スプリントとストーリーポイントはカスタムフィールドに格納されており、デフォルトのレスポンスには含まれません。 Jira の検索はデフォルトで簡易ビューを返すため、スプリントが進行中でも、そこから作成したスプリントダッシュボードにはスプリント情報が表示されません。これらを取得するには、view: "evidence"（または "full"）を渡すか、このサイトの customfield_* ID を明示的に要求してください。ID は Cloud サイトごとに異なります。カスタムフィールドの値は、トップレベルの customfield_* キーではなく、fields.customFields の下に返されます。

最初は maxResults: 100 を指定します。スプリント、ボード、またはフィルターのダッシュボードを完全に作成する場合は、対象範囲を網羅するまで、または作業項目単位での表示が実用的でなくなるほど大きくなるまでページネーションします。

デフォルトでは、対象範囲全体をページネーションで取得するクエリを 1 つ実行します。シグナルごとに個別の JQL を実行するのではなく、返された作業項目セットから通常のダッシュボードシグナルをローカルで導出します。

対象範囲のクエリで必要なフィールドが返された場合は、以下をローカルで導出します。

• 最近完了した項目：statusCategory = Done と resolutiondate から導出します。
• 長期間未完了の項目：statusCategory != Done と updated から導出します。
• 担当者のいない未完了項目：statusCategory != Done と空の assignee から導出します。
• 優先度の高い未完了項目：statusCategory != Done と priority から導出します。
• ステータスまたはラベルによるブロッカー：status、statusCategory、labels から導出します。
• 担当者の負荷、停滞している作業、期限リスク、計画上の不足：正規化された対象範囲のデータセットから導出します。

表示する主張を安全に導出できない場合、対象範囲がローカル処理に適さないほど大きい場合、またはユーザーがシグナルごとの正確な根拠を示す監査形式のダッシュボードを求めている場合に限り、対象を絞った追加クエリを使用します。

目安：

• 小規模または中規模のスプリントダッシュボード：対象範囲全体をページネーションで取得するクエリを 1 つ実行します。必要な場合でも、ブロッカーのテキストまたは依存関係のステータスを確認する対象限定クエリは最大 1 つにします。
• 大規模な対象範囲のダッシュボード：作業項目全体の取得と処理に時間がかかる場合や価値が低い場合は、範囲を絞った追加クエリを使用します。
• 根拠を重視するレビュー：呼び出し回数の最小化よりも正確な JQL の根拠が重要な場合は、焦点を絞った複数のクエリを使用できます。

正当な理由がある場合に限り使用する、対象を絞った追加クエリの例：

• 最近完了した項目：<scope> AND statusCategory = Done ORDER BY resolutiondate DESC
• 長期間未完了の項目：<scope> AND statusCategory != Done AND updated <= -3d ORDER BY updated ASC
• 担当者のいない未完了項目：<scope> AND statusCategory != Done AND assignee is EMPTY ORDER BY priority DESC, updated ASC
• 優先度の高い未完了項目：<scope> AND statusCategory != Done AND priority in (Highest, High) ORDER BY priority DESC, updated ASC
• ブロッカーのシグナル：<scope> AND statusCategory != Done AND (status = Blocked OR text ~ "blocked" OR labels in (blocked, blocker)) ORDER BY priority DESC, updated ASC

「ブロッカーはない」や「依存関係はない」など、否定的な主張は、その根拠となるクエリまたはフィールドの取得範囲がソース付録に示されていない限り行わないでください。ブロッカーについてステータスとラベルのみを確認した場合は、「ステータス／ラベル上のブロッカーは見つかりませんでした」と記載し、ブロッカーが存在しないと断定しないでください。シグナルを確認していない場合は、その旨を記載してください。

導出したシグナルについては、個別の裏付けクエリを新たに作らず、ソース付録に基となる対象範囲の JQL とフィールドの取得範囲を記載してください。追加の JQL を含めるのは、実際に実行した対象限定の追加クエリに限ります。

作業項目のリンク（issuelinks）については、可能であればリンク先作業項目のステータス／カテゴリを取得します。リンク先の詳細を取得できない場合は、依存関係のステータスを解決済みではなく不明として表示します。

正規化

出力を設計する前に、コンパクトでレンダラーに依存しない作業項目モデルを作成します。次の項目を含めます。

• キー、URL、概要、タイプ、ステータス、ステータスカテゴリ、優先度
• 担当者の表示名、または Unassigned
• 担当者のステータス（active、inactive、unknown、unassigned）
• 作成からの経過時間、更新からの経過時間、完了済みの場合は解決からの経過時間、期限までの日数
• 親／エピック／ワークストリーム、スプリント、見積もり、コンポーネント、バージョン、ラベル
• リンクされた作業項目のキー、方向、リンクタイプ、取得可能な場合はリンク先のステータス

派生シグナルは、Jira の事実情報から根拠を説明できるものにします。完了、進行中、未着手、停滞、長期停滞、ブロック中、担当者なし、非アクティブな担当者、時間的制約あり、サポートへの影響あり、スペース間の依存関係、計画データの欠落を示します。テキストだけに基づく確度の低いシグナルには、推定であることを明記します。

ダッシュボードモデル

レンダリングの前にダッシュボードモデルを作成します。すべてのレンダラーで同じモデルを使用します。

次の項目を含めます。

• コンテキストメタデータ：タイトル、プロジェクトまたはスペース、スプリント、ボード、フィルター、JQL、期間、クエリ実行日時、モード
• 上部に表示する 4 つの統計：コミット済みの範囲または総範囲、完了または完了済み、進行中または作業中、要注意
• スプリントデータが欠落している場合、混在している場合、古くなっている場合、または最近のプロジェクトの動きと混在している場合に限り、対象範囲に関する注記
• 実データがある場合に限り、任意のキャパシティまたはコミットメントの内訳
• カテゴリ、値、単位、期間がそろっている場合に限り、任意のグラフデータ
• 担当者ごとの作業負荷と不足
• リスク項目と要注意項目
• 優先度の高い作業項目テーブル
• 最近完了した項目
• 正確な JQL、対象フィールド、前提条件、要注意 の構成を記載したソース付録

モデルを埋めるためにデータを捏造しないでください。空のセクションや裏付けのないセクションは省略します。

ダッシュボードの構成

表示するダッシュボードは、シンプルで一貫性のある構成にします。データがある場合は、全体として次の順序にしてください。

1. 簡潔なコンテキストヘッダー

   • タイトルと、プロジェクト、スペース、ボード、スプリント、または期間のメタデータを表示します。
   • 短くまとめます。クエリ、フィールドの網羅状況、エグゼクティブサマリーの文章を先頭に置かないでください。

2. 上部の4つの統計情報

   • 統計値を正確に4つ表示します。
   • デフォルトでは、コミット済み／合計、完了済み、進行中、要注意を表示します。
   • ストーリーポイントを利用できない場合は、作業項目数を使用します。
   • 要注意には、最も重要度の高いリスクをまとめます。対象は、ブロック中、長期間更新なし、未割り当て、期限が迫っている、未解決の関連作業です。
   • 補足の件数は、表示内容の判断に影響する場合に限り、スクロール後に表示します。

3. スコープに関する注記（必要な場合のみ）

   • スプリントデータが欠落している、混在している、古い、または最近のプロジェクトの進捗と組み合わされている場合は、上部の統計情報の下に簡潔な注記を1つ表示します。
   • 1～2文の短い文章にします。

4. キャパシティまたはコミットメントのバー

   • キャパシティ、コミットメント、または割り当てセグメントのデータがある場合に限り、キャパシティまたはコミットメントを視覚化します。
   • キャパシティ、セグメント、またはバッファの値を捏造するくらいなら、表示を省略します。

5. スプリントチャート

   • 利用可能な場合は、残作業の推移を折れ線グラフで表示します。
   • その横に、ステータス分布を円グラフまたは簡潔なステータス表示で示します。
   • その下に、稼働日ごとの解決済み／完了数を棒グラフで表示します。
   • カテゴリ、値、単位、または期間が不明なチャートは省略します。プレースホルダー、サンプル、空、または推測に基づくチャートは表示しないでください。

6. 担当者の負荷とギャップ

   • 担当者ごとに、進行中、長期間更新なし、ブロック中、サポートに影響する項目、完了数を表示します。
   • 未割り当て、非アクティブな担当者、担当者のステータスが不明な項目も含めます。
   • 簡潔にまとめます。担当者ごとのカードより、小さな表または棒グラフを優先してください。

7. リスクと注意事項

   • 担当者の負荷の下に配置します。
   • マネージャーまたはリードの注意が特に必要と思われる作業項目のみを含めます。
   • 各項目には、キー、理由、根拠、担当者、経過期間、次の質問を表示します。
   • 特に目立つ項目がある場合は、最も重大なデリバリーリスクをコールアウトまたは強調表示した行で示します。

8. 優先度の高い作業項目テーブル

   • スプリント内の優先度が高い作業項目、または注意が必要な項目の上位を、簡潔な表にまとめます。
   • 重要度の低い作業項目をすべてデフォルトで表示しないでください。

9. 最近完了した項目と任意の詳細

   • 最近完了した作業がある場合は、折りたたみ可能なセクションまたは簡潔な表にして、主要な概要の下に配置します。
   • ワークストリームによるグループ化や依存関係は、閲覧者が次に確認すべき内容に影響する場合に限り表示します。
   • 依存関係は、デフォルトでは未解決、またはステータス不明の関連作業に限定します。

10. データソースの付録

    • 正確なJQL、クエリのタイムスタンプ、フィールドの網羅状況、前提条件、要注意の内訳を最下部に配置します。

データセット全体を利用できない場合も、全体的な順序は維持し、正確に表示できないセクションやチャートは省略します。

コンテンツとスタイル

• 段落よりもチャートや表のほうが効果的な場合は、それらを使用します。
• データが裏付ける場合は参照レイアウトの順序に従います。ページ全体の構成を変えるのではなく、裏付けのないチャートを省略してください。
• 作業項目の概要は短くまとめます。影響を説明するために短い抜粋が必要な場合を除き、説明全文は避けてください。
• すべての推奨事項や次の質問を、作業項目のキーまたは集計値に結び付けます。
• Jiraの事実と、導出または推測されたシグナルを区別します。
• レンダラーが対応している場合は、意味に応じたトーンを使用します。完了にはsuccess、長期間更新なし／期限のリスクにはwarning、ブロック中／期限超過／深刻なリスクにはdanger、注記／関連作業にはinfo、重要度の低い事実にはneutralを使います。
• 色にはラベルを添えます。大きなボタンより、作業項目キーへのリンクを優先します。
• 最初に表示される画面では、プロセスに関する注記ではなく、ステータスと注意事項に焦点を当てます。

レンダラー固有のスタイル

Cursor Canvas の場合：

• Canvas コンポーネントとホストのテーマスタイルを使用します。
• 上部エリアはコンパクトに保ち、コンテキストヘッダーの後に、統計情報を必ず4つだけ配置します。
• カスタムレイアウトコードよりも、Canvas のテーブルやチャートを優先します。

インタラクティブな成果物または静的 HTML の場合：

• コンパクトなカード、テーブル、シンプルなチャートを使った、落ち着いたダッシュボードレイアウトにします。
• モバイルとデスクトップの両方でテキストを読みやすくします。
• チャートの代替表示とステータスカラーには、アクセシブルなラベルを使用します。
• ソースの詳細は、メインのダッシュボードの下に配置します。

Markdown の場合：

• 短いセクション見出しを使用します。
• 段落よりもテーブルを優先します。
• 注意事項と推奨事項は簡潔にします。
• ソースクエリは末尾に配置します。

セルフチェック

返答する前に、次の点を確認します：

• スコープはユーザーまたは提供された URL から取得されており、不足または曖昧なスコープは、クエリを実行する前に確認されています。
• 選択したレンダラーは、現在の環境の機能に合っています。
• Cursor Canvas の使用が利用可能な場合に限られています。
• Cursor Canvas を使用した場合、Canvas がインポートするのは cursor/canvas のみです。
• 上部エリアは、コンパクトなコンテキストヘッダーの後に、統計情報が必ず4つ続く構成になっています。
• 上部バーの上にクエリリスト、フィールドカバレッジ、エグゼクティブサマリーがありません。
• 可能な場合、通常のシグナルはページネーションされたスコープクエリから導出されています。対象を絞った追加クエリは、スコープデータだけでは安全に裏付けできない可視の主張を支える場合に限り使用されています。
• 件数は、クエリされた作業項目セットと整合しています。
• 空のセクションは省略されています。
• カテゴリ、値、単位、期間が利用できる場合に限り、チャートが表示されています。
• リスクラベルは、可視の Jira データから説明できます。
• ソース付録には、可視の主張に関する正確な JQL とフィールドカバレッジが含まれています。
• Jira の書き込みツールは使用されていません。