Llm Wiki Pm

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 or revise a page with new info
• User asks to lint, audit, or health-check the wiki
• User asks to create or bootstrap a PM wiki
• User references "my wiki", "the wiki", "knowledge base", "notes" in a PM context
• Natural memory phrases (no other memory system assumed): "remember that",

"note that", "don't forget", "keep in mind", "save this", "log this", "make a note", "record that", "I want to remember" → treat as a wiki ingest. Capture the fact as a short wiki page or update to an existing relevant page. Use §2 Ingest with source conversation | . Ask user which page it belongs to if unclear, or create a new entity/concept page if it warrants one.

• "I have a meeting/call/1:1 with [person]" → triggers §9 Pre-Meeting Briefing
• "What happened this week / last week / recently?" → triggers §10 Catch Me Up
• "[tag] digest" or "catch me up on [topic]" → triggers §11 Tag Digest
• "What am I missing?", "blind spots?", "coverage gaps?" → triggers §12 Coverage Audit
• "What did we learn?", "capture learnings", "record what we found" → triggers §13 Learn
• After completing a PM-domain task, Proactive Behavior #7 offers to capture uncaptured learnings

Sub-skills (route to these)

These capabilities live in separate, independently-installable sub-skills, each with its own triggers. Route to them — including mid-flow, when a core operation surfaces one of these needs (don't try to do them from the core skill):

| Need | Sub-skill | Triggers | |------|-----------|----------| | Communication persona pages, relationship maps, org charts | llm-wiki-persona | "build a persona", "communication profile", "map relationships" | | Daily/weekly briefs, tag digests, coverage briefs | llm-wiki-brief | "daily/weekly brief", "catch me up", "[tag] digest" | | PRDs, user stories, release notes | llm-wiki-prd | "write a PRD", "user stories", "release notes" | | Research sprints, competitive deep dives, stub enrichment | llm-wiki-research | "research [topic]", "deep dive", "auto-research [entity]" | | Relationship/account health, CRM context, touchpoints | llm-wiki-crm | "relationship health", "account health", "who haven't I talked to" | | Daily-maintenance loop (sweep all sources → ingest → brief → tidy), incl. scheduled/autonomous 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 operation handles it where one exists (§10/§11/§12); persona, PRD, research, CRM, and maintain have no core fallback — they require their sub-skill. (You can still run the maintenance steps manually via the core ingest/brief/lint operations.)

Proactive Behaviors

These fire whenever the skill is loaded, not tied to explicit commands. Append notes briefly after your answer, never before; don't interrupt it. All searches below: wiki-search semantic_search preferred, grep fallback. Limits: max 1 suggestion per turn; skip during code/debug tasks; only for PM-domain facts not already addressed.

1. Proactive Recall

User mentions a named entity (company, person, product) → search the wiki; if a page exists, surface it inline (one line), including confidence:/coverage: from frontmatter: > "Wiki has [[page]] (updated YYYY-MM-DD, confidence: verified, coverage: partial). Want a summary?"

Always flag rumor confidence: "Wiki has [[page]] (rumor, unverified). Treat with caution." Skip entities that came up only in passing.

2. Ambient Fact Capture

User states a wikifiable PM fact (decision, person, company, roadmap, competitor, customer) → offer to add it: "That sounds wikifiable. Want me to add it?" Skip casual chat, unspecific opinions, hypotheticals. Dedup gate (mandatory): search the wiki for the statement's key noun phrases first. If a page already holds the claim (same entity + same fact), offer an update instead, don't duplicate: > "Already in [[page]] (updated YYYY-MM-DD). Want me to update it?"

3. Contradiction Alert

User states a fact about a known entity → search that entity, check for conflicts: > "This may conflict with [[page]] from YYYY-MM-DD. Which is current?"

Best-effort. Don't surface false positives from vague matches.

4. Open Question Backlog

A factual question the wiki can't answer → offer to log it ("Want me to log that as an open question?") as a question-tagged page under queries/ with text + date. Skip rhetorical questions or ones the user is about to answer themselves.

5. Decision Journaling

Decision language ("we decided", "the call is", "going with X", "I've decided") → offer to log it ("Want me to log that decision?"). If yes, create/update a decision-tagged page with who decided, when, and the rationale if stated.

6. Relationship-Aware Answers

Question involves a named person → check entities/-persona.md and concepts/relationship-map.md; if found and relevant, fold in 1-2 lines of key traits. Don't pad; skip if persona data isn't relevant.

7. Post-Task Capture

After a substantive PM-domain task (research, ingest, query, briefing, strategy), self-audit for uncaptured facts/decisions/entity-updates/relationship-changes/ open-questions and offer a one-line summary: > "This task surfaced N uncaptured facts/decisions. Want me to record them? (§13 Learn)"

Guardrails: PM-domain tasks only (skip code/debug); skip if already captured via #2-#5; max 1 offer per task (not per turn), no repeats within a multi-turn task; never auto-write; ignore passing/hypothetical mentions.

8. Tool Discovery

At session start, inventory connected MCP tools. When a query would be richer with an unconnected tool, suggest it once: > "This query would be richer with [tool]. Setup: [install command]. See references/recommended-tools.md."

Examples: public-company financials → SEC EDGAR; competitor LinkedIn → LinkedIn MCP; site traffic → SimilarWeb; cited grounded answers → NotebookLM; reading lists/highlights → Readwise. Guardrails: max 1 suggestion per session (don't nag); only tools from references/recommended-tools.md (don't invent); skip tools the user declined; bundled tools should just work, so only flag key-required ones; frame as enhancement — answer with available tools first, then mention the upgrade path.

Wiki Location

Before running any bash command that uses $WIKI, resolve it with:

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

Resolution: .wiki-path (project) → CLAUDE_PLUGIN_OPTION_wiki_path (global) → WIKI_PATH → cwd. Run /llm-wiki-pm:set-wiki-path ~/path to set project path. additionalContext states the active path each session.

The SessionStart hook's additionalContext states the active path each session.

Session Defaults

Wiki-first protocol: Before answering any PM knowledge question, search the wiki using 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.

Freshness-first protocol (counterweight to wiki-first): The wiki is only as good as the information fed into it. Wiki-first must not become a self-reinforcing loop where the wiki only ever cites itself and slowly drifts from reality. For ANY substantive operation — answering, creating, OR updating, on any page type, not just people/companies — proactively pull fresh primary information from connected tools (Slack, Gmail, Granola/meetings, CRM, web) rather than relying solely on what the wiki already records. Specifically:

• Before writing or updating a page, sweep connected tools for newer primary sources on the topic. Ingest what you find to raw/ and anchor claims with inline provenance. Don't build or revise a page purely from the prose of other wiki pages — that launders secondhand mentions into false confidence (e.g. mislabeling a CTO as a "vendor cost owner" because that's all the linked pages happened to say).
• One batch sweep satisfies freshness-first for a batch operation. "Before writing... sweep" is per-operation, not per-page. A daily-maintenance run or multi-page ingest that touches ~8 pages does NOT mean eight separate tool sweeps: do one registry-driven sweep up front (per the Source-completeness guard), then write all the pages that sweep covered. The per-page rule applies to a standalone single-page write/update done outside a batch (a decision-bearing edit to one page → refresh that topic first). This resolves the apparent conflict with "Respect cost": batch once, write many; don't re-sweep per page, and don't skip the sweep entirely.
• When answering, if the most relevant wiki pages are thinly sourced, stale (past the staleness thresholds), or single-source, run a quick live search to corroborate or refresh before relying on them. Surface what changed and offer to update the page.
• Default to ingest, not just recall. When a connected tool surfaces something the wiki doesn't have, treat it as a candidate ingest, not a throwaway lookup. The goal is a wiki that constantly absorbs new signal, not one that re-serves old signal.
• Be honest about provenance age. Distinguish "the wiki says X (as of )" from "live sources confirm X today." If you couldn't verify against a live source, say so.
• Respect cost. Proportional to stakes: a quick lookup needn't trigger a full sweep, but anything written, updated, or decision-bearing should be checked against live sources.

