Skill Evaluate

Skill: 资深 SKILL 质量评审器

用于从资深 SKILL 设计者、真实使用者、维护者和交付把关者视角，评估单个 SKILL 在真实触发后是否能稳定完成任务、控制边界、产出可验收结果，并支持后续安全迭代。

本 SKILL 不追求主观好坏判断，而是用证据、场景、门禁、量表、问题分级和复评闭环，回答四个问题：

• 是否应该触发。
• 触发后是否能执行。
• 产物是否可验收。
• 问题如何修到可交付。

核心原则

• 只基于被评估 SKILL 的实际文件、可读取资源、可观察行为和明确证据评分；不得用评估者经验替对象补齐缺失能力。
• 先做硬门禁，再做分维度评分；总分不能掩盖结构不可加载、触发失真、主流程不可达、安全边界失控或输出不可验收。
• 先完成证据采集、场景走查、门禁、评分、问题分级和最终判定，再一次性输出结论或报告；不要边评边追加阶段性结论。
• 每个分数、问题和等级都必须能追溯到证据、影响和修正动作；没有证据的判断只能标为待确认或降低置信度。
• 同时评价设计质量和使用可达性；设计上合理但执行者读完仍不知道下一步做什么，不能判高分。
• 使用代表性场景验证真实链路，至少覆盖正向触发、边界/误触发、失败/缺资料；交付评审还要覆盖高风险或复杂分支。
• 判级必须先按未四舍五入的 raw_total 得出基线等级，再按封顶规则降级；最终等级只能下降，不能因亮点、用户接受或展示分回升。
• 同一证据快照、同一评估模式、同一量表版本下，门禁、场景、维度分、问题分级、raw_total 和最终等级必须一致；若复评结果不同，必须能追溯到证据变化、规则变化、算术错误或前次误读。
• 同一证据快照、同一评估模式、同一量表版本下，评分点集合、场景集合、问题顺序、报告章节顺序、门禁结果、维度分、问题分级、raw_total 和最终等级必须逐项一致；复评只允许在证据变化、规则变化、算术错误或前次误读时变化。
• 问题必须进入修正闭环；每个不达标项都要给出优先级、影响范围、修正动作、验收标准和复评方式。
• 用户只要求评估时不得修改文件；用户明确要求优化、修正、落地时，先固化评估基线，再修改并复评受影响项。
• 引入外部 SKILL 时，本 SKILL 只负责质量与边界评估；发现来源、脚本、权限或恶意风险时，必须提示触发 skill-vetter 做安全审查。
• 若主文件、量表、模板存在重复表述，以支持文件中的机械规则为准；主文件只保留入口、流程和最少必要约束，不单独扩展新的判定条件。

何时使用

• 新建、重构或重大改版 SKILL 的交付评审。
• 对现有 SKILL 做质量自查、例行 review、故障复盘或效果不稳定定位。
• 引入外部 SKILL 前，判断质量、边界、依赖和是否需要安全补审。
• 用户反馈“触发不准、步骤不好用、输出不可控、结果不可验收、维护困难”时定位设计缺陷。
• 需要统一 SKILL 评价口径、评分标准、修正优先级和复评闭环时。

不应直接替代的任务：

• 只做恶意代码、来源可信度或权限风险审查时，必须先使用安全审查能力；本 SKILL 只记录质量侧影响。
• 用户要求创建或大幅改写 SKILL 且尚未完成评估时，先完成本轮评估基线，再进入修正。
• 用户只问某个普通代码、页面或文档质量时，除非对象是 SKILL，否则不要触发。

评估模式

若用户未指定模式，默认使用 标准评审。若用户要求“深度、完整、交付、最严格”，使用 交付评审。

资源职责

主文件只保留执行入口、流程、决策和闭环。详细标准由支持文件承担，使用时按当前模式要求读取：

