Mach aus jedem KI-Agenten einen Schwarm, der Befunde beweist.
Ein Master-Prompt aktiviert 13 spezialisierte Prüfbereiche, lässt unabhängige Skeptiker jeden relevanten Befund angreifen und liefert nur belegte, priorisierte GitHub-Issues.
13 PRÜFBEREICHE · ≥2-VON-3 VERIFIZIERT · PRIORISIERTER OUTPUT
Kopiert eine Vorlage — ersetze die Repo-URL, bevor du sie ausführst.
Loslegen
Nutze auditor.rapold.io mit deinem KI-Agenten
Keine Installation — funktioniert mit jedem Agenten, der eine URL abrufen und Tools ausführen kann (läuft mit Claude Code). Sag ihm, er soll ein Repo mit auditor.rapold.io auditieren: er holt den Audit-Prompt — einen einzigen Einstiegspunkt, der Sprache und Umfang erfragt — und legt dann die Issues an.
Audit github.com/your/repo using auditor.rapold.io
Kopiere ihn, setze deine Repo-URL ein, füge ihn in deinen Agenten ein.
Er fragt dann nach: Ausgabesprache (Deutsch / English), welche der 13 Audits (oder das ganze Repo) und ob er Issues erstellen darf — dann führt er sie aus und öffnet einen nach Priorität sortierten Tracker.
KI-Agenten: hole auditor.rapold.io/llms.txt und agiere als Audit-Orchestrator (Sprache + Umfang erfragen, dann ausführen).
Ehrliche Antworten auf die naheliegenden Fragen
- Halluziniert es Belege?
- Jede file:line wird in der adversariellen Verifikation (Phase 3) anhand der echten Datei nachgeprüft; nicht verifizierbare Aussagen werden verworfen.
- Verlässt mein Code meinen Rechner?
- Nein — dein Agent holt nur den Prompt; dein Repo berührt unsere Domain nie.
- Was kostet ein Durchlauf?
- Nur die Tokens deines Agenten — grenz den Umfang auf ein paar Audits ein, um die Kosten zu steuern.
Warum es anders ist
Die meisten Audit-Prompts liefern unverifizierte Meinungen. Diese erzwingen Disziplin.
Beleg oder nichts
Jeder Befund nennt ein konkretes Artefakt — file:line, einen Query-Plan, einen Request, einen Config-Wert, eine gemessene Metrik. Kein Beleg, kein Befund.
Adversarielle Selbstprüfung
Kein Befund überlebt, bevor unabhängige Skeptiker-Agenten ihn zu widerlegen versucht haben — er muss mindestens zwei von drei überstehen, sonst wird er verworfen. Wer eine feindselige Lesart nicht übersteht, ist kein Befund.
Blind-Spot-Jagd
Ein Completeness-Critic fragt jede Runde, welche Oberfläche, welcher Use-Case oder welche Annahme ungeprüft blieb. Lücken werden deklariert, nie verschwiegen.
Umsetzbarer Issue-Tracker
Ausgabe sind GitHub-Issues, angeführt von einem nach Priorität sortierten Tracking-Issue, jedes mit Management-Summary und Vorher/Nachher-Fix. Ein Befund, den du nicht umsetzen kannst, ist nur eine Meinung.
Beweise statt Behauptungen
Wir haben die ganze Suite auf das eigene Repo angesetzt
Die Bibliothek prüft sich selbst — angesetzt auf genau dieses Repo, mit dem Backlog als öffentliche GitHub-Issues. Diese Seite bekam ihr eigenes Content-Audit; über das ganze Repo erreichte jeder Prüfbereich A− bis A. Unten: das echte Backlog, die Noten und ein Befund in voller Tiefe.
- P1Kein sichtbarer Ergebnis-Beleg — predigt „Evidence“, liefert Prosa #100
- P1Aktivierungsbefehl lässt sich nicht kopieren #103
- P1„any AI agent“ — unbelegte Universalbehauptung #104
- P1End-CTA wiederholt den Hero, statt abzuschliessen #107
- P2„Google-grade“ — unbelegter Superlativ #113
- P3Hero-Badge „copy & paste“ doppelt den Subhead #122
Das echte Backlog aus dem Audit genau dieser Seite — 23 Befunde, jeder davon jetzt behoben.
Öffne ein Issue und prüfe den Beleg auf GitHub.
/de served <html lang="en">
- Beleg
- web/app/layout.tsx:71
- Vorher
- / and /de → <html lang="en">
- Nachher
- /de → <html lang="de">
Die Bibliothek
13 stack-agnostische Audits, eine gemeinsame Methodik
Jedes ist ein eigenständiger Master-Prompt: eine mehrphasige Spezifikation, keine einmalige „review my code“-Frage. Setz mehrere auf dasselbe Repo an — ihre Befunde fliessen ohne Doppelungen in einen einzigen, nach Priorität sortierten Tracker, weil jedes Audit demselben Issue-Vertrag folgt.
Zertifizierungs-Readiness
Audit-ready für SOC 2, ISO 27001, ISO 42001 und NIS2/CRA — direkt aus dem Repo.
Wähle ein Ziel, und der Orchestrator führt genau die Audits aus, die dieses Framework braucht. Jeder Befund trägt die Control-IDs, nach denen ein Auditor fragt, und fliesst in eine Gap-Matrix pro Control mit Readiness-Score. Kein Zertifikat — aber der schnellste ehrliche Weg dorthin.
READINESS_TARGET: soc2
SOC 2
Trust Services Criteria — Security, dazu Availability, Confidentiality, Processing Integrity und Privacy, wenn im Scope.
- Liefert
- Control-Gap-Matrix (CC1–CC9 und die Kategorien im Scope), Evidenz-Register, Readiness-Score.
READINESS_TARGET: iso27001
ISO/IEC 27001:2022
Annex A — die 93 Controls über die Themen Organisation, Personal, Physik und Technik.
- Liefert
- Gap-Matrix, Entwurf der Statement of Applicability, Risikoregister-Grundstock, Readiness-Score.
READINESS_TARGET: iso42001-ai-act
ISO/IEC 42001 + EU AI Act
Annex A des KI-Managementsystems plus die Pflichten des AI Act je Risikostufe.
- Liefert
- KI-System-Inventar mit Risikostufe, Gap-Matrix, Gerüst für das Impact Assessment, Readiness-Score.
READINESS_TARGET: nis2-cra
NIS2 + CRA
Die zehn Massnahmen aus NIS2 Art. 21 und die Produkt- und Schwachstellen-Anforderungen aus CRA Annex I.
- Führt aus
- securityinfrastructureleanrepodata
- Liefert
- Gap-Matrix, SBOM- und Disclosure-Readiness, Prüfung der Meldefähigkeit (24-h- und 72-h-Fenster).
Readiness, nicht Zertifizierung: Die Audits bewerten die technisch prüfbaren Controls und sammeln die Belege. Organisatorische Controls — Richtlinien, HR, physische Sicherheit — werden als „nicht prüfbar“ ausgewiesen, nie als fehlend. Schweizer revDSG und DSGVO ordnet das Compliance-Audit immer zu.
Zum Control-CrosswalkDie Methode
Sechs Phasen, jedes Mal
Recon, ein paralleler Spezialisten-Schwarm, dann adversarielle Verifikation, bevor irgendetwas in den Bericht kommt.
Audit using auditor.rapold.io
Du tippst — eine Zeile, jeder fähige Agent.
- 0
Reconnaissance
Faktisches Inventar + Oberflächen-Karte. Noch keine Meinungen.
- 1
Spezialisten-Schwarm
Viele Domänen-Experten parallel, jeder belegpflichtig.
securityaccessibilityperformancedata… · parallel - 2
Cross-Pollination
Zusammenführen, Doppelungen entfernen, Verbund-Befunde sichtbar machen.
- 3
Adversarielle Verifikation
Unabhängige Skeptiker widerlegen jeden P0/P1; ≥2 von 3 zum Überleben.
übersteht ≥2 von 3 - 4
Benchmark
Vergleich gegen benannte Best-in-Class-Referenzen und Standards.
- 5
Synthese
Bericht, Scorecard, Issues und eine 30/60/90-Roadmap.
Du bekommst — nach Priorität sortierte GitHub-Issues.
Die Massstäbe
Vier Massstäbe. Jeder Bericht daran gemessen.
Für sich allein nutzbar. Der eine bewertet 0–100 anhand einer Rubrik; der zweite legt die exakte Issue-Form fest — so bleiben zwei Durchläufe vergleichbar, auch wenn die generierte Formulierung abweicht; der dritte ordnet jeden Befund den Controls von SOC 2, ISO 27001, ISO 42001, NIS2, CRA und revDSG zu; der vierte macht aus jedem Lauf einen Bericht für die Geschäftsleitung und maschinenlesbare Exporte.
Sieh, was dein KI-Agent findet, wenn er jede Aussage belegen muss.
Es ist kostenlos und MIT-lizenziert. Setz es auf einem Wegwerf-Branch ein, lies Befunde, die 2-von-3 Skeptikern standhalten mussten, und behalte nur die Fixes, denen du zustimmst.
Jede Aussage hier hat dasselbe Audit überstanden — lies das öffentliche Backlog (#97).