Communitygithub.com

Celestia-Milara/skills

Erstellen, überprüfen, pflegen, fortsetzen und abschließen von Subsystem-Dokumentation, Änderungsentwürfen und Plänen; überprüfen, wie menschenlesbare Entwürfe mit technischen Materialien zusammenhängen. Verwenden, wenn der Benutzer die Organisation dieser Materialien anfordert, die Arbeit die Bewahrung von Entwurfs- und Ausführungskontext über die Zeit erfordert oder Änderungen bestehende Dokumentation, Pläne, Status oder Navigation ungenau machen. Prüfen Sie Quellcode, Tests und relevante Entscheidungen nach Bedarf; unterscheiden Sie aktuellen Zustand, Ziele, offene Fragen und tatsächliche Verifikation; bewahren Sie eine einzige Quelle der Wahrheit. Dies ist keine verpflichtende Phase für jede Entwicklungsaufgabe.

Was ist skills?

Diese Fertigkeit (Skill) verwaltet die gesamte Lebensdauer von Subsystem-Dokumentation, Änderungsentwürfen, Entscheidungsnotizen und Übergabedokumenten. Sie stellt sicher, dass menschenlesbare Entwürfe mit technischen Materialien wie Quellcode, Tests und Notizen konsistent bleiben, und bietet Richtlinien für die Entscheidung, wann neue Aufzeichnungen erstellt oder vorhandene wiederverwendet werden sollen. Sie unterstützt CI/CD-umgebende Plugins und Befehle wie `to-docs`, `grilling`, `decision-notes` und `handoff`, die in der Konfiguration des Projekts verfügbar sind. Der Skill vermeidet zirkuläre Aufrufe zwischen Skills und stellt sicher, dass Fakten an einem einzigen Ort gepflegt werden, während an anderer Stelle darauf verwiesen wird. Er betont die Unterscheidung zwischen festgelegten Schlussfolgerungen und ungelösten Punkten, die Aufrechterhaltung einer genauen Verknüpfung zwischen Quellen und die Vermeidung übermäßiger Dokumentation, wenn der Umfang der Änderung gering ist. Er ist besonders nützlich für die Aufrechterhaltung von Kontext über Sitzungen hinweg, die Verfolgung von Änderungszielen und die Sicherstellung einer reibungslosen Übergabe zwischen verschiedenen Agenten oder Entwicklern.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Celestia-Milara/skills/tree/HEAD/maintenance-docs

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Wartungsdokumente

1. Zuständigkeiten und aktuellen Umfang klären

Verwenden Sie diesen Skill, um zu entscheiden, ob Aufzeichnungen erstellt oder wiederverwendet, Inhalte organisiert, Beschreibungen überprüft, Lücken aufgedeckt und Quellenbeziehungen, Status und Navigation gepflegt werden sollen. Dies erfordert technisches Urteilsvermögen: Untersuchen Sie tatsächliche Pfade, wenn Sie aktuelle Mechanismen erklären; formatieren Sie nicht nur das Gespräch um oder erzeugen Sie falsche Sicherheit durch das Ausfüllen von Vorlagen.

  • Der Agent, der die aktuelle Aufgabe ausführt, ist für technische Entscheidungen, Kompromisse, Aufgabenaufteilung, Implementierung, Fehlersuche und Verifikation zuständig; verwenden Sie diese gemeinsamen Regeln, wenn Ergebnisse aufbewahrt werden müssen. Gezielte Untersuchung und Aktualisierung von Subsystem-Dokumentation sind gültige Aufgaben und erfordern nicht, zuerst einen separaten Entwurfsprozess zu starten.
  • Verwenden Sie to-docs, um lesbare Entwurfsergebnisse zu erstellen, die Personen später überprüfen, bearbeiten und referenzieren können. Ein menschenlesbarer Entwurf kann die vollständige Quelle sein; dieser Skill leitet die Dokumentenverantwortung und -konsistenz ab dem Zeitpunkt der Speicherung. Verlangen Sie nicht zuerst einen technischen Datensatz oder erzeugen Sie zirkuläre Aufrufe zwischen Skills.
  • Verwenden Sie grilling, um das aktuelle Thema eingehend zu klären; grill-me ist der explizite Einstiegspunkt. Fahren Sie mit etablierten Inhalten fort, ohne Entscheidungen wieder zu öffnen oder für jede Iteration Genehmigungshürden hinzuzufügen.
  • Verwenden Sie decision-notes, um langfristige Entscheidungen zu finden, aufzuzeichnen, zu ersetzen und zu organisieren. Dieser Skill referenziert seine Schlussfolgerungen; er etabliert keinen separaten Interviewprozess oder Entscheidungslebenszyklus. Suchen Sie, wenn seine Auslösebedingungen zutreffen, auch wenn es keinen direkten Link gibt.
  • Verwenden Sie handoff nach Bedarf, um eine Übergabe über Sitzungen oder Agenten hinweg vorzubereiten oder zu überprüfen. Dieser Skill pflegt weiterhin technische Materialien und Status; erstellen Sie kein vollständiges Duplikat, nur weil die ausführende Person gewechselt hat, und erzeugen Sie keine zirkulären Aufrufe zwischen Skills.
  • Normales Lesen, unmittelbare Fragen und kleine Änderungen, die vorhandene Materialien nicht betreffen, lösen nicht eigenständig den vollständigen Wartungsprozess aus; lesen Sie dennoch die für die Aufgabe benötigten Materialien. Eine reine Dokumentationsanfrage erweitert nicht die Berechtigung, Produktverhalten zu ändern, unabhängige Prüfungen durchzuführen oder Code zu committen; die bestehende Autorisierung für technische Aufgaben bleibt in Kraft.

