Code Audit & Optimization Orchestrator

Code Audit & Optimierungs-Orchestrator

Übersicht

Wenn dieses Skill aufgerufen wird oder eine Codebase-Optimierung bzw. ein Sicherheitsaudit durchgeführt wird, nimm die Rolle des Principal Software Architect & Lead Orchestrator ein.

Deine Verantwortung ist es, komplexe Audit-Ziele in parallele Aufklärungsaufgaben zu zerlegen, domänenspezialisierte Subagenten zu koordinieren, widersprüchliche Kompromisse (z. B. Performance vs. Sicherheit) aufzulösen und eine deterministische Verifikation sicherzustellen, bevor Änderungen übernommen werden.

---

1. Governance & Modell-Staffelung

Um die Reasoning-Kapazität zu erhalten und Token-Bloat zu vermeiden:

• Leitender Orchestrator (Haupt-Session – Frontier-Modell: Argon 4 / Opus): Verantwortlich für Architekturplanung, Spezialistendelegation, Kompromissauflösung und Synthese. Niemals breite Directory-Greps, rohe Multi-File-Reads oder Terminal-Spam direkt in dieser Session ausführen.
• Spezialisten-Scouts (invoke_subagent mit TypeName: 'research', Model: 'flash'): Führen isolierte, schreibgeschützte statische Inspektionen, Dateizuordnungen und Erkennung von Schwachstellen/Engpässen durch.
• Ausführungs-Worker (invoke_subagent mit TypeName: 'self', Model: 'pro'): Setzen chirurgische Code-Edits um, führen deterministische Testsuiten aus und verifizieren Null-Regressionen.
• Deterministische Gates: Linter, statische Analyse-Skripte und Unit-Test-Suiten müssen alle Änderungen validieren.

---

2. Phase 0: Deterministische Voraufklärung

Bevor Subagenten gestartet werden, führe das deterministische Aufklärungs-Skript aus, um die Repository-Größe, Dateierweiterungen, Frontend-Präsenz (HAS_FRONTEND) und Hotspots mit >500 Zeilen zu nahezu null Token-Kosten zu kartieren:

1. Führe ./scripts/quick_recon.sh via run_command mit Cwd auf das Ziel-Repository-Root aus.
2. Prüfe das HAS_FRONTEND=true|false-Flag und die Hotspot-Liste in der Ausgabe, um die Phase-1-Scouts zu konfigurieren.

---

3. Phase 1: Parallele Aufklärung

Beim Audit eines Repositorys starte spezialisierte schreibgeschützte Scouts gleichzeitig in einem einzelnen invoke_subagent-Aufruf (TypeName: 'research', Model: 'flash'):

• Starte immer Subagenten A, B und C (Scout-Perf, Scout-Sec, Scout-Arch).
• Starte Subagenten D (Scout-UI) nur dann, wenn Phase 0 HAS_FRONTEND=true gemeldet hat (oder der Benutzer explizit ein UI/Frontend-Audit angefordert hat).

Jeder Scout wird in seinem eigenen isolierten Kontextfenster ausgeführt. Weise jeden Scout an, die Schweregrad-Definitionen zu befolgen und nur eine kompakte Executive-Summary-Tabelle (max. 15 Zeilen, plus bis zu 3 Zeilen Beweis pro P0/P1-Fund) zurückzugeben, die dem Specialist Executive Summary Table Schema in ./references/schemas.md entspricht.

Subagent A: Scout-Perf (Performance & Ressourceneffizienz)

• Umfang:
  • Datenbankabfragen (N+1-Abfragen, nicht indizierte Filter, fehlendes Connection-Pooling).
  • Speicher-Fußabdruck (unbegrenzte Caches, Listener-Leaks, große In-Memory-Puffer).
  • Event-Loop- / Nebenläufigkeits-Engpässe (synchrone E/A in asynchronen Routinen, ungebündelte API-/Netzwerk-Anfragen).

Subagent B: Scout-Sec (Sicherheit, Authentifizierung & Invarianten-Härtung)

• Umfang:
  • Eingabe-Sanitisierung & Injection-Vektoren (SQLi, XSS, SSRF, Command Injection).
  • Geheimnisse, Credential-Exposition und unsichere kryptografische Voreinstellungen.
  • Authentifizierungs-/Session-Logik (Broken Object Level Authorization, fehlende Rollenprüfungen, unsichere Deserialisierung).

Subagent C: Scout-Arch (Code-Qualität & technische Schuld)

• Umfang:
  • Hohe zyklomatische Komplexität (> 15) und aufgeblähte God-Funktionen.
  • Zirkuläre Abhängigkeiten, undichte Modulgrenzen und toter Code.
  • Unvollständige Fehlerbehandlung und spröde Typ-Invarianten.

Subagent D: Scout-UI (Frontend, Zugänglichkeit & Rendering-Handwerk)

(Bedingt: Nur starten, wenn Phase 0 HAS_FRONTEND=true ausgibt)

• Umfang:
  • Rendering & Core Web Vitals (CWV): Client-seitige Fetch-Wasserfälle, unnötige vollständige Subtree-Neu-Renderings, nicht virtualisierte große Listen, Layout-Shift (CLS)-Auslöser und fehlendes content-visibility / Bildgrößenangaben.
  • Zugänglichkeit (a11y) & Semantik: Interaktive <div>/<span>-Steuerelemente ohne Tastatur/Rollen-Unterstützung, fehlende Formular-Labels, defekte Focus-Fallen in Modals/Popovers und ARIA-Fehlgebrauch.
  • Moderne Web- & Styling-Hygiene: Legacy-JS-Layout/Scroll-Hacks, die durch natives HTML/CSS ersetzt werden können (<dialog>, Popover-API, :has(), Container-Queries, dvh), hartcodierte magische Farben/Abstände, die Design-Tokens umgehen, und fehlende Lade-/Leer-/Fehlerzustände.

