$docdiet
Verwenden Sie dieses Skill nur, wenn der Benutzer explizit eine Dokumentationsüberprüfung, -bereinigung oder -aktualisierung anfordert (normalerweise durch Aufruf von $docdiet). Es ist ein eigenständiges, bedarfsgesteuertes Überprüfungs-/Aktualisierungs-Skill, kein automatischer, aufgabenbezogener Hook. Überprüfen oder aktualisieren Sie nur den vom Benutzer genannten oder durch die angeforderte Änderung eindeutig offengelegten Dokumentationsumfang; beginnen Sie keine unabhängige Prüfung.
Eine explizite Anforderung wie $docdiet all docs oder $docdiet projektweit autorisiert eine begrenzte, projektweite Durchführung. In diesem Modus ist der Umfang auf Dokumentationsdateien unter dem Repository-Stammverzeichnis mit den Erweiterungen .md, .mdx, .rst oder .adoc sowie auf README*- und CONTRIBUTING*-Dateien auf Stammebene beschränkt. Schließen Sie generierte oder eingekaufte Verzeichnisse und Dateien, Änderungsprotokolle/Release-Notes, Lizenzen oder Rechtsmaterialien, Verhaltenskodizes und durch das Repository geschützte Dateien aus. Die Suche ist auf eine einzige rg --files-Auflistung mit diesen Erweiterungen und Ausschlüssen beschränkt, begrenzt auf 200 Pfade; prüfen Sie nur die von dieser Auflistung zurückgegebenen Pfade. Verwenden Sie höchstens eine zusätzliche, genaue, pfadbeschränkte rg -l -F-Referenzsuche für ein geändertes öffentliches Konzept. Wenn die Begrenzung oder die Suchgrenze erreicht wird, melden Sie den nicht überprüften Rest, anstatt den Umfang zu erweitern.
Entscheidungsregeln
- Zuerst den Umfang prüfen. Wenn keine Dokumentationsdatei oder kein Abschnitt genannt wird, keine Dokumentation berührt wird und keine öffentliche Umbenennung/Entfernung einer Referenzprüfung bedarf, stoppen Sie. Untersuchen Sie nicht die Dokumentation, um zu entscheiden, ob Sie die Dokumentation untersuchen sollen.
- Die kanonische Quelle bearbeiten. Dokumentieren Sie nur dauerhafte Informationen, die Entwickler, Benutzer, Betreiber oder Maintainer benötigen: Verträge, Einrichtung, Konfiguration, Betrieb, Einschränkungen, Invarianten, nicht offensichtliches Verhalten, Migrationen und kritische Warnungen. Lassen Sie Implementierungsdetails, temporäre Zustände, Debugging-Verlauf, abgeleitete Fakten und Zusammenfassungen der Fertigstellung weg.
- Ersetzen, nicht anhäufen. Aktualisieren Sie die vorhandene Erklärung, entfernen Sie veralteten Text und verlinken Sie auf eine kanonische Quelle, wenn ein anderes Dokument einen Verweis benötigt. Behalten Sie historische Details nur für Migration, Kompatibilität oder Architekturbegründung.
- Bereinigung lokal halten. Während der Bearbeitung einer Dokumentationsdatei bereinigen Sie nur den berührten Abschnitt und nahen Text, der eindeutige Anzeichen von Veraltetheit, Duplizierung, Widersprüchlichkeit, Überholtheit, Irreführung, unnötiger Ausführlichkeit oder Bindung an das geänderte/entfernte Konzept aufweist. Wenn die Beweise eine erhebliche Untersuchung erfordern, lassen Sie es in Ruhe.
- Referenzsuchen begrenzen. Für ein umbenanntes, entferntes oder geändertes öffentliches Konzept ist höchstens eine genaue, pfadbeschränkte Suche erlaubt. Bevorzugen Sie
rg -l -Fmit Dokumentations-Globs und melden Sie Dateinamen, keine vollständigen übereinstimmenden Zeilen. Außerhalb des oben genannten expliziten projektweiten Modus inventarisieren Sie keine nicht verwandten Dokumente, durchsuchen Sie keine Dokumentationsbäume, führen Sie keine repositoryweiten Linkprüfungen durch, untersuchen Sie keine nicht verwandten Verläufe und erstellen Sie keinen Bereinigungsagenten. - Dateien selten erstellen. Fügen Sie eine Dokumentationsdatei nur für dauerhafte, eindeutige Informationen hinzu, für die aus der Aufgabe bereits kein geeignetes kanonisches Zuhause bekannt ist.
Schutz
Generierte Dokumentation, Änderungsprotokolle/Release-Notes, Lizenzen oder Rechtsmaterialien, Verhaltenskodizes, eingekaufte/Drittanbieter-Dokumentation oder durch das Repository geschützte Dateien nicht opportunistisch umschreiben. Respektieren Sie Repository-Anweisungen und bewahren Sie sinnvolles Frontmatter und Metadaten.
Wenn eine Markdown-Datei Folgendes enthält:
---
disable-agentic-editing: true
---
ändern Sie diese nicht, es sei denn, der Benutzer fordert diese Datei explizit an. Diese Markierung ist eine docdiet-Konvention: Kein Tool erzwingt sie, Repository-Anweisungen können ihren Schutz nicht aufheben, und nur eine explizite Anforderung für diese Datei hebt ihn auf. Prüfen Sie den Schutz nur für Kandidatendateien; durchsuchen Sie nicht das Repository nach Markierungen.
Abschluss
Wenn Dokumentation berührt wurde, überprüfen Sie statisch nur die berührte Datei/den berührten Abschnitt: Das endgültige Verhalten wird dort dokumentiert, wo es benötigt wird, veralteter Text wurde nur mit Belegen entfernt, Beispiele und Befehle stimmen noch mit der Implementierung überein, und geschützter Inhalt wurde nicht geändert. Im projektweiten Modus wenden Sie diese Prüfungen auf jede berührte Datei an; erweitern Sie die Validierung nicht zu einer repositoryweiten Link- oder Beispielprüfung. Führen Sie Beispiele oder Befehle nicht aus, es sei denn, die Implementierungsaufgabe erfordert dies bereits. Dann stoppen Sie.
Dokumentieren Sie, was Bestand hat. Ersetzen Sie, anstatt anzuhäufen. Bereinigen Sie, was die Aufgabe offenlegt. Jagen Sie nicht.