Mister Clean

Mister Clean 是一种 agent 技能，用于将仓库工作彻底收尾：偿还完成债务、核对规划与 Git 状态、验证结果，并留下一个后继者可直接上手的代码库。其前提很简单：仓库就是下一个团队的提示词，因此干净的交接能创造明智的推进力，而未完成的交接则会在之后的每一次会话中不断累积债务。

调用即是对本技能文档所述流程的常设授权。常规范围内的清理会被执行，而非排队等候；硬性的安全边界和所有权边界依然是硬边界。

使用技能

在 agent harness 中将此仓库安装为技能，然后调用：

$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 服务器刻意设计为只读。它提供规范的技能、参考资料、模板、示例和收尾提示词；调用方 agent 在本地执行被授权的工作，因为仓库策略和所有权可以在本地得到验证。

验证收尾

权威的本地验证器通过一个 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

规划审计是一道可执行的后继就绪底线。它解析 Markdown/MDX 的 YAML frontmatter 以及顶层 JSON 和 YAML 对象记录；既发现规划目录，也发现确切的规范文件，如 ROADMAP.md、STATUS.md、PLAN.md、TASKS.md、BACKLOG.md 和 CURRENT.md；核对物理泳道与当前正文状态；从结构化列表和子表中解析出精确的子 ID；并将同一验收门的重复投影分组。格式错误的结构化记录、不支持的生命周期或门状态、相互矛盾的父级关系、仅限 bundle 的归档标签、已完成子项之后缺失的验收门，以及未执行或失败的验收，均返回非零。每个规划项都必须被结构性地放置在一个经过验证的生命周期/关系图中，或被明确归类为带有理由说明的非工件指导。指导/模板/schema 标签永远不能覆盖生命周期、身份、关系、子表或验收信号；只有附有结构化理由说明时，验收才能是 not_applicable。除这一保守的跨仓库门槛外，仓库特定的 schema 和验证器仍然会运行。

子引用具有明确的语义角色。普通工作工件使用 child_parentage：子行恰好解析到一个工件，并创建一条图边。类型为 index、status_index 或 rollup 的工件使用 rollup_projection：每一行仍然必须唯一解析并匹配当前状态，但它永远不会成为第二个父级。仓库特定的工件可以用 relationship_role: child_parentage 或 relationship_role: rollup_projection 外加 relationship_role_rationale 覆盖默认值；不支持、冲突、含糊或无法解释的覆盖均失败关闭。内置的层级类型和 rollup 类型具有不可变的角色，因此理由说明不能将 story/task 重新标记为 index，也不能将 index 重新标记为父级。Rollup 识别规范的工作项目标列；仓库特定的列需要 rollup_target_column 和 rollup_target_column_rationale；自定义父表使用 child_target_column 和 child_target_column_rationale。带有状态的关系表如果没有可识别或已声明的目标列，就会失败关闭。每个表行和结构化子集合条目都必须包含一个可解析的身份；投影状态必须被识别且保持一致。CamelCase 和 snake_case 记录键共享相同的 schema。普通层级工件可以用 non_relationship_table_columns 加上 non_relationship_table_rationale 来豁免清单/决策表目标列；rollup 工件以及规范的 relationship/lifecycle 列不能使用该豁免。工件类型、身份、生命周期、角色、目标、理由说明以及 top_level 别名都是存在感知的：每个声明的单数别名都必须包含一个非空标量，且等价别名必须一致。仅当相应别名缺失时，才允许推断或使用默认值。重复的 JSON 键、不支持的类状态别名、格式错误的关系作用域以及复合生命周期表述，都会失败关闭。只有工件自身的类型化 ID 和通用 id 才能确立其身份，父字段永远不能。单数、复数、snake-case 和 camel-case 的子/父引用别名会逐条核对；父引用的生命周期必须与解析出的父级一致。

验收发现会递归地沿受支持的父级关系遍历结构化记录，并验证每个声明的结果作用域；not_applicable 的理由说明必须位于该确切作用域内。结构化 JSON/YAML 永远不会被重新解释为散文式文本。Markdown 扫描会忽略围栏示例和 HTML 注释，同时仍然核对可见的标题和块引用状态标签、验收标签、待审阅措辞以及未勾选的验收项。嵌套的规范工作声明和类型未解析的层级别名，不能隐藏在通用元数据或非工件分类之后。已发现规划根目录内的不支持条目、二进制条目和符号链接条目会使独立审计失败；CLEAN bundle 必须包含每个有效条目，并明确将不支持的常规文件归类为有理由依据的非工件。

已安装的技能从自身的 bin/mister-clean.js 解析出同一个独立 CLI；它从不假设目标仓库包含 Mister Clean 工具。将报告、manifest、bundle 及其与摘要绑定的证据记录一起保存在同一个运行目录下。

在提议发布之前，先运行完整的项目检查：

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

公共安全边界

公共分发版本包含通用化的准则和合成示例。私有案例研究、本地路径、凭据、项目名称和运营证据不属于此仓库或其 Git 历史。

许可协议

MIT