CP Registry
Automation

Claude Code Skills & Agents

Vollständige Dev-Doku aller Skills (Slash-Commands) und Agents (Sub-Tasks), die in der Digital-Unit eingesetzt werden. Single-Source-of-Truth — jede andere Stelle verlinkt hier her.

22 im Repo

10 Skills + 12 Agents in .claude/ dieses Repos. Per CLI in eigene Projekte installierbar.

10 global Skills

4 Harness-Orchestrators + 6 generelle Skills in ~/.claude/skills/.

33 global Agents

Subagents für die Harnesses und generelle Disziplinen in ~/.claude/agents/.

4 Harnesses

Bestand, Projekt, Werkstatt, Content — orchestrierte Mehr-Phasen-Workflows mit Phase-Gates.

Lage-Plan: Wo wohnt was?

Drei Speicherorte mit unterschiedlicher Reichweite. Ein SKILL.md oder Agent-File aktiviert sich automatisch, sobald Claude Code die Datei findet.

  • Repo-Ebene — cp-registry/.claude/skills/ + cp-registry/.claude/agents/. Nur in diesem Repo verfügbar. Hier liegen die cp-*-Skills und die Component-Builder-Agents. Per cp-components skills CLI in andere Projekte installierbar.
  • User-Ebene — ~/.claude/skills/ + ~/.claude/agents/. Auf deinem Rechner verfügbar, projekt-übergreifend. Hier wohnen die 4 Harnesses, content-redakteur, frontend-senior, ui-ux-designer, pr, review-pr, screenshot-tips plus alle Harness-Subagents.
  • Projekt-Ebene (eigene Projekte) — <projekt>/.claude/skills/ + <projekt>/.claude/agents/. Wird per cp-components skills oder manuell befüllt. Geteilt im Team via Git.

Repo-Agents (12)

Spezialisierte Sub-Tasks mit eigenem System-Prompt. Werden vom Hauptmodell aufgerufen, arbeiten fokussiert, liefern Ergebnis zurück. Liegen unter .claude/agents/ dieses Repos.

Components & Manifest

cp-component-builder

Was: Erstellt eine komplette neue Component im Registry — Astro-Component-File, erweitertes Manifest (mit useCases, editorialRules, relatedComponents, variants, a11yNotes), Showcase-Seite mit Redakteurshinweisen, Sidebar-Eintrag, optional Werkstatt-Block-Stub und Glossar-Eintrag.

Wann: Neue Component soll ins Registry. "Bau mir Component X im Registry" oder via /cp-add mit nicht-existierendem Namen.

Tools: Read, Grep, Glob, Bash, Write, Edit · Model: sonnet

cp-manifest-validator

Was: Validiert alle Component-Manifeste in registry/components/ gegen Pflichtfelder, Datei-Existenz, Token-Naming, neue erweiterte Felder und Cross-References (Glossar/Use-Case-Index).

Wann: Vor Release oder PR. Wird von cp-components validate und vom harness-werkstatt-promoter aufgerufen.

Tools: Read, Grep, Glob, Bash · Model: haiku

cp-showcase-generator

Was: Generiert eine Showcase-Seite mit CodePreview für eine Component. Liest Props + Manifest, erstellt praxisnahe Beispiele, ergänzt eine strukturierte Redakteurshinweise-Section.

Wann: Nach Component-Build (typisch von cp-component-builder selbst gerufen) oder für existierende Components nachträglich.

Tools: Read, Grep, Glob, Write, Edit · Model: sonnet

redakteurshinweise-writer

Was: Schreibt strukturierte Redakteurshinweise für Component-Showcase-Seiten — vier Blöcke (Wann einsetzen, Inhalts-Empfehlungen, Mobile/A11y, Pitfalls) im einheitlichen Stil aus Manifest + Component-Code abgeleitet.

Wann: Showcase-Seite existiert, aber Redakteurshinweise fehlen oder sind ungleichmäßig.

Tools: Read, Grep, Glob, Edit · Model: sonnet

Werkstatt (Komponenten-Sandbox-Tool)

werkstatt-block-builder

