toyin-software-factory/audit

Ausgabestil (einfache Worte, keine Gedankenstriche, keine Bindestriche)

Schreibe alles, was dieser Skill produziert – Dateien und Nachrichten gleichermaßen – in einfacher, verständlicher Sprache. Sprich den Leser als du an, warm und direkt wie ein Kollege, und präsentiere jeden Schritt als Empfehlung, die er ausführen oder überspringen kann, niemals als Befehl. Behalte technische Begriffe bei, die eine echte Bedeutung haben; erkläre jeden in einfachen Worten. Verwende niemals einen Gedankenstrich oder Bindestrich als Satzzeichen: keinen Em Dash, keinen En Dash und keine zusammengesetzten Bindestrichwörter. Schreibe read only, nicht read-only. Sage es in einfachen Worten oder formuliere den Satz um. Code, Dateipfade, Befehlsflags und Werte, auf die andere Skills abgleichen, behalten ihre Bindestriche. Verwende kurze Sätze, Kommas oder Klammern. Klarheit ist besser als Cleverness.

Was dieser Skill tut

Der Kontext-Bootstrapper: Schreibt die AGENTS.md-Dateien, die jeder spätere Skill und jedes KI-Tool liest.

• Greenfield (noch kein Code): Frage nach Codierungsstandards, erstelle die root AGENTS.md aus den Antworten plus dem Build-Ansatz (Name und einzeiliges Prinzip) aus dem Scope-Header, falls /scope einen gesetzt hat. Läuft nachdem das Projekt mit dem gewählten Stack gerüstet wurde (/scope → /architect entscheidet den Stack → Gerüst → /audit); früher ist verfrüht.
• Brownfield, undokumentiert (Code, keine AGENTS.md): Scanne das gesamte Projekt, schreibe root AGENTS.md und verschachtelte <bereich>/AGENTS.md-Dateien und beurteile, was global (root) vs. bereichsspezifisch (verschachtelt) ist.
• Brownfield, teilweise dokumentiert: Überprüfe vorhandene root und verschachtelte Dokumente mit der gesamten Codebasis; füge nur das hinzu, was fehlt (neue globale Fakten, verschachtelte Dokumente für undokumentierte Bereiche); überschreibe niemals kuratierte Inhalte.

Erstellt keine Spezifikationen (/architect ist dafür zuständig), pflegt keine Dateien nach Änderungen (/sync ist dafür zuständig) und schreibt keinen Feature-Scope (/scope ist für docs/scope/ zuständig).

Kontextdatei-Konvention (AGENTS.md ist kanonisch)

Dauerhafter Kontext lebt in der tool-agnostischen AGENTS.md (root und verschachtelt); jeder Agent (Codex, Cursor, Claude Code und andere) liest sie. CLAUDE.md ist nur ein einzeiliger Verweis, dessen gesamter Körper die benachbarte AGENTS.md über den @-Import von Claude Code importiert (genauer Verweiskörper in agent-prompt.md); Inhalte werden niemals zwischen den beiden dupliziert.

• Schreibe Wissen in AGENTS.md. Erstelle sie, wenn sie fehlt. Überschreibe niemals eine vorhandene AGENTS.md (sie könnte vom Benutzer oder Tool erstellt worden sein); fülle Lücken konservativ und mit Erlaubnis.
• Migriere Legacy-Inhalte: Eine CLAUDE.md mit Inhalt, aber ohne AGENTS.md → Frage um Erlaubnis, verschiebe ihren Inhalt in eine neue AGENTS.md, ersetze CLAUDE.md durch den Verweis. Verwerfe niemals stillschweigend kuratierte Inhalte.
• Root bleibt kurz und global; verschachtelte AGENTS.md nur für aussagekräftige Bereiche mit echten Konventionen (gleiche Root/Nested-Regeln wie zuvor für CLAUDE.md).

Umfang

Ein Bereichspfad-Argument (z. B. auth, src/payments) löst Phase 3 aus. Ohne Argument leiten die unten aufgeführten Pre-flight-Signale zu Phase 0 (mehrdeutig: frage neu vs. bestehend), Phase 1 (Greenfield: frage nach Standards, erstelle Root), Phase 2 (etabliert, keine root AGENTS.md: Ganzes Repo scannen) oder Phase 4 (root AGENTS.md vorhanden: Lücken füllen). Eine Legacy-CLAUDE.md mit Inhalt, aber ohne AGENTS.md wird migriert und dann wie Phase 4 behandelt.

Handlungen vs. Fragen

