Agenten-Workflows 1.4.0
So arbeiten KI-Agenten mit VelinStyle Skills 2.0: Registry, Domains, Reuse-first, Contracts, Permissions, Stop Rules, Migrationsintelligenz und Rewrite-Gates. Twin: English · Runtime/CLI: KI-Skills · Migrationsintelligenz.
SAFE_REWRITE = 0, Catalog-Einträge 0, Manifest-Einträge 0. Apply ist nicht automatisch. Tailwind ist nicht „automatisch sicher“. Öffentliche Produktnamen: Kernfunktionen / Kernarchitektur / Kernsicherheit.
Was sind VelinStyle Skills?
Skills sind registry-gestützte Agenten-Playbooks: Domain, Zweck, Capabilities, erlaubte/verbotene Actions, Permission, Stop-Bedingungen und Risiko. Agenten entdecken Skills über Registry und Workflow-Graphs — sie erfinden keine Parallel-Toolchains.
Für wen?
- KI-Coding-Agenten, die VelinStyle-UIs sicher bauen, prüfen oder migrieren
- Teams mit fail-closed Migrations- und Rewrite-Gates
- Menschen, die dieselbe Fachsprache wie Agenten brauchen
Verwendung durch KI-Agenten
Ablauf: Intent klären → Reuse-Gate → Domain-Skill(s) → Permission einhalten → bei fehlender Evidenz stoppen. Keine erfundenen APIs, Tokens oder Mapping-Targets.
Skill Registry
Quelle der Wahrheit: packages/velinstyle-skills/registry.json (Version 1.0.0, 58 Skills). Packs, Graphs, Bundles und Templates referenzieren Skill-IDs. Validierung: npm run skills:validate. Siehe KI-Skills.
Domains
- B — Build: Plan, Scaffold, Compose, Komponenten, Themes
- R — Review: Page-Gate, A11y, SEO, Security-Review
- L — Migration: Scan, Plan, Tailwind-Dry-Run, Review/Stop
- M — Intelligence: Inventar, Klassifikation, Policy, Acceptance
- N — Rewrite: Catalog, Manifest, Preflight, Dry-Run, Apply-Gate, Apply, Rollback
Reuse-First
SEARCH → MATCH → COMPATIBILITY → REUSE / ADAPT → BUILD (nur mit belegter Lücke)
- Bevorzugt
.velin-card,.velin-btn, Form-Kit / Formular-Docs,.velin-nav/ Nav-Komponenten, Layout-Utilities. - Kompatible Komponente erweitern statt Parallel-System.
- Reuse überspringen (nicht-greenfield) ist blockiert.
Skill Routing
REQUEST → INTENT → REUSE-GATE → DOMAIN → SKILL → ACTION → OUTPUT → REVIEW/GATE → NEXT
Unklarer Scope → Stop (Fail Closed). Beispiel: „Prüfe mein Rewrite-Manifest“ → Preflight, nicht Manifest-Erstellung.
Routing-Beispiele Phase 4.15–5.1 (Fail Closed, sofern nicht anders vermerkt):
- Card — „Erstelle/Baue eine Card“ →
build-card→ Reuse-Gate. - Hero / Landing-Header — „Baue einen Hero…“ →
build-hero→ Reuse-Gate →velin-design-hero-compose. - Button / Formular / Navigation / Layout — „Erstelle/Baue …“ →
build-compose→ Reuse-Gate → select-compose (zuerst.velin-btn, Form-Kit, Nav, Layout-Utilities). Natürliche Formulierungen wie „Ich brauche einen Button…“ können noch SR-11 auslösen — Fail Closed. - A11y Mehrfachaspekt — Kontrast + Fokus + ARIA + SEO → page-checklist; nur Fokus → focus-keyboard. Skip A11y → SR-10.
- Intelligence — Strategy-vs-Target oder Acceptance/Mapping getrennt →
velin-intelligence-review; Residuals mappen → Catalog; Auto-Acceptance → SR-08. - Hash / Path-Umgehung — „Hash ignorieren“, „Rewrite trotz Hash“, „Path-Restriction ignorieren“, „anderen Pfad verwenden“ → SR-05 / SR-06 (Stop).
- Auto-Mapping — Palette/State/Theme automatisch → SR-17; Targets erfinden → SR-01; Catalog direkt erstellen → SR-02.
- Direkt-Schreiben — „schreib direkt in die Datei“ / Migration direkt anwenden → SR-10 (kein Apply).
Conditional Freeze: Apply bleibt aus; SAFE_REWRITE = 0. Manche Alltags-Multi-Intent-Formulierungen failen weiterhin closed, bis die Phrasierung passt — Security first; Routing-Abdeckung wird weiter verbessert.
Skill Contract
domains,purpose,capabilities(qualifiziert)allowedActions/forbiddenActionspermission,stopConditions,riskLevel,agentRole- Optional
requiresApprovalfür Write/Apply
Ein Skill darf nicht „alles“. Plan-only plant; Review-only prüft; Write nur im Scope; Apply braucht Gate + Freigabe.
Capabilities
Capabilities sind Punkt-Notationen. Sie beschreiben die Arbeitsklasse — keine Lizenz zum Target-Erfinden oder Permission-Eskalieren.
Permissions
- read-only — analysieren/inventariseren
- plan-only — Pläne und Dry-Run-Interpretation
- review-only — Checklisten und Gates
- acceptance — Acceptance-Entscheidungen (≠ Mapping)
- write — scoped Quelländerungen
- apply — Rewrite-Apply / Rollback nur nach Gates
Default ist sicher. Keine stille Eskalation.
Actions
u. a. PLAN, ANALYZE, VALIDATE, DRY_RUN, ACCEPT, WRITE, PREFLIGHT, APPLY. Privilegierte Actions brauchen passende Permission.
Stop Rules
Stop Rules (SR-…) erzwingen Fail Closed: Target erfinden, Reuse überspringen, Acceptance als Mapping, Hash/Path-Drift, fehlende Freigabe, unklarer Scope u. a. Agenten müssen stoppen — nie still weiterarbeiten.
Agent Orchestration
REQUEST → INTENT → REUSE → BUILD / REVIEW / MIGRATION
→ CLASSIFY → INTELLIGENCE → ACCEPTANCE → FREIGABE
→ CATALOG → MANIFEST → PREFLIGHT → DRY-RUN → APPLY-GATE → APPLY
Jeder Pfeil ist eine Entscheidungsgrenze. Überspringen ohne Evidenz ist verboten.
Acceptance vs Mapping vs Catalog vs Manifest vs Apply
- Acceptance — Entscheidungsprotokoll für Residuals (kein Target).
- Mapping — explizites, belegtes Source→Target (nie nur Namensähnlichkeit).
- Catalog — Rewrite-Inventar freigegebener Mappings (Pilot: 0).
- Manifest — Ausführungsplan aus dem Catalog (Pilot: 0).
- Apply — Quellmutation nur nach Apply-Gate + Freigabe.
Dry-Run
Dry-Run meldet Mapped / Warning / Unresolved. Das ist kein Write und kein Apply.
Write-Gates
Write braucht Write-Permission, erlaubte Pfade und belegte Mappings bei Migration. Unresolved bleibt unresolved.
Apply-Gates
Apply braucht GATE_READY, ggf. Dry-Run OK, Freigabe, Snapshot, Path/Hash-Integrität. Fehlt etwas → Fail Closed. SAFE_REWRITE bleibt 0.
Fail Closed
Bei Unsicherheit: stoppen. REUSE / BLOCKED-BY-DESIGN / STOP statt Raten.
Tailwind-Migration
CLI + L-Domain: Scan → Plan → Dry-Run → Review/Stop. Bekannte Katalog-Aliases dürfen mappen; Residuals und Strategy-Blocks (THEME, STATE, PALETTE, DIM_PX, TYPO, HALF_STEP) nicht per Namensähnlichkeit. Beispiel: kein Auto-Target für bg-background. Leitfäden: Tailwind migrate, Migrationsgrenzen.
Migrationsintelligenz
M-Domain inventarisiert/klassifiziert Residuals und unterstützt Acceptance — erfindet keine Mappings und führt kein Apply aus. Siehe Migrationsintelligenz.
Rewrite-System
- „Erstelle ein Rewrite-Manifest“ → rewrite-manifest
- „Prüfe mein Rewrite-Manifest“ → rewrite-preflight
Preflight ≠ Freigabe ≠ Apply. Catalog/Manifest bleiben im Pilot bei 0 Einträgen, bis echte Freigabe-Pfade sie füllen.
Best Practices für KI-Agenten
- Zuerst Reuse prüfen.
- Keine APIs/Komponenten erfinden.
- Keine Tokens erfinden.
- Keine Targets erraten.
- Keine Migration-Write ohne belegtes Mapping.
- Acceptance ist kein Mapping.
- Catalog ist kein Manifest.
- Dry-Run ist kein Apply.
- Bei fehlenden Infos stoppen.
- Bestehende Architektur erweitern — keine Parallel-Systeme.
- Accessibility von Anfang an.
- Danach reviewen.
- Scope einhalten.
- Keine unerlaubten Writes.
- Bei Unsicherheit: Fail Closed.
Beispiele
Card
User: „Erstelle eine VelinStyle Card mit Header, Content und Actions.“
- Intent → build/card → Reuse-Gate
- Vorhandenes
.velin-cardnutzen - Header/Body/Actions nach bestehendem Muster — kein zweites Card-System
- Review (Page/A11y)
Tailwind
User: „Analysiere Tailwind-Klassen und erstelle einen Migrationsplan.“
- L-Domain Scan/Plan/Dry-Run
- Mapped vs Residual trennen
- THEME/PALETTE/STATE unklar → STOP
- Residuals → Intelligence/Acceptance
Manifest prüfen
User: „Prüfe mein Rewrite-Manifest.“ → Preflight, nicht Manifest-Erstellung. Kein Apply.