Files
Skills/skills/README.md
T
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

97 lines
3.3 KiB
Markdown

# 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).