Skills

/daily-plan

Jira + GitHub の状況から今日の作業計画を自動生成する。制約理論に基づきボトルネック解消・依存関係を考慮したメンバー別計画を出力。

About

Jira + GitHub の状況から今日の作業計画を自動生成する。制約理論に基づきボトルネック解消・依存関係を考慮したメンバー別計画を出力。

Category:Management
Scope:universal

Usage

Use when user says "daily plan", "今日の計画", "今日のプラン", "今日やること", "daily-plan".

Requirements

MCP SERVERS

Atlassian
Slack

CLI TOOLS

gh

Install

Agent:
curl -sf /api/skills/daily-plan/download | tar xz -C .claude/skills/

Download / Upload

ZIP でダウンロード

→ Claude.ai: Customize > Skills にアップロード

Source

Daily Plan

今日の作業計画を Jira + GitHub の状況から自動生成します。

入力

  • $ARGUMENTS: メンバー名やプロジェクトキーなどの補足情報（任意）
  • プロジェクトキーが指定されない場合は LLAM を使用する
  • メンバーが指定されない場合はユーザーに確認する
    • 休みのメンバーがいるか聞き、いる場合は計画から除外する

定数

  • cloudId: 実行時に getAccessibleAtlassianResources で取得する

手順

1. データ取得（Jira + GitHub を並列実行）

以下の 3つのAPI呼び出しを同時に 実行する（依存関係がないため並列可能）:

1a. Jira スプリントチケット（1回のクエリで全情報取得）

searchJiraIssuesUsingJql を以下のパラメータで呼ぶ:

  • cloudId: getAccessibleAtlassianResources で取得した値を使用する
  • jql: project = <PROJECT_KEY> AND sprint in openSprints() ORDER BY priority DESC, status ASC
  • fields: ["summary", "status", "issuetype", "priority", "assignee", "issuelinks", "customfield_10020", "description"]
  • maxResults: 50

重要: fields に assignee, issuelinks, description を必ず含めること。これにより個別の getJiraIssue 呼び出しが不要になる。description は依存関係の抽出（LLAM-XXX リンクの解析）に使う。

50件を超える場合のみ nextPageToken で次ページを取得する。

1b. GitHub PR一覧（直近30件）

gh pr list --state all --limit 30 --json number,title,author,state,createdAt,headRefName \
  --jq '.[] | {number, title, author: .author.login, state, createdAt: .createdAt[:10], branch: .headRefName}'

1c. GitHub オープンPRレビュー状況

gh pr list --state open --json number,title,author,reviewRequests,reviews \
  --jq '.[] | {number, title, author: .author.login, reviewRequests: [.reviewRequests[].login], reviews: [.reviews[] | {author: .author.login, state}]}'

2. メンバーマッピング（動的構築）

Jira の assignee.displayName と GitHub の author を、以下のヒューリスティクスで自動紐付けする:

  • PR ブランチ名に含まれる LLAM-XXX と Jira チケットのアサイニーを突き合わせる
  • 同一人物の Jira displayName と GitHub login のペアを蓄積する
  • マッピングが不明な場合はそのまま表示する（無理に紐付けない）

3. 分析と計画の作成

以下の構成で 今日一日 の計画を出力する。

計画の原則 — 制約理論 (Theory of Constraints)

チーム全体のスループットは最も遅いボトルネックで決まる。 計画を立てる際は、以下の順で制約を特定し解消することを最優先する:

  1. Blocked チケットの制約を特定する — 何がブロッカーか、誰が解消できるか
  2. レビュー待ちPR（仕掛かり在庫）を流す — 新しい作業を始める前に、完了間近のものを先に片付ける
  3. タスク間の依存チェーンを識別する — 後続タスクが詰まらないよう、基盤タスクの担当を優先的に割り当てる

3a. オープンPR状況テーブル

レビュー待ち・修正要求中のPRを一覧化し、最優先で片付けるべきものを明示。 renovate (bot) のPRは除外する。

3b. スプリント状況サマリ

まずスプリントの残日数とバーンダウン状況を1行で示す:

Sprint 48: 残り N日 / 完了 X件 / 未完了 Y件 (うち進行中 Z件)

customfield_10020 のスプリント情報（endDate）と現在日付から残日数を算出する。 残日数に対して未完了チケットが多い場合は警告を出す。

以下のステータスで分類（テーブル形式）:

  • Blocked
  • 進行中 (In Progress)
  • Ready For QA
  • Backlog（未着手・未割当）
  • 完了（小さく表示）

