Briefing

---
name: briefing
version: 1.3.0
description: Compile daily briefing with meeting context, active deals, and citation tracking
triggers:
  - "daily briefing"
  - "morning briefing"
  - "what's happening today"
  - "brain pulse"
  - "pre-briefing pull"
tools:
  - search
  - query
  - get_page
  - list_pages
  - get_timeline
mutating: false
upstream: briefing@fc834ee
---

# Briefing Skill

Compile a daily briefing from brain context.

> **Filing rule:** When the briefing creates or updates brain pages,
> follow `skills/_brain-filing-rules.md`.

## Contract

- Every fact in the briefing includes an inline `[Source: slug, updated DATE]` citation.
- Meeting participants are resolved against the brain; gaps are explicitly flagged.
- Active deals and action items include deadlines and recency context.
- The briefing is read-only: no brain pages are created or modified unless the user explicitly requests it.
- Stale alerts surface pages relevant to today's context, not just all stale pages.

## Pre-Briefing Context Pull

Run these BEFORE composing the briefing sections. All four pulls are read-only.

0a. **Salience scan.** Surface pages with high emotional or activity salience:

   ```bash
   gbrain salience --days 7
   ```

   Returns pages ranked by emotional weight and recent activity. Fold the top
   5-10 into the briefing under a "High-Salience Pages" section — these are the
   entities and topics that are emotionally or operationally hot right now. Use
   this to prioritize which meetings/deals/people get the most briefing depth.

0b. **Anomaly detection.** Surface statistical anomalies in the brain:

   ```bash
   gbrain anomalies
   ```

   Defaults to today against a 30-day baseline; widen with
   `--lookback-days N` or lower the threshold with `--sigma 2`. Flags cohorts
   (by tag, by type) whose activity broke from their normal cadence — sudden
   spikes in mentions or pages updating far off their usual rhythm. Add hits to
   an "Anomalies" section after the brain pulse.

0c. **Personal recall.** Check stored personal facts and preferences before
   composing:

   ```bash
   gbrain recall --query "current priorities and preferences" --json
   ```

   Use recall to pull personal context — dietary preferences, communication
   preferences, prior commitments or promises made. This prevents the briefing
   from contradicting things the user has previously stated or decided.

0d. **Hot memory pulse (v0.32).** Before composing anything else, run:

   ```bash
   gbrain recall --since-last-run --supersessions --pending --rollup --json
   ```

   Fold the result into the briefing under a "Brain pulse" section at the top:
   1. **Contradictions resolved overnight** — the `--supersessions` output. Lead
      with these because they're new corrections to your model of the world.
   2. **Top mentions** — `top_entities` from `--rollup` (top 5 entity slugs by
      fact count in the window).
   3. **New facts since last briefing** — group the `facts` array under each
      entity from the rollup; include `kind`, `notability`, and `confidence`.
   4. **Pending consolidation footer** — when `pending_consolidation_count > 0`,
      note `N facts await dream-cycle consolidation` so the operator can decide
      whether to run `gbrain dream` before reading further.

   The `--since-last-run` flag advances `~/.gbrain/recall-cursors/<source>.json`
   so the next briefing picks up exactly where this one left off. If you're
   running this as a cron job, pass `--source <slug>` or set `GBRAIN_SOURCE`
   explicitly — cron doesn't start in your repo-root cwd, so dotfile resolution
   may miss the right source. Thin-client installs (`gbrain init --mcp-only`)
   route through the remote brain transparently.

0e. **Open loops (when google sources exist).** Pull who is waiting on the
   user and what they promised:

   ```bash
   gbrain waiting --json
   ```

   Fold the top counterparties (what's owed, due dates, evidence quotes,
   deep links) into the ACTION ITEMS section — these are real loop rows, not
   inferred follow-ups, so they outrank prose heuristics. `waiting` refuses
   on stale google sources (no successful sync in 24h) and names the exact
   fix — that's by design: run the sync it names, then retry (see
   `skills/google-loops/SKILL.md`).

## Phases

1. **Today's meetings.** For each meeting on the calendar:
   - Search gbrain for each participant by name
   - Read their pages from gbrain for compiled_truth context
   - Summarize: who they are, recent timeline, relationship to you
2. **Active deals.** List deal pages in gbrain filtered to active status:
   - Deadlines approaching in the next 7 days
   - Recent timeline entries (last 7 days)
