Docs-Drift-Check

Docs Drift Check

Stelle fest, ob ein Branch oder Diff wahrscheinlich zu Dokumentations-Abweichungen geführt hat, und zeige dann die genauen Dokumentationsdateien und Begriffe an, die überprüft werden sollten. Dieser Skill sollte sich auf konkrete Beweise aus dem Diff stützen, nicht auf allgemeine Spekulationen.

Verwende diesen Skill, wenn

• Der Benutzer fragt, ob ein Branch, PR oder eine lokale Änderung wahrscheinlich Dokumentations-Updates benötigt.
• Der Diff öffentlich sichtbares Verhalten ändert, wie z. B. API-Routen, CLI-Flags, Umgebungsvariablen, Konfigurationsschlüssel, Setup-Schritte oder Datei-/Modulnamen, die in der Dokumentation referenziert werden könnten.
• Die Aufgabe darin besteht, README, docs/, examples/, Onboarding- oder Setup-Dokumentation auf Abweichungen zu prüfen.

Verwende diesen Skill nicht für reine Stiländerungen, Test-Änderungen oder offensichtlich interne Refaktorisierungen ohne sichtbare Verhaltensänderung.

Schnellstart

1. Führe das Hilfsskript aus: bash .agents/skills/docs-drift-check/scripts/docs_drift_check.sh [base-ref]
2. Lies zuerst die Abschnitte mit der höchsten Signalstärke:
   • Potential renames
   • Likely env var changes
   • Likely CLI flag changes
   • Likely route or endpoint changes
   • Likely config changes
3. Untersuche die wahrscheinlichsten Dokumentationsziele:
   • README.md
   • docs/
   • examples/
   • Setup- oder Onboarding-Dokumente in der Nähe der betroffenen Funktion
4. Gib ein kurzes Ergebnis zurück mit:
   • Risikostufe: low, medium oder high
   • konkreten Beweisen aus dem Diff
   • wahrscheinlich betroffenen Dokumentationsdateien
   • empfohlenen Änderungen oder Patch-Plan

Arbeitsablauf

1. Referenz festlegen

• Bevorzuge einen vom Benutzer angegebenen Basis-Referenz.
• Falls keiner angegeben ist, verwendet das Hilfsskript standardmäßig main.
• Falls der Basis-Referenz fehlt, teile dies klar mit und frage nach dem korrekten Branch oder Vergleichsziel.

2. Dokumentationssensitive Änderungen identifizieren

Konzentriere dich auf Änderungstypen mit hohem Signalgehalt:

• Umgebungsvariablen
• CLI-Flags und -Befehle
• API-Routen oder Endpunkte
• Konfigurationsschlüssel
• Umbenannte Dateien oder Module
• Setup- oder Onboarding-Schritte

Verwende das Hilfsskript für einen deterministischen ersten Durchlauf und prüfe den Diff bei Bedarf manuell.

3. Code-Änderungen mit der Dokumentation vergleichen

• Durchsuche die Dokumentation nach alten und neuen Namen, Pfaden, Flags, Routen und Konfigurationsbegriffen.
• Bevorzuge Dokumentation, die dem geänderten Bereich am nächsten liegt, bevor du das gesamte Repository durchsuchst.
• Lies references/heuristics.md, wenn du die Bewertungsmatrix oder die Ausgabeform benötigst.

4. Ergebnis klassifizieren

• low: Dokumentation ist wahrscheinlich in Ordnung, oder nur schwache Signale ohne veraltete Referenzen gefunden
• medium: mögliche Abweichung, oder starke Änderungen an der öffentlichen Oberfläche ohne bestätigte veraltete Dokumentation
• high: wahrscheinliche oder bestätigte Abweichung mit spezifischen veralteten Begriffen, Pfaden oder fehlenden Anweisungen

5. Ausgabe kurz halten

Verwende dieses Format:

1. Risikostufe
2. Begründung
3. Betroffene Dokumentationsdateien
4. Empfohlene Änderungen

Regeln

• Bevorzuge deterministische Beweise aus dem Diff vor semantischen Vermutungen.
• Bezeuge keine bestätigte Abweichung, es sei denn, du kannst auf eine konkrete veraltete Referenz, eine fehlende Dokumentationsaktualisierung oder einen umbenannten Pfad verweisen.
• Falls die Beweise unvollständig sind, sage mögliche Abweichung, anstatt die Sicherheit zu übertreiben.
• Ignoriere reine Formatierungs-, Kommentar- und Test-Änderungen, es sei denn, sie verändern das benutzersichtbare Verhalten.
• Halte das Ergebnis kurz und handlungsorientiert.