Vision/.agents/skills/task-difficulty-verification/SKILL.md

name, description

name	description
task-difficulty-verification	按需求难度分配验证成本——简单改动只做最省的确认、不跑测试；复杂改动必须做回归测试，避免改完反复返工。在本项目（Unity Vision）里做代码、场景或资源改动时适用。

按难度分配验证成本

目标：简单任务不要为了「保险」浪费 token 去测试；复杂任务必须验证，避免改错没发现、来回返工。

先判定难度，并用一句话说明

动手前判定，并用一句话告诉用户这次算简单还是复杂（例如「这算简单任务，改完直接给你」）。判错了用户能当场纠正。

简单任务（符合任一）：

• 单文件小改、文案 / 命名 / 日志 / 注释
• 只读查询、看状态、回答问题
• 加一个对象、调一个参数、改个颜色或层级
• 删除无用代码，且无人引用
• 影响面单一，且用户已明确说明期望结果

复杂任务（符合任一）：

• 跨文件 / 跨模块，或改动落在公共 API、被多处调用的代码上
• 核心逻辑、算法、状态机、存档或数据格式、构建配置、包依赖、渲染管线、材质 / Shader
• 改动会引入其他代码要使用的新类型、新接口、新字段
• 改错了不容易被发现，或者可能破坏原本能跑的东西
• 用户明确要求验证或回归

拿不准时按复杂处理。

「删除兜底代码」属于哪一档

删运行时的后备逻辑（自动查找节点、默认值、容错分支）时，别按行数、也别按动了几个文件判，按删掉之后出错看不看得见判：

• 后备路径其实没被走到（引用 / 配置本来就接全）→ 等同删死代码，简单任务，同一件事涉及几个文件也一样。只做一次最便宜的确认：查一遍引用确实接好，然后交付。
• 后备路径确实在兜着东西（有地方没接）→ 复杂任务。这种改动出错的表现是「不报错、就是不工作」，必须回归。
• 光读代码分不出是哪种：后备代码在的时候，「引用是否接全」本身是看不见的，所以不能拿「我只是删死代码」当免检前提。查一次实际接线就能分清，而这个检查本身就是那次最便宜的确认。

简单任务：不做测试

• 直接改完交付，最多做一次最便宜的确认：读一次返回值、看一眼 transform、curl 一次接口。
• 不跑测试套件，不做回归，不为了确认把整个项目重读一遍。
• 不要用「更保险」当理由补验证步骤。
• 本项目的简单改动不要再跑这些：Unity 编译检查、控制台检查、进 Play 模式实测、保存场景 / 预制体。它们只在「复杂任务：必须回归」那一档才做。

典型的简单改动：改字段类型 / 字段名 / 默认值、文案 / 注释 / 日志、调 Inspector 数值。

复杂任务：必须回归

按下面顺序做，够用即停：

1. 先让编译错误清零：读 mcpforunity://editor/state 等到 compilation.is_compiling == false，再 read_console(types=["error"], count="10")。
2. 跑覆盖本次改动的测试（run_tests，EditMode / PlayMode 按改动性质选），只跑相关范围，不重跑全量。
3. 回头验证本次改动会碰到、但原本正常的行为：调用方、相邻功能点、序列化数据、场景里已存在的对象。
4. 结果讲清楚：跑了什么、过没过、哪部分没测以及原因。

避免重复修改

• 验证通过就停手，不要顺手再改别的地方。
• 验证不过：定位根因改一次，重跑同一条验证；不要一边猜一边连续打补丁。
• 同一处连续两次修不好，停下来把现象和判断交给用户决定。

用户明确要求跑测试、或明确说不用测时，以用户的要求为准。