Llm wiki domain pack
Generate domain-specific LLM-Wiki templates, taxonomies, domain_type mappings, stale policies, capture rules, and review gates. Use for research papers, codebase docs, startup research, trading research, personal second brain, team onboarding, competitive intelligence, or other specialized domains.From its SKILL.md
npx -y skills add po4yka/llm-wiki-skills --skill llm-wiki-domain-packAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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 file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.7 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it
LLM-Wiki Domain Pack
Goal
Create a domain-specific starter pack that adapts the generic LLM-Wiki pattern to a concrete knowledge domain while preserving the stable core page schema.
When to use
- Bootstrapping a new LLM-Wiki install for a specialized corpus (research papers, codebase docs, trading research, competitive intelligence, onboarding) that has no existing domain pack.
- Adding domain-specific
domain_typemappings, taxonomy, or stale/review policy to a wiki that currently only has the generic core types. - A user asks for capture rules, review gates, or templates tailored to one domain rather than the generic core schema.
- Not for ingesting a single document or answering a query — use
wiki-ingestorwiki-queryfor that instead.
Inputs
- Domain name and purpose.
- User type: personal, team, product, research, company.
- Corpus types and capture channels.
- Required core page types and domain-specific specializations.
- Risk level and review needs.
Procedure
1. Define domain jobs
Ask what the wiki should help produce:
- decisions;
- reports;
- strategies;
- onboarding;
- code changes;
- literature reviews;
- market maps;
- trading theses;
- public documentation.
2. Keep core type stable
Start from the shared core types:
source, entity, concept, comparison, synthesis, query, report
Do not add domain-specific values such as paper, decision, competitor or runbook directly to type. Use domain_type instead.
3. Map domain types to core types
Add domain-specific types only when necessary and map each one to a stable core type:
| domain_type | core type | Example use |
|---|---|---|
paper | source | A paper or preprint preserved as a source page. |
experiment | synthesis | A reviewed experiment note or result summary. |
strategy | synthesis | A strategy memo or durable conclusion. |
decision | synthesis | ADR-like decision provenance. |
competitor | entity | Company/product/project tracking. |
incident | report | Incident review or postmortem. |
customer-question | query | Reusable customer/problem question. |
4. Create pack.md
Every domain pack must include pack.md. It is the human-readable contract that explains jobs, stable core page types, domain types, tags, recommended skills and stale policy.
Required sections:
# <Domain> domain pack
## Jobs
## Core page types
## Domain types
Do not ship only machine-readable JSON; pack.md is what humans and agents review first.
5. Create schema.overlay.json
Every domain pack should include:
{
"$schema": "../../templates/schemas/domain-pack.schema.json",
"name": "example-domain",
"version": "0.1.0",
"core_types": ["source", "entity", "concept", "synthesis", "query"],
"domain_type_mappings": {
"decision": "synthesis"
},
"recommended_tags": [],
"stale_policy": {},
"recommended_skills": []
}
Validate the JSON against the schema if the target repository provides one. In a single-skill install, treat this as a structural review: name matches the pack directory, core types stay within the stable enum, and every domain_type maps to one core type.
6. Create optional profile.json
Use profile.json when the pack should provide application instructions for downstream vault setup. Validate it against references/templates/schemas/domain-pack-profile.schema.json when available, or mirror the same fields in a single-skill install:
{
"name": "example-domain",
"version": "0.1.0",
"copy_to": "_meta/domain-packs/example-domain/",
"recommended_workflow": ["wiki-ingest", "wiki-lint"],
"templates": [
{
"source": "templates/wiki/concept-page.md",
"target": "wiki/concepts/concept-template.md"
}
],
"initial_prompts": [
"Use llm-wiki-doctor to inspect this vault in report-only mode."
]
}
Profiles are reviewable instructions, not automatic migrations.
7. Create taxonomy
Define:
- allowed tags;
- entity classes;
- source classes;
- domain_type values;
- status/stale rules;
- claim types;
- review gates;
- capture channels.
8. Create templates
Produce templates for important domain types with frontmatter that preserves both layers:
type: synthesis
domain_type: decision
domain_pack: codebase-docs
status: draft
review_required: true
9. Add skills guidance
Recommend which skills to use first:
llm-wiki-capture-pipeline;wiki-triage;wiki-ingest;wiki-query;wiki-lint;llm-wiki-eval.
Output
## Domain pack summary
## Domain jobs
## Core page types
## Domain type mappings
## Taxonomy
## Templates
## Capture and review policy
## Validation
## Initial workflow
Safety gates
- Do not create excessive page types before real use.
- Do not extend the core
typeenum for one domain; usedomain_type. - Do not encode current volatile facts as taxonomy.
- Do not remove generic lifecycle states.
- Do not make domain templates look verified by default.
- Re-verify any pricing, release, version, or other time-sensitive fact against fresh sources before writing it into a template or taxonomy entry.
What ships with it: 1 file
1.1 KB alongside SKILL.md
references/
Gives 0 of the 12 instructions most context ai engineering skills give in ~1.2k tokens
Counted across 1,193 of the 1,976 authors here whose files we hold, read 2026-08-07
- Dispatch a fresh implementer subagent per taskin 48 of 1193, across 19 files
- Dispatch a final code reviewer after all tasksin 33 of 1193, across 8 files
- Provide full task text to the subagentin 30 of 1193, across 9 files
- Review spec compliance before code qualityin 27 of 1193, across 10 files
- Make the hook script executablein 26 of 1193, across 8 files
- Re-snapshot after navigation or DOM changesin 25 of 1193, across 19 files
- Read files before editing themin 22 of 1193, across 11 files
- Answer subagent questions before proceedingin 22 of 1193, across 7 files
- Mark task complete in TodoWrite after approvalin 22 of 1193, across 6 files
- Merge hook into existing settingsin 21 of 1193, across 3 files
- Ask if installation is global or projectin 20 of 1193, across 2 files
- Copy the hook script to target locationin 20 of 1193, across 2 files
Said here and by no other author read
- ask what the wiki should produce
- start from shared core types
- map domain types to core types
- create pack.md file
- create schema.overlay.json file
- create optional profile.json file
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.