| 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"
[ -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:
- TL;DR — 2-3 sentences + the headline numbers (commits, LOC, MRs
merged/opened, issues filed). One paragraph.
- Shipped — MRs merged — per MR:
!number — title + one line on what it
was. Separate by project if more than one project appears.
- In flight — MRs opened (not yet merged).
- 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.
- Code review activity — approvals, OmniForge/automated reviews, OmniFix
passes, follow-up checks, notable inline comments.
- CI / tooling / infra — new gates, dependency pins, CI fixes, tooling
migrations.
- Issues filed —
#number — title per issue.
- 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.