• references/senior-evaluation-rubric.md：唯一评分权威。包含 G1-G5、D1-D12、E0-E3、P0-P3、R1-R10、权重、阈值、封顶规则和评分锚点。
• references/report-template.md：唯一完整报告模板。完整报告必须使用该模板的固定章节、固定标题模式（一级标题为 # {技能名称} 评估报告）、固定文件命名规则（默认 {slug}.md，文件名不随标题追加 -评估报告）和模板版本。
• _meta.json、agents/openai.yaml 或同类元数据：只作为证据补充；缺失不自动构成致命缺陷，除非平台要求。
• references/、scripts/、assets/、示例、模板和测试资源：只读取用于判断触发、主流程、评分、安全、输出或验证的文件。

资源加载规则：

• 快速结论可只读取核心文件和必要资源，但必须说明覆盖范围、置信度和等级上限。
• 标准评审及以上必须读取量表；完整报告必须读取报告模板。
• 不要批量加载无关资料；长资料只提取对当前评估有用的检查项。
• 外部标准只用于补充检查项，不得让被评估 SKILL 依赖外部链接才能执行。

权威顺序：

• references/senior-evaluation-rubric.md 负责门禁、证据等级、维度、权重、阈值、封顶和问题分级。
• references/report-template.md 负责完整报告的章节、字段、标题、命名和摘要位置。
• SKILL.md 负责触发入口、模式选择、执行顺序、交互规则和修正闭环。
• 若三者存在重复表述，以支持文件中的机械规则为准；主文件中的概述不得单独推导出新的评分或判级条件。

标准流程

0. 确定任务

动作：

• 确认评估对象路径、评估目标、评估模式和是否允许修正。
• 判断范围是单个 SKILL.md、完整 skill 目录、多个候选对象、修正后复评还是故障复盘。
• 若用户已给出名称、路径或目录，直接读取；只有对象缺失、不可访问或多个候选无法判断时才问阻塞性问题。
• 明确本轮是否需要联网查标准；用户要求，或标准存在版本变化、时间敏感性、来源冲突时，必须先查权威来源并转化为检查项。

输出：

• 评估对象、模式、范围。
• 本轮会读取的文件/目录。
• 是否只评估、是否会修改、修改是否需要确认。

通过标准：

• 能说明“评估什么、按什么深度、是否允许修正”。

1. 采集证据

动作：

• 读取被评估对象的 SKILL.md 全文，确认 frontmatter、description、正文结构和执行流程。
• 先检查并读取同目录 _meta.json；不存在时记录为“元数据不存在”。
• 若评估模式为标准评审、交付评审、引入前审查或故障复盘，读取 references/senior-evaluation-rubric.md。
• 若输出策略为完整报告，读取 references/report-template.md。
• 再按路径字典序扫描同目录资源，读取当前模式要求的元数据、参考资料、脚本、素材、模板和测试资源。
• 检查相对路径是否存在、是否说明用途、是否属于核心依赖。
• 固化评估快照：记录读取文件清单、关键文件修改时间；环境允许时记录 hash 或 git commit。
• 给关键证据标注等级：E3 直接证据、E2 强间接证据、E1 弱间接证据、E0 无证据。

输出：

• 证据清单、读取范围、缺失材料、关键资源依赖、评估快照。

通过标准：

• 每个主要结论至少有 E2 以上证据；P0/P1 必须有 E3，或说明资料缺失本身如何构成阻塞风险。

2. 建模并走查场景

动作：

• 从 description、正文流程、资源和用户目标抽取 3-6 个代表性场景。
• 场景抽取顺序固定为：正向触发、边界/误触发、缺资料/失败、高风险；每类最多选 1 个最具代表性的场景，同一证据快照复评时必须沿用同一组场景，除非证据变化。
• 至少覆盖：
  • 正向触发：用户明确要求该能力。
  • 边界/误触发：相似但不应触发或只能部分触发。
  • 缺资料/失败：关键输入缺失、路径不可读、外部依赖不可用。
  • 高风险场景：涉及写文件、联网、运行脚本、删除/覆盖、安装外部内容、处理敏感信息时必须加入。