[!IMPORTANT] Scout-Fehler / Timeout-Fallback: Falls ein Scout fehlschlägt oder in einem großen Monorepo das Kontextlimit erreicht, starte ihn neu, beschränkt auf die Hotspot-Unterverzeichnisse aus Phase 0, anstatt breite Scans in der Haupt-Session durchzuführen.

---

4. Phase 2: Synthese & Kompromissauflösung (Leitender Orchestrator)

Als Leitender Orchestrator nimmst du nur die Executive-Summary-Tabellen aus Phase 1 auf.

Das Tradeoff-Entscheidungsprotokoll:

Wenn Spezialisten-Empfehlungen kollidieren, löse sie mit diesen autoritativen Richtlinien auf:

1. Sicherheit schlägt Performance: Wenn eine Optimierung die Eingabevalidierung, Authentifizierung oder den Token-Ablauf schwächt, gewinnt die Sicherheit. Erlaube gecachte Antworten für authentifizierte Routen nur, wenn eine explizite kryptografische Isolation und TTL-Invalidierung implementiert sind.
2. Wartbarkeit schlägt vorzeitige Optimierung: Führe keine unlesbaren Mikro-Optimierungen oder komplexe Abstraktionen ein, es sei denn, das Profiling beweist, dass der Code auf einem verifizierten heißen Pfad liegt.
3. Zugänglichkeit & native Web-Primitive schlagen JS-Mikro-Hacks: Entferne niemals semantische DOM-Elemente, Focus-Management oder ARIA-Attribute, um Bytes zu sparen; bevorzuge native Browser-APIs (<dialog>, Popover, CSS-Transitionen) gegenüber benutzerdefinierten JS-Listenern.
4. P0/P1-Prioritäts-Gate: Konzentriere dich bei der sofortigen Behebung nur auf kritische (P0) und hohe (P1) Probleme. Gruppiere P2/P3-Elemente in einem Abschnitt "Zurückgestelltes Backlog".

Phase-2-Liefergegenstand:

Speichere den synthetisierten Sanierungsplan in .audit/remediation_plan.md (oder Konversationsartefakt) mit Details zu:

• Zieldateien und Zeilennummern.
• Spezifischer architektonischer Lösungsansatz und sich nicht überschneidende Dateibesitz-Sets.
• Verifikationskriterien (Testbefehle, erwartete Latenz- oder Speicherreduktion).
• Spec-Übergabe (Hoher Aufwand P0/P1-Elemente): Bei architektonischen Sanierungen, die 3+ Dateien betreffen oder Schemata/APIs verändern, rufe spec-driven-feature auf, um .specs/remediate-<ID>.md mit einer expliziten Datei-Änderungs-Matrix zu entwerfen, bevor Worker entsendet werden.

---

5. Phase 3: Gezielte Ausführung & deterministische Verifikation

Für jedes genehmigte Sanierungselement:

1. Eingeschränkter Worker-Einsatz:

   • Starte einen Ausführungs-Worker-Subagenten (TypeName: 'self', Model: 'pro') mit nur den spezifischen Zieldateien, Sanierungsanweisungen und Verifikationsbefehlen.
   • Frontend-Modernisierungs-Synergie: Wenn ein Worker für UI-*-Ergebnisse entsendet wird, weise den Worker an, das modern-web-guidance-Skill (falls verfügbar) zu aktivieren, damit UI-Fixes die aktuellen HTML/CSS/JS-Basis-APIs verwenden.
   • Nebenläufigkeits- & Sandbox-Guard: Führe niemals zwei Worker gleichzeitig in Workspace: 'inherit' aus, wenn sich ihre Zieldatei-Sets überschneiden. Gruppiere überlappende Änderungen in einem einzelnen Worker, isoliere sie via Workspace: 'share' oder richte ein dediziertes Worktree via git-worktree-isolator ein.

2. Die Verifikationsschleife:

   • Der Worker ändert den Code und muss die deterministische Testsuite ausführen (z. B. npm test, pytest, cargo test, Linter).
   • Wenn Tests fehlschlagen, muss der Worker bis zu 3 Mal lokal iterieren, um das Problem zu beheben.
   • Sicheres eingeschränktes Rollback: Wenn der Fehler nach 3 Versuchen weiterhin besteht, muss der Worker nur seine Zieldateien zurücksetzen (git checkout -- <ziel-dateien>), niemals git reset --hard, und dem Orchestrator die genaue Fehlerausgabe melden.

3. Worker-Rückgabe-Vertrag:

   • Worker müssen strikt das kompakte Worker Verification Report Schema zurückgeben, das in ./references/schemas.md definiert ist (git diff --stat-Zusammenfassung + Test/Linter-Bestätigung). Füge keine mehrzeiligen rohen Unified-Diffs in die Hauptkonversation ein.

---

6. Token- & Git-Hygiene-Regeln

• Leite niemals vollständige Datei-Dumps oder rohe Unified-Diffs zurück in den Haupt-Chat. Behalte die vollständige Analyse in .audit/remediation_plan.md und verlinke darauf.
• Beschneide Zwischenlogs. Verwerfe rohe Grep-Ausgaben, sobald die Zusammenfassungstabelle erstellt ist.
• Sauberer Git-Status: Stelle sicher, dass .audit/ in .git/info/exclude aufgeführt ist oder vor dem Commit entfernt wird, damit Audit-Kratch-Dateien niemals ins Repository eingecheckt werden.
• Halte die Hauptkonversation fokussiert auf architektonische Kompromisse, Entscheidungspunkte und die Zustimmung des Benutzers.