# Skill Evaluate > 在需要对任意 SKILL 做资深质量评审、客观评分、交付把关、引入前审查、安全边界检查、故障复盘或修正复评时使用。适用于判断 SKILL 是否可被正确触发、按步骤执行、稳定产出、可验收、可维护、可复用，并输出证据化评分、问题优先级、修正方案、最终判定和复评闭环。 - Skill: `yumih1129/skill-evaluate` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add yumih1129/skill-evaluate` - Raw SKILL.md: https://api.skillmd.com/api/skills/yumih1129/skill-evaluate/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: yumih1129 (https://skillmd.com/u/yumih1129) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/yumih1129/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，否则不要触发。 ## 评估模式 若用户未指定模式，默认使用 `标准评审`。若用户要求“深度、完整、交付、最严格”，使用 `交付评审`。 | 模式 | 适用场景 | 必做动作 | 输出深度 | |------|----------|----------|----------| | 快速把关 | 日常筛查、临时判断是否继续使用 | 硬门禁、核心文件阅读、核心维度、1-2 个场景 | 可用/需修/不可用，最终等级最高为良好 | | 标准评审 | 常规质量评估 | 硬门禁、全维度评分、3 类场景走查、问题优先级 | 完整评分与修正清单 | | 交付评审 | 新建或重大改版后的最终把关 | 标准评审、资源引用核验、输出契约检查、复评入口 | 可直接交付/有条件交付/不可交付 | | 引入前审查 | 外部 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` 时，才给出稳定交付建议。 闭环： ```text 证据采集 -> 场景走查 -> 门禁检查 -> 分维度评分 -> 基线判定 -> 问题分级 -> 最终判定 -> 修正 -> 复评 -> 关闭或继续迭代 ``` ## 用户交互规则 - 用户已提供 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 或主能力链路，再说明其他对象需单独评估。 - 质量过低：直接给出不合格或需重构结论，不做表面润色式建议。 - 评分证据不足：降低置信度并限制等级，不输出优秀或可直接交付。 - 评估与修正混在一起：先固化问题基线，再修正，再复评，避免依据丢失。 - 报告存在旧版残段、重复结论、重复问题清单、多个互相矛盾的总分/等级时，不得继续追加内容；必须清理为单一完整报告后再交付。 - 已存在同名报告时，不得在旧报告末尾追加新版结果；必须按当前模板整体重写目标报告内容，或另存为明确标识的新快照报告。 - 历史报告只可作为对比资料，不得与本轮报告合并成同一套结论；若引用历史分数，必须单独标明“历史对比”，不得参与本轮最终判定。 ## 最终交付要求 - 不只给分数表；必须说明分数为何成立。 - 不输出多版方案，除非用户明确要求比较方案。 - 不展开低价值过程细节；先呈现影响结论的证据、问题、修正动作和验收标准。 - 若引用外部标准，只保留对当前评估有用的检查项，并说明来源。 - 若本轮做了文件修改，最终说明修改范围、验证方式、验证结论和残留风险。