Files
Skills/skills
Brummel 9e10e9dfee boss: migration pilot — autonomous orchestrator mode generalised
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.
2026-05-28 15:43:39 +02:00
..

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

  1. Strip project-specific paths (docs/specs, docs/plans, design/INDEX.md, crates/, bench/).
  2. Strip project-specific commands (cargo build, bench/check.py).
  3. Replace literals with profile-slot references in prose.
  4. Strip project vocabulary (AILang, Form A, .ail.json, Boss); use the profile's vocabulary slots.
  5. Strip project-specific contracts (honesty-rule, feature-acceptance). These belong in the project's own CLAUDE.md, not the plugin.
  6. 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

  1. Drop the ailang- prefix from the name: frontmatter field. The skill path is the disambiguator.
  2. Replace hardcoded standing-reading paths (design/INDEX.md, etc.) with a reference to the profile's standing_reading section.
  3. Replace project-specific Iron Law clauses with the universal discipline constants; project-specific clauses go to the project's own CLAUDE.md.
  4. Verify the body still reads coherently for a generic project (see the per-skill checklist above).
  5. Confirm the tools: frontmatter list matches the agent template's role-based conventions (read-only review vs implementation vs orchestrator).
  6. Confirm the agent does not have Agent in its tools list (no nested subagent dispatch).