Mister Clean

Mister Clean ist eine Agenten-Fähigkeit, um Repository-Arbeit vollständig abzuschließen: Abschluss-Schulden begleichen, Planungs- und Git-Zustand abgleichen, das Ergebnis validieren und eine nachfolgebereite Codebasis hinterlassen. Die Prämisse ist einfach: Das Repository ist der Prompt des nächsten Teams, sodass ein sauberes Erbe intelligente Dynamik erzeugt, während ein unfertiges die Schulden in jeder späteren Sitzung vergrößert.

Die Aufrufung ist eine dauerhafte Autorisierung für die in der Fähigkeit dokumentierten Verfahren. Gewöhnliche Bereinigungen im Rahmen des Geltungsbereichs werden durchgeführt, nicht in eine Warteschlange gestellt; harte Sicherheits- und Eigentumsgrenzen bleiben harte Grenzen.

Die Fähigkeit verwenden

Installieren Sie dieses Repository als Fähigkeit in einer Agent-Harness und rufen Sie dann auf:

$mister-clean

Der Einstiegspunkt ist SKILL.md. Er leitet nur dann zu gezielten Referenzen weiter, wenn das aktuelle Repository sie relevant macht.

Related MCP server: capalith

Den MCP-Server verwenden

Führen Sie den lokalen stdio-Server aus:

npx -y --package @bradheitmann/mister-clean mister-clean-mcp

Oder verbinden Sie einen Streamable-HTTP-Client mit:

https://mister-clean.bradheitmann.ai/mcp

Der MCP-Server ist absichtlich schreibgeschützt. Er stellt die kanonische Fähigkeit, Referenzen, Vorlagen, Beispiele und den Abschluss-Prompt bereit; der aufrufende Agent führt die autorisierte Arbeit lokal aus, wo Repository-Richtlinie und Eigentum überprüft werden können.

Einen Abschluss validieren

Die maßgeblichen lokalen Validatoren werden über eine Node-kompatible CLI bereitgestellt:

mister-clean validate report path/to/closeout-report.json
mister-clean validate manifest path/to/action-manifest.json
mister-clean validate bundle path/to/closure-bundle.json --repo path/to/live-checkout
mister-clean audit planning path/to/live-checkout --json

Die Planungsprüfung ist eine ausführbare Mindestanforderung für die Nachfolgebereitschaft. Sie parst Markdown/MDX-YAML-Frontmatter sowie JSON- und YAML-Objektdatensätze auf oberster Ebene, entdeckt sowohl Planungsverzeichnisse als auch exakte kanonische Dateien wie ROADMAP.md, STATUS.md, PLAN.md, TASKS.md, BACKLOG.md und CURRENT.md, gleicht physische Spuren und den aktuellen Body-Zustand ab, löst exakte Kind-IDs aus strukturierten Listen und Kind-Tabellen auf und gruppiert doppelte Projektionen desselben Abnahmetors. Fehlerhafte strukturierte Datensätze, nicht unterstützte Lebenszyklus- oder Torzustände, widersprüchliche Elternschaft, ein Nur-Bundle-Archivlabel, fehlende Tore nach abgeschlossenen Kindern und nicht ausgeführte oder fehlgeschlagene Abnahmen geben alle einen Nicht-Null-Wert zurück. Jedes Planungselement muss strukturell in einem verifizierten Lebenszyklus-/Beziehungsgraphen platziert oder explizit als Nicht-Artefakt-Anleitung mit einer Begründung klassifiziert werden. Ein Anleitungs-/Vorlagen-/Schema-Label überschreibt niemals Lebenszyklus-, Identitäts-, Beziehungs-, Kind-Tabellen- oder Abnahmesignale; Abnahme kann nur mit einer strukturierten Begründung not_applicable sein. Repository-spezifische Schemas und Validatoren laufen weiterhin zusätzlich zu diesem konservativen Cross-Repository-Tor.

