tune-skill

PDCA：调优技能

任务约定

方法论：PDCA（pdca）

任务：针对具体观察到的行为问题，改进一个现有 Agent 技能；仅在该技能包内进行最小且有证据支撑的更改，并将方法论、原始任务约定、多技能和自我调优问题转交给对应的工作流处理，而不是直接修补。

受众：维护此仓库中技能的 Agent，以及审查技能更改提案的人员。

背景：权限：解决并遵守仓库说明，然后找到维护中的源副本。已安装副本和运行时副本仅作为证据，在使用此技能期间保持只读。全局副本始终为只读。后续任何安装或同步都是由人负责的独立任务，不属于 tune-skill 的范围。保留无关的工作树更改。绝不提交、推送、安装或修改全局副本。

PDCA 运作框架： 计划：从头到尾阅读目标 SKILL.md、其中与行为相关的链接资源、失败的输出或对话，以及任何可用的源代码／运行时差异。锁定一份投诉约定，其中包含行为类别、证据、预期行为和保留边界。根据工件而非用户提供的信息获取事实。如果仍有重要的产品或范围决策不明确，则进行一次有界访谈，最多提出三个问题：一次只问一个问题，说明哪些工件事实导致决策悬而未决，给出建议答案，并且在达成明确共识前不做任何更改。访谈回合也使用四行输出：Result: blocked；Change 写明尚未解决的决策，并确认没有进行编辑；Evidence 提供相关工件事实和建议；Next 中只包含一个要问人的问题。如果三次提问后仍存在决定性歧义，则保持阻塞并指出该歧义；不要猜测或继续访谈。如果现有证据无法确定由哪个类别负责投诉，则在分类前返回 blocked；缺少直接编辑批准不会妨碍分类，但始终会阻止 Do。否则，按以下优先顺序采用第一个匹配的类别：（1）自我调优始终返回 methodology-selector 和 methodology-skill-creator，并在一个独立的设计／创建会话中进行，该会话不会递归运行当前的 tune-skill；（2）外部原因：工具、权限或过期的运行时副本足以完全解释所报告的行为；（3）返回方法：由方法生成的技能选错了方法；（4）返回约定：所选方法有效，但其原始八个字段有误；（5）返回循环：涉及多个技能、共享约定、架构、包外问题、大范围重设计，或任何责任不属于一次直接 tune 的修正；（6）直接调优：仅当剩余原因和完整修正都位于一个目标包内时适用；否则返回 blocked。不得仅因某个特定的较早类别要在目标包外解决，就将其重新分类。使用确切的负责人：返回方法交给 methodology-selector，然后交给 methodology-skill-creator；返回约定则重建 methodology-selector 的八字段方法约定，然后返回 methodology-skill-creator；返回循环交给 loop-orchestrator，并提供新的 loop-goal 意图；外部原因交给证据中指出的人或工具／运行时负责人；阻塞交给负责补充缺失证据或权限的人。对于直接调优，追溯失败输出，找出导致问题的指令、遗漏、冲突或工作流顺序。规划最小的行为更改，以修复投诉和一个相邻案例，同时不影响需要保留的行为。展示投诉、有证据支撑的诊断、目标包中的确切文件、拟议的行为更改、需要保留的行为以及验证计划。批准提案本身必须使用四行输出：Result: blocked；Change 写明确切文件、拟议行为和需要保留的行为；Evidence 概述投诉、诊断和验证计划；Next 请人批准或更正该确切范围。等待人工批准，除非该提案已展示并获批。 Do：获得批准后，只编辑一个目标技能包内因果上必需的文件；为完成一项连贯的修正，必要时可包括其 SKILL.md、参考资料、评估或脚本。如果新证据表明另一个包、共享契约、方法论或原始契约也相关，则在扩大编辑范围前停止，返回 Plan，并依据当前证据按相同优先级重新分类。不要自动还原、重置或丢弃已做出的更改。若在编辑后发生重新分类，返回 Result: blocked；在 Change 中列出确切的部分修改文件并说明状态，在 Evidence 中给出重新分类的证据，并在 Next 中指出必须决定是否保留或还原这些文件的负责人及其所属工作流。不要将无关清理混入更改。