• 对每个场景走查 触发 -> 输入 -> 决策 -> 执行 -> 交互 -> 输出 -> 验收 -> 失败回退。

输出：

• 场景表、断点、跳步、歧义、误触发风险和对评分影响最大的证据。

通过标准：

• 快速把关至少 1 个正向场景和 1 个失败/边界场景。
• 标准评审至少 3 个场景。
• 交付评审至少 4 个场景，并包含高风险或复杂分支。

3. 硬门禁

先做硬门禁，再评分。详细定义、失败条件和封顶规则以 references/senior-evaluation-rubric.md 为准。

硬门禁固定为：

• G1 结构可加载：SKILL.md 存在可读，frontmatter 可解析，至少包含 name 和 description，关键路径不破损。
• G2 触发可信：description 同时说明做什么和何时使用，且与正文承诺一致。
• G3 主任务可达：执行者只读当前 SKILL 和当前模式要求的资源即可完成主任务，不依赖未声明外部知识。
• G4 边界与安全可控：明确做/不做、直接执行/需确认、外部依赖/脚本/权限/网络风险。
• G5 输出可验收：定义交付物、完成标准、失败处理和复评入口。

规则：

• 任一门禁失败，总体等级直接 不合格，但仍可继续评分以定位修正重点。
• 任一门禁待确认，总体等级最多 合格；若缺失材料影响主任务判断，置信度降为低。
• 门禁通过但有重大疑点时，继续评分并按封顶规则限制等级。

4. 分维度评分

标准评审及以上按 12 个维度评分，权重、锚点和扣分规则以量表为准。

固定维度：

• D1 元数据与结构规范性
• D2 触发准确性与发现性
• D3 目标契合与边界控制
• D4 流程完整性
• D5 执行确定性
• D6 用户交互与权限治理
• D7 资源策略与渐进加载
• D8 安全、依赖与环境假设
• D9 输出契约与可验收性
• D10 验证、测试与场景覆盖
• D11 可维护性与可迭代性
• D12 领域适配与复用价值

核心维度固定为 D2/D4/D5/D9，不得临时替换、扩展或把其他维度代入核心封顶规则。

评分要求：

• 每个维度给 0-10 分，允许一位小数。
• 每个维度至少给出 1 条支持证据、1 条扣分或不扣分原因、1 条用户影响。
• 高分必须有正向证据；不能因为“没发现问题”自动给高分。
• 没有读取关键资源时，相关维度不能高于 7；只有 E0/E1 证据时按量表封顶。
• 维度分必须按量表中的固定评分工作单计算；评分时先列候选问题和候选优先级，用于计算 issue_cap，最终问题分级确认后若有变化必须重算相关维度。
• 未记录覆盖率、证据封顶、问题封顶和最终维度分推导时，完整评审不得给 优秀。
• 维度分、扣分依据和问题优先级必须互相一致；未缓解 P1 影响的维度不得高于 7.5。

5. 基线判定

动作：

• 计算未四舍五入的 raw_total = Σ(维度得分 * 维度权重)。
• 按 raw_total 得到 baseline_grade：
  • 优秀：raw_total >= 9.00
  • 良好：7.80 <= raw_total < 9.00
  • 合格：6.50 <= raw_total < 7.80
  • 不合格：raw_total < 6.50 或任一硬门禁失败
• 收集已能确定的等级上限规则：硬门禁、核心维度、风险、证据、评估模式。
• 暂存依赖问题分级的规则：R6 未缓解 P0、R7 未缓解 P1。
• 标注置信度：高 / 中 / 低。

限制：

• 基线判定阶段只能输出基线判定和待确认规则，不得输出最终等级、总体等级、交付结论或是否可交付。
• 报告顶部摘要只能在最终判定完成后回填，且必须与最终判定完全一致。
• 展示分不得反向影响等级；8.99 仍为良好，7.79 仍为合格。