Kind-Referenzen haben eine explizite semantische Rolle. Normale Arbeitsartefakte verwenden child_parentage: Eine Kind-Zeile löst sich zu genau einem Artefakt auf und erzeugt eine Graphkante. Artefakte vom Typ index, status_index oder rollup verwenden rollup_projection: Jede Zeile muss weiterhin eindeutig aufgelöst werden und dem aktuellen Zustand entsprechen, wird aber niemals zu einem zweiten Elternteil. Ein repository-spezifisches Artefakt kann den Standard mit relationship_role: child_parentage oder relationship_role: rollup_projection plus einer relationship_role_rationale überschreiben; nicht unterstützte, widersprüchliche, mehrdeutige oder unerklärte Überschreibungen schlagen fehl (fail closed). Eingebaute Hierarchie- und Rollup-Typen haben unveränderliche Rollen, sodass eine Begründung eine Story/Aufgabe nicht als Index oder einen Index als Elternteil umbenennen kann. Rollups erkennen kanonische Zielspalten für Arbeitselemente; eine repository-spezifische Spalte erfordert rollup_target_column und rollup_target_column_rationale; eine benutzerdefinierte Elterntabelle verwendet child_target_column und child_target_column_rationale. Eine zustandsbehaftete Beziehungstabelle ohne erkannte oder deklarierte Zielspalte schlägt fehl (fail closed). Jede Tabellenzeile und jeder Eintrag einer strukturierten Kindersammlung muss eine auflösbare Identität enthalten; projizierte Zustände müssen erkannt und kohärent sein. CamelCase- und snake_case-Datensatzschlüssel teilen sich dasselbe Schema. Gewöhnliche Hierarchie-Artefakte können eine Zielspalte für Checklisten/Entscheidungstabellen mit non_relationship_table_columns plus non_relationship_table_rationale ausnehmen; Rollup-Artefakte und kanonische Beziehungs-/Lebenszyklusspalten können diese Ausnahme nicht nutzen. Artefakttyp, Identität, Lebenszyklus, Rolle, Ziel, Begründung und top_level-Aliasse sind präsenzbewusst: Jeder deklarierte singuläre Alias muss einen nicht leeren Skalar enthalten und äquivalente Aliasse müssen übereinstimmen. Inferenz oder ein Standardwert ist nur zulässig, wenn der entsprechende Alias fehlt. Doppelte JSON-Schlüssel, nicht unterstützte zustandsähnliche Aliasse, fehlerhafte Beziehungsumfänge und zusammengesetzte Lebenszyklus-Prosa schlagen fehl (fail closed). Nur die eigene typisierte ID des Artefakts und die generische id etablieren seine Identität, niemals ein Elternfeld. Singuläre, plurale, Snake-Case- und CamelCase-Kind-/Eltern-Referenzaliase werden Eintrag für Eintrag abgeglichen; der Lebenszyklus der Elternreferenz muss mit dem aufgelösten Elternteil übereinstimmen.

Die Abnahmeerkennung folgt unterstützten Elternbeziehungen rekursiv durch strukturierte Datensätze und validiert jeden deklarierten Ergebnisumfang; eine not_applicable-Begründung muss in genau diesem Umfang liegen. Strukturiertes JSON/YAML wird niemals als Prosa neu interpretiert. Das Markdown-Scannen ignoriert umrahmte Beispiele und HTML-Kommentare, gleicht aber weiterhin sichtbare Überschriften- und Blockquote-Statuslabels, Abnahmelabels, Sprache für ausstehende Überprüfungen und nicht angehakte Abnahmeelemente ab. Verschachtelte kanonische Arbeitsdeklarationen und typunaufgelöste Hierarchie-Aliasse können sich nicht hinter generischen Metadaten oder Nicht-Artefakt-Klassifikationen verstecken. Nicht unterstützte, binäre und symbolisch verknüpfte Einträge innerhalb einer entdeckten Planungswurzel lassen die eigenständige Prüfung fehlschlagen; ein CLEAN-Bundle muss jeden aktiven Eintrag enthalten und nicht unterstützte reguläre Dateien explizit als begründete Nicht-Artefakte klassifizieren.

Die installierte Fähigkeit löst dieselbe eigenständige CLI aus ihrem eigenen bin/mister-clean.js auf; sie geht niemals davon aus, dass das Ziel-Repository Mister-Clean-Werkzeuge enthält. Bewahren Sie den Bericht, das Manifest, das Bundle und ihre digest-gebundenen Nachweisaufzeichnungen zusammen unter einem Ausführungsverzeichnis auf.

Führen Sie die vollständige Projektprüfung aus, bevor Sie eine Veröffentlichung vorschlagen:

bun install --frozen-lockfile
bun run check
bun src/cli.ts audit public-safety .

Grenze der öffentlichen Sicherheit

Die öffentliche Distribution enthält verallgemeinerte Doktrin und synthetische Beispiele. Private Fallstudien, lokale Pfade, Anmeldeinformationen, Projektnamen und operative Nachweise gehören nicht in dieses Repository oder seine Git-Historie.

Lizenz

MIT