Check：检查目标包的完整差异，并运行可用的结构验证器。默认情况下，所有行为验证均不得修改内容：使用只读工件或隔离的测试框架，不得让测试人员编辑共享仓库或运行环境、同步已安装的全局副本、联系外部系统或执行其他会产生实际影响的操作。如果有效证明必须进行修改，则停止并另行申请授权；无法获得安全证明时不得完成任务。复现原始故障或最小的等效证据案例，运行一个可揭示针对示例过度拟合的相邻案例，并针对投诉内容和之前的版本或差异进行一次非修改性的独立冷读检查。Markdown 检查不属于行为证据。如果检查无法运行或未通过，不得声称任务已完成；应返回 Plan，提出新方案、转交负责工作流或阻止任务。

Act：只有当全部三项行为检查均支持投诉契约且范围保持不变时，才保留更改。否则，应通过新批准的计划进行调整、转交负责工作流，或停止。在完成该检查与行动决策后结束本次调用。

必需输出：严格只返回四行简洁内容，不添加默认的详细信息：Result: changed | routed | blocked；Change: 行为变更或转交／阻止的原因；Evidence: 原始／等效案例、相邻案例和冷读结果，或支持转交／阻止的证据；Next: 确切的下一项技能、负责人，或 none。仅在有人要求时提供诊断或差异详情。

方法适用性

• 最适合：通过重复的测量周期改进工作流。
• 不适用：没有后续周期的一次性决策。
• 选择依据：技能调优会在实际使用中反复进行：规划一项范围明确的行为变更，执行一次，将证据与投诉进行比较，然后保留、调整、转交或停止，不得暗中扩大范围。

标准方法

来源：PDCA 标准参考

定义

通过规划变更、小规模运行、检查证据，并根据所学采取行动，来改进流程。

适用性

• 最适合应通过重复的测量周期改进的工作流。
• 不适用于没有后续周期的一次性决策。

原则

• 计划的变更应足够小，以便进行测试。
• 在固定边界内运行。
• 将结果与预期进行比较。
• 在下一个周期开始前进行标准化、调整或停止。

步骤

1. 规划最小且有用的变更。
2. 在限定范围内运行一次。
3. 根据假设检查证据。
4. 通过保留、更改或停止该循环采取行动。

质量问题

• 变更是否足够小，以便评估？
• 是否测量了结果？
• 下一步行动是否基于证据？
• 运行期间范围是否保持不变？

停止

在完成检查与行动决策后停止。不要为一次性任务凭空安排下一个周期。如果任务不适用于 PDCA、缺少必要上下文，或无法在不猜测的情况下满足验证要求，则停止并寻求人类帮助。

验证

• 在提出更改之前，先将问题限定在用户所述的抽象层级，并根据当前工件证据进行追溯。
• 有界访谈每次只询问一个决策问题，并提供建议答案；只有在调查代码库后仍存在重大歧义时才进行访谈。
• 本次运行将工作分类为直接微调、返回方法论、返回契约、返回循环、外部原因或受阻，并指出负责后续处理的工作流。
• 在人工批准确切诊断、文件、行为更改和保留边界之前，不得编辑目标源文件。
• 直接微调只更改单个目标技能包中因果上必需的文件，不改动已安装副本或全局副本。
• 通过方法论生成的技能须保留其选定的方法论和八字段契约；不兼容的修正应上报至上游。
• 原始故障或与证据等效的故障、一个相邻案例，以及一次不修改内容的独立冷读，均支持任务完成；任何检查缺失或失败都会阻止任务标记为完成。
• 最终回复仅包含 Result、Change、Evidence 和 Next，除非用户要求详细说明。

需提供的证据：

• 投诉契约，以及用于诊断的工件证据。
• 经批准的文件范围，以及目标技能包的最终差异。
• 原始案例或与证据等效的案例、相邻案例和独立冷读的观测结果。
• 最终四行报告：Result、Change、Evidence 和 Next。

人工审查与停止条件

• 在有界访谈后，投诉、预期行为或保留边界仍不明确。
• 证据表明方法论或原始八字段契约有误。
• 修正需要涉及其他技能包、共享契约、架构重设计，或由 tune-skill 修改自身。
• 超出已批准的文件范围。
• 无法运行原始故障、相邻案例或独立冷读，或者其结果不支持任务完成。

必须先获得人工批准，才能在审查确切诊断和拟议更改后编辑目标技能包。

边界

• 仅采用 PDCA；不要混用其他方法论。
• 不得通过更改任务契约来降低验证难度。
• 未获得所需人工决策时，不得执行批准操作。
• 当任务不再符合记录的方法适配情况时，应停止。