Workspace Automation Orchestrator

Dieser Skill reduziert wiederholte manuelle Ausfuehrungsschritte, indem er Prozesse erkennt und innerhalb klarer Safe-Scopes automatisch orchestriert.

Referenzen laden

Lade bei Bedarf die folgenden Dateien fuer Details:

• references/contracts.md fuer Detection-, Safety- und Execution-Contract
• references/v1-automations.md fuer den initialen Automationskatalog
• references/rollout.md fuer den kontrollierten Rollout und Monitoring
• evals/evals.json fuer die ersten Skill-Evaluationsprompts

Ziel

• Wiederkehrende manuelle Prozesse im aktuellen Workspace erkennen
• Automationskandidaten nach Nutzen priorisieren
• Sichere lokale Ablaufe automatisch ausfuehren
• Risiko-Aktionen strikt blockieren und sauber eskalieren

Trigger

Nutze diesen Skill, wenn der User:

• von regelmaessig wiederholten manuellen Schritten berichtet
• Produktivitaet durch wiederholtes manuelles Anstossen verliert
• konsistente Qualitaet/Gate-Compliance erreichen will
• nach "automatisch erkennen", "automatisieren" oder "nicht jedes Mal manuell" fragt

Betriebsmodus

Dieser Skill arbeitet im Hybrid-Modus:

1. Discovery bei Task-Start
2. ROI-Scoring fuer Kandidaten
3. Automatische Ausfuehrung nur bei erreichtem Schwellwert und nur in Safe-Scopes
4. Sonst Vorschlag + explizite Freigabe

Standardprofil fuer dieses Repo: balanced.

Profile:

• strict: auto-run nur bei sehr hohem ROI und null Safety-Zweifel
• balanced: auto-run bei klarem ROI in der Allowlist
• aggressive: nur auf expliziten User-Wunsch, nie als Default

Safety-Vertrag (nicht verhandelbar)

Harte Block-Regeln

Folgende Aktionen werden niemals automatisch ausgefuehrt:

• git push oder sonstige Remote-Write-Operationen
• automatisches Posten von Issue-/PR-Kommentaren
• destructive Git-Kommandos (git reset --hard, git checkout --, History-Rewrites)

Eskalations-Regel

Wenn ein geplanter Schritt nicht in der Allowlist ist:

1. Aktion blockieren
2. Grund nennen
3. sichere Alternative vorschlagen
4. explizite User-Freigabe anfordern

Detection-Contract

Suche nach Automationskandidaten anhand folgender Signale:

• identische oder stark aehnliche Befehle wiederholen sich
• gleiche Sequenzen erscheinen mehrfach (z. B. test -> gate-check -> audit)
• wiederkehrende Quality- oder Gate-Fehler mit demselben Fix-Pattern
• hoher manueller Koordinationsaufwand bei niedrigem Entscheidungsbedarf

ROI-Heuristik

Prioritaet fuer Automation:

priority = frequency_score * effort_score * consistency_gain / risk_factor

Hinweise:

• frequency_score: Wie oft der Ablauf wiederkehrt
• effort_score: Zeit-/Kontextkosten pro manueller Ausfuehrung
• consistency_gain: Qualitaetsgewinn durch Standardisierung
• risk_factor: Ausfuehrungsrisiko (niedriger ist besser)

Auto-Run nur bei:

• Schwellwert erreicht
• Aktion in Safe-Scopes
• keine aktive Block-Regel verletzt

Schwellwerte (balanced)

• priority >= 40: automatisch ausfuehren
• priority 20-39: als Vorschlag ausgeben, optional auf Rueckfrage ausfuehren
• priority < 20: nicht automatisieren

Zusatzregel:

• Wenn risk_factor > 1.0, keine automatische Ausfuehrung; nur Vorschlag mit Begruendung

Safe-Scopes (V1)

V1 nutzt vorhandene Repo-Kommandos statt neuer Parallel-Logik.

Die autoritative V1-Allowlist und Denylist steht in:

• references/v1-allowlist.md

