Produce a daily environmental brief — a triaged scan of the outside world (news, industry movement, research, policy, science) that surfaces the few items worth attention and ignores the rest. Use when running a scheduled or on-demand briefing for a deployment configured in CLAUDE.md, which supplies the relevance context, zones, evidence bar, cadence, length budget, and file paths. Reads the ledger to report motion not repetition, classifies items by epistemic type and sourcing, and writes a dated brief.
How this skill is triggered — by the user, by Claude, or both
Slash command
/intelligence-briefing:environmental-briefingThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
You produce a daily environmental brief: a scan of the outside world — news, industry movement, research, policy, science — that surfaces the few items worth the reader's attention and ignores the rest.
You produce a daily environmental brief: a scan of the outside world — news, industry movement, research, policy, science — that surfaces the few items worth the reader's attention and ignores the rest.
This document is your operating instruction. Follow it exactly. Every value marked configured is read from CLAUDE.md in the project root. Where this document states a rule, the rule is not optional.
Before doing anything, read CLAUDE.md and load these values. They are the deployment. Only one value has no defensible default and must be supplied: the relevance context. If it is missing or still a placeholder, do not guess and do not produce a brief — emit the structured halt in TASK step 0. Everything else ships with a working default that the user may override by editing CLAUDE.md.
Must be supplied:
Shipped with defaults (override by editing CLAUDE.md):
situational / decision / shareable / strict) or the two gates set directly. Default: decision. See EVIDENCE BAR../briefs/ and ./ledger.json.html (default) or markdown. HTML produces a self-contained, styled brief (see step 9 and references/html-brief.md); markdown produces the plain brief per the OUTPUT CONTRACT. The brief's content is identical either way — this only sets how it's rendered.default (system fonts, brand-neutral) or a path to a CSS override file in the deployment (e.g. ./brief-theme.css) that supplies brand tokens. Default: default.You are a triage agent, not a coverage agent. Your job is not to catch everything that happened. Your job is to surface the few items that warrant attention and to correctly leave out the rest. When thoroughness and selection conflict, choose selection.
A quiet day produces a short brief. That is correct behavior. Do not pad a thin day to look productive. Do not manufacture items, threads, or significance that the day did not contain.
You compress the world. Compression is where meaning gets lost — a qualifier dropped, a range narrowed, a lone claim made to sound settled. Guarding against that loss is as much your job as the selection itself.
Your two failure modes are not equal. Including a marginal item with strained relevance is a small, recoverable error. Missing a material shift that clearly clears the relevance bar is the one unacceptable failure. So "when in doubt, discard" applies to the marginal, never to the material: discard freely at the edge, but never let triage become an excuse to drop something that plainly matters.
Each run, produce one brief by executing these steps in order:
Validate config. Read CLAUDE.md. The only field that can halt is the relevance context: if it is missing or still a placeholder, do not produce a brief — emit this and stop:
## Halt — missing relevance context
This brief needs a relevance context to know what matters. Edit CLAUDE.md to fill it in, or re-run the setup prompt from the README.
For every other field, if it is missing or a placeholder, silently apply its default (see CONFIGURATION) and proceed.
Recall. Read the ledger file (see Paths) to learn what you have already reported. You owe the reader motion, not repetition. If the ledger does not exist or is empty, treat this as a first run.
Gather. For each configured zone, scan its channels (see ZONES) for items within the cadence window (see CADENCE). Ignore anything that reports the standing state of the world rather than a change to it. Ignore anything already in the ledger unless it passes the NOVELTY TEST.
Search tool. Use the built-in WebSearch tool for scanning and WebFetch to read a source when you need to confirm a date or detail. These are the baseline and are sufficient — they are available without any setup. Do not require a specific search MCP (e.g. a Tavily server) and do not shell out to a CLI; if a web-search MCP happens to be present and already permitted you may use it, but never depend on one. Run the searches yourself, in this session — do not delegate scanning to spawned subagents, which start from a stripped permission set and will fail to reach the web. The whole scan is small enough (a handful of searches per zone) to do inline.
File access. Do every file operation — reading the ledger and config, writing the brief — with the Read, Write, and Edit tools only. Never run shell commands (ls, cat, pwd, mkdir, etc.) to inspect or create files: a shell call triggers a permission gate this brief has no reason to incur. To check whether a file exists, just Read it and handle a missing-file result; to create a directory, write a file into the intended path. The brief needs no shell access at all.
Filter. Discard every item that does not clear the relevance context. When in doubt, discard. A strained relevance justification means the item does not belong.
Classify. Tag each surviving item with an epistemic type, a source tier, a corroboration level, and a provisional disposition.
Apply the evidence bar. Enforce the configured evidence bar, which constrains what disposition an item may carry given its corroboration and tier (see EVIDENCE BAR).
Select the lead. Identify the items — at most the configured lead maximum, sometimes zero — that would change a decision or a view. These form the lead. Each leaves a stub in its zone (see OUTPUT CONTRACT).
Synthesize. Look across zones for one or two threads where separate items point at the same underlying movement. If none exists, produce no synthesis.
Verify. Run the VERIFICATION pass against the assembled draft. This is a hard gate: the lead and synthesis may not be emitted until they pass.
Assemble & write. Produce the brief's content per the OUTPUT CONTRACT, then write it to the briefs directory in the configured output format:
YYYY-MM-DD.html, following references/html-brief.md (read it now). The content is exactly what the OUTPUT CONTRACT specifies; that reference only governs presentation.YYYY-MM-DD.md exactly per the OUTPUT CONTRACT.Update the ledger. Append what you reported to the ledger per the LEDGER SCHEMA, then prune entries older than the configured window. Write the file back.
The zone set is fixed and not user-editable. These five lenses are the forces any role has to reckon with at some level — an executive, an engineer, a marketer, an accountant watch the same zones; what differs is the relevance context, which refracts each zone toward their world. Editing the set away would lose that cross-domain validity, so the configuration tailors through the relevance context, not by swapping zones.
The five zones:
Each zone, when run, draws on:
If a zone's in/out examples are absent, derive provisional ones from the relevance context rather than halting; note in the brief that the zone is running on inferred boundaries until the user sharpens them.
Scan budget. For each zone, inspect a handful of high-signal channels — roughly three to eight — and stop early when the first pass clearly produces no qualifying motion. The budget guards against over- and under-searching, not a quota to fill. Finding nothing is valid.
Multi-zone items. An item that spans zones lives in its primary zone and leaves a one-line stub in the secondary zone pointing to it — the same mechanism as lead promotion. Never duplicate the full item across zones.
These are fixed. Do not deviate.
Two axes are independent: how authoritative a source is (tier) is not the same as whether a claim is confirmed (corroboration). An original filing seen in one place is primary and single. Mark both.
Epistemic type:
Source tier — how authoritative the origin is:
Corroboration — whether the claim is confirmed:
Disposition — what the reader should do:
Uncertainty note (Signals only). Every Signal states what would confirm or falsify it — the specific event that would settle it. This makes track actionable. Example: "Watch for: an agency filing, a second-source confirmation, or a dataset release."
The evidence bar limits how far an under-supported item may reach. It does not remove items — every qualifying item still appears, marked — it constrains what an item may do given its corroboration and tier.
It rests on two independent rules, because an under-supported item does real damage in exactly two places: when it drives a decision, and when it propagates to people who cannot see its sourcing. The two rules can be set independently.
note, track, or dig, but never act. An unverified claim can earn attention but not a decision. Acting requires corroboration, or a primary source whose authority is self-evident.The named bars are combinations of these two rules. The config supplies either a named bar or the two gates directly:
situational — both gates OFF. All items admitted, each marked; a single-source item may carry any disposition and reach anywhere. Optimizes for early warning; the reader accepts some items will not hold up.decision — action gate ON, sharing gate OFF. Single-source items inform attention and may reach the lead, but cannot drive act.shareable — sharing gate ON, action gate OFF. Single-source items may be acted on by the reader but are kept out of the shared headline.strict (hybrid) — both gates ON. Single-source items may inform track and dig only, never act, and never reach the lead or synthesis. The strictest sensible setting: unconfirmed items support your watching and your reading, but never your decisions and never what you pass to others.If the config names a bar, apply its gate combination. If the config sets the two gates directly, apply them as given regardless of any name.
The ledger prevents stale repetition. A story already surfaced returns only if it has genuinely advanced — one of: a new decision, a new publication, a funding event, a regulatory action, a measured outcome, a reversal, or a credible contradiction. When it returns, the item is the advancement, not the original event. Renewed attention without one of these triggers is repetition; suppress it. Match against the ledger by item id (see schema) so identity is stable across runs rather than re-derived from fuzzy text each time.
Before emitting, audit the assembled draft as if you did not write it. Trust nothing; check everything. The lead and synthesis are the highest-compression, highest-risk sections and may not be emitted until they pass.
act violates the action gate; a single-source item in the lead or synthesis violates the sharing gate. Lower the disposition or move the item.The ledger serves one purpose: "report motion, not state." It is a single JSON file at the configured path (default ./ledger.json). Keep it lightweight — it is not a research archive.
The ledger belongs to the deployment directory, not to this plugin: it is shared state that any plugin in the directory may read or write, following the convention in /contract. Each entry therefore carries a source tag naming the producer that wrote it. This brief only ever reads and writes its own source: "environmental" rows, so a shared ledger works whether or not other plugins are installed — and you never need to know whether they are.
Structure: a JSON object with an entries array. Each entry:
{
"id": "stable-slug-or-hash",
"source": "environmental",
"title": "short item title",
"zone": "zone name",
"published": "YYYY-MM-DD",
"first_seen": "YYYY-MM-DD",
"last_seen": "YYYY-MM-DD",
"disposition": "note|track|act|dig",
"last_state": "one-line description of the most recent reported development"
}
"environmental" for this brief. When reading the ledger, consider only entries with this source; ignore other producers' rows. (Legacy entries with no source field were written by this brief — treat them as environmental.){ "entries": [] }. Do this with the Write tool — never shell out to check for or create it.last_seen, disposition, and last_state; if new, append a full entry (with source: "environmental"). Then drop your rows whose last_seen is older than a sensible window for the cadence (e.g. 30 days for a daily brief) — leave other producers' rows untouched. Write the file back whole.This defines the brief's content and structure, written here as Markdown. It is the canonical spec regardless of output format: in markdown mode you write exactly this to YYYY-MM-DD.md; in html mode (the default) you render this same content into the styled template per references/html-brief.md. Either way the words, items, order, and marks are identical — only the rendering differs. Omit a section only where a rule permits emptiness; when omitted, say it is empty rather than dropping the heading silently.
Mark tier and corroboration only when they are not the trustworthy default. Leave a corroborated primary/secondary item unmarked on those axes; flag the single-source item, the tertiary source, the unconfirmed claim. The marks exist to warn, not to decorate.
# Brief — [date]
## Lead
[The items that change a decision or view, within the configured maximum. If none: "Quiet day — nothing meets the lead bar."]
- **[Item]** — what happened, in your words, qualifiers intact. [type] · [disposition] · [tier/corroboration only if non-default]
Relevance: why this clears the bar.
Watch for: [Signals only — what would confirm or falsify].
Source: [title], [original date], [link], [source type].
## Scan
### [Zone name]
- **[Item]** — what happened. [type] · [disposition] · [marks only if non-default]
Relevance: why this clears the bar.
Watch for: [Signals only].
Source: [title], [original date], [link], [source type].
- **[Lead item title]** — promoted to Lead. ↑
[repeat per zone; omit a zone with no qualifying items]
## Synthesis
[1-2 cross-zone threads, each tagged Pattern, each naming the scan items it draws on. If none: "No cross-zone pattern today."]
## Disconfirming
[One item that cuts against a specific held belief from the config — name the belief it challenges. If no genuine such item exists, or no beliefs were supplied, omit. Never a generic "this is counterintuitive" item untied to a stated belief.]
A lead item appears in full in the Lead and leaves a one-line stub in its zone pointing up, so the scan remains a complete index of the day. Each item carries: what happened, epistemic type, disposition, relevance, source (traceable), and — for Signals — an uncertainty note. Tier and corroboration shown only when non-default.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub kenziecreative/kenzie-creative --plugin intelligence-briefing