Skill stabilize

Skill: SKILL 收口稳定器

用于在不扩能力、不改边界、不换交付效果的前提下，对已有 SKILL 做深度分析、机械收口和稳定性提升。

本技能处理的是已有 SKILL 的收口优化闭环，不是新建技能，也不是独立质量评审。它回答四个问题：

• 哪些表述或结构会让同一输入在多次执行中产生不同结果。
• 哪些内容可以收掉而不改变功能、性能或效果。
• 哪些内容必须保留，并标记为有意边界。
• 如何把评估结论直接落到本地文件，形成更稳定的 SKILL。

本地资源与权威顺序

1. 当前目标 SKILL 的 SKILL.md frontmatter：只定义技能标识与触发描述。
2. 当前目标 SKILL 的 SKILL.md 正文：只定义流程、选择规则、门禁、失败处理和交付要求；正文与其他本地文件冲突时，以正文为准。
3. 当前目标 SKILL 的本地 references/、scripts/、assets/、模板、示例和元数据：只承担局部细节、模板、素材、脚本或补充职责，不补充、不覆盖正文中的权威规则。
4. 本技能自身文件：只定义如何分析和收口目标 SKILL，不替目标 SKILL 提供缺失能力。

固定术语

• 可安全收口项：同时通过阶段 3 三重判断的候选修改。
• 有意边界：无法机械化，且继续收口会改变功能、性能或效果的内容；输出时必须写作“有意边界：{内容}；保留原因：{原因}”。
• 阻塞性问题：缺少目标路径、路径不可读、多个候选无法唯一确定、或修改权限与输出模式冲突。
• 已足够稳定：阶段 2 识别的全部漂移源都已关闭，或标记为有意边界，且不存在可安全收口项。

终止判定

判定优先级固定为：阻塞并停止 > 继续收口 > 停止并输出结果。

• 阻塞并停止：存在 阻塞性问题。
• 继续收口：不存在 阻塞性问题，且存在至少 1 个 可安全收口项。
• 停止并输出结果：不存在 阻塞性问题，且不存在 可安全收口项。
• 已足够稳定：停止并输出结果，并且阶段 2 识别的全部漂移源都已关闭或标记为 有意边界。

硬边界

以下约束必须同时满足；任一项不满足时，不进入收口修改：

1. 不改变任何功能边界、触发条件、输入输出、执行方式、性能要求和交付效果。
2. 不引入依赖外部上下文才能理解的内容。
3. 不新增模糊词、可多解条件、隐含例外或临场判断。
4. 不用“通常、尽量、优先、适合、相关、可能”等软词替代规则；能枚举就枚举，能固定就固定，能判定就判定。
5. 不删除必要门禁、失败处理、边界控制或回退机制。
6. 不把已有资源文件变成新的自由发挥空间。
7. 所有修改都必须能追溯到当前目标 SKILL 及其本地资源。
8. 某项内容无法机械化且继续收口会改变功能、性能或效果时，保留并标记为“有意边界”。
9. 某项内容可以收掉且不改变功能、性能或效果时，必须收掉。

何时使用

• 用户要求优化、提升、收口、稳定、规范、统一或压缩已有 SKILL 的表达与规则。
• 用户要求在不改能力边界的前提下，减少歧义、减少漂移、增强自包含或提高重复评测一致性。
• 用户要求把对某个 SKILL 的评估结论直接落地成修订结果。
• 用户要求梳理多文件 SKILL 的权威顺序、资源职责和重复规则来源。

不应触发的情况：

• 用户要新建一个全新 SKILL，或把现有 SKILL 扩能力、扩边界、改触发范围。
• 用户只要求独立评估、评分、审查或报告，而不要求修改。
• 用户要做恶意脚本、来源可信度或权限风险审查。

分流规则：

• 只做独立评估，不修改文件：转交 skill-evaluate。
• 需要扩能力、改边界、改触发范围或重设计：转交 skill-create 或进入重构流程，不按本技能收口。
• 需要在现有边界内直接优化落地：使用本技能。

输入约定

若用户提供以下字段，按字段直接执行：

• SKILL_ROOT：目标 SKILL 根目录。
• output_mode=analysis：只做分析，不修改文件。
• output_mode=edit：直接修改目标文件。

