v1.0.0 to v1.0.0

---

name: agent-role-scaffolder

version: 1.0.0

type: skill

author: Lukas Geiger + Claude

created: 2026-08-25

updated: 2026-08-25

description: >

Baut und prüft neue Agentenrollen im ellmos-Ökosystem: native Claude-Code-

Subagenten (dauerhafte Rollendefinition) und Companion-Worker (SendMessage-

wiederverwendete Instanz für eine Ticket-/Aufgabenserie). Formalisiert das

bislang unformalisierte eigene Wissen aus dem laufenden Bau von Agentenrollen

(ati-agent, bueroassistent, versicherungs-agent u. a.) zu einem

wiederverwendbaren Scaffold-plus-Verify-Ablauf. Nutze diesen Skill, wenn eine

neue Rolle entstehen soll ("neue Agentenrolle bauen", "Subagent anlegen",

"Companion-Worker starten") oder eine bestehende gegen die Haus-Konventionen

geprüft werden soll ("ist dieser Agent richtig aufgesetzt?").

visibility: public

language: de

standalone: true

anthropic_compatible: true

bach_compatible: false

bach_origin: false

---

# agent-role-scaffolder

<!-- FAMILY-ROUTER:Agenten-Orchestrierung START -->

> **Familie Agenten-Orchestrierung — Wegweiser:** Modell wählen/staffeln ->

> `model-strategy`; Orchestrierungsmuster wählen -> `choose-your-orchestrator`;

> Schwarmoperationen (5 Grundmuster + 2 Modi) -> `swarm-operations`; Aufgabe

> zerlegen/delegieren/abnehmen -> `orchestrator`; anbieterübergreifende

> Nachrichten/Presence/Locks -> `agents-bridge`; **eine neue Rolle bauen oder

> prüfen -> dieser Skill (agent-role-scaffolder)**.

<!-- FAMILY-ROUTER:Agenten-Orchestrierung END -->

## Zweck

Dieses Ökosystem hat bereits eine reife Familie von Orchestrierungs-Skills

(`model-strategy`, `swarm-operations`, `orchestrator`, `choose-your-orchestrator`,

`agents-bridge`) — aber **keinen davon für die Frage "wie entsteht eine neue

Rolle richtig".** Diese Lücke füllt `agent-role-scaffolder`. Er dupliziert die

genannten Skills nicht, sondern **routet zu ihnen**, sobald Staffelung,

Orchestrierungsmuster oder Cross-Provider-Messaging gebraucht werden.

**Herkunft:** User-Entscheid M5 aus Ticket `T-20260825-935905816`

(Marketplace-Vollsichtung): Verdikt (b) — eigenes Agenten-Bau-Wissen war

vorhanden, aber unformalisiert. Das offizielle Claude-Code-Plugin

`agent-sdk-dev` (claude-plugins-official, Apache-2.0) diente als

**strukturelles Vorbild**: eine scaffolding-Kommando-Datei plus zwei

themenspezifische Verifier-Subagenten mit Checkliste und einem

PASS/PASS-WITH-WARNINGS/FAIL-Berichtsformat. Übernommen wurde die **Form**

(Scaffold-Frage-Katalog → Aufbau → Verifikations-Checkliste mit

strukturiertem Bericht), nicht der Text und nicht der Gegenstand — jenes

Plugin baut rohe Claude-Agent-SDK-Apps (Python/TypeScript), dieser Skill

baut **ellmos-eigene Agentenrollen** (Subagent-Definitionen und

Companion-Worker). Das Original ist NICHT installiert; es liegt read-only im

lokalen Marketplace-Cache und wurde nur gelesen (`.PLUGINS/CLAUDE.md`

Regel 5: Ideen frei, Formulierungen nicht). Register-Eintrag:

`.AI/.PLUGINS/PLUGIN-REGISTER.md`, Status `zitiert`.

## Zwei Bauwege — beide gehören hierher

Im ellmos-Ökosystem entstehen neue Rollen auf zwei strukturell verschiedenen

Wegen, die nicht verwechselt werden dürfen (analog zur TS/Python-Trennung

des Vorbild-Plugins — hier aber entlang der tatsächlichen Systemgrenze):

| | **Nativer Subagent** | **Companion-Worker** |

|---|---|---|

| Was entsteht | eine dauerhafte Rollendefinition (`~/.claude/agents/<name>.md`, per `Agent`-Tool startbar) | eine ad-hoc benannte, per `SendMessage` wiederverwendete Instanz für EINE Aufgabenserie |

| Lebensdauer | dauerhaft, wiederverwendbar über Sitzungen hinweg | für die Dauer einer Ticket-/Themenserie, danach verworfen |

| Beispiele im Bestand | `ati-agent`, `bueroassistent`, `versicherungs-agent`, `gesundheitsassistent`, `persoenlicher-assistent`, `production`, `research-agent`, `reflection-agent`, `test-agent`, `entwickler-agent` | dieses Session-Modell selbst (z. B. `skillcreator-bau`, `policyreg-decisions`, `workflowhooker-ausbau` — benannte Worker im Ticket-System) |

| Lebenszyklus-Schicht | Claude-Code-eigene Agent-Registry | **COMA** (`.MODULES/.ORCHESTRATION/coma`) — sofern prozessübergreifend gestartet, nicht nur Tool-intern |