3. **Time-sensitive threads.** Open items from timeline entries:
   - Items with deadlines in the next 48 hours
   - Follow-ups that are overdue
4. **Recent changes.** Pages updated in the last 24 hours:
   - What changed and why (read timeline entries from gbrain)
5. **People in play.** List person pages in gbrain sorted by recency:
   - Updated in last 7 days
   - Have high activity (many recent timeline entries)
6. **Stale alerts.** From gbrain health check:
   - Pages flagged as stale that are relevant to today's meetings

## GBrain-Native Context Loading

Before generating any briefing, load context from gbrain systematically.

### Before a meeting

For every attendee on the calendar invite:
- Find their brain page by an exact match only: `gbrain whois <email> --json`,
  then `gbrain whois "<name>" --json` when the address has no match; exactly
  one match counts ([identity rule](../conventions/brain-first.md#identity-exact-match)).
  A search's top hit is not the attendee.
- `gbrain get <slug>` -- load compiled truth, recent timeline, relationship context
- If no page exists, note the gap ("No brain page for alice-example -- consider enrichment")

### Before an email reply

Before drafting or triaging any email:
- Resolve the sender with `gbrain whois <address> --json` (exact email, title
  or alias; [identity rule](../conventions/brain-first.md#identity-exact-match)); no
  match, or an ambiguous one, means an unknown sender, not the nearest known contact
- Read their compiled truth to understand who they are, what they care about, and
  your relationship history. This turns a cold reply into an informed one.

### Daily briefing queries

Run these queries to populate the briefing sections:
- `gbrain query "active deals status"` -- deal pipeline snapshot
- `gbrain query "meetings this week"` -- recent meeting pages with insights
- `gbrain query "pending commitments follow-ups"` -- open threads and action items
- `gbrain list --type person --sort updated_desc --limit 10` -- people in play

## Output Format

```
DAILY BRIEFING -- [date]
========================

MEETINGS TODAY
- [time] [meeting name]
  Participants: [name] (slug: people/name, [key context])

ACTIVE DEALS
- [deal name] -- [status], deadline: [date]
  Recent: [latest timeline entry]

ACTION ITEMS
- [item] -- due [date], related to [slug]

RECENT CHANGES (24h)
- [slug] -- [what changed]

PEOPLE IN PLAY
- [name] -- [why they're active]
```

## Back-Linking During Briefing

If the briefing creates or updates any brain pages (e.g., new meeting prep
pages, updated entity pages), the back-linking iron law applies: every entity
mentioned must have a back-link from their page. See `skills/_brain-filing-rules.md`.

## Citation in Briefings

When presenting facts from brain pages, include inline citations:
- "Jane is CTO of Acme [Source: people/jane-doe, updated 2026-04-01]"
- This lets the user trace any claim back to the brain page and assess freshness

## When it fails

Follow the [agent operator protocol](../conventions/agent-operator-protocol.md) for any gbrain error `code`, exit code, `[AGENT]` block or notice block. Specific to this skill:

- `gbrain waiting` refuses on stale data: run the sync command it names (or tell the user to, when it needs the brain host), then retry. Do not build the "waiting on you" section from stale mail.
- `recall` / `query` sections come back empty with a degraded notice: write "the brain is searching keywords only right now" in that section instead of "nothing happened".
- One section's source fails (`rate_limited`, `timeout`): ship the rest of the briefing and name the missing section; never silently drop it.

## Anti-Patterns

- **Briefing without brain queries.** Never generate a briefing from memory alone; always query gbrain for current data.
- **Uncited facts.** Every claim must include `[Source: slug, updated DATE]`. A fact without a citation is unverifiable.
- **Stale context presented as current.** If a page hasn't been updated in 30+ days, flag the staleness explicitly rather than presenting it as fresh.
- **Modifying brain pages unprompted.** The briefing is read-only by default. Do not create or update pages unless the user explicitly requests it.
- **Ignoring coverage gaps.** When a meeting participant has no brain page, say so. Silence about gaps hides ignorance.

## Tools Used

- Search gbrain by name (query)
- Read a page from gbrain (get_page)
- List pages in gbrain by type (list_pages)
- Check gbrain health (get_health)
- View timeline entries in gbrain (get_timeline)