.plugins¶
Provenance¶
- Source:
.spec/spexcode/.plugins/spec.md - Source SHA-256:
1a825c4cd18a38e45ad938ab379d213a6c8d9f3d73bc8d18e5a8e073e1ec24a2
.plugins/ is the instance of the plugin system: the concrete dev-flow plugins SpexCode ships for
working in this repo. Each plugin is a skill-shaped node — its folder is the unit (a spec.md plus any
co-located scripts) — carrying a surface: command|system|… field that names where it plugs in, per
[[plugin-system]]'s [[surface]] field-driven routing. Discovery is recursive, so a plugin may sit under a
grouping shelf: the auxiliary surface: system prompt contracts live under [[prompts]], the surface:
command presets under [[commands]], the surface: skill plugins under [[skills]], the surface: review
remark presets under [[review]], while [[core]] — the dev-flow contract subsystem whose children are the
surface: hook gates — sits as a flat child beside them.
/api/plugins and the launcher's system gather read from here, not from [[plugin-system]] (which holds the
spec of the plugin system itself). Only built/active plugins gather — a pending node is declared
intent, not yet an active plugin, so it renders on the board but is neither offered as a command preset nor
materialized into the agent's contract.
Which plugins spex init ships is the [[init-preset]] rule. seed: false excludes a plugin subtree; shared
plugins have one body and one helper set — there is no separately authored adopter variant. Dogfood eval
scenarios/readings remain with the implementation and git history they measure.