CommunitySchreiben & Editierengithub.com

robcsaszar/crucible

Ein paralleles Codebase-Audit-Skill für Claude Code, das seine eigenen Ergebnisse kritisch hinterfragt, bevor es sie meldet.

Was ist crucible?

Crucible ist ein fortschrittliches KI-Agenten-Skill für Claude Code, das eine vollständig autonome, mehrphasige Codebase-Überprüfung durchführt. Es startet parallele Recon-Agenten für verschiedene Bereiche, identifiziert Schwachstellen und Bugs, unterzieht diese Ergebnisse einer adversarischen Prüfung und verifiziert die Befunde anschließend unabhängig. Das Skill erstellt einen detaillierten Plan (PLAN.md), spezifische Änderungsvorschläge mit Code (SPEC.md) und kann sogar automatisierte Pull Requests erstellen. Es ist besonders nützlich für Entwicklerteams, die Sicherheitslücken, Code-Qualitätsprobleme oder veraltete Funktionalitäten in großen Codebasen systematisch aufdecken und beheben möchten. Crucible unterstützt dabei die Iteration über verschiedene Erkenntnisstufen und verhindert, dass fehlerhafte oder nicht verifizierte Ergebnisse gemeldet werden. Es setzt auf eine klare Trennung zwischen Analyse, Gegenprüfung und unabhängiger Verifikation, um qualitativ hochwertige Audits zu gewährleisten.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add robcsaszar/crucible

Installed? Explore more Schreiben & Editieren skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Was macht crucible?

Parallele Domänenreconnaissance → adversarischer Kill → Planen → Verifizieren → SPEC → Implementieren → PR.

Datei-Eigentumsregel

Subagenten schreiben NIEMALS Dateien. Sie geben Ergebnisse als Text zurück. Du (der Orchestrator) schreibst jedes Artefakt. Dateien sind der phasenübergreifende Übergabepunkt – das Gedächtnis der Subagenten ist es nicht.

Einrichtung

Analysiere den Aufruf nach:

  • Domains (erforderlich) — benutzernahe Bereiche, die geprüft werden sollen, z. B. player, curator
  • Scope-Hinweis (optional) — Fokus innerhalb einer Domain eingrenzen, z. B. lobby SSE, role selection

Bestimme das Ausgabeverzeichnis: .crucible/run-<N>/, wobei N die nächste ungenutzte ganze Zahl ist.

Prüfung auf vorherige Läufe: Scanne .crucible/ nach vorhandenen Run-Verzeichnissen. Lies jedes findings.json. Füge deren bestätigte IDs als Ausschlussliste in die Phase-1-Agenten ein – bekannte, behobene Probleme nicht erneut entdecken; Aufwand auf Lücken konzentrieren.

In diesem Lauf geschriebene Dateien (alle durch den Orchestrator):

DateiPhaseRolle
codebase-map.md1Kontext, der wortwörtlich in alle nachgelagerten Agenten eingespeist wird
recon-<domain>.json1Rohe Ergebnisse pro Domain
findings.json1→2→4Zusammengeführte Ergebnisse; Urteile werden pro Phase angehängt
PLAN.md3Priorisierter Korrekturplan
SPEC.md5Vorher/Nachher-Code + Testfälle pro Ergebnis

Phase 1 – Reconnaissance

PFLICHTLEKTÜRE references/recon-phase.md vor dem Starten der Agenten.

Starte einen Recherche-Agenten pro deklarierter Domain, alle parallel. Gib jedem mit: Codebase-Pfad, Domain-Name, Scope-Hinweis (falls vorhanden), bekannte IDs zum Überspringen.

Agenten geben JSON-Text zurück. Wenn ein Agent stattdessen Prosa anstelle eines JSON-Arrays zurückgibt, fordere einmalig mit der exakten Schemaform aus assets/findings-schema.json auf. Wenn es erneut fehlschlägt, schreibe ein leeres recon-<domain>.json ([]) und notiere den Fehler in codebase-map.md. Fahre fort – eine fehlgeschlagene Domain ist heilbar; brich den Lauf nicht ab.

Sammle gültige Antworten, dann:

  1. Schreibe recon-<domain>.json pro Agentenantwort
  2. Erstelle codebase-map.md – wichtige Dateipfade, Domänengrenzen, gemeinsam genutzte Module, Konventionen
  3. Führe alle Domänenergebnisse in findings.json zusammen

Abschlusskriterium: Jede Domain hat ein recon-<domain>.json, codebase-map.md wurde geschrieben, findings.json wurde geschrieben. Lade references/adversarial-phase.md erst in Phase 2.

Phase 2 – Adversarische Überprüfung

PFLICHTLEKTÜRE references/adversarial-phase.md vor dem Starten der Agenten.

Starte einen allgemeinen Agenten pro Ergebnis (batche Ergebnisse aus derselben Domain). Jeder Agent erhält das Ergebnis-JSON und codebase-map.md – NICHT die Argumentation des Recon-Agenten. Die Unabhängigkeitsgrenze ist das Qualitätstor.

Agenten geben CONFIRMED / REJECTED / DOWNGRADED mit Code-Beleg zurück. Hänge jedes Urteil an den entsprechenden Eintrag in findings.json an. Führe node scripts/validate-findings.cjs findings.json aus – behebe alle Schemafehler vor Phase 3.

Wenn der Validator selbst nicht ausgeführt werden kann – node nicht im PATH, das Skript oder sein Schema fehlt, ein Verwendungsfehler oder irgendein Fehler vor Beginn der Validierung (Fehler beim Laden des Schemas, Fehler beim Parsen von JSON) – dies ist kein Bestehen. Notiere ⚠ findings unvalidated — validator unavailable: <Grund> in der Ausgabe der Ergebnisse und oben in der SPEC-Übergabe, dann fahre fort. Eine Schema-Ablehnung ist der gegenteilige Fall und blockiert immer: Korrigiere die Ergebnisse, führe erneut aus, fahre bei einer Ablehnung nicht fort. Beide beenden derzeit mit Exit-Code 1, also lies den Fehlertext, nicht den Exit-Code.

Abschlusskriterium: Jedes Ergebnis hat ein adversarial_verdict-Feld. Schema-Validierung besteht. Lade references/recon-phase.md ab diesem Punkt nicht erneut.

Phase 3 – Plansynthese

Null-Ergebnisse-Prüfung: Vor der Synthese zähle die bestätigten + herabgestuften Einträge in findings.json. Wenn null, schreibe .crucible/run-<N>/REPORT.md mit der einzelnen Zeile „Keine umsetzbaren Ergebnisse nach adversarischer Überprüfung.

Verwandte Skills