chukaofili/agent-plugins

Verwendet, wenn ein PR-Stadium oder eine Funktion abgeschlossen ist und bevor der PR geöffnet wird; wenn Dateien, Pakete, Routen, Befehle, Umgebungsvariablen, APIs oder Konventionen hinzugefügt, umbenannt, verschoben oder entfernt wurden; oder wenn darum gebeten wird, „Dokumentation zu aktualisieren“, „Dokumentation zu synchronisieren“, „README/AGENTS.md zu aktualisieren“ oder gesagt wird, „die Dokumentation ist veraltet“. Prüft jedes Dokument gegen den Code, behebt Abweichungen, generiert generierte Dokumente neu und committed das Ergebnis in den aktuellen Branch.

Was ist agent-plugins?

Diese Fähigkeit synchronisiert die Dokumentation mit dem aktuellen Code, um Abweichungen (Drift) zu verhindern, die bei Änderungen an Dateien, Paketen, Routen, Befehlen, Umgebungsvariablen, APIs oder Konventionen auftreten. Sie wird nach jedem abgeschlossenen Feature oder jedem Stacked-PR-Stadium ausgeführt, bevor der PR geöffnet wird. Die Fähigkeit erstellt ein Inventar aller relevanten Dokumente in `docs/DOCS.md` (nicht in `AGENTS.md`), überprüft deren Behauptungen gegen den Code, bearbeitet Abweichungen, führt Generatoren für generierte Dokumente aus und committed die Änderungen atomar in den aktuellen Branch. Sie unterstützt Plattformen wie Claude Code und Cursor und ist besonders nützlich für Entwickler, die sicherstellen möchten, dass READMEs, API-Dokumentation und Konfigurationsdateien immer aktuell sind, ohne den Kontext eines Agenten dauerhaft zu belasten.

Funktioniert mit✓Claude Code~Codex CLI~Cursor✓Gemini CLI

npx skills add https://github.com/chukaofili/agent-plugins/tree/HEAD/plugins/coding-protocol/skills/sync-docs

Dokumentation

Dokumentation synchronisieren

Dokumentation driften leise ab. Nichts schlägt fehl, wenn eine README eine Datei nennt, die verschoben wurde. Führen Sie dies nach jedem gestapelten PR-Stadium oder abgeschlossenen Feature aus, bevor der PR geöffnet wird.

Der Vertrag dieser Fähigkeit beinhaltet das Committen. Sie kann ohne Nachfrage committen, immer in den aktuellen Branch, niemals main.

Wann überspringen

Nichts hat sich geändert, auf das ein Dokument verweist (reine interne Logik). Schreiben Sie dennoch im Abschnitt „Testen“ des PRs „Dokumentation geprüft, keine Abweichung“, damit der Reviewer weiß, dass es ausgeführt wurde.
Der Benutzer möchte noch keinen Commit der Dokumentation.

Das Inventar: `docs/DOCS.md`

Die Liste der relevanten Dokumente befindet sich in docs/DOCS.md, nicht in AGENTS.md, damit der ständig aktive Kontext nicht mit jeder Synchronisierung wächst.

# Dokumentationsinventar

| Pfad | Zuständig für | Generiert von |
|---|---|---|
| README.md | Pitch, Setup, Umgebungsvariablen, Layout | |
| AGENTS.md | Agentenregeln + Projekt-Gates | |
| packages/api/README.md | Endpunkte, Skripte, Umgebungsvariablen | |
| docs/api/openapi.json | API-Referenz | `pnpm generate:openapi` |

## Eingefroren (niemals durch eine Synchronisierung bearbeitet)
- docs/plans/

## Drift-Prüfungen
<!-- ein Grep pro Fehler, der tatsächlich aufgetreten ist, mit einem Kommentar, warum -->

Erster Durchlauf: Erstellen. Durchsuchen Sie nach root- und paketbezogenen README.md / AGENTS.md / CLAUDE.md, Mitwirkendendokumentation, API-Dokumentation (OpenAPI-Beschreibungen, llms.txt), Skills- und Rules-Verzeichnissen sowie Verweisen auf Umgebungsvariablen (.env.example, Konfigurationsschemata). Notieren Sie, wofür jedes zuständig ist.

Jeder Durchlauf: Ein Dokument, das Sie finden und das nicht aufgeführt ist, wird im selben Commit hinzugefügt.

Vorgehen

Prüfung. Vergleichen Sie den Branch mit seiner Basis (git diff <base>...HEAD --stat) und listen Sie auf, was sich geändert hat, das ein Dokument erwähnen könnte: Pfade, Paketnamen, Routen, Befehle und Skripte, Umgebungsvariablen, exportierte APIs, Verhalten, Konventionen.
Verifizierung. Überprüfen Sie für jedes Dokument im Inventar jede konkrete Behauptung gegen den Code: Jede benannte Datei existiert unter diesem Pfad, jeder Befehl existiert im Manifest, jede Umgebungsvariable wird tatsächlich gelesen, jede Route und jeder Export existiert wie beschrieben. Lesen Sie den Code; vertrauen Sie nicht dem Prosa, auch nicht dem Prosa, das Sie zuvor geschrieben haben.
Bearbeitung. Beheben Sie die Abweichung. Beschreiben Sie, was der Code tut, und erfinden Sie niemals Verhalten, um ein Dokument besser lesbar zu machen. Wenn Code und Dokument nicht übereinstimmen und Sie nicht sagen können, welches falsch ist, kennzeichnen Sie es, anstatt zu raten.
Neugenerierung. Führen Sie jeden im Inventar aufgeführten Generatorbefehl aus. Bearbeiten Sie niemals ein generiertes Dokument manuell.
Führen Sie die in docs/DOCS.md aufgeführten Drift-Prüfungen durch. Wenn eine Synchronisierung einen Fehler findet, der wahrscheinlich wieder auftritt (ein alter Pfad, ein umbenannter Befehl), fügen Sie einen Grep dafür mit einem Kommentar hinzu, warum.
Commit. Stagen Sie die Dateien nach Pfad, niemals git add -A. Machen Sie einen atomaren Commit, docs(<Scope>): sync <was> with <Änderung>, im aktuellen Branch.
Push, wenn der Branch bereits ein Remote verfolgt (git pull --rebase zuerst). Niemals auf main pushen.

Regeln

Eingefrorene Historie: Designs, Pläne und Übergaben in docs/plans/ sind Momentaufnahmen dessen, was zum Zeitpunkt der Entscheidung festgelegt wurde. Sie werden in Greps auftauchen; das ist erwartet, keine Abweichung. Bearbeiten Sie sie niemals in einer Synchronisierung.
Spikes und Prototypen werden gelöscht, sobald ihre Richtung ausgeliefert oder verworfen wurde, nicht als Referenz behalten. Die Schlussfolgerungen eines Spikes sind der unzuverlässigste Text im Repository, sobald die Produktion mehr weiß. Alles, was noch wissenswert ist, wird in die Dokumentation des ausgelieferten Codes übernommen.
Größenbudget: Dokumentenzeilen zählen zum PR-Budget. Wenn die Synchronisierung ein Stadium über 500 Zeilen bringt, landen Sie es als reinen Dokumentations-Stage oben auf dem Stapel (siehe stacked-prs).
Verweisdateien bleiben winzig. Eine CLAUDE.md oder GEMINI.md, die nur auf AGENTS.md verweist, sollte so bleiben. Kopieren Sie keinen Inhalt hinein.