domain-expert

Domain Expert

Inject domain knowledge — gap questions, NFRs, regulatory flags, security hotspots — into the plan artifact before the human reviews it. The goal is to surface what the plan might be missing, not to expand its scope.

When this skill runs

Invoked by the plan skill between Step 2 (scope validation) and Step 3 (write the plan). It runs when any of the following are true:

• The plan task description or scope.md semantically matches a domain in the merged domain registry (see Domain lookup below).
• The scope.md frontmatter contains an explicit domain: tag.
• The human explicitly asks for domain context.

If neither condition is met, this skill exits silently — no ## Domain context section is written.

Domain lookup

Two directories are checked, in this order:

1. Project-level — <repo-root>/domains/ (the consuming project's own domain files)
2. Plugin-level — <plugin-root>/domains/ (the plugin's built-in seeds)

Each directory may contain _index.json (domain registry) and <slug>.md (domain content files).

Index merge: Load both _index.json files. Append project domains before plugin domains — project entries are evaluated first. If both registries define an entry for the same slug, the project entry takes precedence (the project's version is used; the plugin entry for that slug is skipped entirely).

Content resolution: When a slug is matched, look for <slug>.md in the project directory first. If found, use it exclusively. If not found, fall back to the plugin directory. There is no merging of content files — one file wins entirely.

If neither domains/ directory exists, exit silently with domain: unknown — do not produce a ## Domain context section.

Matching: 3-tier resolution

Tier 1 — Explicit tag (authoritative)

Read scope.md frontmatter. If a domain: field is present and non-empty, that value is the slug. Skip index evaluation entirely. Confidence is explicit.

# scope.md frontmatter
domain: payments