Phase 1 stellt Fragen zu Codierungsstandards per MCQ, bevor sie die root AGENTS.md erstellt. Phase 2 handelt sofort, keine Fragen; sie schreibt die root und die verschachtelten Dokumente, die sie für gerechtfertigt hält. Die Phasen 3 und 4 handeln, um zu erkunden, fragen aber um Erlaubnis, bevor sie eine vorhandene root AGENTS.md ändern oder eine Legacy-CLAUDE.md migrieren; Phase 4 meldet die Erstellung verschachtelter Dokumente für undokumentierte Bereiche zuerst und wendet sie dann nach Bestätigung an.

Artefakt-Eigentümerschaft

Die AGENTS.md-Dateien enthalten den Inhalt: erstelle root, wenn sie fehlt (Phase 1, 2) und <bereich>/AGENTS.md, wenn sie fehlt und gerechtfertigt ist, nach Ermessen (Phase 2, 3, 4); wenn eine vorhanden ist, fülle Lücken oder schlage Ergänzungen mit Erlaubnis vor; überschreibe niemals. Die CLAUDE.md-Dateien sind nur Verweise (root und Bereich), die erstellt werden, wenn sie fehlen; eine Legacy-Datei mit Inhalt wird mit Erlaubnis in AGENTS.md migriert. Wenn du eine verschachtelte AGENTS.md erstellst, füge genau eine Verweiszeile zur root AGENTS.md unter ## Context files hinzu: - [<bereich>/AGENTS.md](<bereich>/AGENTS.md) (<einzeilige Beschreibung>). Niemals eine pro Unterordner, nur dort, wo unterschiedliche Konventionen existieren.

Portabilität (jedes Betriebssystem, jeder Agent)