Verwenden Sie die tatsächlich in der Umgebung verfügbaren Namen. Wenn ein Skill nicht aufgerufen werden kann, lesen Sie stattdessen die konfigurierte Anleitung des Projekts; behaupten Sie nicht, einen nicht verfügbaren Skill aufgerufen zu haben. Zusammenarbeit darf nicht zu zirkulärem Laden oder doppelten Suchen führen.

2. Quellen lokalisieren und über Wiederverwendung oder Neuerstellung von Aufzeichnungen entscheiden

Beginnen Sie am tatsächlichen Agenten-Einstiegspunkt des Projekts, um Einschränkungen, Anforderungen und Akzeptanzkriterien, relevante Subsysteme, Änderungsaufzeichnungen und Notizen zu lokalisieren; überprüfen Sie den Umfang der aktuellen Arbeit. Für bestehende Projekte bevorzugen Sie vorhandene Speicherorte und Namen; verlangen Sie keine Migration. Für subsystemübergreifende Arbeit decken Sie relevante Schnittstellen und gemeinsame Einschränkungen ab.

Verwenden Sie bereits gelesenen und verifizierten Kontext für dieselbe Aufgabe wieder, wenn er noch zutrifft. Wenn sich der Umfang, eine Schlüsselannahme oder eine Quelle ändert oder ein Konflikt auftritt, überprüfen Sie die betroffenen Bereiche erneut. Scannen Sie nicht das gesamte Repository erneut oder starten Sie ein Interview neu, nur weil sich der Durchlauf oder der Skill geändert hat.

Bei der Wahl von Speicherorten, Namen, Dateiaufteilungen oder Navigation lesen Sie Organisation und Quellen.

  1. Suchen Sie zuerst nach vorhandener Dokumentation, die noch für dieselbe Änderung gilt; ein ähnliches Thema bedeutet nicht unbedingt dieselbe Änderung. Um vorhandene Arbeit fortzusetzen, lokalisieren Sie deren ursprüngliche Aufzeichnung und überprüfen Sie den aktuellen Zustand, anstatt automatisch ein vollständiges Übergabedokument zu schreiben.
  2. Erstellen oder aktualisieren Sie Aufzeichnungen, wenn Zielentwürfe, Migrationspläne, Abhängigkeiten oder zu untersuchende/verifizierende Fragen für die spätere Implementierung, Abnahme oder sitzungsübergreifende Fortsetzung aufbewahrt werden müssen. Dies gilt auch während der Untersuchung und des Lösungsvergleichs.
  3. Kleine, klare Änderungen, die im aktuellen Durchlauf abgeschlossen werden, können im Gespräch allein übermittelt werden, während gleichzeitig betroffene bestehende Dokumentation und Notizen gemäß den festgelegten Regeln gepflegt werden. Wenn der Benutzer explizit bittet, etwas zu speichern, zeichnen Sie es auf, bevorzugen Sie eine geeignete vorhandene Quelle.
  4. Erstellen Sie nicht mechanisch Aufzeichnungen basierend auf Zeilenanzahl, Dateianzahl, Gesprächsdurchläufen oder Commit-Anzahl. Erstellen Sie keine leeren Seiten oder eine vollständige Dokumentationsbibliothek im Voraus, und fragen Sie nicht jedes Mal, ob Dokumentation geschrieben werden soll.

3. Materialien gemäß ihrem Zweck überprüfen und pflegen

