用途
Architecture Satisfaction 用于执行一个有界的架构重构循环，朝着明确陈述的设计目标推进，同时保证系统在每一个有意义的步骤之后仍然可以工作。它适合那种“目的地可以用具体术语说清楚、且当前系统在每次有意义变更后都能被测试”的刻意架构重构。
它明确不是通用的清理流程：低风险代码卫生应使用 housekeeper，Git 分支/PR/worktree/stash 清理应使用 repository-cleanup。
主要能力
- 在编辑代码前，先以具体术语写下架构目标，包括：模块边界与归属、依赖方向、应保持稳定的公共接口、必须继续工作的行为、性能约束、证明安全性的测试/冒烟检查/实时流程、已知风险与回滚点。
- 若目标模糊，暂停并澄清：把开放问题作为选项提出（在可用时使用 AskUserQuestion，例如哪些公共接口必须保持稳定；否则在聊天中提出）。因为主观的停止条件可能导致无限运行。
- 在首次编辑前获得目标批准。若运行环境有 plan mode，则进入（EnterPlanMode），把目标与验证计划写成计划，用 ExitPlanMode 提交审批，并把批准后的计划复制到进度文件；否则在聊天中展示目标与计划并等待明确的同意。
- 维护进度文件，默认位于 /tmp，按项目命名，例如 /tmp/refactor-my-project.md，用于记录：架构目标与约束、当前风险、检查点历史、已做决策、运行的命令及其结果、独立审查发现、阻塞项、下一步行动。该进度文件是长重构与交接的临时状态，除非用户要求，否则不应替代项目文档。
使用方式
工作流如下：
- 检查当前仓库状态：分支、未提交工作、近期提交、测试命令、应用启动命令、相关架构文档。
- 在进度文件中定义架构目标、约束、当前风险与验证计划，并在任何代码编辑前获得批准（见“先定义满意”）。
- 一次只做一个显著的、可审查的变更。
- 每次显著变更后实时测试受影响的行为。优先使用项目真实的 app/runtime 检查，而不仅是静态检查。
- 运行相关自动化检查：测试、类型检查、linter、formatter、构建、迁移或聚焦的冒烟脚本。
- 每次显著变更后运行独立审查。针对检查点的起始提交运行 code-review 技能（在支持子智能体的环境中，其 Correctness 轴作为 leek-skills:pr-reviewer 子智能体运行，否则内联运行），并用“独立审查重点”向其说明。若该技能未安装，则使用现有的 autoreview 命令或单独的审查轮次，查找行为回归、遗漏的调用方、泄漏的抽象和测试缺口。
- 在进入下一个架构步骤前，修复实时测试、检查或审查发现的问题。
- 当用户要求提交或仓库工作流期望检查点提交时，提交每个已验证的检查点。保持提交小，并以架构动作命名。
- 用检查点、证据、决策和下一步行动更新进度文件。
- 重复，直到达到陈述的架构目标、检查通过、审查未发现阻塞问题。
检查点纪律：每个检查点应包含一个连贯的架构变更、通过或明确解释的验证、已审查的 diff、若提交则附简短提交信息、以及解释改了什么和为什么的进度文件条目。不要让多个不相关的重构在验证前累积。小而经过验证的检查点可降低风险并保留回滚点。
独立审查重点：要求审查轮次查找——依赖方向被破坏或循环依赖；接口变宽或泄漏实现细节；重构中遗漏的调用点；测试未覆盖的行为变化；迁移或数据兼容性风险；性能回归；比原始代码更难理解的过度抽象；现在描述旧架构的文档或注释。
报告：结束时给出——架构目标；已完成的检查点；运行的实时测试与自动化检查；独立审查发现与修复；创建的提交（如有）；剩余风险或推迟的工作；当前进度文件路径。每个需要用户的事项（风险、推迟、批准）以 ⚠️ 开头，每个失败的检查以 ❌ 开头，不使用其他标记。
适用场景
- 目标可具体陈述的刻意架构重构。
- 每次有意义变更后系统可被测试的重构。
- 需要保留回滚点、逐步验证、独立审查的长期重构工作。
限制
- 没有具体目标和验证计划时，不得开始广泛重构。
- 不得在一个检查点中合并不相关的架构动作。
- 除非用户明确想要进行中的检查点，否则不得提交失败的检查点。
- 未经检查调用方和兼容性，不得重写公共接口、数据形状或迁移行为。
- 不得丢弃用户更改或不相关的工作。
- 主观的停止条件可能导致无限运行，因此必须先澄清目标。
- 进度文件是临时状态，除非用户要求，否则不替代项目文档。
关于收费、价格、平台支持等具体信息，资料中暂未提供。