Briefing

Daily and on-demand briefing. Read the referenced file ONLY when triggered.

Arguments

Mode × Phase matrix

Prerequisites

• bridge-config.yaml with work.enabled: true. If not: offer setup.
• Standing orders are loaded at session start (per AGENTS.md, for every agent). If /briefing is invoked standalone (e.g. via cron or a long-running session), manually load protocols/standing-orders/*.md and protocols/standing-orders/user/*.md before Phase 1 — the applications surface logic in Stream C depends on them, and an applications order is user-tier (a *.md glob alone does not reach user/).

Decision Tree

User wants to...
├── Full daily briefing              → Read references/workflow.md, then
│                                       references/control.md (inbox first,
│                                       one thing first, levers). With a view:
│                                       the render is the shape, not the whole
│                                       run; uncovered streams still run, end
│                                       with the receipt line
├── Quick local-only briefing        → Read references/workflow.md (--quick path)
├── Change how mine LOOKS (triage, brevity, plan, bucket titles,
│   "not this again")                → the profile's `view:` / `mutes:`,
│                                       docs/briefings.md § Views; then
│                                       `briefing.py validate`
├── Which briefings do I have / set one up / change what mine shows
│                                    → `python3 scripts/briefing.py list`;
│                                       new or changed profile: copy
│                                       workflow/briefings/_template.yaml,
│                                       keys in docs/briefings.md, then
│                                       `briefing.py validate`
├── Steer: yes/later/drop, "yes once green", open the day's tabs,
│   status of all tabs, tell a tab   → Read references/control.md
├── Detailed commit analysis         → Read references/commit-analysis.md
├── Are we behind on anything?       → Read references/upstream-summary.md
│                                       (covers BOTH inbound channels: CORE from
│                                       the `role: oss-core` upstream, and every
│                                       subscribed org overlay. Needs an
│                                       `upstreams:` list in bridge-config.yaml;
│                                       a Bridge with none skips)
└── Questions about briefing         → Answer from this file

Sister skills (don't duplicate)

/briefing is a daily rollup. The skills above are deeper dives into a single dimension; cross-link rather than re-implement.

Activity Types (log entries)

These describe what kind of work happened — used as the Type column in work/log.md activity-log tables.

Distinct from the commit-message classification taxonomy in references/commit-analysis.md — that one is for analyzing git history (🐛 Bug Fixing, 🎯 Feature, 🔧 Code Refactoring, …). The taxonomies overlap on a few icons but address different artefacts; don't try to unify them.