Mister Clean

Mister Clean es una habilidad de agente para cerrar por completo el trabajo del repositorio: saldar la deuda de finalización, conciliar el estado de la planificación y de Git, validar el resultado y dejar un código base listo para el sucesor. Su premisa es sencilla: el repositorio es el prompt del próximo equipo, por lo que una herencia limpia genera impulso inteligente, mientras que una inacabada acumula deuda en cada sesión posterior.

La invocación constituye una autorización permanente para los procedimientos documentados en la habilidad. La limpieza ordinaria dentro del alcance se ejecuta, no se pone en cola; los límites estrictos de seguridad y propiedad siguen siendo límites estrictos.

Usar la habilidad

Instala este repositorio como una habilidad en un entorno de agente y, a continuación, invoca:

$mister-clean

El punto de entrada es SKILL.md. Solo enruta a referencias específicas cuando el repositorio actual las hace relevantes.

Related MCP server: capalith

Usar el servidor MCP

Ejecuta el servidor stdio local:

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

O conecta un cliente HTTP Streamable a:

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

El servidor MCP es intencionadamente de solo lectura. Expone la habilidad canónica, las referencias, las plantillas, los ejemplos y el prompt de cierre; el agente que invoca realiza el trabajo autorizado localmente, donde pueden verificarse la política y la propiedad del repositorio.

Validar un cierre

Los validadores locales de referencia se exponen a través de una CLI compatible con Node:

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

La auditoría de planificación es un umbral mínimo ejecutable de preparación para el sucesor. Analiza el frontmatter YAML de Markdown/MDX además de los registros de objetos JSON y YAML de nivel superior, descubre tanto los directorios de planificación como los archivos canónicos exactos, como ROADMAP.md, STATUS.md, PLAN.md, TASKS.md, BACKLOG.md y CURRENT.md, concilia los carriles físicos y el estado actual del cuerpo, resuelve los ID de hijo exactos a partir de listas estructuradas y tablas de hijos, y agrupa las proyecciones duplicadas de la misma puerta de aceptación. Los registros estructurados malformados, los estados de ciclo de vida o de puerta no admitidos, la filiación contradictoria, una etiqueta de archivo exclusiva del bundle, la falta de puertas tras hijos completados y la aceptación no ejecutada o fallida devuelven un código distinto de cero. Cada elemento de planificación debe ubicarse estructuralmente en un grafo verificado de ciclo de vida/relaciones o clasificarse explícitamente como guía no artefacto con una justificación. Una etiqueta de guía/plantilla/esquema nunca anula las señales de ciclo de vida, identidad, relación, tabla de hijos o aceptación; la aceptación solo puede ser not_applicable con una justificación estructurada. Los esquemas y validadores específicos del repositorio siguen ejecutándose además de esta puerta conservadora entre repositorios.

Las referencias a hijos tienen un rol semántico explícito. Los artefactos de trabajo normales usan child_parentage: una fila de hijo se resuelve en exactamente un artefacto y crea una arista en el grafo. Los artefactos tipados como index, status_index o rollup usan rollup_projection: cada fila debe seguir resolviéndose de forma única y coincidir con el estado actual, pero nunca se convierte en un segundo padre. Un artefacto específico del repositorio puede anular el valor predeterminado con relationship_role: child_parentage o relationship_role: rollup_projection más un relationship_role_rationale; las anulaciones no admitidas, conflictivas, ambiguas o sin explicación fallan en modo cerrado. Los tipos integrados de jerarquía y rollup tienen roles inmutables, por lo que una justificación no puede reetiquetar una historia/tarea como índice ni un índice como padre. Los rollups reconocen las columnas de destino canónicas de elementos de trabajo; una columna específica del repositorio requiere rollup_target_column y rollup_target_column_rationale; una tabla principal personalizada usa child_target_column y child_target_column_rationale. Una tabla de relaciones con estado y sin columna de destino reconocida ni declarada falla en modo cerrado. Cada fila de tabla y cada entrada de colección estructurada de hijos debe contener una identidad resoluble; los estados proyectados deben ser reconocidos y coherentes. Las claves de registro CamelCase y snake_case comparten el mismo esquema. Los artefactos de jerarquía ordinarios pueden eximir una columna de destino de lista de verificación/tabla de decisiones con non_relationship_table_columns más non_relationship_table_rationale; los artefactos rollup y las columnas canónicas de relación/ciclo de vida no pueden usar esa vía de escape. El tipo de artefacto, la identidad, el ciclo de vida, el rol, el destino, la justificación y los alias top_level son conscientes de la presencia: cada alias singular declarado debe contener un escalar no vacío y los alias equivalentes deben coincidir. La inferencia o un valor predeterminado solo se permiten cuando el alias correspondiente está ausente. Las claves JSON duplicadas, los alias no admitidos similares a estados, los alcances de relación malformados y la prosa compuesta de ciclo de vida fallan en modo cerrado. Solo el ID tipado propio del artefacto y el id genérico establecen su identidad, nunca un campo de padre. Los alias de referencia de hijo/padre en singular, plural, snake-case y camel-case se concilian entrada por entrada; el ciclo de vida de la referencia al padre debe coincidir con el padre resuelto.

El descubrimiento de aceptación sigue las relaciones de padre admitidas de forma recursiva a través de los registros estructurados y valida cada alcance de resultado declarado; una justificación not_applicable debe estar en ese alcance exacto. El JSON/YAML estructurado nunca se reinterpreta como prosa. El escaneo de Markdown ignora los ejemplos en bloques de código y los comentarios HTML, aunque sigue conciliando las etiquetas de estado visibles en encabezados y citas, las etiquetas de aceptación, el lenguaje de revisión pendiente y los elementos de aceptación sin marcar. Las declaraciones canónicas anidadas de trabajo y los alias de jerarquía sin resolver por tipo no pueden ocultarse tras metadatos genéricos ni una clasificación de no artefacto. Las entradas no admitidas, binarias y simbólicas dentro de una raíz de planificación descubierta hacen fallar la auditoría independiente; un bundle CLEAN debe incluir todas las entradas vivas y clasificar explícitamente los archivos regulares no admitidos como no artefactos justificados.

La habilidad instalada resuelve la misma CLI independiente desde su propio bin/mister-clean.js; nunca asume que el repositorio de destino contiene las herramientas de Mister Clean. Mantén el informe, el manifiesto, el bundle y sus registros de evidencia vinculados al hash juntos en un único directorio de ejecución.

Ejecuta la comprobación completa del proyecto antes de proponer una versión:

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

Límite de seguridad pública

La distribución pública contiene doctrina generalizada y ejemplos sintéticos. Los estudios de caso privados, las rutas locales, las credenciales, los nombres de proyectos y la evidencia operativa no pertenecen a este repositorio ni a su historial de Git.

Licencia

MIT