A pasted script drifts. The same capability, packaged once, does not.
Most operator tooling lives as ad-hoc scripts and tribal knowledge: pasted between repos, fragmenting under maintenance, invisible to anyone else on the same team. The cost stays low until a second project needs the same capability, and then it compounds. Each paste is a copy that drifts out of sync with the original, and the fix that landed in one repo never reaches the others.
ae-systems answers that with a registry. Each capability lives in exactly one plugin directory, every directory follows the same canonical layout, and one manifest is the only thing that knows about all of them. The unit of work stops being "a script I paste again" and becomes "a plugin with an install command."
Open one plugin and the rest read the same.
Each plugin is self-contained and follows one layout. The same shape repeats from one to the next, so opening any of them is the experience of opening all of them. The rules are conventions, not tooling: a slash command is always a skill with model invocation disabled, plugin-relative paths resolve through one substitution variable, and every skill body stays short enough to read in a sitting.
No application to build, no runtime to run. Only a register.
Nothing compiles and nothing runs at the root: everything is documents and configuration loaded when a session opens. Adding the marketplace reads the register once. Installing a plugin reads that plugin's own manifest once. From there, its components are discovered at session start. The register's only job is to hold the plugins; each one stands alone.
Documentation, workflow, knowledge. Install the toolkit, or install one.
The register sorts every plugin into three families. A fresh machine pulls the whole toolkit in one step; a single project installs one plugin in isolation when that is all it needs.
A private convenience, or an installable unit any session can pull.