First skill migrated from AILang's in-tree skills/. boss carries the autonomous orchestrator authority (god-mode: dispatches every other skill, decides done-state vs bounce-back), so it is the load-bearing pilot for the migration pattern. Profile schema gains three slots that boss needs: - `git.issue_tracker.url` — browsable issue list URL - `git.issue_tracker.list_cmd` — shell command listing open issues - `notifications.command` — script invoked on done-state / bounce-back; falls back to chat if empty AILang-specific bits dropped from the prose: - AILang/Gitea URL + tea CLI hardcoding → profile slots - `design/contracts/0004-feature-acceptance.md` cross-reference → project CLAUDE.md (not the plugin's concern) - "Boss" terminology → "orchestrator" (the plugin term; "Boss" was AILang vocabulary) - "Brummel-as-LLM" → "the orchestrator" - "milestone" → "cycle" (the profile's vocabulary slot) Universal substance preserved verbatim: Iron Law, the five process steps, the four bounce-back triggers + new-cycle rationale, notification protocol, done-state editorial rules, Common Rationalisations, Red Flags. No discipline-prose compression. design/out-of-scope claim retracted: boss DOES generalise, and its body now demonstrates how — the queue mechanic is a single shell-command slot, not a transport-coupled contract. skills/README.md flags boss as the landed pilot; the other seven skills follow once the pattern is approved.
skills/
One subdirectory per skill, each containing a SKILL.md plus
the agent files that skill dispatches under agents/. Agents
live with their dispatching skill, not in a parallel top-level
directory — this is what makes the "no orphan agents" rule
structurally true rather than only documented.
Migration from AILang's in-tree ~/dev/ailang/skills/ runs in
iteration 1. The boss skill is the migration pilot
(landed); the remaining seven skills follow once the pattern
is approved.
Expected layout after migration:
skills/
├── boss/ (pilot: landed)
│ └── SKILL.md
├── brainstorm/
│ ├── SKILL.md
│ └── agents/
│ └── grounding-check.md
├── planner/
│ ├── SKILL.md
│ └── agents/
│ └── plan-recon.md
├── implement/
│ ├── SKILL.md
│ └── agents/
│ ├── implement-orchestrator.md
│ ├── implementer.md
│ ├── spec-reviewer.md
│ ├── quality-reviewer.md
│ └── tester.md
├── audit/
│ ├── SKILL.md
│ └── agents/
│ ├── architect.md
│ └── bencher.md
├── debug/
│ ├── SKILL.md
│ └── agents/
│ └── debugger.md
├── fieldtest/
│ ├── SKILL.md
│ └── agents/
│ └── fieldtester.md
└── docwriter/
├── SKILL.md
└── agents/
└── docwriter.md
boss has no agents — it is itself the dispatcher of the
others, not a dispatcher-of-subagents.
install.sh symlinks each skill's directory into
~/.claude/skills/<name> and each skill's agents/
subdirectory into ~/.claude/agents/<name>, so Claude Code's
flat user-level discovery still finds everything while the
source tree keeps the structural binding.
Migration checklist per skill
- Strip project-specific paths (
docs/specs,docs/plans,design/INDEX.md,crates/,bench/). - Strip project-specific commands (
cargo build,bench/check.py). - Replace literals with profile-slot references in prose.
- Strip project vocabulary (
AILang,Form A,.ail.json,Boss); use the profile's vocabulary slots. - Strip project-specific contracts (honesty-rule,
feature-acceptance). These belong in the project's own
CLAUDE.md, not the plugin. - Verify the body still reads coherently for a generic project — would it make sense in a Python web service? A TypeScript library?
Migration checklist per agent
- Drop the
ailang-prefix from thename:frontmatter field. The skill path is the disambiguator. - Replace hardcoded standing-reading paths
(
design/INDEX.md, etc.) with a reference to the profile'sstanding_readingsection. - Replace project-specific Iron Law clauses with the universal
discipline constants; project-specific clauses go to the
project's own
CLAUDE.md. - Verify the body still reads coherently for a generic project (see the per-skill checklist above).
- Confirm the
tools:frontmatter list matches the agent template's role-based conventions (read-only review vs implementation vs orchestrator). - Confirm the agent does not have
Agentin its tools list (no nested subagent dispatch).