Llm wiki research
PM knowledge base skill for Claude Code. Karpathy's LLM Wiki pattern with supersession, privacy, crystallize, and qmd hybrid search.
npx -y skills add anh-chu/llm-wiki-pm --skill llm-wiki-researchAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 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.
What its author says it does
Copied from the file, not written here
Research sprints, competitive deep dives, and auto-enrichment of stub wiki pages. Delegates web fetching to worker-source-fetcher. Files all findings back into the wiki.
SKILL.md
8.4 KB, as published. Nobody here has run it
LLM Wiki Research
Sub-skill of llm-wiki-pm. Handles research sprints, competitive deep dives, and auto-enrichment of stub entities. Delegates all URL fetching to worker-source-fetcher so privacy filtering and raw/ logging happen correctly.
WebFetch note: WebFetch is listed in allowed-tools for quick page previews (e.g., confirming a URL before delegation). For source capture (saving to raw/), always delegate to worker-source-fetcher. Never call WebFetch directly for source saving — privacy filtering and raw/ logging won't happen.
Orient First
Orient per AGENTS.md before any writes:
- Read
$WIKI/SCHEMA.md - Read
$WIKI/index.md - Read last 20-30 lines of
$WIKI/log.md - Read
$WIKI/overview.md
Research sprints may create many pages. Get user confirmation before creating 5+ pages.
Wiki Path Resolution
WIKI=$(cat .wiki-path 2>/dev/null | tr -d '[:space:]')
WIKI=${WIKI:-${CLAUDE_PLUGIN_OPTION_wiki_path:-${WIKI_PATH:-$(pwd)}}}
Worker Delegation
This skill uses worker-source-fetcher for all URL fetching. Never call WebFetch directly for source capture — always invoke the worker:
"Use worker-source-fetcher to fetch [URL]"
This ensures privacy filtering and raw/ logging happen correctly. The worker returns:
"OK: saved to raw/<subdir>/<slug>.md" — use that path for synthesis.
Operation 1: Research Sprint
Trigger: "research sprint on [topic]", "deep research on [topic]"
① Define scope
Confirm with user:
- What is the topic / question to answer?
- Target depth: surface / standard / deep
- Time budget (number of sources)
② Wiki-first
grep -r "<topic>" $WIKI --include="*.md" -l
Read all relevant pages. Surface: "Wiki has N relevant pages. Here's what we already know: [...]. Gaps: [...]."
③ Research plan
Present 3-5 specific sources to fetch — name each, why it's relevant, what question it answers. Typical: analyst reports, company pages, recent press, whitepapers, industry forums. Get user confirmation before fetching.
④ Delegate fetching
For each confirmed source: "Use worker-source-fetcher to fetch [URL]"
If a fetch fails (404, paywall, timeout), note it and continue. Collect all raw/ paths before writing.
⑤ Synthesize
Read all fetched raw files. Extract entities, claims, data points. Cross-reference against existing wiki pages. Distinguish:
- Confirmed (claim now in 2+ independent sources)
- New (single source, not yet corroborated)
- Contradicts wiki (surface the conflict explicitly)
⑥ File findings
Create/update wiki pages per core ingest discipline: inline provenance, coverage markers, confidence levels, min 2 outbound wikilinks, backlink audit.
Produce a synthesis page at queries/research-<topic>-<YYYY-MM-DD>/README.md:
---
title: "Research Sprint: <Topic>"
created: YYYY-MM-DD
type: query
tags: [<relevant tags>]
sources: [<raw slugs fetched>]
---
## Scope
Question: [...] Depth: [...] Sources: N
## What We Knew
[Pre-sprint wiki state summary]
## What We Learned
[Net-new findings with inline citations]
## Confirmations
[Claims now corroborated by 2+ sources]
## Contradictions
[Conflicts with existing wiki pages — cite both sides]
## Still Unknown
[Gaps that fetching didn't resolve]
## Pages Created/Updated
- [[slug]]: [brief note]
⑦ Surface delta
What did we learn that we didn't know? What did it confirm? What's still unknown? Any contradictions with the wiki?
⑧ Log
## [YYYY-MM-DD] research-sprint | topic: <X> | sources: N | pages created/updated: N
Operation 2: Competitive Deep Dive
Trigger: "competitive deep dive on [company]", "full competitive analysis of [company]"
① Read existing coverage
Read $WIKI/entities/<company>.md and related comparisons/ pages. If coverage: comprehensive, ask: "Already marked comprehensive — update pass or fresh deep dive?"
② Research plan
Standard source set:
- Official website (product, pricing, about)
- Recent press (last 6-12 months)
- Job postings (signals: what they're building)
- Pricing page
- G2 / Gartner / Capterra reviews
- Analyst mentions (MQ, Wave, IDC)
- Crunchbase / LinkedIn (funding, headcount)
Get user confirmation before fetching.
③ Delegate fetching
"Use worker-source-fetcher to fetch [URL]" for each confirmed source.
④ Update entity page
Apply diff discipline (core §4): snapshot to _archive/<company>-<date>.md first, show diff before writing, update inline provenance on revised facts, sweep stale variants.
⑤ Update comparison pages
Update existing comparisons/ pages. Offer to create a new comparison page if the deep dive reveals strong differentiation.
⑥ Flag confidence by source
| Source type | Confidence |
|---|---|
| Official website, press releases | verified |
| Analyst reports, G2 reviews | likely |
| Forums, social media, unofficial blogs | rumor |
⑦ Log
## [YYYY-MM-DD] competitive-deep-dive | entity: <company> | sources: N | pages updated: N
Operation 3: Auto-Research (Stub Enrichment)
Trigger: "auto-research [entity]", "enrich [entity]", "fill in [entity] page"
For entity pages with coverage: stub. Fast enrichment pass. This is factual/web
enrichment. If the user wants relationship/CRM context (tier, touchpoint, feature
asks) rather than facts, route to llm-wiki-crm's enrich instead.
① Read the stub — what do we already know? What's in gaps:?
② Search
WebSearch: "[entity name]" recent news
WebSearch: "[entity name]" official website
WebSearch: "[entity name]" [primary domain, e.g. pricing / funding / product]
③ Extract — description, key facts, relationships to other wiki entities, recent events.
④ Update stub page with inline provenance [source: url, date]. Bump coverage: stub → partial if meaningful data found. Update gaps: and sources: frontmatter. Bump updated:.
Do NOT fabricate. If search returns nothing useful, say so. Leave coverage: stub.
⑤ Log
## [YYYY-MM-DD] auto-research | entity: <X> | coverage: stub→partial | sources: N
# or if nothing found:
## [YYYY-MM-DD] auto-research | entity: <X> | no public data found | coverage: stub (unchanged)
Operation 4: Gap Research
Trigger: "research our gaps", "fill coverage gaps", "research stubs"
① Scan for stubs
grep -r "coverage: stub" $WIKI --include="*.md" -l
grep -rL "coverage:" $WIKI/entities $WIKI/concepts --include="*.md"
② Present list — ask user which to prioritize.
③ Run Operation 3 on each selected stub in sequence. Surface result before moving to next: "Enriched [[entity]] — stub → partial. Found: [key facts]. Continue?"
④ Report
Gap research complete:
- N pages enriched (stub → partial)
- N pages still stub (insufficient public data)
- N pages skipped
⑤ Log
## [YYYY-MM-DD] gap-research | stubs scanned: N | enriched: N | still-stub: N
Pitfalls
- Orient first: before any writes. Research sprints may touch many pages.
- Delegate fetching: always use
worker-source-fetcher— never WebFetch directly for source saving. - Confirm before mass creates: 5+ pages → user confirmation first.
- Inline provenance: every non-obvious claim needs
[source: slug, location]. - Coverage markers: bump
coverage:after meaningful enrichment. - Confidence discipline: verified / likely / rumor — label accordingly.
- No fabrication: if search returns nothing, say so.
- Snapshot before destructive updates:
_archive/<slug>-<date>.mdbefore deep dive overwrites. - Dedup: grep before creating. Confirm update vs create.
- Privacy: private by default — leave customer names, deal sizes, and 1:1 content unflagged (never add
shareable: trueto them). - Synthesis page: research sprints always produce
queries/research-<topic>-<date>/README.md.