Was: Fuegt einen neuen Block-Typ in die Komponenten-Werkstatt hinzu. Generiert Stub-HTML, BLOCKS-Eintrag, BLOCK_CODE-Template, optional Grid-Item-Varianten. Bearbeitet src/pages/zusammenspiel/werkstatt.astro.

Wann: Neue Component soll auch in der Werkstatt waehlbar sein.

Tools: Read, Grep, Glob, Edit · Model: sonnet

werkstatt-template-creator

Was: Erzeugt eine neue Werkstatt-Vorlage (Template) — vollständige Block-Konfiguration mit realistischen deutschen Default-Inhalten. Editiert src/data/werkstatt-templates.ts. Templates erscheinen im Pattern-Katalog automatisch.

Wann: Neues Pattern (z.B. "Service-Landingpage") soll als Startpunkt in der Werkstatt verfügbar sein.

Tools: Read, Grep, Glob, Edit · Model: sonnet

werkstatt-config-validator

Was: Validiert gespeicherte Werkstatt-Configs (data/werkstatt/*.json) gegen das BlockNode-Schema. Prüft Block-Typen, Variants, Controls, Children-Konsistenz, Heading-Hierarchie.

Wann: Vor Pull-Request, der Werkstatt-Configs ändert. Oder als Routine-Check.

Tools: Read, Grep, Glob, Bash · Model: haiku

Schulung & System-Doku

lab-page-builder

Was: Erstellt eine neue Schulungs-/Lab-Seite mit dem Lab.astro-Framework. Generiert Outcomes, interaktive Sections, Takeaways. Geeignet für /schulung/* und /zusammenspiel/* Routen.

Wann: Neue Schulungs-Seite für Redakteure, Designer, PMs oder Frontend.

Tools: Read, Grep, Glob, Write, Edit · Model: sonnet

glossary-extender

Was: Fuegt einen neuen Begriff im Glossar hinzu mit der Standard-Struktur (term, short, long, related, forRoles). Bearbeitet src/pages/system/glossary.astro.

Wann: Neuer Begriff soll ins Glossar — schmaler als /harness-content für einen einzigen Eintrag.

Tools: Read, Edit · Model: haiku

decision-tree-extender

Was: Erweitert den Decision-Tree (/system/decision-tree) um eine neue Frage oder ein neues Endergebnis. Bearbeitet src/pages/system/decision-tree.astro.

Wann: Neue Entscheidungslogik (z.B. "Welche Component für X?") soll im Decision-Tree erfassbar sein.

Tools: Read, Edit · Model: haiku

Design & Branding

brand-theme-generator

Was: Erzeugt eine vollständige Brand-Override-CSS aus einem Brand-Brief. Nimmt Primary-Hue, Typografie, Radius-Charakter, exportiert Tokens-Override für ein Kundenprojekt.

Wann: Neues Kunden-Projekt mit eigenem Brand. Wird vom /cp-brand-Skill direkt orchestriert.

Tools: Read, Write · Model: sonnet

Universell (auch außerhalb cp-registry)

a11y-auditor

Was: Prüft Webseiten und Components auf Barrierefreiheit (WCAG 2.2 AA). Analysiert HTML-Semantik, ARIA, Keyboard-Navigation, Farbkontraste, Screen-Reader-Kompatibilität. Drei Modi: companion (light, im Build-Loop), full-audit (alle 9 Kategorien), per-Kategorie (gezielt).

Wann: Vor Release, in Phase 6 von Harness 2 oder Phase 3 von Harness 3, oder ad-hoc. Wird auch vom /cp-test-a11y-Skill gerufen.

Tools: Read, Grep, Glob, Bash · Model: sonnet

Repo-Skills (10)

Slash-Commands, die Multi-Step-Workflows orchestrieren. Liegen unter .claude/skills/ dieses Repos. Per cp-components skills in andere Projekte installierbar.

Projekt-Lifecycle

/cp-init

Was: Initialisiert ein neues Projekt mit dem CP Component Registry. Kopiert Base-Styles, Grid-System und Design Tokens. Optional Wizard-Modus (Multi-Select für Components/Skills).

Wann: Erster Aufruf in einem leeren Projekt-Folder.

Argumente: [projektname] [sitepackage-name]

/cp-add

Was: Fuegt Components aus dem Registry zum aktuellen Projekt hinzu. Löst Dependencies auf, kopiert Files (Component, Manifest, optional Showcase), prüft Token-Verfügbarkeit.

Wann: Bestehende Component aus Library im Projekt einsetzen.

Argumente: <component-namen...>

/cp-update

Was: Aktualisiert installierte Registry-Components auf neueste Version. Zeigt Diffs, fragt vor Ueberschreiben.

Wann: Library-Component hat Update bekommen, lokale Kopie soll nachziehen.

Argumente: [component-namen...] [--force] [--dry-run]

/cp-deploy

Was: Setup-Walkthrough für den Deploy von cp-registry. Waehlt Adapter (Node/Vercel/Netlify), generiert .env-Stub, prüft Storage-Pfade, schreibt README-Snippet.

Wann: Deploy-Setup neu aufsetzen oder prüfen.

/cp-docs

Was: Erweitert die Dokumentation im Registry. Generiert Showcase-Seiten mit CodePreview, Developer-Docs oder Redakteur-Guides.

Wann: Doku-Lück für eine Component oder ein Thema.

Argumente: <component-oder-thema>

Werkstatt-Workflow

/cp-werkstatt-export

Was: Exportiert eine gespeicherte Werkstatt-Konfig als fertige Astro-Seite ins aktuelle Projekt. Liest Config aus data/werkstatt/, generiert .astro-Datei mit Imports + Code.

Wann: Werkstatt-Pattern wurde zusammengestellt, soll als echte Seite produktiv werden.

Argumente: <config-id> [<ziel-pfad>]

/cp-test-a11y

Was: Fuehrt einen A11y-Audit gegen eine Seite oder Werkstatt-Konfig durch. Wrapper um den a11y-auditor-Agent für Code-Prüfung, gibt Report zurück.

Wann: Vor PR, vor Live-Gang, oder als Routine-Check.

Argumente: <pfad-oder-route-oder-config-id>

/cp-brand

Was: Generiert eine Brand-Override-CSS für ein Kundenprojekt. Wrapper um den brand-theme-generator-Agent. Schreibt brand-<projekt>.css ins Projekt und registriert sie.

Wann: Neues Kundenprojekt mit eigenem Branding.

Argumente: <projekt-name>

Wissens-Pflege

/cp-content-strukturieren

Was: Strukturiert eine Wissens-/Schulungs-Seite (oder Section) durch Component-Wahl statt durch mehr Text. Liest den Inhalt, entscheidet pro Section über das passende Component (Card, Tab, Timeline, Dialog, Badge, Accordion, Table, Numbered-Step, Hierarchical-Stack), prüft Spacing, Wide-Content, Headline-Badge-Redundanz und Content-Tiefe.

Wann: Bestehende Seite ist textlastig oder unstrukturiert. Oder neue Seite ist konzipiert, aber die Component-Wahl ist offen.

Argumente: <seiten-pfad-oder-thema>

/cp-expert

Was: Single Source of Truth für das Registry. Kennt Projekt-Kontext, alle Regeln, Schulungs-Inhalte, Digital-Unit-Hub, System-Docs, Components, Skills, Agents. Prüft VOR jeder Antwort, was sich seit Baseline geändert hat. Liefert Briefings an andere Skills/Agents.

Wann: Frage zum Registry-Kontext, oder als Quelle für einen anderen Workflow ("brief mir den ui-ux-designer mit Token-Praxis").

Argumente: [audit | update | brief <target> | lookup <topic> | <freie-frage>]

/cp-search

neu

Was: Semantische Suche über Component-Manifeste. Findet passende Components für einen freien Suchtext oder Use-Case-Slug — sortiert nach Match-Score. Nutzt registry/index.json (generiert via npm run registry:index).

Wann: "Welche Component passt zu Hero mit CTA?", "Was haben wir für Lade-Status?". Erste Anlaufstelle vor /cp-add.

Argumente: <query> [--limit N] [--category <cat>] [--json]

/cp-list

neu

Was: Listet alle Components — gruppiert nach Kategorie oder Use-Case, mit Filter, Tabellen- oder JSON-Output. --missing-fields zeigt unvollständige Manifeste für den nächsten Pflege-Pass.

Wann: Library-Inventur, AI-Konsumption (mit --json), Health-Check.

Argumente: [--category <cat>] [--by-usecase] [--json] [--missing-fields]

/cp-context

neu

Was: Konsolidiertes Context-Bundle für Frontend-Senior — Tokens, Spacing, Components, Patterns, Conventions in einem strukturierten Markdown. Kein Browsing durch 5 Files mehr.

Wann: Onboarding eines AI-Agenten, Frontend-Review-Briefing, Brand-Override-Vorbereitung.

Argumente: [--include tokens|components|patterns|conventions|all] [--for designer|frontend|redakteur]

/cp-screenshot

neu

Was: Erzeugt Screenshots von Pages oder Components in Desktop/Tablet/Mobile-Viewports über Playwright-MCP. Für Werkstatt-Configs nutzt der Skill das Skript scripts/werkstatt-screenshot.mjs.

Wann: Designer-Review, Vorher/Nachher-Belege, Showcase-Hero-Bilder.

Argumente: <page-pfad> [--viewport desktop|tablet|mobile|all] [--format png|webp]

/cp-page-scaffold

neu

Was: Pattern-basierte Page-Generierung. landingpage, produkt-page, service-hub, kampagne, blog-artikel, pillar-page als fertige Astro-Skelette mit Layout, Imports, Komponenten-Komposition.

Wann: Neue Page anlegen — schneller als von Hand, konsistenter als Werkstatt-Export. Patterns leben in registry/patterns/.

Argumente: <pattern> <name> [--target <pfad>] [--brand <slug>]

/cp-werkstatt-to-figma

Spec — wartet auf Figma-Library

Was: Exportiert eine Werkstatt-Konfig als Figma-Frame (One-Way Code → Figma) über den Figma-MCP. Mockup in Sekunden statt Stunden.

Wann: Designer-Handoff, Mockup-Erstellung. Voraussetzung: Figma-Library mit cp-registry-Components plus Token-Variables.

Argumente: <config-id> [--file <figma-file-key>] [--page <name>]

/cp-werkstatt-multi-screen

Spec — Implementation offen

Was: Multi-Screen-Wrapper über der Werkstatt — Sitemap aus mehreren verlinkten Werkstatt- Configs. Datenmodell der Werkstatt unverändert, Wrapper sitzt darüber.

Wann: Komplexere Projekte mit mehreren Screens (Onboarding-Flow, Service-Portal, Multi-Step-Form).

Argumente: [create <name> | add-screen <project-id> <config-id> | list]

Harnesses (4 globale Workflow-Orchestrators)

Mehr-Phasen-Workflows mit Phase-Gates, Iteration-Loops und Tracking. Jeder Harness ist ein eigener Slash-Command und ruft N Subagents auf. Liegen unter ~/.claude/skills/harness-*/SKILL.md.

/harness-bestand

Was: Harness 1 — Bestandsanalyse einer Live-Webseite plus optional Template-Repo. Crawlt per Playwright, analysiert Tonalität, mappt auf Repo-Components, klassifiziert Inkonsistenzen (Klassen A-E) und produziert eine project-dna.md als Output.

Wann: Pitches, Strategie-Workshops, Selbst-Audits, oder als Phase 0 für Harness 2. Drei Modi: full, content-only, audit-only.

Subagents: 5 (live-crawler, repo-inventur, content-analyzer, cross-referencer, synthesizer)

/harness-projekt

Was: Harness 2 — Webseiten-Projekt von Storyline über Layout bis A11y-Audit. 7-Phasen-Workflow mit harten Phase-Gates. Vier Modi: greenfield (alles neu), brownfield-erweiterung (schmaler Patch), brownfield-redesign-teil, brownfield-redesign-komplett. Nutzt cp-registry-Components, integriert Visual-Evaluator-Loop (max 5 Iterationen).

Wann: Neue Site, neue Sektion, Redesign. Liest DNA aus Harness 1 im Brownfield-Modus.

Subagents: 11 (storyline×3, ux-designer, ux-reviewer, layout-analyzer, layout-validator, component-mapper, component-builder, frontend-reviewer, visual-evaluator, a11y-companion, a11y-auditor)

/harness-werkstatt

Was: Harness 3 — Library-Pflege für cp-registry. 5-Phasen-Workflow Spec → Build → A11y → Doku → Promotion für eine neue oder verbesserte Component. Drei Source-Modi: from-projekt (Custom-Component aus Harness-2-Lauf promoten), from-spec, from-design (Figma/Bild/Brief). Promotion ist NIE automatisch — User-Approval Pflicht.

Wann: Neue Library-Component bauen oder bestehende verbessern.

Subagents: 6 (spec, builder, visual-evaluator, a11y-full, doku, promoter)

/harness-content

Was: Harness 4 — Content-Werkstatt zum Schreiben qualitätsgesicherter Texte. Zwei Fälle: Standalone (Brief → Output) oder In-place (Sektion in laufendem Webseiten-Projekt befüllen). Sechs Tonalitäts-Modi: bestand-tonalität, public-sector, schulung, marketing-locker, editorial, custom. Drei Storytelling-Patterns plus Sub-Patterns. Optional: +leichte-sprache, +seo. Iteration-Loop max 5.

Wann: Qualitäts-Content schreiben, mit Approval-Sieb in Webseiten-Projekt einarbeiten, oder Standalone-Texte (Pressetext, Newsletter, Karriere-Anzeige).

Subagents: 4 (tonalitäts-loader, writer, evaluator, applier)

Globale generelle Skills (6)

Disziplin-Skills, die in jedem Projekt nützlich sind. Liegen unter ~/.claude/skills/.

content-redakteur

Was: Webseiten-Content-Spezialist — werblich, redaktionell, didaktisch. Erstellt Element-Plan + Text + Lesbarkeits-Check. Universell für Hero, Landingpage, Schulung (Beginner/Intermediate/ Expert), Blog, FAQ. Im Harness-4-Kontext mit Modi und Patterns aus Sub-Files.

Wann: Texte für Web schreiben, verbessern oder umschreiben. Auch ohne Trigger-Wort, wenn es um strukturierten Web-Content geht.

frontend-senior

Was: Frontend-Senior für moderne Web-Implementation — React 19, Next.js 16, Astro 6, Tailwind v4, modern CSS. Stack-Auswahl ist Pflicht-Schritt 1 (fragt aktiv nach React/Astro/Vanilla).

Wann: Component bauen, TSX/Astro-Code, Server Components, View Transitions, Container Queries, Image-Optimization, Bundle-Performance.

ui-ux-designer

Was: UI/UX-Spezialist mit Mobile-App-Awareness. Layout, Visual Hierarchy, Interaction-Patterns, Form-Design, Microinteractions, Mobile-Adaption, A11y-Prüfung. WCAG 2.2 AA als Pflicht-Layer. Kennt Nielsen 10, BFSG/EAA, iOS HIG, Material Design 3.

Wann: Layout-Logik, Wireframe, Heuristik-Eval, A11y-Audit, Mobile-Adaption, Form-Design, Empty/Error-State-Design.

/pr

Was: Erstellt einen Pull-Request — analysiert Änderungen, erstellt Branch, committet, öffnet PR mit strukturiertem Body. Funktioniert in jedem Git-Repository.

Wann: Änderungen sind fertig, PR soll raus.

/review-pr

Was: Reviewt einen Pull-Request — Code-Qualität, Sicherheit, Performance, Tests, Best Practices.

Wann: Eingegangener PR soll vor Merge gereviewt werden.

/screenshot-tips

Was: Generiert Screenshot-Anleitungen für Redakteure und Tester. Erklärt wie man Seiten, Components und Zustände dokumentiert.

Wann: Doku braucht visuelle Beweise, oder Tester sollen einheitliche Screenshots liefern.

Harness-Subagents (24)

Werden von den Harness-Orchestrators aufgerufen, nicht direkt vom User. Hier dokumentiert, weil sie das Verhalten der Harnesses bestimmen — Verständnis hilft beim Debuggen oder Erweitern.

Harness 1 — Bestand (5)

harness-bestand-live-crawler

Welle 1a. Crawlt eine Live-Webseite per Playwright MCP, schreibt Sitemap, HTML-Snapshots, Screenshots. Read-only auf Live-Site, schreibt nur in 01-live-crawl/.

harness-bestand-repo-inventur

Welle 1b (parallel zu Crawler). Inventarisiert ein Template-Repo (Astro/React/Vue/HTML). Findet Components, Patterns, Tokens, Build-Setup. Schreibt nur in 02-repo-inventur/.

harness-bestand-content-analyzer

Welle 2a. Analysiert Bestand-Texte aus dem Live-Crawl auf Tonalität, Sprachregister, Glossar. Schreibt 03-content-analysis/tonalität.md + glossary.md — wird vom content-redakteur und von Harness 4 (mode: bestand-tonalität) konsumiert.

harness-bestand-cross-referencer

Welle 2b. Mapped Live-Sektionen auf Repo-Components, identifiziert Inkonsistenz-Klassen A bis E. Schreibt 04-cross-reference/.

harness-bestand-synthesizer

Welle 3 (Synthese). Synthetisiert die vier Welle-1/2-Outputs zu project-dna.draft.md + decisions-pending.md. Letzte Stage vor User-Approval, schreibt nach Approval die finale DNA.

Harness 2 — Projekt (11)

storyline-greenfield

Phase 1, Modus greenfield. Baut Storyline + No-Go + Brand-Voice-Snapshot von Null — keine DNA-Vererbung. Erfragt Brief interaktiv, schreibt brand-voice.md als Pseudo-DNA.

storyline-anschluss

Phase 1, Modus brownfield-redesign. Schreibt Storyline an Bestand anschliessend — Tonalität, Sprachregister, Brand-Marker übernimmt aus DNA.

storyline-patch

Phase 1, Modus brownfield-erweiterung. Schmaler Storyline-Patch für eine neue Sektion — fuegt nahtlos an Bestand an.

phase2-ux-designer

Phase 2 (Struktur). Erzeugt Sitemap und User-Flows aus der Storyline. Wendet ui-ux-designer-Expertise im Phasen-Kontext an.

phase2-ux-reviewer

Phase 2 Evaluator. Prüft Sitemap und Flows gegen Storyline, DNA, Heuristiken. Verdict APPROVE / ITERATE / ESCALATE.

phase3-layout-analyzer

Phase 3 (Layouts). Pro Screen ein Aufruf — Section-Plan, Visual-Hierarchy, Component-Vorschläge, Responsive-Adaption. Parallele Sub-Runs möglich.

phase3-layout-validator

Phase 3 Evaluator. Prüft die screen-Specs auf Cross-Screen-Konsistenz, DNA-Konformität, Visual-Reference-Anwendung.

phase4-component-mapper

Phase 4 (Component-Mapping). Mappt Section-Pläne auf konkrete cp-registry-Components, identifiziert Library-Lücken, schlägt Custom-Components vor (mit Promotion-Kandidat-Flag).

phase5-component-builder

Phase 5 (Implementation). Baut EINE Component pro Aufruf — entweder via cp-add (Library) oder als Custom-Component. Pingt anschliessend Frontend-Reviewer + Visual-Evaluator + A11y-Companion.

phase5-frontend-reviewer / phase5-visual-evaluator / phase5-a11y-companion

Phase-5-Quality-Gates. Frontend-Reviewer prüft Code gegen STANDARDS, Visual-Evaluator macht Playwright-Screenshots und vergleicht mit References, A11y-Companion ist Lightweight-Inline-A11y-Check. Aggregat-Verdict steuert Iteration (max 5).

phase6-a11y-auditor

Phase 6 Full-Audit. Wrapper um globalen a11y-auditor in mode:full-audit. Wird PRO ISSUE-KATEGORIE einmal aufgerufen (Heading / ARIA / Keyboard / Contrast / Forms / Media / Token-Conformance / Light-Dark / Container-Queries) — verhindert Context-Bloat.

Harness 3 — Werkstatt (6)

harness-werkstatt-spec

Phase 1. Schreibt die Component-Spec (purpose, variants, useCases, requiredTokens, A11y-Pflichten) — aus Project-Custom-Component, Spec-File oder Design-Brief.

harness-werkstatt-builder

Phase 2. Baut die Component in Library-Qualität — alle Variants, Token-Conformance, Container Queries, Light+Dark, A11y. Iteriert basierend auf Visual-Evaluator-Findings (max 5).

harness-werkstatt-visual-evaluator

Phase 2 Quality-Gate. Wie phase5-visual-evaluator, aber Werkstatt-spezifisch — alle Variants nebeneinander, Container-Query-Sweep (1/2/3/4 Spalten), Light+Dark im selben Render.

harness-werkstatt-a11y-full

Phase 3. Wrapper um globalen a11y-auditor mode:full-audit, geht alle 9 WCAG-Kategorien sequenziell durch. Strenger als der Phase-6-Auditor in Harness 2 — Library-Component muss alle Kategorien bestehen.

harness-werkstatt-doku

Phase 4. Schreibt Showcase, README und manifest-update.json für die promotion-bereite Component.

harness-werkstatt-promoter

Phase 5. Promoviert die fertige Component in cp-registry — moved Files, schreibt Manifest-Update, ruft cp-components validate, dokumentiert in post-promotion-log. NIEMALS automatisch — User-Approval Pflicht.

Harness 4 — Content (4)

harness-content-tonalitäts-loader

Phase 2. Liest Brief plus optional project-dna.md und Glossar, baut die Tonalitäts-Spec (Modus, Persona, Sprachregister, Hard-Constraints, Few-Shot-Anker). Splittet bei Modus-Mix in N Sub-Specs.

harness-content-writer

Phase 3 (Generator). Schreibt den Content basierend auf Spec, Brief und (ab Iteration 2) Critique aus Evaluator. Wrapper um content-redakteur mit Modus-Header (verhindert Drift) und Iteration-Awareness.

harness-content-evaluator

Phase 3 (Evaluator, opus). Scort gegen Tonalitäts-Spec, Modus-Few-Shots und Hard-Constraints. Drift-Bremse — Critique muss Modus-konform sein, niemals in Richtung neutraler Sachstil pushen.

harness-content-applier

Phase 5 (nur Fall A In-place). Präsentiert Approved-Text als Preview, holt Approval pro Sektion, edit'tet dann die Astro-Component (Lorem-Ipsum oder Platzhalter ersetzen). Bei mode: in-place-direct wird das Sieb übersprungen.

Generelle globale Subagents (5, außerhalb Harness)

content-redakteur

Generator-Agent. Wrapper um den content-redakteur-Skill — direkter Aufruf möglich, oder via Task-Tool.

frontend-senior

Generator-Agent. Wrapper um den frontend-senior-Skill — für Code-Implementation in TSX/Astro/Tailwind.

frontend-reviewer

Evaluator-Agent. Reviewt Frontend-Code gegen STANDARDS.md. Findet Probleme, schlägt Fixes vor — fixt nicht selbst. Evaluator-Gegenstück zum frontend-senior.

ui-ux-designer

Generator-Agent. Wrapper um den ui-ux-designer-Skill.

a11y-auditor

Evaluator-Agent. WCAG 2.2 AA Audit, Multi-Mode (companion / full-audit / per-Kategorie). Wird sowohl im Repo (durch /cp-test-a11y) als auch global (in Harness 2 + 3) eingesetzt.

Welcher Skill / Agent für welche Aufgabe?

Schnelle Orientierung. Wenn du die richtige Wahl nicht findest, fragt /cp-expert dich durch — er kennt das ganze Inventar.

  • Bestehende Webseite analysieren / DNA erstellen → /harness-bestand
  • Neue Webseite oder Sektion bauen (mit cp-registry-Components) → /harness-projekt
  • Neue Library-Component anlegen oder bestehende verbessern → /harness-werkstatt (oder cp-component-builder-Agent direkt für schnelle Fälle)
  • Qualitätsgesicherten Content schreiben → /harness-content
  • Schnelle Text-Anfrage ohne Modus-Loop → content-redakteur-Skill direkt
  • Component im aktuellen Projekt einsetzen → /cp-add
  • Werkstatt-Block hinzufügen → werkstatt-block-builder-Agent
  • Werkstatt-Pattern als Template anlegen → werkstatt-template-creator-Agent
  • Werkstatt-Konfig als Astro-Seite exportieren → /cp-werkstatt-export
  • Glossar-Eintrag (einzeln) → glossary-extender-Agent
  • Decision-Tree erweitern → decision-tree-extender-Agent
  • Schulungs-Seite anlegen → lab-page-builder-Agent
  • Showcase-Seite generieren → cp-showcase-generator-Agent
  • Redakteurshinweise schreiben → redakteurshinweise-writer-Agent
  • Manifest prüfen → cp-manifest-validator-Agent
  • Werkstatt-Configs validieren → werkstatt-config-validator-Agent
  • A11y-Audit auf eine Seite → /cp-test-a11y oder a11y-auditor-Agent
  • Brand-Theme-CSS für neuen Kunden → /cp-brand
  • Wissens-Seite strukturieren (Component-Wahl) → /cp-content-strukturieren
  • Layout / Wireframe / A11y / UX-Review → ui-ux-designer-Skill
  • Code-Implementation TSX / Astro → frontend-senior-Skill
  • Code-Review → frontend-reviewer-Agent
  • PR erstellen → /pr
  • PR reviewen → /review-pr
  • Frage zum Registry / Projekt-Kontext → /cp-expert

Installation

Repo-Skills nutzen (im cp-registry selbst)

cd cp-registry
claude
# Alle 10 Repo-Skills + 12 Repo-Agents sind sofort verfügbar.

Repo-Skills in eigenes Projekt installieren

cd mein-projekt

# Alle universellen Skills (a11y-auditor, pr, review-pr, etc.):
cp-components skills --universal

# Spezifische Skills/Agents auswählen:
cp-components skills pr review-pr a11y-auditor

# Alle Skills + Agents:
cp-components skills all

# Liste anzeigen:
cp-components skills --list

Globale Skills (Harnesses + generelle Disziplinen)

Diese liegen unter ~/.claude/skills/ und sind in jedem Projekt automatisch verfügbar — kein Install nötig. Werden manuell gepflegt (Edit der SKILL.md-Files). Kein CLI-Update-Mechanismus.

Eigene Skills anlegen

Projekt-Ebene

Unter <projekt>/.claude/skills/. Im Repo committet, für alle im Team verfügbar.

mkdir -p .claude/skills/mein-skill
# SKILL.md erstellen
git add .claude/skills/mein-skill
git commit -m "Add mein-skill"

User-Ebene

Unter ~/.claude/skills/. Nur für dich, in allen Projekten verfügbar.

mkdir -p ~/.claude/skills/mein-skill
# SKILL.md erstellen
# Sofort in allen Projekten nutzbar

Anatomie eines Skills / Agents

Ein Skill ist eine Markdown-Datei mit Frontmatter. Der Frontmatter steuert Trigger, Tools und Modell, der Body ist der Workflow-Prompt.

Skill-Frontmatter (SKILL.md)

---
name: mein-skill                      # Slash-Command-Name (/mein-skill)
description: Was der Skill macht...   # Trigger-Phrasen, wann er aktiviert
argument-hint: "<arg1> [arg2]"        # Optional, Argumente
allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
---

# Mein Skill

Workflow-Prompt für den Skill...

Agent-Frontmatter (agents/mein-agent.md)

---
name: mein-agent
role: generator | evaluator | both
description: Was der Agent macht...
tools: Read, Write, Edit          # Tool-Allowlist (strict)
model: sonnet | opus | haiku
---

Du bist der ... Agent. Dein Auftrag: ...

Cross-Skill-Konvention

  • Pflicht-Inject von ~/.claude/skills/_shared/STANDARDS.md am Anfang jedes Skills/Agents.
  • Im Brownfield-Modus übersteuert project-dna.md die globalen STANDARDS — Konsistenz mit Bestand schlägt Modernität.
  • Generator/Evaluator-Markierung im Frontmatter — bei both: separater System-Prompt-Block pro Modus, keine Self-Eval.
  • Handoff-Block am Output-Ende mit Sub-Sections "Hinweise an content-redakteur / ui-ux-designer / frontend-senior / a11y-auditor" — auch wenn leer (_keine_).
  • Tool-Allowlist strict — nur was wirklich gebraucht wird.

Weiterführend