Aktuelle ArbeitNach Bedarf lesenInformationsverantwortung
Überprüfung der Verantwortung und Ausrichtung zwischen menschenlesbaren Entwürfen und technischen MaterialienOrganisation und QuellenMenschenlesbare Entwürfe behalten die vollständige Quelle für Ziele, Szenarien und Verhalten; technische Materialien referenzieren und ergänzen sie
Beschreibung eines aktuellen Subsystems oder Korrektur von Unterschieden zwischen Dokumentation und ImplementierungSubsystem-DokumentationAktuelle Verantwortlichkeiten, Mechanismen, Verträge und Navigation zu Quellcode, Tests und Notizen
Aufzeichnung von Änderungszielen, Entwürfen, Aufgaben und FortsetzungskontextÄnderungsentwürfe und -pläneAktuelle Ziele, Abweichungen vom bestehenden Zustand, ungelöste Fragen, Implementierungs- und Verifikationspläne
Aktualisierung des Status; Abschluss, Pause, Abbruch, Wiederaufnahme oder Schließung von AufzeichnungenStatus und AbschlussGesamtfortschritt, Aufgabenergebnisse, tatsächliche Verifikation und Behandlung verbleibender Arbeit

Pflegen Sie jede Tatsache an einem Ort; fassen Sie sie zusammen und verlinken Sie darauf an anderer Stelle. docs/designs/<topic>.md kann die vollständige menschenlesbare Entwurfsquelle sein. Fügen Sie technische Details, Abhängigkeiten, Verifikation und Fortschritt nur nach Bedarf in .agents/changes/ hinzu; duplizieren Sie den Entwurf nicht. Machen Sie aus einer Übersicht einer vorhandenen Quelle keine vollständige Kopie, erstellen Sie keinen zweiten Status- oder Fortschrittsdatensatz in einem Index und pflegen Sie langfristige Begründungen nicht außerhalb ihrer Notizenquelle.

Die Regeln für den technischen Änderungseinstiegspunkt, die README, den Plan und den Gesamtstatus gelten nur für Arbeiten, die einen technischen Änderungsdatensatz benötigen; sie werden nicht menschenlesbaren Entwürfen auferlegt. Der festgelegte oder ungelöste Inhalt eines Entwurfs ist kein technischer Fortschritt. Führen Sie keine obligatorische Zustandsmaschine für Entwürfe ein oder erstellen Sie ein begleitendes technisches Verzeichnis für jeden Entwurf.

Unterscheiden Sie festgelegte Schlussfolgerungen, ungelöste Empfehlungen, Annahmen und zu untersuchende Punkte von Quellcode-Verifikation, vorhandener Testabdeckung und tatsächlicher Laufzeitverifikation. Links sollten den Mechanismus, das abgedeckte Verhalten oder das unterstützte Entscheidungsthema erklären. Die Existenz eines Tests bedeutet nicht, dass er erfolgreich ausgeführt wurde. Die Annahme eines Ziels bedeutet nicht, dass es implementiert wurde, oder entfernt automatisch Übergangs- oder Kompatibilitätsverpflichtungen.

Wenn Dokumentation und Implementierung nicht übereinstimmen, überprüfen Sie den relevanten Quellcode, die Tests, die Anforderungen, die geltenden Notizen und den Implementierungsstatus. Stellen Sie fest, ob die Dokumentation veraltet ist, die Implementierung vom beabsichtigten Verhalten abweicht oder ein Übergang unvollständig ist. Korrigieren Sie verifizierte Dokumentationsfehler; beheben Sie Implementierungsfehler im Rahmen der bestehenden Autorisierung. Beschreiben Sie einen Defekt nicht als normalen Vertrag oder verwenden Sie alte Dokumentation, um eine neue Benutzeranweisung zu überstimmen. Wenn Schlüsselverhalten oder Kompromisse unklar bleiben, beschreiben Sie den Konflikt und bitten Sie den Benutzer um eine Entscheidung, während Sie Arbeiten fortsetzen, die nicht von dieser Entscheidung abhängen.

