测验验收

Skill chenyuxiaojin/CYXJ-79/测验验收

测验验收(quiz 验收):一段长工作会话或大改动结束后、合并/发布/交付之前, 生成一份"发生了什么"的直白报告 + 底部测验,用户满分才算验收通过。解决的问题:Claude 干的活越多,用户越可能"以为自己懂了"——光看 diff 或摘要只能获得表面理解,测验暴露真实的理解缺口。触发词:测验验收、考考我、quiz、出个测验、「我想确认我真的理解了这次改动」。当一次会话改动量大、决策多,而用户即将合并/发布/关闭会话时,应主动建议做一次测验验收。From its SKILL.md

Install

npx -y skills add chenyuxiaojin/CYXJ-79 --skill 测验验收

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.9 KB, 940 tokens by cl100k_base, as published. Nobody here has run it

测验验收 · 满分才放行

方法论来自 Anthropic 工程师 Thariq《A Field Guide to Fable》:长会话后 Claude 完成的往往比用户意识到的多,读 diff 只能获得浅层理解(很多行为取决于既有代码路径)。让用户先通过测验再合并,是把"未知的未知"在出事前暴露出来的最后一道闸。

用户是非程序员——报告和题目都考行为和决策,不考语法和 API 记忆。

流程(三步)

第 1 步:盘点这次到底发生了什么

先取证,不凭印象:

有 git → 看本次会话涉及的 diff / 新增文件
无 git(文案、配置、素材类)→ 盘点本次会话产出和修改的所有文件
回顾会话中的关键决策,尤其:偏离原计划的地方、替用户做的假设、留下的隐患

第 2 步:生成报告 + 测验(HTML artifact)

一份 HTML,上半是报告,下半是测验。报告结构:

## 这次做了什么(一段话总览)
## 为什么这么做(关键决策 + 每个决策当时的理由)
## 偏离与假设(哪里没按原计划走、替你拍板了什么)
## 现在的行为(改动后,系统/文件/流程在真实使用中会怎么表现)
## 遗留与风险(没做的、将来可能咬人的)

测验规则:

5~8 题,选择题为主、简答一两道
题目考的是:「这个改动之后,X 情况下会发生什么?」「当时为什么选 A 不选 B?」「如果要改 Y,应该动哪里?」「哪个隐患在什么条件下会爆?」
每道题必须对应一个真实的理解缺口会导致真实代价的点,不出送分题、不出抠字眼题
答案先不给,等用户作答

第 3 步:批改与放行

用户作答后逐题批改:答错的题 = 真实理解缺口,详细讲解到懂,不是报个对错
有错 → 讲解后针对错题换角度出补考题(不重复原题),直到满分
满分 → 明确宣布:验收通过,可以合并/发布/收工
用户答题过程中暴露出报告没覆盖的疑问 → 当场补讲,并检查是不是改动本身有问题

边界

测验暴露出"改动本身可能有错"时,停止验收流程,回到调试纪律:先用证据定位,不许顺手改
用户明确说"跳过测验直接合并"→ 尊重,但提醒一句这次改动里风险最高的一个点

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.