Mister Clean

Mister Clean — это навык агента для полного доведения работы в репозитории до конца: погашение долга по завершению, согласование планирования и состояния Git, проверка результата и оставление кодовой базы, готовой для преемника. Его предпосылка проста: репозиторий — это промпт следующей команды, поэтому чистое наследование создаёт интеллектуальный импульс, а незавершённое — усугубляет долг в каждой последующей сессии.

Вызов представляет собой постоянную авторизацию для процедур, описанных в навыке. Обычная очистка в пределах области действия выполняется, а не ставится в очередь; жёсткие границы безопасности и владения остаются жёсткими границами.

Использование навыка

Установите этот репозиторий как навык в среде агента, затем вызовите:

$mister-clean

Точка входа — SKILL.md. Она направляет к целевым справочным материалам только тогда, когда текущий репозиторий делает их уместными.

Related MCP server: capalith

Использование MCP-сервера

Запустите локальный stdio-сервер:

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

Или подключите Streamable HTTP-клиент к:

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

MCP-сервер намеренно доступен только для чтения. Он предоставляет канонический навык, справочные материалы, шаблоны, примеры и промпт завершения; вызывающий агент выполняет авторизованную работу локально, где можно проверить политику и права владения репозиторием.

Проверка завершения

Авторитетные локальные валидаторы предоставляются через один Node-совместимый CLI:

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

Аудит планирования — это исполняемый минимальный порог готовности преемника. Он разбирает YAML frontmatter в Markdown/MDX, а также объектные записи JSON и YAML верхнего уровня, обнаруживает как каталоги планирования, так и точные канонические файлы, такие как ROADMAP.md, STATUS.md, PLAN.md, TASKS.md, BACKLOG.md и CURRENT.md, согласует физические дорожки и текущее состояние тела, разрешает точные идентификаторы дочерних элементов из структурированных списков и дочерних таблиц, а также группирует дублирующиеся проекции одного и того же приёмочного критерия. Искажённые структурированные записи, неподдерживаемые состояния жизненного цикла или критериев, противоречивое родительство, метка архива только для бандла, отсутствующие критерии после завершённых дочерних элементов и невыполненная или проваленная приёмка — всё это возвращает ненулевой код. Каждый элемент планирования должен быть структурно размещён в одном проверенном графе жизненного цикла/связей или явно классифицирован как руководство, не являющееся артефактом, с обоснованием. Метка «руководство/шаблон/схема» никогда не переопределяет сигналы жизненного цикла, идентичности, связей, дочерних таблиц или приёмки; приёмка может быть not_applicable только при наличии структурированного обоснования. Схемы и валидаторы, специфичные для репозитория, по-прежнему выполняются дополнительно к этому консервативному межрепозиторному контролю.

Ссылки на дочерние элементы имеют явную семантическую роль. Обычные рабочие артефакты используют child_parentage: строка дочернего элемента разрешается ровно в один артефакт и создаёт второго родителя. Артефакты с типом index, status_index или rollup используют rollup_projection: каждая строка по-прежнему должна разрешаться однозначно и соответствовать текущему состоянию, но она никогда не становится вторым родителем. Артефакт, специфичный для репозитория, может переопределить значение по умолчанию с помощью relationship_role: child_parentage или relationship_role: rollup_projection вместе с relationship_role_rationale; неподдерживаемые, конфликтующие, неоднозначные или необъяснённые переопределения завершаются отказом. Встроенные типы иерархии и сводных данных имеют неизменяемые роли, поэтому обоснование не может переобозначить историю/задачу как индекс или индекс как родителя. Сводные данные распознают канонические целевые столбцы рабочих элементов; столбец, специфичный для репозитория, требует rollup_target_column и rollup_target_column_rationale; настраиваемая родительская таблица использует child_target_column и child_target_column_rationale. Таблица связей, несущая состояние, без распознанного или объявленного целевого столбца завершается отказом. Каждая строка таблицы и запись структурированной коллекции дочерних элементов должна содержать одну разрешимую идентичность; проецируемые состояния должны быть распознаны и согласованы. Ключи записей в CamelCase и snake_case используют одну и ту же схему. Обычные артефакты иерархии могут исключать целевой столбец чек-листа/таблицы решений с помощью non_relationship_table_columns и non_relationship_table_rationale; сводные артефакты и канонические столбцы связей/жизненного цикла не могут использовать эту лазейку.

Псевдонимы типа артефакта, идентичности, жизненного цикла, роли, цели, обоснования и top_level учитывают наличие: каждый объявленный единичный псевдоним должен содержать одно непустое скалярное значение, а эквивалентные псевдонимы должны совпадать. Вывод значения или значение по умолчанию допускается только при отсутствии соответствующего псевдонима. Дублирующиеся ключи JSON, неподдерживаемые псевдонимы, подобные состояниям, некорректные области связей и составное прозаическое описание жизненного цикла завершаются отказом. Только собственный типизированный ID артефакта и общий id устанавливают его идентичность, но никогда поле родителя. Псевдонимы ссылок на дочерние/родительские элементы в единственном числе, множественном числе, snake-case и camel-case согласуются построчно; жизненный цикл родительской ссылки должен соответствовать разрешённому родителю.

Обнаружение приёмки рекурсивно следует поддерживаемым родительским связям через структурированные записи и проверяет каждую объявленную область результата; обоснование not_applicable должно находиться именно в этой области. Структурированные JSON/YAML никогда не интерпретируются как проза. Сканирование Markdown игнорирует примеры в ограждённых блоках и HTML-комментарии, при этом согласует видимые метки состояния в заголовках и цитатах, метки приёмки, формулировки ожидающего рассмотрения и неотмеченные пункты приёмки. Вложенные канонические объявления рабочих элементов и неразрешённые по типу псевдонимы иерархии не могут скрываться за общей метаданной или классификацией «не артефакт». Неподдерживаемые, бинарные и символически связанные записи внутри обнаруженного корня планирования приводят к ошибке автономного аудита; бандл CLEAN должен включать каждую активную запись и явно классифицировать неподдерживаемые обычные файлы как обоснованные не-артефакты.

Установленный навык использует тот же автономный CLI из собственного bin/mister-clean.js; он никогда не предполагает, что целевой репозиторий содержит инструментарий Mister Clean. Храните отчёт, манифест, бандл и их привязанные к дайджесту записи доказательств вместе в одном каталоге прогона.

Запустите полную проверку проекта перед предложением релиза:

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

Граница общественной безопасности

Публичный дистрибутив содержит обобщённые принципы и синтетические примеры. Приватные примеры из практики, локальные пути, учётные данные, названия проектов и операционные доказательства не должны находиться в этом репозитории или его истории Git.

Лицензия

MIT