Morning Standup

Compile Benjamin's personal actionable todo list for today from Jira, Slack, and GitHub.

Key principle: Every item in the output must represent something Benjamin personally needs to act on today. If a ticket is assigned to someone else, already resolved, or doesn't require Benjamin's action — exclude it.

Configuration

jira:
  cloudId: "4a4bd20b-0645-4d11-9c98-8d0285630fd4"
  userId: "712020:30e7c6ae-4ea0-498a-b65d-c6107cba7e08"
  baseUrl: "https://hgdata.atlassian.net/browse/"
  projects:
    - key: RGI
      board: 1236
    - key: MITB
      board: 1036
      label: Engineering-Applications

slack:
  supportChannel: "C09E1666N78"  # eng-applications-support
  userId: "U09ATNQ9UV7"  # Benjamin Gelis
  priorityUsers:
    - Claire Renaud
    - Matthieu Courtin

github:
  username: "BenjaminG"
  orgs:
    - MadKudu
    - HGData

persistence:
  directory: "~/.claude/standups"
  format: "YYYY-MM-DD.md"

Execution Steps

1. Gather Slack Data

Query #eng-applications-support channel:

mcp__slack__conversations_history channel_id: "C09E1666N78" limit: "15"

From the results:

• When priority recaps contain multiple team sections (Applications, Data, Core, etc.), only extract items under the Applications section — that is Benjamin's team. Ignore Data, Core, and other sections.
• Note any unresolved @mentions of Benjamin (U09ATNQ9UV7)
• Note any questions or requests directed at Benjamin or his team that need a response
• Collect all Jira issue keys mentioned in Slack messages for validation in step 3

2. Gather Jira Data

RGI Project — All non-Done issues assigned to Benjamin:

acli jira workitem search --jql 'project = RGI AND assignee = "712020:30e7c6ae-4ea0-498a-b65d-c6107cba7e08" AND status not in (Done)' --fields "key,summary,status,priority" --csv

MITB Project — Only issues with Engineering-Applications label assigned to Benjamin:

acli jira workitem search --jql 'project = MITB AND assignee = "712020:30e7c6ae-4ea0-498a-b65d-c6107cba7e08" AND status not in (Done) AND labels = "Engineering-Applications"' --fields "key,summary,status,priority" --csv

For each issue returned, fetch details, full comments, and attachments to build comprehensive context.

Important: Fetch all issue data in a loop rather than individual parallel calls, to avoid cascading failures when one call errors. First, create the attachments directory:

mkdir -p /tmp/standup-attachments

Then fetch details for each issue:

for key in KEY1 KEY2 KEY3; do
  echo "=== $key ==="
  acli jira workitem view "$key" --json 2>&1
  echo "--- comments ---"
  acli jira workitem comment list --key "$key" --json 2>&1
  echo "--- attachments ---"
  acli jira workitem attachment list --key "$key" --json 2>&1
  echo
done

Processing attachments: For issues that have image attachments (png, jpg, gif, webp), download the most recent 2-3 images per issue:

# For each image attachment found in the JSON output above:
curl -L -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
  "$JIRA_BASE_URL/rest/api/3/attachment/content/$ATTACHMENT_ID" \
  --output "/tmp/standup-attachments/$KEY-$FILENAME"

Then use the Read tool to view each downloaded image (Claude is multimodal and can read images). Screenshots often contain the actual QA feedback, bug reproductions, or UI states that explain what needs to happen next.

Env vars required for attachment download: JIRA_EMAIL, JIRA_API_TOKEN, JIRA_BASE_URL. If not set, skip attachment download and note it in the output.

From the full comments, attachments, and details, extract for each issue:

• Full comment thread context: Read ALL comments (not just the latest), understand the conversation arc — who raised what, what was discussed, what was decided
• Visual context from screenshots: If images are attached, view them and describe what they show (e.g., "Screenshot shows missing chart legend in conversion volume view")
• Next action: What Benjamin specifically needs to do next (review, fix, respond, deploy, etc.)
• Whether actionable now or waiting on someone else

Cleanup: After generating the standup report, remove temp files:

rm -rf /tmp/standup-attachments

3. Check Jira Notifications (Watched Issues)

Fetch recently updated issues Benjamin is watching — these surface activity on issues he cares about but may not be assigned to:

acli jira workitem search \
  --jql 'watcher = currentUser() AND updated >= -3d ORDER BY updated DESC' \
  --fields "key,summary,status,assignee" --csv

For each watched issue returned:

• Skip issues already fetched in step 2 (assigned to Benjamin) — avoid duplicate work
• Fetch the last 3 comments to understand what changed:

acli jira workitem comment list --key <KEY> --json 2>&1

From the results, determine if Benjamin needs to act:

• Someone asked Benjamin a question or requested input in the comments
• A status change requires Benjamin's attention (e.g., moved to review, blocked)
• A teammate's work that Benjamin needs to unblock or approve