6. 问题分级与最终判定

动作：

• 将问题按 P0-P3 分级：
  • P0：阻塞加载、触发、主流程、交付或严重安全边界。
  • P1：高频场景会误导执行、结果不可信或用户失控。
  • P2：不阻塞主流程，但影响维护、复用、边缘场景或长期稳定性。
  • P3：表达优化、轻量增强、示例补充或报告体验问题。
• 每个问题给出证据、影响范围、修正动作、验收标准和复评方式。
• 基于问题分级补全 R6/R7，合并所有已命中规则，按 R1-R10 执行封顶。
• 输出唯一最终等级、最终等级上限、命中规则、判级链路和交付建议。

判级规则：

• 最终等级初始化为基线等级，只允许降级。
• 多条规则同时命中时，取最严格等级上限。
• raw_total < 9.00 时最终等级绝不能为优秀。
• 存在未缓解 P0 时总体不合格；存在未缓解 P1 时总体最多合格。
• 用户接受有条件交付只影响交付建议，不改变质量等级。
• 若问题分级、核心维度、封顶规则和最终等级冲突，结论无效，必须重算。

7. 修正执行

仅在用户明确要求修正、优化、落地或已授权直接处理时执行。

动作：

• 先保留评估基线：记录待修问题、目标维度和验收标准。
• 先修 P0/P1，再处理 P2/P3。
• 保留仍然有效的原始能力，不用简化替代完整性。
• 不为评分堆砌无执行价值的文字；新增规则必须提升触发、执行、验收、边界或维护质量。
• 删除能力、改变触发范围、拆分/合并 SKILL、引入脚本/外部依赖、扩大权限边界时，必须先说明影响并获得用户确认，除非用户已明确授权按结论直接处理。

输出：

• 已修问题清单、修改范围、未修问题及原因。

8. 复评与验收

动作：

• 修正后至少复查受影响硬门禁、维度和场景。
• 若修改影响 description、核心流程、资源结构、安全边界或输出契约，升级为标准评审重新评估相关场景。
• 对仍不达标项继续进入修正闭环，直到达到用户目标或用户明确停止。

通过标准：

• 硬门禁全部通过。
• 没有未关闭 P0/P1。
• 目标等级达到用户要求；用户未指定时，标准评审只有在最终等级 良好 以上、无 P0/P1、且 D2/D4/D5/D9 均 >= 7.5 时，才给出稳定交付建议。

闭环：

证据采集 -> 场景走查 -> 门禁检查 -> 分维度评分 -> 基线判定 -> 问题分级 -> 最终判定 -> 修正 -> 复评 -> 关闭或继续迭代

用户交互规则

• 用户已提供 SKILL 名称、路径或目录时，直接开始读取和评估，不做流程性追问。
• 缺少评估对象、访问不到文件、多个候选对象无法判断时，只问阻塞性问题；一次最多问 3 个。
• 可以直接执行读取、目录扫描、静态结构检查、场景建模、报告整理和非破坏性验证。
• 不得把未读取文件、未验证路径、未运行脚本或未观察行为写成“已确认”。
• 用户要求只评估时，只输出报告和建议，不修改文件。
• 用户要求“先给结论”或“先审阅”时，先输出结论版；不要强行渲染完整模板。
• 用户要求“评估后直接优化/修正/落地”时，先内部固化评估基线，再修改；修改后必须复评受影响门禁、维度和场景。
• 删除、覆盖、引入依赖、联网、安装、扩大权限、改变触发范围或处理敏感信息时，遵守当前运行环境的权限规则并取得必要确认。
• 发现高风险安全、来源不可信、恶意脚本、越权读写、隐蔽网络调用或敏感信息风险时，停止给“可引入/可交付”结论，并提示触发 skill-vetter。

输出策略

根据用户请求选择唯一输出形态，不要混写多套结论。

结论版

用户要求“先给结论、简报、只看判断、让用户审阅”时使用。

必须包含：

