CommunityCodierung & Entwicklunggithub.com

modus-reinit

Umfassende Prüfung und Neuerstellung von Wissens-Snapshots, unter Beibehaltung stabiler Geschäftsidentitäten und manueller Materialien; nur explizit ausgewählte Inhalte dürfen geändert werden.

Was ist modus-reinit?

Dieses Skill (`tencentmusic/modus`) ermöglicht eine vollständige Neubewertung und Rekonstruktion von Wissens-Snapshots in einem modularen, agentenbasierten Entwicklungssystem. Es identifiziert und kategorisiert Änderungen (z. B. unverändert, reine Ankeranpassung, Implementierungswechsel, Inhaltsreparatur) und führt eine schrittweise Ausführung durch: von der synchronen Erstellung der Evidenz über die Scope-Modellierung bis zur parallelen Domain-Autorisierung. Die Dokumentation beschreibt detailliert, wie Module geprüft, Inhaltslücken repariert, Strukturänderungen konsistent umgesetzt und schließlich die Ergebnisse durch Publikationsverifikation bestätigt werden. Es unterstützt die Plattformen Claude Code, Cursor und Codex-ähnliche Agenten. Der Hauptnutzen liegt in der automatisierten, nachvollziehbaren und minimalinvasiven Aktualisierung von Wissensartefakten, wobei die Integrität des Quellcodes und die Eindeutigkeit der Geschäftsidentitäten erhalten bleiben.

Funktioniert mit~Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/tencentmusic/modus/tree/HEAD/src/modus/scaffold/templates/skills/modus-reinit

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

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

Dokumentation

Was macht modus-reinit?

Vollständige Überprüfung von bestehenden Inhalten. Gemeinsam genutzte Evidenz-Richtlinien, Erstellungs-Framework und Publikationsvertrag; dieses Dokument beschreibt nur die Abweichungen des Reinit.

Erst Bestandsaufnahme, dann Änderungsnachweis

Vollständiges Einlesen des bestehenden Inhalts und der Hashes, Klassifizierung der Ziele in unchanged, anchor-only, implementation-change, scope-change, content-repair, vermutlich außer Dienst gestellt oder manuell erstellter Inhalt. Stabile Identitäten und Hauptdefinitionen werden standardmäßig wiederverwendet; Quellcode-Pfade / Symbolverschiebungen reparieren nur Anker; Layoutänderungen sind keine Scope-Änderungen.

content-repair umfasst: generische Template-Absätze anstelle realer Szenarien, repräsentative Anker anstelle von Fakten, modulübergreifende Kopien, unklare Erfolgs-/Fehlersemantik, komplexe Beziehungen ohne signifikant hilfreiche Diagramme. Texte, die tatsächlich die Aufgaben der Leser erfüllen und deren Fakten unverändert sind, bleiben unchanged und werden übersprungen.

