Skip to content

Extending the Template

Jump to bottom
Chris Sweet edited this page Jul 14, 2026 · 2 revisions

type: reference up: "What-is-the-llm-wiki-Template" related:

Extending the Template

How to adapt the template to your own needs without breaking template updates. Grounded in features/README.md, docs/adding-a-feature.md, the Claude Code overlay files, Edge-Types.md, scripts/kg/sparql/, and the sync/manifest machinery.

Can I add my own slash commands? Where do they go?

Yes. Claude Code slash commands live in .claude/commands/<name>.md; each is a thin front door that references a model-side skill in .claude/skills/<name>.md. Add both a command file and (optionally) its skill file, following the shape of the shipped wiki-source / wiki-experiment / wiki-lint pairs. Because the template's sync only manages files named in its manifest, your own command and skill files are left untouched by update-from-template.sh.

Can I add my own skills (model-side procedures)?

Yes, the same way: drop a .claude/skills/<name>.md file. The three shipped skills are the model; keep a skill and its slash command in sync if you pair them (the template notes the slash-command-vs-skill parallel-file drift as a known footgun). For substantial, optional, removable capabilities, prefer packaging as a feature (below) rather than loose files.

Can I add custom edge types beyond the standard vocabulary?

Yes, by editing Edge-Types.md in your wiki to add the predicate with a one-line definition (and, for KG queryability, its inverse convention). The vocabulary is deliberately extensible: the SCHEMA notes that heavy use of related: is a signal the specific vocabulary should be extended. Caveat: the KG pipeline resolves predicates against the LA3D ontology and validates with SHACL shapes fetched from that spec, so a brand-new predicate is carried through the extractor but will not gain a materialized inverse or shape-checking until the upstream ontology/shapes recognize it. For local use that is fine; for cross-tool interchange it is a limitation.

Can I add custom node types?

Yes. The type: field is open; add a new value and use it. Two page types (analysis, decision) carry required-section contracts in the SCHEMA; a custom type has no required structure beyond the general page format. As with edges, a custom type: value is carried through the extractor as a node but is only shape-validated to the extent the upstream SHACL spec knows it; unknown types are tolerated (they appear as-is), so nothing breaks.

Can I use a different LLM agent than the ones supported out of the box?

The template ships overlays for Claude Code (validated) and Cursor (structural only), plus --agent=none (no overlay). For another agent, the intended path is either the minimal mode (the agent reads CLAUDE.md/AGENTS.md and follows the documented procedures) or authoring a new overlay under wiki/agents/<overlay>/ with the surfaces that agent supports (rules, commands, hooks) plus a setup.sh that wires them in. The core pattern is agent-agnostic; only the injection mechanism differs per agent. Whether a given non-instructed agent actually follows the procedures is empirically open.

Can I add my own SPARQL queries to the library?

Yes. Drop a .rq file into scripts/kg/sparql/. The shipped set (11 queries: hub-notes, orphan-notes, extension-chains, and so on) is a curated starting library, not a ceiling. Your queries run against the same graph-full.ttl via rdflib. See Knowledge-Graph.

Can I export the wiki to a different format?

Partly, and more is planned. Today the wiki is Markdown-plus-frontmatter in git, so any Markdown tool can consume it, and the KG pipeline exports the graph as JSON-LD and RDF Turtle. A dedicated OKF (Open Knowledge Format) export is analyzed but not yet shipped (see Knowledge-Bundles-Overview); the template wiki's OKF-Alignment-Ideas page works through a scripts/export-okf.sh option but marks it deferred until external bundle exchange is a real requirement. For now, export means "clone the Markdown" or "use the emitted .ttl/.jsonld".

Can I add project-specific rules to CLAUDE.md without breaking template updates?

Yes. CLAUDE.md is host-owned: update-from-template.sh preserves your project narrative and does not overwrite it. The template injects its managed subsections (memory-boundary, wiki-maintenance) behind paired HTML-comment sentinels (<!-- lw:wiki-maintenance --> ... <!-- /lw:wiki-maintenance -->), and re-injection is idempotent on those sentinels. So keep your own rules outside the sentinel-wrapped blocks and they survive updates untouched; the template only ever touches the content between its own sentinels.

How do I add a SessionStart hook of my own?

Add your hook script under .claude/hooks/ and register it in .claude/settings.json under hooks.SessionStart as its own matcher group (the overlay's setup.sh registers each hook as a separate group precisely so they do not clobber each other's matchers). The template already installs ensure-wiki.py (matched to startup|resume) and session-start.sh (all sources); model your own registration on those. .claude/settings.local.json is per-user and gitignored if you want a personal, uncommitted hook.

Can I run the wiki without git?

Not really, and it is not recommended. Git is foundational to the design: the wiki is a separate git sub-repo, the SessionStart hook clones it with git, the write protocol is built entirely on git mechanics, log attribution reconciles against git blame, and versioned history is a core value proposition. You could keep the Markdown files without a remote, but you would lose the auto-clone, the multi-writer protocol, attribution provenance, and version history, which is most of what makes the wiki durable memory. The template assumes git throughout.

Packaging an extension as a feature

For anything substantial, optional, and removable, the cleanest path is an opt-in feature under features/<name>/. A feature is a self-contained directory with a feature.json manifest (declaring files, tests, ci, claude_md section, system_deps, depends_on) and optionally a CLAUDE.section.md inserted into the derived project's CLAUDE.md. Enable it at instantiation (--features=<name>) or later (./scripts/enable-feature.sh <name>); remove it symmetrically (./scripts/disable-feature.sh <name>). Enabled features are tracked in .features-enabled. The first shipped feature is agent-comms (the ask federation primitive; see Team-Workflow). The canonical guide is docs/adding-a-feature.md.

See also

Clone this wiki locally