llm-wiki-brief

Files (1)

• SKILL.md

SKILL.md (first lines)

# LLM Wiki Brief

Structured briefs, digests, and check-ins from the PM wiki. Richer, more structured output than the §10/§11 fallbacks in the core llm-wiki-pm skill.

For ingest, update, query, lint, and all other wiki operations — the core `llm-wiki-pm` skill handles those. This skill is brief-only.

## When This Skill Activates

- "daily brief", "what happened today", "what happened yesterday"
- "weekly brief", "weekly checkin", "what happened this week", "week in review", "catch me up on the week"
- "[tag] digest", "brief me on [tag]", "summarize [tag] pages", "what's new in [topic]", "what changed in [competitive/customer/strategy/etc]"
- "what's thin", "what needs more work", "coverage brief"

## Wiki Path Resolution

```bash
WIKI=$(cat .wiki-path 2>/dev/null | tr -d '[:space:]')
CONF='${user_config.wiki_path}'; case "$CONF" in '${'*) CONF= ;; esac  # plugin option, if set
WIKI=${WIKI:-${CONF:-${WIKI_PATH:-}}}
[ -z "$WIKI" ] && [ -f SCHEMA.md ] && WIKI=$(pwd)  # cwd only if it is already a wiki
```

## Orient (lightweight)

This skill is read-only by default. Before any brief:
1. Read `$WIKI/_status.md` if it exists — surface any pre-computed warnings immediately
2. Read last 20-30 lines of `$WIKI/log.md` — know what's recent before summarizing

Full orient (AGENTS.md 4-step protocol) only required if filing output as a wiki page.

## Source-Completeness Guard (when briefs sweep live sources)

When a brief is asked to pull from external sources (whatever the user's connected stack — issue trackers, mail, chat, CRM, meeting notes, web), the core llm-wiki-pm **Source-completeness guard** applies in full: an empty or errored source is a signal to vary the query, not to declare the sweep done.

**A brief is exec-facing synthesis — the Provenance-tier & falsification guard applies (core skill → Session Defaults).** A brief reads as a complete, current picture, so a laundered claim does the most damage here. Tier every headline claim computed/primary/recalled; don't state a claim recalled from wiki prose as current fact without confirming it against a live source (a wiki page saying "pipeline is thin" does not override what the CRM says today). For any decision-bearing line, name and run the query that would disprove it before it goes in the brief, and mark claims you couldn't verify as unverified rather than asserting them.

- **Get the source set from the registry, not from memory.** Before sweeping, read the `## Sweep Registry` in `$WIKI/MY-INTEGRATIONS.md` and cover every source listed; the ledger below must have one row per registered source. If no registry exists, build the set from connected tools + the `Active Sources` table, confirm it with the user, and write it to the registry. Forgetting a registered source (e.g. omitting Slack or GitHub from the sweep) is the worst failure — it reads as complete while a high-signal source went unread.
- Run ≥2 varied queries per source before calling it empty (broaden terms, widen the window, try aliases/handles/scope variants, switch syntax). Keyword search tools commonly miss on first phrasing.
- Classify each requested source as `hits` / `empty-after-retries` / `failed`. Never collapse `failed` or `empty-after-retries` into "covered."
- **Always emit a Source Coverage ledger** (see below) listing every requested source and its state. A source that returned nothing must appear in the brief, not vanish from it. No "enough captured" while a requested source is `failed` or was abandoned after one query.

```markdown
### Source Coverage
- <source A>: hits (N items)
- <source B>: hits (N threads)
- <source C>: empty-after-retries — tried "X", "<scoped query> Y", "<author filter> Z"; quiet or query miss. Confirm scope/range?
- <source D>: failed — not connected
```

---

## Operations

### 1. Daily Brief

**Triggers:** "daily brief", "what happened today", "what happened yesterday"

① Resolve `$WIKI`. Read `$WIKI/_status.md` if present.

② Read `$WIKI/log.md`. Filter entries from the last 24-48 hours. Parse:
   - Pages created (`ingest`, `create`)
   - Pages updated (`update`)
   - Decisions logged (`decision`)
   - Open questions added (`query`, `question`)

③ For decision and question entries, read the referenced page to pull the one-line summary or question text.

④ Output format — structured, scannable, no prose padding:

```markdown
## Daily Brief — YYYY-MM-DD

### New Pages
- [[slug]] — one-line description

### Updated Pages
- [[slug]] — what changed (one phrase)

### Decisions Logged
- [[slug]]: decision text (YYYY-MM-DD)

### Open Questions Added
- [[slug]]: question text

### Warnings
- (staleness, coverage flags, lock state from _status.md)
```

If 24h window is empty, expand to 48h and note it. If still empty, offer weekly brief.

**Log:** Read-only — do not append to log.md unless user asks to file output.

**If you file the brief as a page** (e.g. `briefings/YYYY-MM-DD.md`), stamp
`lifecycle: dated-digest` in its frontmatter. These are orphans by design;
the flag keeps them out of the lint orphan count (see schema-guide). Without
it, every daily brief permanently inflates the orphan metric.

---

### 2. Weekly Brief / Check-in

**Triggers:** "weekly brief", "weekly checkin", "what happened this week", "week in review", "what did I miss"

① Resolve `$WIKI`. Read `$WIKI/_status.md` if present.

② Read `$WIKI/log.md`. Filter entries from last 7 days (default; user can specify N days).

③ Aggregate counts: pages created, updated, decisions logged, questions added vs resolved.

④ Identify top 3 areas of activity: grep mentioned slugs' frontmatter tags, count by tag frequency.

⑤ Lightweight staleness check on `overview.md` and `index.md`: if `updated:` older than 14 days AND log shows writes this week, surface warning.

⑥ Coverage gaps: grep for `coverage: stub` pages created this week only — not all stubs, just new ones.

⑦ Output format:

```markdown
## Weekly Brief — Week of YYYY-MM-DD

From anh-chu/llm-wiki-pm, MIT.

More from anh-chu/llm-wiki-pm