Docs / architecture / domain-plugin

Domain plugin

Skill Wiki ships with zero built-in domains. A domain is a domain.yaml file dropped in your corpus root. The runtime discovers and registers it at boot.

Why config-driven?

Earlier prototypes had domains baked into the runtime — adding "fintech" required a code change. That made forking, customising, and shipping domain-specific corpora painful. v0.1.0 inverts: every domain is a YAML config + recursive discovery.

The flow

primes/                                  ┐
├── sources/                             │
│   └── @my/                             │  scanned recursively
│       ├── ...                          │  by discoverDomains()
│       └── domain.yaml  ←  one per Prime ┘

                  ▼
       ┌──────────────────────┐
       │  DomainRegistry      │  in-memory map
       │  (per-process)       │
       └──────────────────────┘
                  │
                  ▼
        runtime queries pick up
        domain-specific:
          • tag boosts
          • intent fields
          • L5 validator hooks

What domain.yaml declares

A worked example, taken from a hypothetical security corpus. The same shape works for any domain — the field names are protocol-level; the values are domain-specific.

name: security
version: "1.0.0"
description: "Application security knowledge for AI agents — input validation, authn/authz, crypto, …"

# Hierarchical taxonomy of sub-domains.
hierarchy: threat-model

# Multi-axis tags the retriever can boost on.
axes:
  - risk-class
  - attack-surface
  - data-sensitivity
  - control-family
  - severity

# Composition contract scaffold (defaults).
contract:
  input-validation: atom-checklist
  authn: atom-token-flow

# L5 validators (optional).
validators:
  - name: sql-injection-shape
    checker: regex
    pattern: "(?i)\\b(or|and)\\b\\s+1\\s*=\\s*1"
  - name: owasp-input-validation
    checker: ai-judge
    rubric: "@security/rubric-owasp-input-validation"

How the runtime uses it

Tag boosts

Atoms carrying tags from axes: get a multiplicative boost when the retriever's IntentObject matches. e.g. an atom tagged owasp-input-validation ranks higher when intent says focus: "input-validation".

Intent fields

L1 (intent classification) reads axes to know what fields to populate in the IntentObject. A security L1 produces { axes: ["attack-surface", "control-family"], persona: "@security-auditor", ... }; a different domain's L1 produces a different shape entirely.

L5 validator hooks

The validators array describes how to check generated output. Each entry is a tuple of (checker name, parameters). The reference v0.1.0 supports two checkers: regex and ai-judge. Domain plugins can register additional checkers via the MCP server's plugin slot.

Discovery rules

• Recursive walk from $PRIME_DIR, max depth 4.
• Files named exactly domain.yaml at any level.
• Names must be unique across loaded domains. Conflicts hard-fail at boot.
• Unicode tags allowed. Emoji tags work.
• Loaded once per server process; kill -HUP reloads.

Tradeoffs

Plugin model means a v1 protocol that doesn't need to know about your domain. The cost: validation must be domain-blind in the protocol layer. The L1 / L5 plugins are where domain-specific intelligence lives.

Authoring a domain.yaml: see Extending → domain.yaml.

See also: Primes → frontend-design for the flagship design corpus — its domain.yaml is a concrete reference for a visual / aesthetic domain.