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:

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:

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:

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:

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:

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:

• gbrain search "<attendee name>" -- find their brain page
• 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:

• gbrain search "<sender name>" -- load sender context
• 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 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)