Welcome to the NZRT Wiki Podcast. Today we’re looking at LLM Wiki Schema.

This episode covers how notes are structured in the NZRT LLM knowledge vault. Whether you’re creating a new skill file or reviewing an existing one, this schema tells you exactly what to include and how to format it.

Let’s start with the frontmatter — that’s the block of metadata sitting at the very top of every skill note, before any main content. Think of it as the ID card for your document.

The frontmatter is written in a format called YAML, and it contains eight fields. Here’s what each one does.

First, tags. Required, and it holds a list of labels that make your note searchable and categorisable. Every note gets the vault-level tag 000LLM, the general LLM tag, a category tag, and a skill-specific slug. We’ll come back to those in a moment.

Second, aliases. Also required. These are human-readable names for the skill — alternative ways someone might refer to it, so if your file uses a technical slug, aliases give you the friendly labels people would actually search for.

Third, role. Required, and always set to the vault maintainer role, which in this case is xc.

Fourth, category. Required. This tells you which broad type the skill belongs to. There are seven options, and we’ll cover those shortly.

Fifth, complexity. Required. Low, medium, or high — reflecting how much effort the skill takes to implement.

Sixth, status. Required. A note moves through three stages: draft, review, and complete. This field tracks where it sits in that lifecycle.

Seventh, created. Required. The date the note was first made, in ISO 8601 format — that’s year, then month, then day.

Eighth, related. Optional. This lets you link out to other skill notes connected to this one.

Now let’s talk about the body of a skill file. Every note follows the same section order, and that consistency is what makes the vault navigable.

You start with the skill name as the top-level heading, followed by a single sentence defining what the skill is. Then comes an overview explaining what the skill is, what an LLM does when performing it, and why it matters. After that, a section called How It Works gives you a step-by-step or conceptual breakdown of the mechanism.

Next is Prompt Patterns — this is where reusable templates live. Placeholders in those templates are written in a specific style: all uppercase letters, words separated by underscores, and wrapped in double curly braces. So something like “document text” would appear as a placeholder in that format rather than as plain words.

Then you have an Examples section with concrete input and output pairs showing the skill in action, followed by NZRT Applications, which maps the skill to real work across WordPress, Dolibarr, Nextcloud, or TOGAF. After that comes Parameters and Tuning, covering things like temperature settings, token limits, and model recommendations. Then Limitations, documenting known failure modes and when not to use the skill. And finally, Related Skills, with links to connected notes and a one-line explanation of each relationship.

Now let’s cover the seven category types. Foundational covers core LLM techniques that everything else builds on — prompt engineering sits here. Text-processing is for skills that take input and transform it into a different form of text, such as summarization, extraction, and classification. Development covers code and technical artifact generation. Retrieval is about grounding LLM output in source documents — this is where RAG and question answering live. Analytical covers multi-step reasoning over complex inputs. Integration connects LLMs to external systems, like tool use and function calling. And architecture handles multi-LLM orchestration and agent design — things like pipelines and agent frameworks.

The tag taxonomy builds on all of this. At the top level you have three general tags: one for the vault itself, one for general LLM content, and one for broader AI and machine learning context. Then come the seven category tags matching the types we just covered. Each individual skill note also gets its own slug tag — examples include prompt-engineering, code-generation, summarization, data-extraction, question-answering, classification, reasoning, tool-use, rag, and agents. Finally, there are integration tags for the specific systems this vault connects to: wordpress, dolibarr, nextcloud, togaf, and nzrt.

The naming conventions are straightforward. Skill files live in a Skills folder and use lowercase words separated by hyphens, with a dot-md extension. Section headings use title case. And wikilinks use the slug form of the skill name.

Finally, the complexity guide gives you a clear way to decide which level applies. Low means a single prompt with no external dependencies that works reliably out of the box. Medium means you’ll need some prompt tuning, a few examples to guide the model, or some light post-processing of the output. High means you’re dealing with system design, external tools, retrieval pipelines, or multi-step chains.

That covers the full schema — frontmatter, body structure, categories, tags, naming conventions, and complexity levels. If you’re writing a new skill file for the vault, this is your complete checklist.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.