Audit-Vorlage
documentation
Prüft deine Doku gegen den Standard und gegen den Code, der sie bestätigt oder widerlegt.
Zugeordnet zu: DOCUMENTATION-STANDARD · Diátaxis
So funktioniert dieses Audit
Spezialisten-Agenten gehen jede kritische Leser-Journey nur mit der Doku durch und prüfen dann jede Aussage an der Realität: Dokumentierte Commands werden gegen die Scripts ausgeführt, Env-Variablen mit dem Code abgeglichen, der sie liest, Code-Beispiele nachvollzogen oder ausgeführt. Bewertet werden Repo-Kopf, Onboarding, Doc-Code-Drift, Schreibstil und Diátaxis-Passung auf einer Rubrik von 0 bis 100 — jede Seite gemessen an dem Job, den sie erfüllen soll.
Wann du es einsetzt
Vor dem Open-Sourcing
Du machst ein Repo öffentlich, und das README ist die Eingangstür. Das Audit geht als neuer Leser den Weg vom Clone bis zum ersten grünen Test durch, nennt den genauen Schritt, an dem er hängenbleibt, und markiert fehlende Value-Line, Badge-Reihe, Management-Summary und Architektur-Diagramm.
Nach einem Refactor mit Umbenennungen
Ein Refactor hat Scripts, Env-Variablen und Modulpfade umbenannt, aber die Doku beschreibt noch die alten Namen. Das Audit testet dokumentierte Commands gegen die package.json, gleicht Env-Variablen mit dem Code ab, der sie liest, und .env.example mit der Realität — und liefert ein Drift-Register, das für jeden Treffer die Doku- und die Code-Zeile zitiert.
Übergabe eines Service an On-Call
Du gibst einem anderen Team den Pager für einen Service, den es nicht gebaut hat. Das Audit prüft Runbooks, Rollback-Schritte und Referenz-Doku an der echten Infra und der API-Oberfläche, sodass ein falscher Rollback-Schritt oder eine undokumentierte Pflicht-Config als P0/P1 auftaucht, bevor es um 3 Uhr nachts der Alarm tut.
Was du bekommst
Eine Rubrik-Scorecard mit Notenband plus ein Drift-Register und priorisierte GitHub-Issues, jedes mit einem Vorher/Nachher-Fix.