若用户未提供字段，按以下顺序判断：

1. 用户明确要求“只分析、只评审、不要改文件”时，使用 analysis。
2. 用户明确要求“优化、修改、修订、落地、直接改”时，使用 edit。
3. 其余情况只问阻塞性问题；一次最多问 3 个。

标准流程

0. 确定对象与模式

动作：

• 确认目标 SKILL 路径、输出模式和是否允许修改。
• 判断目标是单文件 SKILL 还是多文件 SKILL。
• 判断是否存在需要先分流到 skill-evaluate 或 skill-create 的请求。

输出：

• 目标路径。
• 输出模式。
• 本轮是否修改文件。
• 本轮是否需要分流。

通过标准：

• 能说明“改哪个 SKILL、以什么模式处理、是否直接改文件”。

1. 通读本地文件并建立证据表

动作：

• 按固定读取规则读取目标 SKILL 目录及其所有本地资源。
• 建立文件清单、职责清单和权威顺序。
• 记录哪些规则在主文件定义，哪些规则在资源文件定义，哪些规则重复定义。

固定读取规则：

1. 先按路径字典序扫描目标目录下全部文件和子目录。
2. 再按路径字典序读取以下后缀的文本文件：.md、.markdown、.txt、.json、.yml、.yaml、.toml、.ini、.csv、.tsv、.py、.sh、.js、.ts、.jsx、.tsx、.mjs、.cjs、.html、.htm、.xml、.svg。
3. 其他后缀的文件若被正文、元数据、示例、模板或脚本显式引用，只记录路径、文件类型、引用位置和推断用途，不读取内容。
4. 不存在本地资源目录时，记录为“无该资源目录”，不创建新目录；目录存在但为空时，记录为“资源目录为空”。

固定检查项：

• frontmatter 与正文是否分责清楚。
• 资源文件是否承担了不应承担的流程或判定规则。
• 同一规则是否在多个文件重复出现。
• 路径、模板、示例、脚本是否被正文直接或隐式依赖。

输出：

• 证据表。
• 权威顺序。
• 重复规则清单。

通过标准：

• 只读本地文件即可说明每条核心规则的权威来源。

2. 识别漂移源

按以下顺序检查所有可能导致漂移的来源：

1. 模板选择。
2. 输入范围。
3. 读取顺序。
4. 优先级。
5. 示例选择。
6. 失败处理。
7. 记录口径。
8. 重复表述。
9. 可选条件。
10. 降级路径。
11. 资源文件职责不清。
12. 任何会让不同执行者得出不同结论的自由解释空间。

输出：

• 漂移源清单。
• 严重性排序，固定等级为：
  • S1：会改变触发、执行、输出、失败处理或权限判断。
  • S2：会导致不同执行者选择不同流程、模板、资源或权威来源。
  • S3：会导致输出结构、术语、记录口径或示例选择不一致。
  • S4：只影响表达简洁性，不影响执行结论。
• 同级排序固定为：先按证据位置在目标 SKILL 中的首次出现顺序，再按文件路径字典序。
• 每项对应的证据位置。
• 每项对应的处理类别：必须修改、保留为有意边界、转交其他技能、无需处理。

通过标准：

• 能指出“为什么同一输入会得到不同结果”。

3. 三重判断候选修改

对每一个候选修改，按以下顺序判断；三项全部满足才允许修改：

1. 不会改变功能、性能或效果。
2. 只是消除歧义、增强确定性或统一权威口径。
3. 会让同一输入在多次运行中的结果更稳定。

任一项不满足时：

• 不修改该项。
• 若继续收口会改效果，标记为“有意边界”。

允许的处理类别固定为：

• 必须修改：三重判断全部通过。
• 保留为有意边界：继续收口会改变功能、性能或效果。
• 转交其他技能：请求本身需要扩能力、改边界、改触发范围，或只要求独立评估。
• 无需处理：该项不构成漂移源，或已被更高优先级规则完全覆盖。

4. 收敛为机械规则

对允许修改的内容，按以下目标收口：

• 固定顺序。
• 固定枚举。
• 固定优先级。
• 固定门禁。
• 固定失败路径。
• 固定输出结构。
• 固定权威来源。

禁止行为：

