skill-creator

技能创建与修改

修改范围与授权沿用全局规范。用户表达“想用这次经验升级技能”等复盘或升级意向，但具体改动尚未确定时，先展示准备提炼的内容、修改位置和具体改法，确认后再修改；意向不等于批准助手自行补出的方案。用户已确认具体方案或明确委托准确修改时直接执行，不重复索取授权。经授权的技能修改默认在同一次任务中完成源码修改、必要检查、精确提交推送、后台更新和生效核验，发布流程交给 agent-rules，不需要另说“更新”或调用 chat-notes。用户明确只讨论、只检查、只改本地、暂不提交或暂不发布时，遵守该限制。

维护正确的技能源码，保留原名称、专业能力、来源许可及用户修改，只处理本次目标。

根据实际影响选择验证

• 文字整理：含义不变的精简、引用移动或格式修改，核对含义、引用和格式。不能只按字数判断：一句触发、授权或完成条件的修改也属于行为变化。
• 行为修改：改变触发、提问、授权、执行或完成条件时，独立子智能体实际试跑代表性任务，检查动作与成果。推演和格式检查不能代替行为验收。
• 效果比较：需要判断新版是否更好时做新旧对照；新建技能需要证明额外价值时与不加载技能比较。重复试跑、扩大样本和盲评用于解决已有疑问，不默认全套运行。
• 新建技能：明确用途与触发，按实际任务选择最少必要内容，并试跑代表性任务。普通业务任务中遇到困难，不自动新建或安装技能。

工作步骤

1. 读技能源码、相关依赖及已有验证材料，核对本次修改范围。
2. 准备最小修改，保留必要参考、脚本接口和来源；编写方法见 编写与结构。违反后会造成破坏或难以恢复的硬性要求，要点直接写在入口正文，不只放在被引用的文件里，执行模型不一定会打开引用；被引用文件里的这类要求有改动时，同步核对入口。
3. 按上面的影响选择验证。优先使用现有用例，补本次变化涉及的场景；行为试跑与对照方法见 实际评测。
4. 检查执行记录与实际产物，修复本次范围内已发现的问题，复查受影响部分。
5. 按 agent-rules 的技能定向发布完成提交推送、后台更新和同参数只读核验；已有成功回执且当前状态仍一致时不重复更新。交还时按全局规范的“交接”简短说明，未验证项和风险照常写明；关键差异、样例和限制不贴进回复，用户追问时再给。大量成果逐件比较或用户指定时使用现有查看器；只有需要安装包时才打包。

独立试跑

测试执行者使用新上下文，只接收任务、准确的被测技能路径及必要材料，不接收修改讨论、预期答案或评分标准。明确允许写入的临时范围；涉及删除、投稿、仪器或配置时用隔离样本或模拟环境。主智能体根据实际动作、产物和原稿状态验收，而不是只读执行者的“通过”结论。

普通行为测试使用实际运行该技能的模型；中文文风效果评测默认 Opus 4.6，模型身份与上游调用别名按 中文文风评测 核对。对照双方使用相同模型、材料、工具和权限。

直接指定加载技能后执行，验证的是行为；普通请求是否会自动加载技能，需要另外的触发测试。现有触发脚本使用 Claude，不能用其结果声称验证了 Codex/Astra 自动触发，详见 触发优化与工具。

受阻与完成

• 工具、环境或独立执行通道不可用时，继续可完成的源码及静态检查，明确保留相关未验证项；只暂停依赖该项的验收，不以推演冒充实际试跑。
• 区分结构检查、行为试跑、效果对比和运行副本生效。调用成功不代表质量提高；缺少的耗时或 Token 数据标为未知，不估造数字。
• 测试执行者完成指定业务任务即可，不为一次测试再建立技能维护循环；维护技能本身的测试只在实际被改的下层技能上执行必要业务试跑。
• 过程材料沿用共享规则的 过程文件/任务主题/，不默认生成额外报告、查看器或安装包。
• 后台更新和生效核验均成功时，使用“已更新完成”汇报；失败或无法确认时使用“更新没完成”，说明原因、已保留的成果和下一步。只推送源码不能报告完成；用户明确限制发布时说明“按要求未更新”。
• 保留上游 Apache-2.0 许可和接受历史。上游能力继续可用，本地默认流程以本入口为准；更新先比较差异，避免覆盖本地定制。

按需资料

• 编写与结构：触发描述、渐进读取和如何从失败中改进。
• 实际评测：独立任务、新旧对照、评分、盲评和查看器。
• 触发优化与打包工具：现有接口及适用环境。
• 记录格式：保持现有 JSON 结构。
• 中文文风模型约定
• 上游来源