Erlaubte lokale Orchestrierung

• make test-fast
• make check
• make gate-check COMMIT_TYPE=<feat|fix|chore|signal>
• make audit-diff
• make changelog-entry COMMIT_TYPE=<...> MSG='...'
• make catalog
• gezielte lokale pytest-Laeufe fuer betroffene Tests

Erlaubte Analyse-/Discovery-Schritte

• Status-/Diff-Pruefung (read-only)
• Erkennen wiederkehrender Task-Sequenzen
• Ableiten naechster lokaler Safe-Aktionen

Ausfuehrungsprotokoll

1. Scan
   • Aktuelle Aufgabe erfassen
   • Wiederholungsmuster im aktuellen Arbeitskontext erkennen
2. Score
   • Kandidaten nach ROI-Heuristik priorisieren
3. Safety-Gate
   • Jede Kandidatenaktion gegen Hard-Blocks und Allowlist pruefen
4. Execute or Escalate
   • In Safe-Scopes: automatisch ausfuehren
   • Ausserhalb: blockieren, begruenden, Freigabe anfordern
5. Report
   • Was automatisch ausgefuehrt wurde
   • Was blockiert wurde und warum
   • Empfohlene naechste Schritte

Reihenfolge fuer V1-Auto-Orchestrierung

Wenn mehrere Aktionen in den Auto-Run fallen, nutze diese Reihenfolge:

1. make catalog (Discovery)
2. make gate-check COMMIT_TYPE=<...> (fruehe Gate-Sichtbarkeit)
3. make audit-diff (nur wenn relevant)
4. make test-fast (schnelle Verifikation)

Regel fuer make check:

• Nur automatisch starten, wenn User explizit "vollstaendig" oder "full check" verlangt
• Sonst als Vorschlag ausgeben, weil Laufzeit und Umfang hoeher sind

Output-Vertrag

Der Skill liefert immer einen strukturierten Kurzreport:

• detected_repetitions: erkannte wiederkehrende Prozesse
• auto_executed: automatisch ausgefuehrte Safe-Aktionen
• blocked_actions: blockierte Aktionen inkl. Block-Grund
• manual_approvals_needed: Aktionen mit Freigabebedarf
• next_best_automations: Top-Kandidaten fuer weitere Automatisierung

Template:

Automation Report
- profile: <strict|balanced|aggressive>
- detected_repetitions:
   - <pattern>: <evidence>
- auto_executed:
   - <command>: <status>
- blocked_actions:
   - <action>: <reason>
- manual_approvals_needed:
   - <action>: <why>
- next_best_automations:
   - <candidate>

Drift-spezifische Integrationsregeln

• Drift Policy Gate weiterhin vor nicht-trivialen Aenderungen beachten
• Existierende Repo-Workflows und Make-Targets bevorzugen
• Keine neue Automationslogik einfuehren, wenn ein bestehender Befehl den Zweck bereits erfuellt
• Bei Unsicherheit konservativ bleiben: nicht ausfuehren, sondern eskalieren

Beispiele

Beispiel 1: Wiederkehrende QA-Sequenz

Input-Situation:

• User startet mehrfach pro Tag dieselbe Sequenz aus test-fast, gate-check, audit-diff

Erwartetes Verhalten:

1. Sequenz als wiederkehrenden Prozess erkennen
2. ROI hoch einstufen
3. komplette Sequenz in Safe-Scopes automatisch ausfuehren
4. Ergebnis kompakt reporten

Beispiel 2: Unsichere Aktion mit Remote-Write

Input-Situation:

• Workflow endet mit vorgeschlagenem git push

Erwartetes Verhalten:

1. git push blockieren
2. Block-Grund klar nennen
3. nur sichere lokale Vorstufen ausfuehren
4. fuer Push explizite User-Freigabe anfordern

Grenzen

Dieser Skill automatisiert V1 bewusst nur lokale, risikoarme Workflows. Er ist kein Freifahrtschein fuer autonome Remote-Aktionen oder Policy-Bypass.