3c. 依存関係図

チケット間の依存関係を ASCII 図で可視化する。

  • ステップ1のデータに含まれる description 内のリンク（LLAM-XXX）と issuelinks から依存チェーンを構築する
  • 追加の getJiraIssue 呼び出しはしない（ステップ1で取得済み）
  • レイヤー構造で表示（Backend 完了 → Backend 進行中 → Frontend 画面群）
  • 各チケットにステータスアイコンを付ける（✅完了, 🔨進行中, 📋Backlog, 🚫Blocked）
  • クリティカルパス（最も長い依存チェーン）を明示する
例:
  Layer 1 (完了)     Layer 2 (進行中)     Layer 3 (Frontend)
  ┌──────┐           ┌──────┐            ┌──────┐
  │ -949 │──────────▶│ -951 │──────────▶ │ -903 │──▶ ...
  │ ✅   │           │ 🔨   │            │ 📋   │
  └──────┘           └──────┘            └──────┘

クリティカルパス: 951 → 771 → 903 → 904 → 900

3d. メンバー別の今日の作業計画

各メンバーについて、番号付きリストで 優先順 を明示:

  1. オープンPRのレビュー対応・マージ推進（仕掛かり在庫を流す）
  2. 修正要求への対応
  3. 進行中タスクの継続・完了
  4. 次に着手すべきタスク（依存関係を考慮）
  5. 他メンバーのPRレビュー担当

各アクションには具体的な PR 番号や Jira チケット番号を記載する。

3e. 今日の全体方針

  • 午前・午後でのフォーカスポイント
  • Blocked チケットのブロッカー確認提案
  • チケット間の依存関係の注意点
  • スプリント残日数を考慮したペース判断: 残日数に対して未完了が多い場合、スコープ縮小やペアプロ等の具体的な対策を提案する

4. Jira チケット調整提案（任意）

分析結果に基づき、以下の調整が必要なチケットを提案する:

  • 優先度の調整: 分析の結果、優先度が実態と合っていないチケット（例: セキュリティバグが Medium のままなど）
  • 未割当チケットのアサイン提案: 依存関係・メンバーの負荷バランスを考慮した割り当て案
  • スプリントへの追加/削除: スプリント外だが今日対応すべきチケット、または今スプリントでは不要なチケット

提案をテーブル形式で表示し、ユーザーに「適用しますか？」と確認する。 承認された場合のみ editJiraIssue で一括更新する。

出力フォーマット

マークダウンテーブルを活用し、視認性の高いフォーマットで出力すること。 メンバーごとのセクションには番号付きリストで優先順を明示すること。 タイトルには日付を含めること（例: # 今日の作業計画 — 2026/03/03 (火)）。

5. Slack 投稿（任意）

計画の出力が完了したら、ユーザーに「Slack に投稿しますか？」と確認する。 投稿する場合は投稿先チャンネルも確認する（デフォルト: #sdh-clinic-dev）。

投稿フォーマット（mrkdwn マルチメッセージ）

Slack は Markdown テーブル非対応のため、以下の形式で投稿する:

メッセージ1（チャンネル投稿）: サマリ

*:calendar: 今日の作業計画 — YYYY/MM/DD (曜日)*

PR N件オープン / Blocked N件 / 進行中 N件
方針: *（一行で全体方針）*

詳細はスレッドへ :thread:

メッセージ2（スレッド）: オープンPR状況

  • > 引用ブロックで各PRを1行ずつ記載
  • ステータスに応じた絵文字（:warning: 修正要求, レビュー待ち 等）

メッセージ3（スレッド）: 依存関係図

  • ASCII 図をコードブロック ``` で囲む
  • クリティカルパスを最後に1行で明示

メッセージ4（スレッド）: メンバー別計画

  • *:bust_in_silhouette: メンバー名* + 番号付きリスト
  • 最後に *:dart: 全体方針* で午前/午後のフォーカスを記載

投稿には slack_send_message を使用。メッセージ1の message_ts をスレッドの thread_ts に指定する。

注意事項

  • メンバーはユーザーに確認するか、$ARGUMENTS で指定される
  • 休みのメンバーは計画から除外し、そのメンバーのPRレビューは他のメンバーに再割当する
  • Jira → GitHub のマッピングはステップ2で動的に構築する（ハードコードしない）
  • renovate (bot) のPRは計画から除外する
  • 完了済みチケットは参考情報として小さく表示する
  • 週間計画と異なり、今日一日で達成可能な現実的な範囲に絞ること