165. A skill is derived for every domain of the registry and shown wherever skills are
Context
ADR 0146 made a capability reachable by name from Claude Code when its declaration says
.skill(alias, argument). One capability says it (intents.propose as /intent). The
other 189 MCP tools are reachable only by describing a want and hoping the model finds the
tool, and a person opening the skill listing sees eight workflow skills and nothing of what
the registry offers. The owner asked for every skill to be derived, integrated with the
layer, enforced, and shown on the site and in the UI — not for more hand-written aliases.
ADR 0146 rejected one skill per capability: hundreds of names, each restating a tool. The
registry already groups its capabilities by module (mesh, plan, continuity, ...), and
a module is the unit a person thinks in ("what does the mesh say", "move the plan").
Decision
Every module of the registry that offers a public capability with an MCP tool is one
skill, /mj-<module>. The editors plan derives it from the registry and from nothing
else: its description is the module and its capabilities' own titles, its body is a table of
those capabilities with their tool, their command line and whether they change anything.
A capability joins its module's skill by having a tool; nothing lists domains.
The model may load a domain skill on its own. Loading it changes nothing. Calling a
capability that changes something is governed by the file: only when the person asked for
that change, once, with a refusal or an unknown outcome reported as it is. A capability that
declares .skill(..) keeps its own file, disable-model-invocation and all (ADR 0146).
Names are yielded, never shared. The mj- prefix keeps domains apart from the products'
own commands and the layer's workflow skills; a domain whose name a command alias or a
workflow skill already has is not written.
It is enforced where the other projections are. majordomus generate writes the files,
generate --check (and the pre-commit hook that runs it) fails on a missing, stale or
orphaned one, and editors.status reports the domains capability of the claude-code
adapter with every path. The rule is project.every-domain-is-a-skill.
It is shown wherever skills are. The site's skills section and the UI read the same
projection editors.status answers — workflow skills, command skills and domain skills,
each with the name it is typed by — so a skill that exists in Claude Code exists on the
landing page and in the dashboard, and nowhere is it typed by hand.
Alternatives rejected
One skill per capability. Rejected again for the reason ADR 0146 gives.
A hand-maintained list of "important" capabilities. A second definition of which capabilities matter, which nothing holds to the registry.
Moving the owner's personal ~/.claude/commands into the layer. They serve every
repository the owner works in (/commit, /pr, /push); a repository's layer is the wrong
owner for them. The one defect they carry here — a personal evolve beside the layer's
workflow skill evolve — is reported, not taken over.
Consequences
- About fifty
.claude/skills/mj-*/SKILL.mdfiles, regenerated with the registry. - The listing's cost is bounded: each description is cut at a word to 300 characters.
- Argument inference per capability remains the later step ADR 0146 named; a domain skill hands the request to the agent, which reads the tool's schema as it already does.