Ausführung

  1. Einmaliges synchrones Erstellen der aktuellen Evidenz pro Repository und Abrufen des reinit-diff-Kontexts; bei Fehlschlag sofort zurück zum aktuellen Quellcode. Gemäß dem Maschinen-Evidenz-Vertrag gezielt erweitern, nicht direkt auf Bundle-interne Dateien zugreifen und keine Cursor-Ausschöpfung anstreben.
  2. Nach Scope-Modellierung in der Reihenfolge „stabile Identität → Einstiegspunkt / Objektverantwortung → semantische Änderung → strukturelle Änderung → Dateiänderung“ bewerten und Bereiche, Handles, Hash beim Einlesen, präzise Domain-/Module-Evidenz/Status, Domain-Abdeckung, Ergebnis und Diagrammkandidaten in eine einzelne Ausführungskarte mit schemaVersion: 2 schreiben. Nur neue Zusammenführungen, Aufteilungen, Verschiebungen, Umbenennungen oder nachgewiesene Außerdienststellungen einmal bestätigen. Standardmäßig seriell; bei expliziter Benutzerermächtigung und mehreren sich nicht überschneidenden betroffenen Domains das parallele Schreiben pro Domain laden und den Domain-Worker-Delegationsvertrag verwenden; der Haupt-Autor behält die exklusive Ausführungskarte und die gemeinsamen Artefakte.
  3. Für jedes geänderte oder content-repair-Modul einen präzisen Selektor zum Anfordern des module-authoring-Kontexts verwenden, beide Zusammenfassungen und den requestedScope abgleichen; breite Anforderungen, die mehrere unabhängige Module in der gesamten Domain abdecken, sind ungültig. Präzise, voneinander unabhängige Anforderungen können parallel gestellt werden; anschließend die Quellcode-Pfade und Symbole der aktuellen Domain zusammenführen, duplizieren und in Chargen zurücklesen. Bei fehlgeschlagener Anforderung, leerem Ergebnis oder Teilfragmenten auf die aktuellen Methoden, Konfigurationen, SQL und Tests zur Nachbesserung zurückgreifen; keine Klassennamen, Schnittstellensignaturen oder Dateierstzeilenanker als Wiederherstellung des Inhalts betrachten. Die gleiche Verkettung nicht für verschiedene Themen erneut scannen und nicht gleichzeitig in denselben Inhalt schreiben. Nach Szenarioabschluss erneut nachweisen; in der ursprünglichen Hauptdefinition überarbeiten, kein Changelog anhängen, nicht aufgrund von Template-Änderungen massenhaft neu schreiben oder neu zeichnen.
  4. In vollständigen Domain-Chargen mit der Reihenfolge „Sechs-Themen-Hauptdefinition → Modul-Szenario → Domain-Routing“ die betroffenen Bereiche zurücklesen. Quellcode-Pfade und Zeilennummern in die wenigen anchors.locations der einzelnen generierten Dokumente im Frontmatter migrieren; vollständige Quellcode-Pfade, path#L und Evidenz-Listen aus dem Inhalt entfernen; Ziel der Reparatur ist die Wiederherstellung vollständiger Aufgaben, Feld-Semantik, kritischer Verzweigungen, Zustände und Fehlerbehandlung, nicht die Wiederherstellung von Titeln, Ankern oder ähnlichen Textumfängen. Nach Evidenz-Abschluss gemäß Text-Bild-Ausdruck die Kandidaten neu bewerten und das einzige Hauptbild aktualisieren; Navigationstabellen ersetzen keine erklärenden Diagramme. Die domainweite coverage-audit muss den Bereich der Kandidaten, Fähigkeiten, Source-Pfade und Symbole dieser Domain verwenden; modus/knowledge/** nicht zulässig; no-match, leere Ergebnisse oder Teilfragmente lösen nur Nachbesserung oder explizite Lücken aus. Gültige Ergebnisse als Domain-Abdeckung erfassen; nach Abschluss der drei Leser-Rücklesungen liest der Haupt-Autor die tatsächlichen Dateien und markiert sie als reviewed. Nur bei Änderungen von domainübergreifender Ausrichtung, Eigentümerschaft, Status, Bedingungen, Abschluss oder Wiederherstellung wird die Hauptübersicht aktualisiert; Team Standard und vorhandene Geschäftslogik werden standardmäßig als ursprüngliche Bytes geschützt; neue Domains verwenden modus knowledge seed-business --domain <slug> --json zum Erstellen fehlender Indizes.
  5. Strukturänderungen schreiben zuerst die neuen Zielorte und führen eine semantische Rücklesung durch, reparieren eingehende Links und Navigation in generierten Inhalten, dann löschen die alten generierten Dateien basierend auf dem Hash beim Einlesen. Nicht aus verschwundenen Symbolen, Teilfragmenten oder Abdeckungslücken direkt auf Außerdienststellung schließen.
  6. Nach globaler semantischer Rücklesung modus knowledge verify --publication --json ausführen, CAS veröffentlichen und zurücklesen. Die Publikation muss die schemaVersion: 2-Ausführungskarte, keinen Quellcode-Pfad im Text, strukturierte Anker, modulweise Evidenz, Domain-Abdeckung und visuelle Entscheidung abgleichen; clean ist noch kein Nachweis für Inhaltsqualität. Große Mengen gleich langer kurzer Texte, keine realen Szenarien, nur Navigationstabellen, Zustandsthemen ohne Übergänge oder Evidenz nur in der ersten Zeile erfordern weitere Überarbeitungen. Ausführungskarten nicht vorzeitig löschen und nicht nach Verlust eine kleinere, als „alle reviewed“ markierte Karte auf Basis der Ausgabe neu erstellen. Nur wenn alle Ziele den Endzustand erreicht haben, die semantische Rücklesung, die tatsächliche Publikation und die Rücklesung nach der Publikation erfolgreich sind, wird die Ausführungskarte bereinigt; normale maschinelle Überprüfungen ersetzen die Publikation nicht. Tatsächliche Ergebnisse als unverändert, überarbeitet, gelöscht, Konflikte und Lücken melden.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Verwandte Skills