Filtering: Only include watched issues where Benjamin has a concrete action item. Exclude purely informational updates (e.g., someone else resolved it, automated status transitions).

4. Gather GitHub Data

Benjamin's open PRs across all repos:

gh search prs --author=@me --state=open --limit 20 --json title,number,repository,url,isDraft,updatedAt,createdAt

PRs requesting Benjamin's review:

gh search prs --review-requested=@me --state=open --limit 10 --json title,number,repository,url,author

Enrich with review state — for each non-draft PR from Benjamin's list, fetch the review decision:

for pr in $(echo "$PRS_JSON" | jq -r '.[] | select(.isDraft == false) | "\(.repository.nameWithOwner):\(.number)"'); do
  repo="${pr%%:*}"
  num="${pr##*:}"
  echo "=== $repo#$num ==="
  gh pr view "$num" --repo "$repo" --json reviewDecision,reviews --jq '{reviewDecision, reviewCount: (.reviews | length)}'
done

Possible reviewDecision values:

• CHANGES_REQUESTED — a reviewer requested changes; Benjamin is blocking their wait
• APPROVED — all reviewers approved; ready to merge
• REVIEW_REQUIRED or empty (0 reviews) — no one has reviewed yet; Benjamin is waiting on others

From the results:

• Match PR titles/branches to Jira issue keys (e.g., a PR title containing "RGI-265" or branch named "feat/MITB-599")
• Note which of Benjamin's PRs are drafts vs ready for review
• Note PRs from teammates that need Benjamin's review
• Flag stale PRs (open > 30 days) — these likely need rebase, cleanup, or closing
• Note PR age using createdAt field
• Classify each non-draft PR by review state for tier routing:
  • CHANGES_REQUESTED → UNBLOCK OTHERS (reviewers waiting on Benjamin)
  • REVIEW_REQUIRED with 0 reviews → MONITORING footer (Benjamin is waiting, no action needed)
  • APPROVED → IN PROGRESS (ready to merge — Benjamin needs to act)

5. Validate Slack Items Against Jira

For every Jira issue key found in Slack messages (step 1) that was NOT already fetched in step 2, fetch the issue details, full comments, and attachments:

acli jira workitem view <ISSUE-KEY> --json
acli jira workitem comment list --key <ISSUE-KEY> --json
acli jira workitem attachment list --key <ISSUE-KEY> --json

Download and view image attachments the same way as step 2.

For each Slack-mentioned issue, determine:

• Is it assigned to Benjamin? If assigned to someone else, it's not Benjamin's action item.
• Is it still open? If status is Done/Resolved/Closed, exclude it entirely.
• Does it require a response from Benjamin? (e.g., someone asked him a question, requested a review, or awaits his input)
• What is the current actual status? Use comments and status to get the real state, not just what Slack says.

Filtering rules:

• Exclude issues assigned to others unless Benjamin has a specific pending action (reply, review, unblock)
• Exclude resolved/closed issues entirely
• Exclude issues where the Slack message is informational only (no action needed from Benjamin)

6. Load Previous Standup

Check for the most recent standup file in ~/.claude/standups/:

ls -1 ~/.claude/standups/*.md 2>/dev/null | sort -r | head -1

If a previous standup exists, read it and extract:

• All Jira issue keys and their statuses (parse from section headers and item lines)
• All PR entries

This data is used in step 7 to generate the diff section. If no previous standup exists (first run), skip the diff.

To detect stale items, also check the 2 standups before that:

ls -1 ~/.claude/standups/*.md 2>/dev/null | sort -r | head -3

An item is stale if it appears with the same status across 3+ consecutive standups.

7. Merge and Prioritize

Build a single priority-ordered numbered list of Benjamin's personal action items, grouped into urgency tiers. Items are numbered continuously across all tiers (1, 2, 3... N — no resets between tiers).

When a Jira issue has a matching open PR (matched by issue key in PR title or branch), annotate the item inline with ⌥ PR #N and link.

Tier assignment rules:

Monitoring (not a tier — compact footer section):

Items Benjamin has handed off. These are NOT numbered and appear as a single compact footer line.

Own PRs with REVIEW_REQUIRED / 0 reviews also route to MONITORING (not IN PROGRESS).

Escalation check: During step 7, for each item that would route to MONITORING, scan the issue's comments (already fetched in step 2) for:

1. Comments from the last 24 hours that @mention Benjamin or ask a direct question
2. Subtasks assigned to Benjamin that are not Done
3. The issue being reassigned back to Benjamin after being with QA/reviewer

If any escalation trigger fires, route the item to the appropriate action tier instead (see table above).

Within each tier, sort by: Jira priority (Blocker > Critical > High > Medium > Low), then by most recent activity.

8. Generate Output

Construct links for every issue key as [KEY](https://hgdata.atlassian.net/browse/KEY).

Format — Priority Stack:

┌─────────────────────────────────────────────────────────────┐
│  🌅  STANDUP — {date}                                       │
│  Last sync: {previous_date} · {N} action · {N} monitoring · {N} standby · {N} msg│
└─────────────────────────────────────────────────────────────┘

⚡ DO NOW
  1. 💬 [Brief description] — [who] [what]
     └─ #channel · date · What to respond
  2. 🔴 [KEY](url) — Summary
     └─ Context from comments/attachments → next action

🔄 UNBLOCK OTHERS
  3. 🟡 [KEY](url) — Summary                     ⌥ [PR #N](gh-url)
     └─ Feedback details / what to address
  4. 🟡 [repo#N](gh-url) — PR title — by [author]
     └─ Brief description of PR purpose

🔨 IN PROGRESS
  5. 🟠 [KEY](url) — Summary                     ⌥ [PR #N](gh-url)
     └─ Active work context / ready to merge

📋 UP NEXT
  6. 🔴 [KEY](url) — Summary                    High
     └─ Why it matters
  7. ⬜ [KEY](url) — Summary
     └─ Brief context

⏳ WAITING
  8. ⏸ [KEY](url) — Summary
     └─ Waiting on: {waiting_on} · standby Xh ago
  9. ⏸ [KEY](url) — Summary
     └─ Waiting on: {waiting_on} · standby 1d ago

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
🔔 Overnight: 🆕 KEY reason · ➡️ KEY old → new · ✅ KEY done · ⏸ KEY reason · ▶️ KEY
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

👀 Monitoring: KEY (brief) · KEY ⌥#N (brief) · KEY (brief) ...
🔍 Analysis: KEY (brief) · KEY (brief)
📦 Backlog: KEY (brief) · KEY (brief)
🧹 Stale PRs: #N(Nd) #N(Nd) ...

Header box rules:

• {N} action = count of items in DO NOW + UNBLOCK OTHERS + IN PROGRESS + UP NEXT (things requiring Benjamin's involvement)
• {N} monitoring = count of items in the MONITORING footer (handed off, no action needed)
• {N} standby = count of items in WAITING tier
• {N} msg = pending Slack messages
• Last sync: {date} uses the most recent previous standup date. Omit if first standup.
• Omit {N} standby from the header if zero standby tasks. Omit {N} monitoring if zero.

Context line (└─) rules:

• Every item MUST have a └─ context line underneath
• The line should answer: "What do I need to do with this?"
• Derive context from the full comment thread + attachments + PR status + Slack messages — not from the issue title or a single comment
• Read ALL comments on each issue to understand the full conversation arc before summarizing
• If image attachments exist, view them and incorporate visual context (e.g., "Screenshot shows missing chart legend on conversion page")
• Keep to 1-2 lines, ~20 words max
• For Jira items: synthesize the full discussion + visual evidence into a clear next action for Benjamin
• For PRs: note age, review status, whether it needs rebase/cleanup
• For stale PRs (> 30 days): flag explicitly (e.g., "Open 45 days, likely needs rebase or closing")
• Use ⏸ prefix when an item is blocked/waiting on someone else

PR annotation rules:

• If a Jira item has a matching PR, append ⌥ [PR #N](gh-url) inline on the same line
• Mark draft PRs explicitly with "(draft)"
• Route Benjamin's PRs by review state:
  • CHANGES_REQUESTED → 🔄 UNBLOCK OTHERS (reviewers waiting on Benjamin to address feedback)
  • REVIEW_REQUIRED / 0 reviews → 👀 MONITORING footer (Benjamin is waiting, no action needed)
  • APPROVED but not merged → 🔨 IN PROGRESS (ready to merge — Benjamin needs to act)
• Teammate PRs requesting Benjamin's review go in the 🔄 UNBLOCK OTHERS tier
• Benjamin's open PRs that don't match any Jira issue go in the 🧹 Stale PRs footer line

Overnight diff rules:

• Compact single-line format between ╌ dividers
• Use emoji prefixes: 🆕 (new items), ➡️ (status changes), ✅ (completed/resolved), ⚠️ (stale 3+ standups), ⏸ (newly on standby), ▶️ (unblocked since last standup)
• All changes on one line, separated by ·
• Compare by Jira issue key and status from previous standup file
• Completed = keys in previous standup but absent from today's data
• New = keys in today's data but absent from previous standup
• Status Changes = keys present in both with different status
• Stale = keys with identical status across 3+ consecutive standups
• Newly standby = keys that transitioned to standby since last standup — show as ⏸ KEY reason
• Unblocked = keys that transitioned from standby to active since last standup — show as ▶️ KEY
• Omit the entire overnight section if no previous standup exists

Footer section rules:

• 👀 Monitoring, 🔍 Analysis, 📦 Backlog, 🧹 Stale PRs are compact single-line lists
• Format: emoji Label: KEY (brief) · KEY (brief)
• Monitoring line format: 👀 Monitoring: KEY (brief status) · KEY ⌥#N (brief) · ...
  • Each entry: issue key, optional ⌥#N for linked PR, parenthetical status (~15 chars max)
  • Sort: In Review → In QA → Ready For QA (closest to done first)
  • If > 8 items: show first 6 + +N more
• Stale PRs use #N(Nd) format showing PR number and age in days
• Omit any footer line with no items

Tier omission: Omit any tier that has no items. Do not show empty tier headers.

9. Persist Report

After displaying the output, save the full standup report:

mkdir -p ~/.claude/standups

Write the complete output to ~/.claude/standups/YYYY-MM-DD.md (using today's date).

If a file for today already exists (e.g., re-running standup), overwrite it with the latest data.

10. Generate Task File

After persisting the standup report, generate a structured task file for cross-session tracking.

Create ~/.claude/daily-tasks/YYYY-MM-DD.json by extracting each numbered item from the standup output:

mkdir -p ~/.claude/daily-tasks

Extraction rules — parse the standup output just generated:

1. For each numbered item (1..N), extract:

   • Item number → id
   • Tier header above it → tier (map: ⚡ DO NOW → "do_now", 🔄 UNBLOCK OTHERS → "unblock_others", 🔨 IN PROGRESS → "in_progress", 📋 UP NEXT → "up_next", 👀 Monitoring footer → "monitoring")
   • Jira key from [KEY](url) pattern → jira_key, jira_url
   • Summary text after the em dash → summary
   • Context line (the └─ line) → context
   • PR annotation ⌥ [PR #N](url) → pr_url
   • Source: items with jira_key → "jira", Slack-only items → "slack", PR-only items → "github"

2. Items without a Jira key (e.g., Slack @mentions, PR review requests) should still be included with jira_key: null.

3. For monitoring items (from the 👀 Monitoring: footer line): parse the line, split by ·, and create task entries with tier: "monitoring". The context field gets the parenthetical text. The summary comes from the Jira data already fetched in step 2.

JSON schema:

{
  "date": "YYYY-MM-DD",
  "standup_file": "~/.claude/standups/YYYY-MM-DD.md",
  "updated_at": "ISO-TIMESTAMP",
  "tasks": [
    {
      "id": 1,
      "tier": "do_now",
      "status": "pending",
      "jira_key": "RGI-265",
      "jira_url": "https://hgdata.atlassian.net/browse/RGI-265",
      "summary": "Migrate Evr Insights pages",
      "context": "In QA; Claire feedback on missing chart names",
      "pr_url": null,
      "source": "jira",
      "started_at": null,
      "completed_at": null,
      "carried_from": null,
      "waiting_on": null,
      "paused_at": null
    }
  ]
}

Merge logic — if ~/.claude/daily-tasks/YYYY-MM-DD.json already exists (re-run):

1. Read the existing task file
2. Build a lookup map: jira_key → {status, started_at, completed_at, waiting_on, paused_at} for all existing tasks
3. For each new task being generated: if its jira_key matches an existing task, carry over status, started_at, completed_at, waiting_on, paused_at from the existing entry
4. Tasks with status === "standby" are routed to the ⏳ WAITING tier regardless of what Jira reports for their status
5. This prevents losing in-progress/done/standby state when re-running standup mid-day

Carry-over from previous day:

Check if yesterday's task file exists:

cat ~/.claude/daily-tasks/$(date -v-1d +%Y-%m-%d).json 2>/dev/null

For tasks that appeared in yesterday's file and reappear today (matched by jira_key):

• Set carried_from to yesterday's date string
• If yesterday's task had status === "standby", carry over standby status, waiting_on, and paused_at intact — the task is still blocked

Write the JSON file using the Write tool to ~/.claude/daily-tasks/YYYY-MM-DD.json.

Amend standup file: After writing the task file, append an HTML comment reference to the standup markdown file:

<!-- task-file: ~/.claude/daily-tasks/YYYY-MM-DD.json -->

11. Empty State

If no tasks found across all sources:

No pending tasks - check backlog or ask PM for priorities.

Still persist the empty standup file so the diff tracks that it was a clean day. Also persist an empty task file with "tasks": [].

Notes

• Both RGI (1236) and MITB (1036) boards are Kanban (no sprints). Use status to infer tier placement.
• Exclude Canceled and Done issues from output
• Omit any tier or footer line that has no items
• Use 🔴 emoji for High priority items (not bold text)
• Requirement Analysis and Backlog items go in the compact footer lines, not in the numbered tiers
• Blockers should be surfaced as 🔴 items in the ⚡ DO NOW tier with clear blocking context