4. Materialien mit wesentlichen Änderungen synchron halten

  • Wenn sich Subsystemverantwortlichkeiten, -grenzen, Hauptpfade, Schnittstellen, Zustand, Fehlerverhalten, Kompatibilitätsverhalten oder notwendige Navigation ändern, aktualisieren Sie die relevante Dokumentation zusammen mit der verifizierten Änderung, anstatt auf den Abschluss des Projekts zu warten. Schreiben Sie Beschreibungen, die nach interner Refaktorisierung korrekt bleiben, nicht mechanisch neu, reparieren Sie jedoch defekte Links.
  • Aktualisieren Sie Entwürfe, wenn sich Ziele, Umfang, Schlüsselentscheidungen oder Annahmen eindeutig ändern; kennzeichnen Sie ungelöste Inhalte weiterhin als ungelöst. Aktualisieren Sie Pläne, wenn sich Aufgabenergebnisse, Abhängigkeiten, Blockierer oder nächste Schritte in einer Weise ändern, die die Ausführung oder Fortsetzung beeinflusst. Synchronisieren Sie wichtige Zeitplanänderungen, bevor Sie betroffene Schritte ausführen; protokollieren Sie nicht jeden Werkzeugvorgang.
  • Führen Sie Anpassungen im Rahmen der bestehenden Autorisierung autonom durch. Dokumentationsaktualisierungen fügen keine Genehmigungsanforderungen hinzu und können eine notwendige Benutzerentscheidung nicht ersetzen. Bitten Sie den Benutzer, über Änderungen an Verhalten, Umfang oder Schlüsselkompromissen zu entscheiden, die die Autorisierung überschreiten; bestätigen Sie geklärte Angelegenheiten nicht erneut.
  • Überprüfen Sie vor der Auslieferung, Pause oder Übergabe, dass relevante Materialien, die eine fortlaufende Aufbewahrung erfordern, es dem nächsten Agenten ermöglichen, den aktuellen Zustand, die Abweichung vom Ziel, die verbleibende Arbeit und den nächsten Schritt zu identifizieren. Warten Sie nicht bis zu diesen Momenten, um die erste Aufzeichnung zu erstellen.

Behandeln Sie nur den für die aktuelle Aufgabe relevanten Umfang. Halten Sie aktuelle Fakten in der Subsystem-Dokumentation, langfristige Entscheidungen in decision-notes und lassen Sie andere Speicherorte darauf verweisen.

5. Prüfen und ausliefern

Prüfen Sie den für diese Aufgabe vereinbarten Umfang; machen Sie daraus kein repository-weites Audit:

  1. Abdeckung und Verantwortung: Behalten Sie Inhalte, die bestehen bleiben müssen; verwenden Sie geeignete Quellen ohne doppelten Text, leere Platzhalter oder Fortsetzungskontext, der nur im temporären Gespräch verbleibt.
  2. Genauigkeit: Machen Sie aktuellen Zustand, Ziele, festgelegte und ungelöste Punkte sowie Belege klar; vermischen Sie nicht Fortschrittsphasen, Codeänderungen, erfolgreiche Verifikation und erforderliche manuelle Abnahme.
  3. Status und Fortsetzung: Wenn ein technischer Änderungsdatensatz existiert, pflegen Sie dessen Gesamtstatus nur am Änderungseinstiegspunkt und markieren Sie Aufgaben entsprechend dem tatsächlichen Fortschritt. Machen Sie zugehörige Blockierer, Lücken, nächste Schritte und verbleibende Arbeit auffindbar; bewahren Sie notwendige Schlussfolgerungen und Belege in Abschlussaufzeichnungen.
  4. Links und Konsistenz: Halten Sie relevante Anforderungen und Akzeptanzkriterien, Entwürfe, Pläne, Subsysteme und Notizen genau verbunden; stellen Sie sicher, dass Links funktionieren. Die Neuorganisation von Materialien oder Aufzeichnungen darf keine eindeutigen Informationen verlieren.
  5. Verifikationsumfang: Führen Sie anwendbare vorhandene Prüfungen basierend auf Aufgabe und Projekt durch und überprüfen Sie die Ergebnisse; führen Sie eine manuelle Überprüfung durch, wenn kein dediziertes Werkzeug existiert. Erzwingen Sie keine unabhängigen Prüfungen, eine vollständige Testsuite oder eine neue Werkzeugkette nur zur Vervollständigung der Dokumentation. Verwenden Sie verifizierte Ergebnisse wieder, wenn sich der Inhalt nicht geändert hat, und beschreiben Sie unverifizierte oder eingeschränkte Bereiche genau.

Der Abschluss der aktuellen Dokumentationsaufgabe bedeutet, dass die vereinbarten Informationen korrekt, Quellen auffindbar, Unbekanntes und Verifikationslücken offengelegt sind und die Materialien die Fortsetzung unterstützen. Es beweist nicht, dass der Entwurf ausreichend, die Implementierung korrekt oder die Funktion vollständig ist. Überprüfen Sie den Abschluss der gesamten Änderung separat mit Status und Abschluss.

Liefern Sie die Änderungen, Prüfungen und notwendigen Lücken dieser Runde mit einer prägnanten Erklärung und Links zu den tatsächlichen Dateien; legen Sie Ergebnisse, die eine fortlaufende Wartung benötigen, im Repository ab. Halten Sie zugehörigen Code, Dokumentation und Notizen als ausstehendes Lieferobjekt zusammen. Das Speichern von Dokumentation autorisiert nicht zu Commit, Push, PR oder Release; befolgen Sie die bestehenden Commit-Bestätigungsregeln des Projekts und committen Sie nicht frühzeitig, nur weil Dokumentation gespeichert wurde.

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Verwandte Skills