po4yka/llm-wiki-skills/llm-wiki-domain-pack

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_type mappings, 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-ingest or wiki-query for 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:

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 type enum for one domain; use domain_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.