From llm-wiki
This skill should be used when the user wants to "create a project wiki", "set up a wiki for implementing tickets", "create a wiki for autonomous coding", "initialize a product wiki", "set up a knowledge base for the codebase", or wants Claude to be able to implement Jira/Linear/GitHub tickets autonomously without needing to ask for context. Creates a wiki structured around the missing layer between code and tickets. Works for both established products and greenfield projects.
How this skill is triggered — by the user, by Claude, or both
Slash command
/llm-wiki:create-project-wiki [product or domain description] (optional)[product or domain description] (optional)This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create a wiki designed to enable autonomous agentic code implementation. This wiki fills the missing layer between the codebase and the ticket — the *why* and *what* that Claude cannot derive by reading code alone.
Create a wiki designed to enable autonomous agentic code implementation. This wiki fills the missing layer between the codebase and the ticket — the why and what that Claude cannot derive by reading code alone.
Claude can already explore the codebase. It can read files, trace call stacks, grep for usages, and understand what the code does. The wiki must not duplicate this.
The wiki holds only what cannot be learned from the code:
The wiki does not hold:
The distinction on code pointers: where a feature lives is a wiki concern; what the code at that location does is not. "The billing feature is in src/billing/, entry point is BillingService.charge()" belongs in the wiki. What charge() does does not.
The test: Could Claude figure this out by reading the codebase? If yes, it doesn't belong in the wiki — with one exception: code location pointers are always worth recording, even when the code is readable, because they save Claude from exploring the wrong part of the repo.
Before the discovery interview, ask one question:
"Is this an established product with existing code and decisions, or a greenfield project just getting started?"
This determines which mode to use. The page types and schema structure are the same in both modes — the difference is in how the interview is conducted and how incomplete answers are handled.
Use when the product has existing code, decisions, and team knowledge to document.
Ask all of the following in a single message:
Wait for answers. Generate the schema from what's provided — skip or stub any section the user doesn't answer.
Use when the product is early-stage and many things are still undecided.
Ask only what's knowable right now — in a single message:
Frame the questions explicitly: "Answer only what you know — skip anything undecided. The wiki will grow as the product does."
Generate wiki/CLAUDE.md from whatever answers are provided. For any section with no information yet, write a stub marked TODO rather than leaving it empty or making things up.
Add a "Greenfield notice" at the top of the generated schema:
> ⚠️ **Greenfield wiki** — This wiki was initialized early. Many sections are stubs.
> As the product takes shape, fill them in by ingesting PRDs, design docs, and decision notes,
> or by asking the wiki-agent to add pages after key decisions are made.
> Update this schema (`wiki/CLAUDE.md`) whenever the product's structure or conventions change.
Add a "Schema evolution" section to the schema:
## Schema evolution
This schema is a living document. Update it when:
- New domain entities emerge that don't fit existing page types
- New integrations are decided
- Team conventions are established
- The product's scope changes significantly
To update: edit `wiki/CLAUDE.md` directly, then ask the wiki-agent to lint the wiki and flag
any existing pages that need updating to match the new schema.
Generate stub pages for any entities the user named, using the page type templates below with TODO in unfilled sections. This gives Claude something to build on immediately rather than an empty wiki.
Based on the answers, generate wiki/CLAUDE.md with the following sections. Tailor every section to the specific product and domain — do not use generic placeholder text. For greenfield, stub unknown sections with TODO.
Write 3-4 sentences describing exactly what this wiki is for:
Include this verbatim, as it governs how Claude should behave in every session:
When working on a ticket or implementing a feature, read the relevant wiki pages before reading the code. The wiki provides the intent and the map; the code provides the implementation. Use the wiki's code location pointers to find where to start in the codebase, then read the code to understand how it works.
If the wiki and the code appear to conflict, flag it — the wiki may be stale or the code may have drifted from intent.
Never add content to the wiki that can be learned by reading the codebase, with one exception: always record code location pointers (which modules, directories, and entry points implement a feature). The wiki is not documentation of what the code does. It is context for why the product works the way it does, and a map for where to find it.
If a wiki page has a
TODOsection, note it when citing that page — the information may be missing. Suggest filling it in if it's relevant to the current task.
Define the following page types, tailored to the domain. For each, specify the naming convention and required sections.
Domain entities (pages/entities/)
One page per core domain entity. Required sections:
Feature specs (pages/features/)
One page per significant product feature. Required sections:
path/to/module — ClassName — brief role (e.g. src/billing/ — BillingService — orchestrates charge lifecycle). Not what the code does; just where it lives.Business rules (pages/rules/)
For rules that span multiple features or entities. Required sections:
Integrations (pages/integrations/)
One page per external service. Required sections:
Architecture decisions (pages/decisions/)
For significant decisions where the rationale isn't obvious from the code. Required sections:
Workflows (pages/workflows/)
For end-to-end business processes that span multiple features or services. Required sections:
Gotchas (pages/gotchas/)
A catch-all for non-obvious constraints, landmines, and "don't do X because Y" rules. Required sections:
The index is organized by page type (Entities, Features, Rules, Integrations, Decisions, Workflows, Gotchas). Each entry: page title, one-line summary, last updated date.
## [YYYY-MM-DD] <operation> | <title>
Operations: ingest, query, lint, create, update.
([Source](../raw/filename.md))
After generating the schema, create:
mkdir -p wiki/raw wiki/pages/entities wiki/pages/features wiki/pages/rules \
wiki/pages/integrations wiki/pages/decisions wiki/pages/workflows wiki/pages/gotchas
Create wiki/index.md organized by the page types above, with empty tables for each section.
Create wiki/log.md with an initial entry:
## [today] create | Project wiki initialized
Product: [product name from discovery]
Mode: [established / greenfield]
Purpose: Autonomous agentic implementation — fills the gap between codebase and tickets.
For greenfield mode, also create stub entity pages for any entities named in the interview.
After setup, tell the user:
For established mode:
wiki/raw/ and ask the wiki-agent to ingest them.For greenfield mode:
wiki/CLAUDE.md and tell the wiki-agent to lint for pages that need updating.npx claudepluginhub christianasc5/christianasc5-marketplace --plugin llm-wikiFetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.