• 最终或暂定结论、置信度和评估覆盖范围。
• 是否可用/可交付/需修/不可交付。
• 影响结论的关键证据。
• P0/P1/P2/P3 中最重要的问题。
• 下一步动作。

限制：

• 若未完成完整评分，不得伪装成完整报告。
• 若问题分级尚未完成，只能写“暂定结论”或“基于当前证据的结论”，不得输出最终等级。

完整报告

用户要求完整评审、交付评审、正式报告、评分表或文档化结论时使用。

要求：

• 读取并遵守 references/report-template.md。
• 报告模板版本固定为 skill-evaluate-report/v1。
• 完整报告必须包含：摘要、证据范围、硬门禁结果、代表性场景走查、分维度评分、评分工作单、基线判定（非最终结论）、问题清单与修正建议、最终判定（唯一终局结论）、附录。
• 标题、文件名、摘要位置、章节顺序和附录术语以 references/report-template.md 为准；本文件只规定何时进入完整报告模式。
• 若模板与本文件冲突，以模板为准。

修正交付

用户要求直接落地优化时使用。

必须包含：

• 本轮修正了哪些问题。
• 保留了哪些原有能力。
• 触发、流程、交互、验收、边界或维护如何增强。
• 修改后复查了哪些门禁、维度和场景。
• 残留风险和后续复评入口。

生成前自检

输出前必须内部完成以下校验；校验结果默认不写入正文，除非用户要求：

• frontmatter 可解析，name 与目录标识一致，description 与正文能力一致。
• 评估对象、模式、范围、证据和置信度已明确。
• 场景走查满足当前模式要求。
• G1-G5、D1-D12、P0-P3、R1-R10 的使用与量表一致。
• 评分工作单已记录每个维度的检查点覆盖率、证据封顶、问题封顶、模式/资源封顶和最终得分。
• raw_total 使用未四舍五入值判级，展示分未造成等级跃升。
• 核心维度只使用 D2/D4/D5/D9。
• 基线判定只作为基线，最终判定才是唯一终局结论。
• 不存在两个不同总分、两个不同等级、两份问题清单或旧版结论残段。
• 存在未关闭 P1 时最终等级不高于合格；存在未关闭 P0 时最终等级为不合格。
• 完整报告与 references/report-template.md 一致，且技能名称来源、slug 来源、标题、文件名、摘要字段、章节顺序和附录术语已确认。

失败处理

• 找不到评估对象：说明已检查路径和缺口，向用户询问唯一阻塞信息。
• SKILL.md 不可读或 frontmatter 破损：硬门禁失败，仍给出可修复路径。
• 支持资源缺失：标记受影响维度和置信度，不臆测资源内容。
• 用户目标过大：先评估一个主 SKILL 或主能力链路，再说明其他对象需单独评估。
• 质量过低：直接给出不合格或需重构结论，不做表面润色式建议。
• 评分证据不足：降低置信度并限制等级，不输出优秀或可直接交付。
• 评估与修正混在一起：先固化问题基线，再修正，再复评，避免依据丢失。
• 报告存在旧版残段、重复结论、重复问题清单、多个互相矛盾的总分/等级时，不得继续追加内容；必须清理为单一完整报告后再交付。
• 已存在同名报告时，不得在旧报告末尾追加新版结果；必须按当前模板整体重写目标报告内容，或另存为明确标识的新快照报告。
• 历史报告只可作为对比资料，不得与本轮报告合并成同一套结论；若引用历史分数，必须单独标明“历史对比”，不得参与本轮最终判定。

最终交付要求

• 不只给分数表；必须说明分数为何成立。
• 不输出多版方案，除非用户明确要求比较方案。
• 不展开低价值过程细节；先呈现影响结论的证据、问题、修正动作和验收标准。
• 若引用外部标准，只保留对当前评估有用的检查项，并说明来源。
• 若本轮做了文件修改，最终说明修改范围、验证方式、验证结论和残留风险。