katalyst

Add a new Katalyst check type end-to-end across check execution, config parsing, CLI validation, tests, fixtures, and the generated Hugo check-types reference docs. Use when the user asks to add, extend, or document a new check type in this repository.

Take stock of an existing body of content with katalyst: profile what's there, surface its recurring kinds of item (candidate collections), and get oriented before declaring any structure. Use when a user points at an existing wiki, docs tree, or notes corpus and wants to understand it, "see what's in here", or prepare to onboard it into katalyst. Precedes katalyst-identify-collections.

Define each collection's schema in a katalyst project — the fields its items must have and the constraints they must satisfy — plus the checks that enforce them. Use when a user has collections and wants to declare their structure, add required fields, types, or validation rules. Step 2 of the Define stage; its prerequisite is katalyst-identify-collections.

Gate writes to a katalyst project's content so every change is validated as it happens, rather than only at commit time. Use when a user wants writes checked the moment they occur, an agent workflow where edits must pass checks before they land, or enforcement without a git commit step. Paired with katalyst-deploy (chooses the mechanism) and katalyst-deploy-precommit-hook (the alternative).

Install a git pre-commit hook that runs `katalyst check` (and `katalyst fix --check`) so malformed frontmatter or non-canonical formatting fail the commit instead of landing. Use when a user wants katalyst enforced at commit time, a "pre-commit hook", or to block bad content before it reaches the branch. Paired with katalyst-deploy (chooses the mechanism) and katalyst-deploy-cli-gating (the alternative).

Set up automatic enforcement of a katalyst project once, so its checks run on every change without anyone remembering to invoke them. Knows both mechanisms (a git pre-commit hook and CLI-gated writes), helps choose between them, and routes to the specific setup skill. Use when a user wants katalyst to "run automatically", "enforce on commit", "guard the content", or stop relying on manual `katalyst check` runs.

Identify the collections in a katalyst project — the recurring kinds of item the content is made of — and declare them in `.katalyst/`. Use when a user knows roughly what content they have and wants to define its object types, set up collections, or structure a knowledge base. Step 1 of the Define stage; points forward to katalyst-define-schemas for each collection's schema.

PLACEHOLDER — not yet authored, excluded from release. Will migrate content when a collection's schema changes.

PLACEHOLDER — not yet authored, excluded from release. Will migrate a project when its storage layer changes.

Orientation and routing for katalyst: what it is, its model and vocabulary (projects, collections, items, schemas, checks), and which katalyst skill to use for a goal. Use when a user mentions katalyst and you need to know what it does or where to start, when content needs structure/consistency enforcement, or to pick among the katalyst task skills. Does no task work itself — it routes.

Tone and style guide for writing or revising any developer-facing prose in this repo — AGENTS.md, the deep-dive and reference docs under docs/, the Hugo user-docs site under docs/, the project README, skill SKILL.md files, and Go doc comments. Use whenever editing or adding prose to a `.md` file, writing a package doc comment, or when asked to "document this", "write a README", "update the docs", or the equivalent.

Drafts or revises a domain model document — the shared vocabulary for a domain's nouns and verbs, defined the way users and the development team think about them, independent of code. Use when the user asks to "write a domain model", "define the terms for X", "document the domain of Y", wants to capture the working vocabulary for a feature, or is reviewing an existing domain-model doc.

Drafts a feature or architecture spec in product/specs/{slug}-spec.md following the project's structure and prose style. Use when the user asks to "write a spec", "spec this out", "create a spec for X", or needs a new spec under product/specs/.

Drafts a concise decision proposal in the form "we should do X because Y" from the current chat or session topic. Use when the user asks to turn something into a proposal ("let's turn this into a proposal"), wants a proposal drafted from recent discussion, or when summarizing an agreed direction for a feature, refactor, code standard, or process change. May also be offered proactively when a clear decision statement would help — especially after discussion.

Drafts an implementation plan in product/specs/{slug}-plan.md following the project's structure and prose style. Use when the user asks to "write a plan", "plan this out", "create a plan for X", or needs a new plan under product/specs/.