Agent Role Scaffolder

agent-role-scaffolder

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

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):

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