standup

name

standup

description

Start-of-day / back-at-desk briefing. Reads the claude-overview hub (~/claude-overview/OVERVIEW.md + plans/), pulls live signals from Jira, GitHub, Google Calendar, Gmail, and Slack, then recommends a ranked "do this next" list with the reason for each. Read-only — it advises, it does not modify plans. Use when the user says "standup", "what should I work on", "what's next", "start my day", "catch me up", "back at my desk", "good morning", or asks where to pick up. Accepts a `--fast` argument (aliases `--local`/`--quick`) for a quick hub-only briefing that skips the live signal fetches.

Standup

The inverse of /checkpoint. Where checkpoint saves state on the way out, standup reads the hub and current signals and tells you where to dive in right now. This skill reads from the claude-overview hub at ~/claude-overview/ (absolute path — not the current working directory) and is read-only: it never edits plans or OVERVIEW.md. If it finds drift worth persisting, it offers to run /checkpoint rather than writing itself.

First-time setup: expects a personal hub at ~/claude-overview/. If you don't have one, see _shared/status-workflow/README.md.

Run it from any repo — it always reads the hub by absolute path.

Arguments

• --fast (aliases: --local, --quick) — fast briefing from the hub only. Reads OVERVIEW.md + the active plans and ranks from those alone, skipping every live signal fetch (the slow part). Use for a quick "where do I pick up" when you don't need overnight-change detection. Specifically, in fast mode:
  • Skip step 2 entirely — no Jira, GitHub (gh), Calendar, Gmail, or Slack fetches.
  • Rank (step 3) from the hub only — plans' Next (pick up here) + OVERVIEW priority order/deadlines.
  • Output (step 4): keep 📌 Top of the day, ▶️ Do next (ranked), ⏳ Still blocked, and resume pointers. For 🔀 My open PRs & issues, read the OVERVIEW 🔀 GitHub snapshot block (the documented fallback) instead of live gh. Omit 🆕 Changed since last checkpoint and 📎 Flagged to revisit — both are signal-derived.
  • State up front that it's a --fast briefing — signals weren't pulled, so anything since the hub's last update won't show; run a full /standup for live change detection.

Default (no argument) runs all steps below, including the live signals.

Steps

1. Read the hub.

   • ~/claude-overview/OVERVIEW.md — the at-a-glance table + active-priority sections. This is the source of priority order and deadlines.
   • The active ~/claude-overview/plans/*.md files (skip archive/ and anything marked DONE/parked/not-started unless the user asks). Each plan's Next (pick up here), Blocked / waiting on, and Resume lines are the raw material.
   • Note the priority signals already encoded: 🔴 > 🟡 > 🟢/🔵, explicit "#1 priority", and hard deadlines (e.g. a GA date). Convert relative dates using date +%Y-%m-%d — never guess today.

2. Pull live signals (skip this entire step in --fast — brief from the hub only) (each is best-effort — skip gracefully and say so if unavailable; never block the briefing on a signal, never guess a status from memory). Run the independent fetches in parallel:

   • Jira — extract the ticket keys referenced across the active plans (grep -rhoiE '(DOC|RED)-[0-9]+' ~/claude-overview/plans/*.md | sort -u) and batch-fetch live status/assignee via searchJiraIssuesUsingJql (key in (…)). Flag: newly assigned to you, newly closed/resolved (→ possibly unblocked or already-done), and status advances. (Same reconcile logic as /checkpoint step 4.)
   • GitHub (docs repo redis/docs, local clone ~/repos/docs). Fetch three things:
     • My open PRs: gh pr list --repo redis/docs --author "@me" --state open --json number,title,reviewDecision,isDraft,updatedAt. Flag ready to merge (reviewDecision APPROVED + not draft), approved but still draft (un-draft + merge), and stale (no update in >2 weeks).
     • Issues assigned to me: gh issue list --repo redis/docs --assignee "@me" --state open --json number,title,updatedAt. (Authored issues are usually empty — assignee is the useful list.)
     • Plan-referenced PRs: for PR numbers named in the plans (grep -rhoE '#[0-9]{3,5}' ~/claude-overview/plans/*.md), gh pr view <n> --repo redis/docs --json state,reviewDecision,statusCheckRollup,mergeable,title to catch newly .

Rules

• Read-only. Standup never edits OVERVIEW.md or plan files. It recommends; /checkpoint records. Safe to run any number of times a day.
• Never fabricate status. Every "newly closed / approved / assigned" claim must come from a live fetch this run, not memory or inference. If a signal source is down, say "couldn't check X" — don't guess.
• Best-effort signals. Any of Jira / GitHub / Calendar / Gmail / Slack may be unauthenticated or unavailable (non-interactive sessions, expired tokens). Skip the missing ones, note them briefly, and brief on the rest.
• Respect the hub's priorities. Deadlines and the 🔴/#1 ordering from OVERVIEW win over raw recency. A hard GA date outranks nice-to-haves.
• Concrete over comprehensive. The goal is "start here," not a full status dump — that's what OVERVIEW.md is for. Cap the ranked list at ~5.

Operator note — GitHub / gh

gh needs both the OS keyring (for the token) and network access to api.github.com. In a restricted shell those can be unavailable, producing a keyring "token invalid" message or an api.github.com x509/TLS verification error — neither means the token is actually bad (verify with gh auth status in a normal shell). For the GitHub signal to work reliably, gh should be run in an environment where the keyring and api.github.com are reachable. You can manage what the sandbox permits via the /sandbox command; a one-time allow for gh / api.github.com makes this seamless. Until then, the OVERVIEW 🔀 GitHub snapshot block is the fallback source.