| Bauanleitung hier | `references/subagent-role-scaffold.md` | `references/companion-worker-scaffold.md` |

**Faustregel:** Braucht die Fähigkeit einen eigenen, über viele Sitzungen

hinweg wiederverwendbaren Namen mit fester Trigger-Beschreibung (z. B. „immer

wenn es um Steuerbelege geht") → nativer Subagent. Ist es eine begrenzte,

aber inhaltlich zusammenhängende Serie von Aufgaben, die ein Koordinator

gerade delegiert (Ticket-Kette, Themenwechsel) → Companion-Worker.

## Ablauf

1. **Bauweg wählen** (Tabelle oben) — im Zweifel den User fragen, nicht raten.

2. **Scaffold-Fragen durchgehen** (siehe passende `references/*.md`) — analog

zum Vorbild-Plugin nacheinander, nicht alle auf einmal: Zweck/Auslöser,

Werkzeugbedarf (`Tools:`), Modellwahl (→ **Schritt 3**), Koordinations-Bedarf

(Boss-Agent mit Experten oder Einzelrolle?).

3. **Modellwahl NICHT hier entscheiden — an `model-strategy` delegieren.**

Score-basierte Auswahl, Cross-Agent-Delegation, Advisor-Pairing,

Eskalationstrigger sind dort bereits gelöst; hier nur der Verweis. Faustregel

aus dem Bestand: Subagenten erben **nicht pauschal** das Hauptmodell (siehe

Feedback-Memory `feedback_subagenten_modellstaffelung`).

4. **Orchestrierungsmuster prüfen**, falls die neue Rolle mit mehreren anderen

zusammenarbeiten soll — `choose-your-orchestrator` wählt das Muster,

`swarm-operations` liefert die 5 Grundmuster + 2 Modi, `orchestrator` das

Zerlegen/Delegieren/Abnehmen-Protokoll.

5. **Team-/Messaging-Konventionen einhalten** (`references/

model-staffing-and-messaging.md`): `SendMessage` für Cross-Agent-

Kommunikation, Ticket-Claim-per-Dateiname bei Ticket-Delegation, „verweisen

statt wiederholen" beim Beauftragen (zentrale Regeln nicht im Prompt

nacherzählen, nur das Aufgabenspezifische).

6. **Verifizieren** — die passende Checkliste in der gewählten

`references/*.md`-Datei abarbeiten, Bericht im Format

`PASS / PASS MIT WARNUNGEN / FAIL` erstellen (Struktur siehe unten).

7. **Bei Bedarf katalogisieren** — eine dauerhafte neue Rolle gehört ins

passende Register (`~/.claude/agents/`, ggf. Plugin-Bündelung); ein

Companion-Worker braucht kein Register-Eintrag, nur eine klare erste

Aufgabenübergabe.

## Verifikations-Berichtsformat (für beide Bauwege)

Struktur bewusst vom Vorbild-Plugin übernommen (Form, nicht Wortlaut) — vier

Abschnitte, knapp:

- **Status:** PASS | PASS MIT WARNUNGEN | FAIL

- **Kritische Punkte:** was die Rolle unbrauchbar macht (fehlende Trigger-

Beschreibung, `Tools:` zu weit/zu eng, Modell nicht per `model-strategy`

begründet, keine Abgrenzung zu einer bestehenden Rolle geprüft)

- **Warnungen:** suboptimal, aber funktionsfähig (z. B. Hauptmodell geerbt

statt gestaffelt, kein Rotationskriterium für einen langlebigen

Companion-Worker)

- **Bestandene Prüfungen + Empfehlungen:** was passt, was als Nächstes

## Verwandte Skills

- `model-strategy` — Modellwahl/-staffelung (Schritt 3, hier nur referenziert).

- `swarm-operations` — Schwarmmuster für Mehrfach-Rollen-Zusammenarbeit.

- `choose-your-orchestrator` — wählt das passende Orchestrierungsmuster.

- `orchestrator` — Protokoll für Zerlegen/Delegieren/Abnehmen.

- `agents-bridge` — Cross-Provider-Messaging/Presence/Locks, falls die neue

Rolle über Claude Code hinaus mit Codex/Gemini/Kimi kommunizieren muss.

- `skill-explorer` — prüft, ob eine Fähigkeit schon existiert, BEVOR eine neue

Rolle gebaut wird (Duplikatsvermeidung).

## Changelog

### 1.0.0 (2026-08-25)

- Erstfassung. Gebaut nach User-Entscheid M5 (`T-20260825-935905816`) über

`ellmos-skill-creator`. Formalisiert Companion-Worker-Muster (Primärquelle:

`_control-center/_TICKETS/README.md`, Abschnitt „Leitprinzip

(Kontext-Ökonomie)"), COMA-Lebenszyklus (Primärquelle:

`.MODULES/.ORCHESTRATION/coma/README.md`), und das beobachtete

„Boss-Agent koordiniert Experten"-Muster bestehender Rollen. Routet bewusst

zu `model-strategy`/`swarm-operations`/`orchestrator`/

`choose-your-orchestrator`/`agents-bridge` statt sie zu duplizieren.

Vorbild `agent-sdk-dev` (claude-plugins-official) NICHT installiert, nur

gelesen und strukturell zitiert (`.PLUGINS/CLAUDE.md` Regel 5).