| name | 507-simplify |
| description | 在保持公开契约与可观察行为不变的前提下，对指定代码范围或 507-inspect 报告逐项建立证据、修改并验证。可深入内部模块、抽象与接缝；若需要行为变化则停止并路由到需求实施。Use when user mentions simplify, simplify code, 简化, 简化代码, 行为不变重构, 内部简化, 按报告修改, 处理 inspect 报告, 局部重构, 降低复杂度, 收敛架构摩擦。 |
行为不变简化（simplify）
把已有代码的内部结构改得更深、更集中、更易验证，同时保持公开契约与调用者可观察行为不变。507-simplify 接收一个指定范围或完整的 507-inspect 报告，逐项验证后修改；不把“有候选”误当成“必须修改”。
合同
- 可直接处理两类输入：用户明确指定的文件/目录/模块范围，或
507-inspect 的完整候选报告。没有范围时不得自行扩大到全库。
- 逐项双层证据链：
507-inspect 的代码观察证据是候选依据；507-simplify 还必须为每项建立行为基线或可执行验证信号。
- 先验证、后修改：只有基线/信号足以证明候选成立，且重构目标可定义时才修改代码；否则保留现状并带证据关闭该项。
- 行为不变：允许深改内部模块、抽象和接缝，但不得改变公开 API、公开契约、错误模式、时序、持久化语义、兼容性或其他调用者可观察行为。
- 行为变化即退出：若证据显示目标需要新增能力、修正产品语义或改变公开行为，停止该项，说明证据，并路由到需求澄清与正常实施流程；不得以
507-simplify 名义偷偷改变行为。
- 宿主中立：只依赖可获得的代码、文档、测试和项目验证命令；不假定特定 Agent 宿主、编排器、插件或命令格式。
- 公开通用：使用
module、interface、seam、adapter、depth、locality、leverage 等通用架构词；不要把宿主专属操作写进合同，也不使用旧斜杠命令作为入口或下一步。
不做什么
- 不做无证据的“顺手清理”、全库扫描或架构重设计。
- 不把
507-inspect 的推荐强度当作实施批准；Strong 也必须通过本 skill 的行为验证门槛。
- 不重写需求、不修复需要改变产品行为的问题、不替代需求规格或工单流程。
- 不为了制造 seam、adapter 或抽象而改代码；没有真实变化或复用证据时优先删除透传层。
- 不把通过测试等同于证明行为不变；测试只是验证信号的一部分。
输入与范围确认
按以下优先级确定输入：
- 用户明确指定的文件、目录或模块；
507-inspect 的完整报告；- 没有指定时，以当前 Git diff（版本差异）作为候选范围；若工作区没有相关差异，先询问是否改看某个 commit（提交）或明确路径，不自动扫描全库。
开始时记录：
- 来源：直接范围、
507-inspect 报告，或两者；报告必须完整接收，不只挑最方便的一张卡。
- 范围：允许读取和修改的文件/目录/模块，以及明确不包含的邻接范围。
- 目标：要降低的具体摩擦（如重复、泄漏、透传、难测接缝或局部性差）。
- 不变量：公开 API、调用约定、错误与时序、数据格式、资源生命周期及用户可见结果中哪些必须保持不变。
- 验证条件：现有测试、回归命令、类型/静态检查、可复现样例或其他项目既有信号。
若报告缺少定位证据、置信等级、范围或不变量，先补读代码和项目规范；仍无法建立验证信号时，带缺口证据关闭，不猜测修改。
每项重构的记录卡
无论来自报告还是直接指定，都为每项建立如下记录；记录可在工作报告中呈现，也可落在项目已有的变更载体中：
### Simplify item: <稳定标题>
- source: <指定范围 / inspect 卡片标识>
- scope: <允许改动的文件、模块与 seam>
- observation: <代码观察证据；文件、符号、路径或可复现事实>
- confidence: <High | Medium | Low>；<为何如此>
- claimed_friction: <要消除的真实摩擦>
- public_invariants: <必须保持不变的公开契约与可观察行为>
- baseline: <改动前的行为样本、测试结果或快照>
- verification_signal: <改动后可重复运行的验证信号与通过条件>
- gate: <成立才修改 / 不成立关闭 / 需要行为变化退出>
- change: <实际内部重构；未修改则写原因>
- result: <修改并通过 / 带证据关闭 / 路由需求实施>
- evidence: <命令、测试、对比、样例或关闭依据>
observation 必须来自代码事实，不写只有直觉的评价；confidence 不能省略。基线和验证信号必须说明“比较什么”以及“什么结果算通过”。
工作流程
1. 读取上下文并锁定范围
先读项目的适用规范、相关术语、决策记录、目标模块及其调用者和测试。核对 507-inspect 卡片与当前代码是否仍匹配。若已失效，记录差异并关闭，不按旧定位修改。
2. 建立行为基线
按风险选择最小但足够的基线组合：
- 现有单元/集成/端到端测试及其结果；
- 公开入口的输入—输出、错误、顺序、重试、并发或资源生命周期样例；
- 序列化、持久化、日志/事件等确属调用者或外部系统可观察的结果；
- 类型、静态检查、构建和回归命令；
- 对没有现成测试的路径，先记录可复现样例或建立不改变产品行为的验证信号。
基线不足以区分候选是否成立时，不先改代码。优先补验证信号；若补信号本身需要改变公开行为，则退出并路由需求实施。
3. 判断候选是否成立
用证据回答：
- 该摩擦是否在当前代码中真实存在，而非历史描述或偏好？
- 删除测试是否显示模块只是透传，或复杂度会在多个调用处重现？
- proposed seam 是否有真实变化；一个 adapter 只是一个假设，两个不同适配物才是接缝证据？
- 重构能否保持
public_invariants，并由 verification_signal 判定？
结论只有三类：
- 成立才修改：证据和信号足够，目标是行为不变的内部重构。
- 不成立，带证据关闭：摩擦不存在、报告已过时、收益不足，或无法建立可靠信号。
- 需要行为变化，退出并路由：目标超出内部重构合同。
4. 小步修改
一次只做一个可解释的内部重构，优先改善 locality、leverage、depth 和可测试性。可以合并/删除透传模块、收拢职责、重放接缝后的实现、替换内部 adapter 或重排私有抽象；不得借机修改公开 API 或可观察语义。
每一步保持代码可验证。若修改中发现必须扩大范围，先暂停并记录原因；不得静默修改范围外文件。
5. 验证与回归
对每项运行其基线对应的验证信号，并补做受影响调用者、接缝和错误路径的最小回归。比较重构前后：
- 公开入口结果、错误与时序是否一致；
- 兼容格式、持久化/事件语义和资源生命周期是否一致；
- 测试、类型/静态检查、构建及项目既有检查是否通过；
- 变更是否确实减少跳转、重复、泄漏或测试摩擦，而非只移动复杂度。
失败时回退该小步或停止该项，保留失败证据；不得通过放宽断言、删除覆盖或改变测试期望来“绿化”。
6. 收口报告
报告必须逐项覆盖完整输入报告，不修改的项也要列出。至少包含：
- 范围与未触及范围；
- 每项记录卡及成立/关闭/路由结论；
- 修改文件与内部结构变化；
- 行为不变的基线、验证信号和结果；
- 关闭项的反证或证据缺口；
- 仍需走需求实施的行为变化项；
- 未验证的风险和建议下一步（使用通用描述，不指定宿主命令）。
质量门槛
完成前逐项确认：
与相邻技能的边界
| 技能 | 责任 |
|---|
507-inspect | 只读发现摩擦，产出带代码观察证据与置信等级的完整候选报告；不修改。 |
507-simplify | 本技能：逐项建立基线、验证、修改或带证据关闭；可独立接收指定范围。 |
| 需求/规格工作流 | 处理新增能力、产品语义或公开行为变化。 |
| 正常实现/审查工作流 | 执行已批准的行为变化，并验证交付质量。 |
完整报告交给 507-simplify，不要求每张卡都产生代码变更；“关闭”也是有证据的交付结果。重构完成后可用 507-review 独立审查；用户明确要求提交时再用 507-commit。
完成与接力
- 完成信号：每个指定候选都有“修改并验证”或“带证据关闭”的结论，公开契约与可观察行为保持不变。
- 产物：经验证的内部简化、逐项证据结论、测试结果和必要地图更新。
- 候选出口：需要行为变化的候选进入
507-grill、507-prd 或 507-issue；地图变化进入 507-map；完成后进入 507-review，用户明确要求提交时再进入 507-commit。
- 回退条件：无法建立行为基线或验证信号时停止该项，不凭结构偏好继续改造。