• Befehle: git ist das einzige erforderliche CLI, auf jedem Betriebssystem gleich. Andere Shell-Schnipsel (Dateianzahl, find, [ -f ]) sind POSIX-Referenzen, keine wörtlichen Skripte; verwende die plattformübergreifenden Dateiwerkzeuge deines Agenten (Suche/Glob, Lesen, Schreiben), um aufzulisten, zu zählen und das Vorhandensein zu prüfen.
• Gebündelte Dateien leben im Ordner dieses Skills: agent-prompt.md, die Phasenmodus-Dateien (modes/*.md) und die Pattern-Voreinstellungen (patterns/*.md). Löse den Ordner zu einem absoluten Pfad auf. Lese die entsprechende Phasenmodus-Datei beim Routing, dann agent-prompt.md plus die AUSGEWÄHLTE Pattern-Voreinstellung zum Zeitpunkt des Schreibens. Die GROSSBUCHSTABEN-Platzhalter (PHASE, AREA, ADDITIONAL_STANDARDS, MONOREPO_OR_NO, INSTALLED_SKILLS, DECLINED_TOOLS usw.) sind die Eingaben, die du im Pre-Flight und in den Fragerunden gesammelt hast; wende jede beim Lesen an.
• Keine Unterstützung für interaktive Fragen? Stelle jede Multiple-Choice-Frage als Klartext mit denselben Optionen.

Ausführung

Der Haupt-Thread führt das Schreiben in jeder Phase durch; er übergibt das Schreiben von AGENTS.md niemals an einen Subagenten. Der einzige Subagent ist ein schreibgeschützter scout (günstigstes Modell, Claude Code: haiku, niemals das Sitzungsmodell), der nur für einen großen Scan erzeugt wird; er gibt eine kompakte Map zurück, von der der Haupt-Thread schreibt. Ein kleines Gerüst oder ein einzelner Bereich benötigt keinen scout; lese es direkt. Unmittelbar vor dem Schreiben lese agent-prompt.md (Persona, phasenspezifische Anweisungen, Vorlagen) plus, in Phase 1, die ausgewählte Pattern-Voreinstellung; dann schreibe entsprechend. Lese agent-prompt.md nur zum Zeitpunkt des Schreibens, nicht während des Pre-Flight.

Pre-Flight (Haupt-Thread macht dies vor allem anderen)

Sammle mehrere Signale (eine Dateianzahl allein täuscht: ein Gerüst bläht sie auf, eine unbekannte Sprache macht sie zu null):

1. Kontextdateien: root AGENTS.md vorhanden → ROOT_EXISTS; eine CLAUDE.md nur mit Inhalt → ROOT_LEGACY; keines → ROOT_MISSING.
2. Quellcode-Anzahl über gängige Ökosysteme (Erweiterungen wie .ts/.tsx/.js/.jsx/.py/.go/.rs/.java/.rb/.swift/.kt/.php/.cs/.dart/.ex/.exs/.scala/.c/.cpp/.h/.lua/.clj), ohne ausgelagerte/generierte Verzeichnisse (node_modules, .git, dist, build) und Konfigurationsdateien (*.config.*).
3. Etablierungssignale: git log --oneline für die Tiefe der Commit-Historie; ein echtes Manifest (package.json, pyproject.toml, go.mod, Cargo.toml, composer.json, *.csproj, pubspec.yaml, mix.exs, Gemfile).
4. Monorepo-Signal: Workspace-Marker (pnpm-workspace.yaml, turbo.json, ein "workspaces"-Feld in package.json) oder irgendwelche apps/*/package.json / packages/*/package.json nahe der Wurzel.
5. Workflow-Einrichtungssignal (WORKFLOW_SETUP): root AGENTS.md FEHLT, während der Workflow den Stack bereits entschieden hat, d.h. eine Architekturspezifikation in docs/specs/ existiert (ein Abschnitt ## Proposed stack) und/oder docs/scope/ ein "Stack und Architektur"-Feature (oder ähnliches grundlegendes Gerüst) enthält. Dies ist die beabsichtigte Greenfield-Reihenfolge (/scope → /architect entscheidet den Stack → /develop rüstet ihn → /audit): frisch gerüstet, benötigt noch Codierungsstandards. Wenn dies ausgelöst wird, sind das Manifest und die Gerüstquellen, die jetzt existieren, das Gerüst, nicht eine vorhandene Codebasis.

Wähle die Phase. Die Reihenfolge der Prüfungen ist wichtig: das Workflow-Einrichtungssignal übertrifft die reine Codeanzahl, da ein frisches Gerüst ein Manifest und Quelldateien hat, aber dennoch Greenfield ist.

Bedingung	Phase
Bereichspfad als Argument gegeben	Phase 3
ROOT_EXISTS (oder ROOT_LEGACY nach Migration)	Phase 4
ROOT_MISSING und WORKFLOW_SETUP (Stack-Spezifikation und/oder Scope-Stack-Feature)	Phase 1, obwohl jetzt ein Manifest und Gerüstquellen existieren. Frage nach Codierungsstandards; erstelle Root aus dem Stack der Spezifikation. Behandle ein gerade gerüstetes Workflow-Projekt niemals als Brownfield.
ROOT_MISSING, kein WORKFLOW_SETUP, keine Quelldateien UND kein Manifest	Phase 1
ROOT_MISSING, kein WORKFLOW_SETUP, hat Code (Quelle ≥ 10 oder ein Manifest), ≥ 2 Commits und eindeutig echten Feature-Code (nicht nur Gerüst)	Phase 2, jede Sprache
ROOT_MISSING, kein WORKFLOW_SETUP, hat Code, sieht aber wie unberührtes Gerüst aus, oder ≤ 1 Commit, oder du kannst Greenfield nicht von Brownfield unterscheiden	Phase 0, frage

Warum diese Reihenfolge: Ein frisches Gerüst hat ein Manifest und Startdateien, ist aber immer noch Greenfield, daher würde eine reine Codeanzahl es fälschlicherweise als Brownfield einstufen und die Standards-Fragen überspringen; das Workflow-Einrichtungssignal fängt das ab und leitet zu Greenfield weiter. Echtes Brownfield (Phase 2) bedeutet echten Feature-Code, echte Historie und keinen laufenden Workflow-Setup. Alles Mehrdeutige fällt in Phase 0; setze ein mögliches Greenfield-Projekt niemals standardmäßig auf Brownfield.

Monorepo (MONOREPO=ja): Root plus einen leichten Stub pro Workspace, vertiefe bei Bedarf. Jeder Workspace (apps/*, packages/*) ist ein erstklassiger Bereich; sein primäres Dokument lebt im Workspace-Root (packages/api/AGENTS.md), niemals tiefer vergraben. Ein Ganzes-Repo-Lauf scannt nicht jeden Workspace tief; schreibe die Repo-Root-AGENTS.md (Monorepo-weite Werkzeuge, gemeinsame Konventionen) plus einen leichten Stub pro Workspace aus seinem Manifest, ohne Code-Scan, mit Root-Verweisen. Der vollständige Scan von Konventionen/gotchas/Schlüsseldateien erfolgt, wenn der Entwickler /audit packages/api (Phase 3) ausführt oder dort zum ersten Mal baut. Eine Stelle innerhalb eines Workspace, die ein eigenes Dokument rechtfertigt (packages/ui/src/mdx/), erhält eines zusätzlich zum Workspace-Root-Dokument, das von dort verlinkt wird. Ein Dokument, das bereits in einem Workspace vergraben ist, ohne Workspace-Root-Dokument: frage: "packages/ui hat eine Kontextdatei unter src/mdx/, aber keine im Root. Soll ich sie nach packages/ui/AGENTS.md verschieben oder als verschachteltes Dokument unter einer neuen packages/ui/AGENTS.md behalten?" Beim Verschieben: platziere es im Workspace-Root. Beim Behalten als verschachtelt: erstelle das Workspace-Root AGENTS.md UND behalte das tiefe Dokument, verlinkt vom Root. Migriere Legacy-CLAUDE.md-Inhalt gemäß der obigen Konvention. Wende MONOREPO=ja plus die Workspace-Liste beim Schreiben an.

Legacy-Migration (jede Phase): bei ROOT_LEGACY, frage vor dem Fortfahren um Erlaubnis: "Ich habe eine CLAUDE.md mit Projektkontext gefunden, aber keine AGENTS.md. Ich werde den Inhalt in eine neue AGENTS.md verschieben (damit alle Tools sie lesen) und die CLAUDE.md durch einen Verweis ersetzen. Fortfahren?" Bei Ja: kopiere den Inhalt wörtlich in AGENTS.md, ersetze dann CLAUDE.md durch den Verweis; AGENTS.md existiert jetzt, also fahre fort als Phase 4 (Lücken füllen). Bei Nein: lasse beide unberührt und fahre ohne Migration fort. Gleiches gilt für jede verschachtelte <bereich>/CLAUDE.md.

Route zur ausgewählten Phase

Phase 0 (mehrdeutig) wird unten inline behandelt. Für die Phasen 1 bis 4 lese nur die passende Modus-Datei und folge ihr:

• Phase 1 (Greenfield-Setup) → modes/greenfield.md
• Phase 2 (Ganzes-Repo-Scan) → modes/whole-repo.md
• Phase 3 (Bereichsscan) → modes/area.md
• Phase 4 (Lücken füllen) → modes/gapfill.md

Lese die anderen Modus-Dateien nicht. Die Greenfield- und Ganzen-Repo-Modi lesen zusätzlich modes/tool-skills.md für den Agent Skills / MCP-Durchlauf (überspringe dies für Bereichs- und Lückenfüllungs-Läufe).

Phase 0: Klassifizieren (nur wenn Pre-Flight mehrdeutig ist)

Rate nicht. Frage einmal über den interaktiven Optionsauswähler deines Agenten (AskUserQuestion auf Claude Code) oder als Klartext mit denselben Optionen. Markiere eine Option (empfohlen) basierend auf dem stärkeren Signal (ein gerüstartiger Baum mit einem Manifest, aber wenig Historie tendiert zu Neu; echter Feature-Code und tiefe Historie tendiert zu Bestehend), und der Auswähler fügt einen letzten freien Textplatz hinzu:

• Frage: "Ich kann nicht sagen, ob dies ein neues Projekt oder eine bestehende Codebasis ist (<begründe warum: z. B. 'ein Manifest existiert, aber ich sehe keine Quelle in einer Sprache, die ich erkenne' oder 'Dateien sehen aus wie unberührtes Gerüst'>). Welches ist es?"
• Kopfzeile: "Projektstatus"
• Optionen: 1. Neues Projekt, "Ich werde nach deinen Codierungsstandards fragen und den Kontext erstellen." → Phase 1 (lese das Manifest/Gerüst für den Stack; frage trotzdem nach Standards). 2. Bestehende Codebasis, "Ich werde scannen, was hier ist, und es dokumentieren." → Phase 2.

Nach allen Phasen

Wenn keine AGENTS.md geschrieben wurde, obwohl sie hätte geschrieben werden sollen (die Datei fehlt/ist leer), melde den Fehler und mache es noch einmal; gib keinen Erfolg weiter, der nicht eingetreten ist. Andernfalls gib den Bericht weiter: was entdeckt wurde (2 bis 4 Aufzählungspunkte), was geschrieben wurde (Dateipfade), was vorgeschlagen oder übersprungen wurde (wenn vorhandene Dateien gefunden wurden).

Pattern-Voreinstellungen

Siehe patterns/ für die vier Codierungsstil-Voreinstellungen, die in Phase 1 (Greenfield-Modus) verwendet werden.

Schreibleitfaden

Siehe agent-prompt.md (der Haupt-Thread liest es zum Zeitpunkt des Schreibens; seine phasenspezifischen Anweisungen und AGENTS.md-Vorlagen).