today

---

name: today description: Generate a daily work-update brief. Runs the plugin's collector (today's git commits across all worktrees by author email + the GitLab activity feed: pushes, MRs, issues, comments), writes a consolidated data file, then synthesizes a structured boss-update message from it. Use when the user wants a "what I did today" / standup / status update.

daily-brief: today

Produce a daily work-update brief from git history + GitLab activity, ready to send to a manager. Two phases: (1) a deterministic Python collector gathers and consolidates the raw data into one markdown file; (2) you synthesize the actual boss-update message from that data using the structure below.

The collector is zero-dependency Python (stdlib only) — use system python3, no venv. It uses the glab CLI as its GitLab API transport by default (so glab handles OAuth token refresh itself), and filters GitLab events client-side — so it works with a glab OAuth login out of the box.

Phase 1 — run the collector

Resolve the plugin's scripts directory, then run the orchestrator. Forward any flags the user passed (e.g. --repo, --since, --days, --no-gitlab).

PLUGIN="${CLAUDE_PLUGIN_ROOT:-}"
GR="$PLUGIN/scripts/generate_brief.py"
# fallback if CLAUDE_PLUGIN_ROOT isn't set (e.g. running from a clone)
[ -f "$GR" ] || GR="$HOME/claude-daily-brief/scripts/generate_brief.py"

python3 "$GR" $ARGUMENTS

Defaults (no args needed):

• repos — every git repo under ~/repos (override with --repo (repeatable), --repos-root, or $DAILY_BRIEF_REPOS_ROOT). Only repos with the author's commits produce output, so it captures work across all the user's repos, not just one.
• author — $DAILY_BRIEF_AUTHOR, else each repo's git config user.email (catches every author-name variant: jdoe, Jane Doe, …).
• window — yesterday 00:00 → now (local tz). This is deliberate: at early-AM hours the just-finished workday is the previous calendar date, so "today since midnight" would miss most of the day. Override with --since YYYY-MM-DD --days N if the user wants a different window.
• --noon — alternative window: 10:00 yesterday → 10:00 today (a 24h cycle); overrides --since/--days. Use for a 10am-start workday — run at 2-3am it captures the whole day (10:00 yesterday → now) including the after-midnight work, and excludes the previous workday's pre-10am tail.
• GitLab — on, via the glab api transport; --no-gitlab for git-only/offline.
• brief — off by default; --brief appends a template-based draft so the script is usable standalone (this skill still produces the polished version).

The script prints the output file path and a one-line summary. Read that file — it has three sections: GitLab activity feed, deduplicated commit log (with diff stats), and per-worktree breakdown.

If the collector reports gitlab: skipped (no token), tell the user to run glab auth login or export GITLAB_TOKEN=..., then re-run. Don't fabricate GitLab data.

Phase 2 — synthesize the boss-update message

Using only the data in the consolidated file, write a comprehensive but scannable update. Group by theme, not a raw commit dump. Use this structure:

1. TL;DR — 2-3 sentences + the headline numbers (commits, LOC, MRs merged/opened, issues filed). One paragraph.
2. Shipped — MRs merged — per MR: !number — title + one line on what it was. Separate by project if more than one project appears.
3. In flight — MRs opened (not yet merged).
4. Security & integrity fixes — group the fix(...) commits that close numbered review findings, IDOR/TOCTOU/authz/money-integrity items. Call out the count and the categories.
5. Code review activity — approvals, OmniForge/automated reviews, OmniFix passes, follow-up checks, notable inline comments.
6. CI / tooling / infra — new gates, dependency pins, CI fixes, tooling migrations.
7. Issues filed — #number — title per issue.
8. Full commit changelog — compact list of the non-merge commits (SHA + subject), grouped by area; list merges separately.

Rules:

• Stay factual and evidence-based — every claim comes from the data file. No marketing language ("blazingly fast", "100% secure", "magnificent").
• Attribute MRs/issues by their !/# number and exact title from the data.
• If a section has no entries, omit it rather than padding.
• Note the date window the brief covers (from the file header) so the manager knows which day(s).

Present the message in the chat (copy-pasteable), and offer to save it to ~/Downloads/work_update_boss_<date>.md. If the user asked for a different tone/length (shorter, more formal, Slack-style), adapt — but default to the comprehensive structure above.

When NOT to synthesize from judgment

If the user only wants the raw data (not a synthesized message), stop after Phase 1 and just point them at the output file. Don't invent work that isn't in the data — if the window is empty, say so plainly.