Source-completeness guard (anti-premature-closure): A thin, empty, or errored result from a requested source is NOT permission to stop. It is a signal that your search, not the source, may be the problem. "Enough captured", "that's sufficient", or moving on while a requested source returned nothing is a defect, not a judgment call. Specifically:

• Define the source set before you sweep (anti-omission). This guard catches "you reported a source empty" but NOT "you forgot the source exists" — the more dangerous failure. Before any "ingest all sources" / daily-brief / multi-source sweep, enumerate the canonical sweep registry in $WIKI/MY-INTEGRATIONS.md (the ## Sweep Registry section) and iterate every source listed there. The registry, not your memory, defines what "all sources" means. If the file or section is missing, build the set from your connected-tool inventory plus the Active Sources table, confirm it with the user, and write it to the registry before sweeping — do not sweep an implicit, from-memory list. Silently omitting a registered source (declaring a sweep complete without it) is the worst-case defect: it reads as a complete picture while a high-signal source went unread.
• Empty ≠ done. Before concluding a source has nothing, run at least 2-3 query variations: broaden/narrow terms, widen the time window, try aliases/synonyms/handles/scope variants, and switch search syntax to whatever the tool supports (sender/author filters, channel/folder/label scopes, bare keyword). Keyword-based search tools commonly miss on first phrasing — vary before you quit, whatever the source.
• Distinguish the three states. For each requested source, classify the outcome as: hits (returned content), empty-after-retries (genuinely nothing after ≥2 varied queries), or failed (auth error, not connected, timeout, rate limit). Never silently collapse failed or empty-after-retries into "covered."
• Make voids visible. When a multi-source task (e.g. "ingest all sources", daily brief) is asked to cover N sources, you MUST report the status of every requested source — including the ones that came back empty or failed. Surface: which source, what queries you tried, and the most likely reason (genuinely quiet vs. wrong query vs. not connected vs. unauthorized). A void you report is honest; a void you hide reads as false completeness.
• No closure language over an unresolved void. Do not say a sweep is complete while any requested source is in failed state or was abandoned after a single query. Either resolve it, or explicitly flag it as an unresolved gap and offer the next step (reconnect tool, confirm channel name, widen range).
• Proportional, not infinite. This is not a mandate to loop forever. ≥2 varied queries per source, then report state. The bar is: tried honestly, reported truthfully — not "searched until found."

Source-depth guard (open what you found): Breadth of search is not depth of source. A hit that references content is not the content. If a result links to, attaches, or names a file/doc/image/canvas/PDF/spreadsheet/URL, that artifact is an unresolved source — fetch and read it before synthesizing anything from the surrounding prose. Specifically:

• Referenced ≠ read. A Slack thread saying "here's the 1-pager" with an attached image, a message linking a Drive doc, a ticket citing a spec — the prose around the artifact is a pointer, not a substitute. Drafting feedback, decisions, or page content from the pointer alone is a defect, even when the surrounding text sounds complete.
• Open before you write. Before producing any analysis, review, or wiki page that depends on a referenced artifact, actually fetch it (read the image, download the doc, follow the link). Real tiers, prices, numbers, and matrices routinely live only inside the file and contradict the thread summary.
• Name what you couldn't open. If an artifact can't be fetched (no access, unsupported type, dead link), treat it like a failed source: flag it explicitly as unread, do not synthesize over it, and offer the next step. Never let an unopened attachment read as covered.

Session trust model: Trust .wiki-path for location. Trust SCHEMA.md for taxonomy — new tags go there first. Trust log.md for recent activity. Deviate from any of these only with explicit user confirmation.

Tool Selection Hierarchy

Use ALL connected tools eagerly. At session start, inventory every MCP tool and integration available to you. The plugin bundles wiki-search for semantic wiki search. Use it alongside any user-connected tools.

| Priority | Tools | When | |----------|-------|------| | 1 | wiki-search (bundled) — semantic + TF-IDF over wiki | Wiki queries, entity lookup, semantic recall | | 2 | MCP integrations — Gmail, Slack, calendar, CRM, or any user-connected MCP | Emails, threads, messages, events, enriching entity pages with comms | | 3 | WebFetch / WebSearch | External research, fetching web pages for wiki ingest | | 4 | grep | Exact token match only (dollar figures, codenames, frontmatter values) | | 5 | Read (file reads) | When you already know the exact file and need full content |

Bundled MCP server: wiki-search (semantic + TF-IDF over wiki via @wirux/mcp-markdown-vault, ~80MB model on first use).

Optional tools that enhance these capabilities are listed in references/recommended-tools.md. Suggest them via Proactive Behavior #8 when the user's query would benefit.

Rules:

• Connected tools first, file reads last. If a tool answers faster than

reading files, use it.

• Search before read. Use search/query tools to find relevant pages before

reading files. Don't scan sequentially.

• Use all available tools. Inventory at session start. Don't overlook tools.
• Bound connected-tool output. Broad searches against chat/email/warehouse

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: anh-chu
• Source: anh-chu/llm-wiki-pm
• License: MIT

Install and usage instructions live in the source repository linked above.