llm-wiki-pm

Files (20)

• SKILL.md
• crystallize-guide.md · references/
• ingest-guide.md · references/
• learn-guide.md · references/
• lint-guide.md · references/
• obsidian-sync.md · references/
• output-formats.md · references/
• privacy-guide.md · references/
• recommended-tools.md · references/
• schema-guide.md · references/
• source-discipline.md · references/
• update-guide.md · references/
• backlinks.py · scripts/
• lint.py · scripts/
• MY-INTEGRATIONS.md · templates/
• SCHEMA.md · templates/
• index.md · templates/
• log.md · templates/
• overview.md · templates/
• persona.md · templates/

SKILL.md (first lines)

# LLM Wiki PM

Persistent knowledge base for PM work. Non-coding. Domain: product strategy,
competitive landscape, customer relations, roadmap, AI market, internal org.

Markdown files in a directory. Readable in Obsidian, VS Code, any editor.
The agent writes. You curate sources, ask questions, steer.

## When This Skill Activates
- User asks a question about PM knowledge, competitive intel, customers, strategy, or roadmap
- User asks to update/revise a page, or to lint/audit/health-check the wiki
- User asks to create or bootstrap a PM wiki, or references "my wiki / knowledge base / notes"
- **Natural memory phrases**: "remember that", "note that", "don't forget", "keep
  in mind", "save this", "log this", "make a note", "record that" → treat as a
  wiki ingest (see §2 micro-capture fast path). Ask which page if unclear.
- "I have a meeting/call/1:1 with [person]" → §9 Pre-Meeting Briefing
- "What happened this week / recently?" → §10 Catch Me Up
- "[tag] digest" / "catch me up on [topic]" → §11 Tag Digest
- "What am I missing?", "blind spots?", "coverage gaps?" → §12 Coverage Audit
- "What did we learn?", "capture learnings" → §13 Learn
- After a substantive PM task, Proactive Behavior B offers to capture learnings

## Sub-skills (route to these)

Route to these — including **mid-flow** when a core operation surfaces the need:

| Need | Sub-skill | Triggers |
|------|-----------|----------|
| Daily/weekly briefs, tag digests, coverage briefs | `llm-wiki-brief` | "daily/weekly brief", "catch me up", "[tag] digest" |
| Research sprints, competitive deep dives, stub enrichment | `llm-wiki-research` | "research [topic]", "deep dive", "auto-research [entity]" |
| Daily-maintenance loop (sweep all sources → ingest → brief → tidy), incl. scheduled runs | `llm-wiki-maintain` | "daily maintenance", "morning sweep", "ingest all sources and brief", "do the daily run" |

If a sub-skill isn't installed, the core skill's matching fallback handles it where
one exists (§10/§11/§12); research and maintain require their
sub-skill (you can still run maintenance steps manually via core ingest/brief/lint).

## Proactive Behaviors

Fire whenever the skill is loaded. Append notes briefly *after* your answer, never
before. Searches: wiki-search `search_text` preferred, grep fallback.
**Limits:** max 1 suggestion per turn; skip during code/debug tasks; PM-domain
facts not already addressed; never auto-write.

**A. Entity-aware recall & contradiction.** When the user mentions a named
company/person/product (not just in passing), search the wiki; if a page exists,
surface it in one line with its `confidence:`/`coverage:` and `updated:` date.
Always flag `rumor` confidence: "Wiki has [[page]] (rumor, unverified). Treat with
caution." If the user's statement conflicts with the page, note it: "This may
conflict with [[page]] from YYYY-MM-DD. Which is current?" For a named person,
fold in 1-2 relevant traits from `entities/<name>-persona.md` if present.

**B. Capture offer (facts, decisions, open questions).** When the user states a
wikifiable PM fact, a decision ("we decided", "going with X"), or asks a factual
question the wiki can't answer, offer to capture it — *after* a mandatory **dedup
search** of the statement's key noun phrases. If a page already holds the claim,
offer an update, don't duplicate: "Already in [[page]] (updated YYYY-MM-DD). Update
it?" Decisions → a `decision`-tagged page (who, when, rationale). Unanswerable
questions → a `question`-tagged page under `queries/`. After a substantive PM task
(research, ingest, briefing, strategy), self-audit once for uncaptured items and
offer §13 Learn. Skip casual chat, hypotheticals, and anything already captured.

*(Tool-discovery suggestions live in `references/recommended-tools.md` — surface
one only when a query would clearly be richer with an unconnected tool.)*

## Wiki Location
Before any bash command using `$WIKI`, resolve it:
```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
```
Resolution: `.wiki-path` (project) → the plugin's `wiki_path` option (global) →
`WIKI_PATH` → cwd, but only if cwd already is a wiki (has `SCHEMA.md`). If `WIKI`
is empty, stop and tell the user to run `/llm-wiki-pm:set-wiki-path ~/path`.
The SessionStart hook states the active path each session.

## Session Defaults

**Wiki-first protocol:** Before answering a PM knowledge question, search the wiki
with connected tools. Don't synthesize from training data when wiki pages exist.
Cite explicitly: "Per [[page]]...". If no page exists, say so and offer to create
one or log an open question. Before asking the user a fact about people, teams,
ownership, customers, roadmap or process, search the wiki first, including during
code or GitHub work.

**Source discipline (the wiki is a map, not the territory):** wiki-first must not
become wiki-only. Verify from source; use the wiki to know where to look. Four
guards govern this — the full detail and rationale are in
`references/source-discipline.md` (read it before a substantive ingest, a
multi-source sweep, or any decision-bearing/exec-facing synthesis). The input side
is largely enforced by the `pre-write.sh` freshness gate and `lint.py`
(self-referential sourcing, missing inline provenance). In brief:

- **Freshness-first guard.** Before writing/updating a page, sweep connected tools
  for newer primary sources and anchor claims with inline `[source:]` markers;
  don't build a page from other pages' prose. One batch sweep covers a batch
  operation. Distinguish "wiki says X (as of date)" from "live sources confirm X today".
- **Source-completeness guard.** For any multi-source sweep, enumerate the
  **canonical sweep registry** in `$WIKI/MY-INTEGRATIONS.md` (`## Sweep Registry`)
  and cover every source. Empty ≠ done: run ≥2 varied queries, then classify each
  source `hits` / `empty-after-retries` / `failed` and report all three — never
  collapse `failed`/`empty-after-retries` into "covered."
- **Source-depth guard.** A hit that *references* an artifact (attached file,
  linked doc, cited spec) is not the content. Open it before synthesizing; if you
  can't, flag it unread and don't write over it.
- **Provenance-tier & falsification guard.** Tier every asserted claim
  `computed` / `primary` / `recalled`; never state a recalled claim as fact in a
  decision-bearing answer without upgrading it against a primary source. Route
  targeting/pipeline/quantitative questions to the primary system (CRM, warehouse,
  Gong), not wiki prose. Before exec-facing synthesis, run a falsification pass:
  name and run the query that would disprove each headline claim.

**Session trust model:** Trust `.wiki-path` for location, `SCHEMA.md` for taxonomy
(new tags go there first), `log.md` for recent activity. Deviate only with explicit
user confirmation.

## Tool Selection Hierarchy

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

More from anh-chu/llm-wiki-pm