• 不新增自由选择分支。
• 不新增“视情况”“看需要”“相关内容”这类口径。
• 不在多个文件重复扩展新的选择条件。

5. 处理多文件职责

单文件 SKILL：

• 只优化该文件，不额外发散。

多文件 SKILL：

• 先固定权威顺序，再修改文件。
• 主文件只保留流程、选择规则、门禁、失败处理和交付要求。
• 资源文件只保留局部细节、模板、参考、素材或脚本职责。
• 同一条规则只能有一个权威来源；其他文件只引用，不复制，不另起口径。

6. 执行改写

改写时固定使用以下规则：

1. 把“建议、通常、优先、尽量”收敛成“必须、只、固定、按以下顺序、否则”。
2. 把模糊描述改成可判定列表。
3. 把多个可能路径压成单一优先级链。
4. 把自由选择压成固定顺序、固定阈值或固定范围。
5. 把失败处理写成明确的停止、提示、降级或回退规则。
6. 把重复内容压成一句权威定义，其他地方只引用。
7. 如果一段话只是重复已定义规则，删掉冗余解释。
8. 如果一段话无法机械化且继续收口会改效果，标记为“有意边界”。

7. 复核闭环

修改后按以下顺序复核：

1. 是否已复跑最小场景：正向触发、边界/误触发、失败/回退；若目标 SKILL 涉及写文件、联网、脚本、权限或敏感信息，再补 1 个高风险场景。
2. 是否还存在同一输入会产生不同结论的地方。
3. 是否还存在重复规则来源。
4. 是否还存在资源文件职责越界。
5. 是否还存在可由更机械写法替代的表述。
6. 是否误改了功能边界、触发条件、输入输出、执行方式、性能要求或交付效果。

若存在阻塞性问题，先停止并报告阻塞性问题；若仍存在可安全收口项，继续收口；若不存在可安全收口项且所有漂移源已关闭或标记为有意边界，停止并判定为 已足够稳定；若继续收口会改变功能、性能或效果，停止并标记为“有意边界”。

用户交互规则

• 用户已给出目标路径时，直接读取，不做流程性追问。
• 目标缺失、路径不可访问或多个候选无法判断时，只问阻塞性问题；一次最多问 3 个。
• analysis 模式只输出分析结果，不修改文件。
• edit 模式直接修改目标 SKILL；修改前不枚举多版方案，除非用户明确要求。
• 删除能力、改变触发范围、扩能力、引入新外部依赖、拆分/合并 SKILL 时，停止本技能并说明已超出收口边界。
• 用户要求“直接落地、直接体现到 SKILL 中”时，跳过方案枚举，直接修改目标文件。

输出模式

analysis

按以下顺序输出：

1. 结论：是否需要修改，是否已足够稳定。
2. 仍然存在的漂移源，按严重性排序。
3. 每个问题为什么会导致漂移，以及是否允许修改。
4. 总体判断：是否已接近闭合，哪里还没闭合。

edit

按以下顺序输出：

1. 结论：是否需要修改。
2. 直接给出可落地的修订结果。
3. 目标只涉及 1 个文件时，输出完整替换文本；涉及多个文件时，输出精确 patch。
4. 明确说明哪些问题已经收掉，哪些属于有意保留的边界。

质量门禁

输出前必须同时满足以下条件：

• 同一输入多次处理，结果一致；若因有意边界无法完全一致，必须显式标注。
• 只读本地文件就能独立理解和执行。
• 所有规则都能追溯到目标 SKILL 及其本地资源。
• 不存在“看情况”“视而定”“相关内容”这类未机械化口径；若存在且未通过阶段 3 三重判断，已标记为“有意边界”。
• 如果还有更确定、更简洁、更机械的写法，且不改变功能、性能或效果，已经采用。

失败处理

• 目标路径缺失：只询问目标 SKILL 的明确路径或目录名。
• 目标目录不可读：停止修改，说明无法建立证据表。
• 本地资源冲突且无法判定权威来源：先输出权威顺序冲突，不直接改写冲突规则。
• 用户要求扩能力、改触发、改边界：停止本技能，说明该请求应转交重构或新建流程。
• 某项内容继续收口会改变功能、性能或效果：保留原内容并标记为“有意边界”。
• 用户只要独立评估：转交 skill-evaluate，不在本技能内伪装成优化闭环。