agentsclimarketplace

Llm wiki brief

Skill anh-chu/llm-wiki-pm/skills/llm-wiki-brief

Structured daily/weekly briefs, tag digests, and check-ins from the PM wiki. Richer output than core catch-me-up.From its SKILL.md

Install
npx -y skills add anh-chu/llm-wiki-pm --skill llm-wiki-brief

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
  • runs commandsInstructs the agent to run 2 commands, including `WIKI=$(cat .wiki-path 2>/dev/null | tr -d '[:space:]')` and 1 more.

SKILL.md

9.9 KB, ~2.5k tokens by cl100k_base, as published. Nobody here has run it

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

WIKI=$(cat .wiki-path 2>/dev/null | tr -d '[:space:]')
WIKI=${WIKI:-${CLAUDE_PLUGIN_OPTION_wiki_path:-${WIKI_PATH:-$(pwd)}}}

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.
### 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:

## 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:

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

### Summary
- Pages created: N | updated: N | decisions: N | open questions: N added, N resolved

### Top Activity Areas
1. [tag] — N entries, top pages: [[a]], [[b]]
2. [tag] — N entries, top pages: [[c]]
3. [tag] — N entries, top pages: [[d]]

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

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

### Staleness Flags
- [[overview.md]] last updated YYYY-MM-DD — may need refresh

### Coverage Gaps from This Week
- [[slug]] created as stub — gaps: X, Y

### Warnings
- (from _status.md)

⑧ Offer to file as queries/weekly-brief-YYYY-MM-DD.md. If yes, run full orient per AGENTS.md before writing.

Log: ## [YYYY-MM-DD] brief | weekly | last 7 days | filed: yes/no — only if filing.


3. Tag Digest

Triggers: "[tag] digest", "brief me on [tag]", "summarize [tag] pages", "what's new in [tag]"

① Resolve $WIKI. Check tag exists in $WIKI/SCHEMA.md taxonomy. If not: "Tag '[x]' not in taxonomy. Did you mean: [closest matches]?"

② Grep for matching pages:

grep -rl "tags:.*\b<tag>\b" $WIKI/entities $WIKI/concepts $WIKI/comparisons --include="*.md"

③ Sort by updated: desc. Read each page: title, type, updated, coverage, confidence, 2-3 sentence summary.

④ Cross-reference with log.md: grep each slug in last 30 days. Note recent activity.

⑤ Identify themes: recurring entities/concepts, what changed recently, open questions (question-tagged pages with matching tag), patterns, gaps.

⑥ Output format:

## [Tag] Digest — YYYY-MM-DD
N pages tagged [tag]

### Key Themes
- [Theme]: [2-3 sentence synthesis]
  Sources: [[page-a]], [[page-b]]

### Recently Updated (last 14 days)
- [[slug]] (YYYY-MM-DD): what changed

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

### Notable Patterns
- [Pattern observed across pages]

### Coverage Notes
- [[slug]]: stub — gaps: X, Y

⑦ Offer to file as queries/[tag]-digest-YYYY-MM-DD.md. If yes, full orient before writing.

Log: ## [YYYY-MM-DD] digest | tag: <tag> | N pages | filed: yes/no — only if filing.


4. Coverage Brief

Triggers: "what's thin", "what needs more work", "coverage brief"

① Scan coverage: frontmatter across entities/, concepts/, comparisons/. Count: stub, partial, comprehensive, missing.

② For stub/partial pages, collect tags: and gaps:. Group by primary tag.

③ Output format:

## Coverage Brief — YYYY-MM-DD

### Summary
- Stub: N | Partial: N | Comprehensive: N | No marker: N

### Stubs by Domain
**[competitive]** — N stubs
- [[slug-a]], [[slug-b]]
- Top gaps: X, Y

**[customer]** — N stubs
- [[slug-c]]

### Partial Pages with Notable Gaps
- [[slug]]: gaps: [list]

### Recommended Next Actions
- [[slug]]: highest-priority — appears in N cross-references

④ Offer: "For full audit with orphan detection and taxonomy analysis, run Coverage Audit (§12) from llm-wiki-pm."

No log entry — pure read operation.


Boundaries

This skill handles: daily brief, weekly brief, tag digest, coverage brief.

For everything else — ingest, update, query, lint, archive, persona, pre-meeting briefing — the core llm-wiki-pm skill handles those.

"For full ingest/update/query operations, the core llm-wiki-pm skill handles those."

Behavioral Constraints (per AGENTS.md)

  • No writes without orient. Filing a brief requires full orient + SCHEMA.md compliance.
  • No schema drift. Filed query pages use taxonomy tags only.
  • No orphan pages. Filed briefs need min 2 outbound [[wikilinks]].
  • Privacy. Pages are private by default (only shareable: true pages are export-safe). For any non-shareable page, surface topic category only, not content.
  • Human tone. Scannable over verbose. No em-dashes. No AI tells.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.