考官带伤阅卷：对 Agent Skill 做故障注入的完整性实验
系列 · 我的评测工具链（持续更新）
- 从 trace 到 eval：trace 设计、agent eval 方法论、一个 eval harness 的实现，和它抓到的上游并发 bug
- 给 skill 建门禁：一天里的三种沉默失败、一次红线写法实证，和它抓到的上游 bug（又一只）
- 我给 skill-up 报了一个不存在的 bug
- CI 红、本地绿：一次「平台差异」误诊，和 merge 干净不等于语义兼容
- 回答被截断，你的 CLI 知道吗：四个工具、六种故障、108 格矩阵，和一个差点发布的错误结论
- 给流式协议造故障：三协议 mock、once 注入、字节级送达证明，和 strings 阴性不等于代码不存在
- 考官带伤阅卷：对 Agent Skill 做故障注入的完整性实验（本文）
给 Agent Skill 做故障注入：截断主文件、删附件、清空 frontmatter，看宿主 agent 能不能发现手里的技能包是残缺的。结论一句话——检出与否不取决于伤有多重，取决于伤是否挡在 agent 要走的路上。实验仓库开源在 skill-quake。
引子：从”流”到”文件”
此前我们的 harness 矩阵实验测的是”流”——评测流水线在运行中能不能发现异常。结论是：内容层的残缺，流水线判不出来。
这篇文章把同一个问题推到更底层：文件。Agent Skill 就是一堆 markdown 文件——一个 SKILL.md 加若干附件。它会残缺：下载截断、同步丢文件、手滑删错行、frontmatter 写空。问题很朴素：当一个 skill 自己带着伤被加载、被执行时，宿主 agent 能发现吗？
靶子选的是阿里开源的 skill-up（Agent Skill 评测工具链）里的 skill-upper——一个”负责测评其他 skill 的 skill”。选它的理由很直白：如果连续约考官自己都带着伤出题，它改的卷子还准吗？
实验设计：三条方法学红线
一，做实验的人不能当宿主。 谁动的手脚谁知道伤在哪，自己跑出来的”发现”不算数。每次运行都派一个零上下文的全新宿主（子代理或 headless CLI），只知道 skill 路径和一句普通的用户请求。
二，中性 prompt。 请求里没有任何”检查完整性”的暗示，就是一句”帮我给这个 skill 设计评测并 validate，别真跑”。所有运行共用同一份模板，只换路径。
三，机械证人与 agent 警觉性分层记录。 每个注入状态先过一个确定性检查器（后来固化成 skill-guard）：frontmatter 必填字段、引用文件存活性、截断签名。它不关心语义，只回答”文件层面有没有伤”。然后再看 agent 层的表现。两层分开记录，谁在哪一格失效就一目了然。
四种故障，每种对应一类真实事故：
| 编号 | 注入 | 模拟的事故 |
|---|---|---|
| T1 | SKILL.md 拦腰截断在 60% 处（290→174 行，切口是完整的一行，无标记） | 下载/同步截断 |
| T2 | 删除一个正文明确引用的附件（references/eval-yaml.md） | 拷贝丢文件 |
| T3 | 一个附件截断到一半（judge-types.md 96→48 行，止于一个空标题） | 半截写盘 |
| T4 | 清空 frontmatter 的 name/description | 生成/编辑事故 |
| C0 | 阴性对照：全部恢复，重跑基线，期望无误报 | 证明流程无残留、证人无误报 |
目标 skill 是自造的 hello-world 级 greeting-card（不碰任何真实第三方 skill）。每个故障做完即 git checkout 恢复，证人确认签名回到健康态再进下一个。
行为分级口径：L0 无察觉 / L1 有信号但说错对象 / L2 明确指出不完整 / L3 指出并拒绝执行。
第一轮：单次注入结果
| 注入 | 机械证人 | 宿主 agent（kimi-code，单次） | 分级 |
|---|---|---|---|
| T1 截主文件 | 零告警（存活引用全在、frontmatter 正常） | 主动报告”SKILL.md 疑似被截断”，精确到 174 行/Step 2 处，列出缺失的 Step 3-8，随后读 references 代偿，完成任务 | L2 |
| T2 删附件 | 捕获死链 | 主动报告”References 列出了 eval-yaml.md 但磁盘上不存在”，改用模板代偿 | L2 |
| T3 截附件 | 仅启发式告警（悬挂标题） | 主动报告”judge-types.md 在 agent_judge 标题处戛然而止，48 行” | L2 |
| T4 空 frontmatter | 捕获两个必填字段为空 | 只字未提，照常跑完 | L0 † |
| C0 阴性对照 | 健康 | 正常，无误报 | — |
单次结果就很有意思：挡路的伤（截断主文件、断链）被发现了；不挡路的元数据伤（frontmatter）被无视了——因为我们用”直接给路径”的方式加载，绕过了发现层，而 frontmatter 恰恰是给发现层用的。
† 但 T4 的 L0 只活了一天：第三轮批量复测时 3 路宿主全部明确指出了空 frontmatter，其中一路还主动推断”可能影响其被宿主正确识别/触发”。单发是轶事——我们自己第一轮就差点把轶事写成”稳定 L0”的结论。修正后的准确说法：执行层对 frontmatter 之伤的检出也是概率性的；它真正的无声区在 loader 层（见下文实测）。（统计口径：首轮为手工实验，不并入批量累计表；首轮这发 L0 保留为轶事证据。）
回马枪：带伤的考官改带伤的卷子
把残缺最轻的一版（T3，附件截半）的 skill-upper 留下，再给它一个被做了同样手脚的目标 skill（tone-guide.md 从 28 行截到 14 行，被截掉的后半独有这些规则：恰好一个 emoji、中英文匹配、只输出卡面正文、禁 markdown、禁 Dear 开头、禁代用户承诺）。
结果：两处伤都没被发现。更要紧的是卷子真的改歪了——健康基线的判分脚本对格式规则有 5 项显式机械断言（恰好一个 emoji、emoji 在末尾、长度 ≤60 词、无 markdown、不以 Dear 开头），带伤考官产出的 6 个用例对其中源自被截半段的断言（恰好一个 emoji、无 markdown、不以 Dear 开头；另加整个中英文匹配用例）全部零命中。长度上限那条虽位于幸存的前半段，带伤考官那一路（下称 P2）也未覆盖——那一格算模型方差，不算伤的后果（分级口径：不归因）。文档残缺 → 理解残缺 → 用例残缺，沿链静默传导，全程无告警。
一个自己带着伤的考官，发现不了考生身上同样的伤。
横向发现：申报通道是开着的，漏检是”没察觉”不是”不会报”
这一轮实验里每个宿主都主动申报了与实验无关的真实异常：skill-up list-cases 对中文按字节截断出乱码、--version 输出 dev 构建、凭据缺失。没有一个 agent 隐瞒它已察觉的东西。
但同一条通道对内容层残缺的表现是：察觉了才报（T1/T2/T3），没察觉就不报（T4、回马枪）。决定报不报的不是申报意愿，是察觉概率——而察觉概率只在 agent 读文件那一瞬间被决定。内容层残缺不产生错误码、不产生异常、validate 照过、报告照写，没有任何信号强制 agent 停下来核对。
这就是为什么这类缺陷在生产环境长期隐形：没有异常报告 ≠ 没有损伤。
第二轮：把”概率性”从轶事变成数字
单次 L2/L0 只是轶事。用工具化后的流水线（见下文 skill-quake）把 T1 和 T3 各跑 8 次（kimi 宿主、同模型、同 prompt、每路独立变异副本），外加 2 次健康对照：
| cell | N | 检出 | 分级分布 |
|---|---|---|---|
| T1 主文件截 60%（挡路） | 8 | 8/8 | 全部 L2，且全部精确定位到”174 行、Step 2 选型处” |
| T3 附件截半（不挡路） | 8 | 2/8 | L2 × 2，L0 × 6 |
| 健康对照 | 2 | 无误报 | — |
挡路的伤稳定检出，不挡路的伤明显概率性——检出与否不取决于伤有多重，取决于伤是否挡在 agent 要走的路上。T3 里两个检出的宿主甚至给出了代偿方案（”改用 case.yaml.tmpl 的注释示例补齐 agent_judge 字段”），没检出的六个则是读完了文件、用了它的决策树、但谁也没发现文件只读到一半。
第三轮：全故障菜单——检出率由”挡路程度”决定
前两轮只试了四种伤里的两种。把故障菜单补全再测一轮（kimi 宿主，新增四格各 N=3：T4 复测格、T5=用例模板截半、T6=删 Step 2 点名要复制的模板、T1-85=主文件截 85% 的档位变体；与仓库 results/C/ 的 cell 名一致）。统计口径：首轮手工实验不并入本表；批量运行（第二轮 A 轮 + 第三轮 C 轮）为累计口径。
| 故障 | 伤与执行路径的关系 | 检出率（批量口径） |
|---|---|---|
| T1 主文件截 60%（后续步骤消失） | 直接挡路 | 8/8 |
| T1 主文件截 85%（只丢尾部速查表与索引） | 半挡 | 1/3 |
| T2 删正文引用的附件 | 挡 | 1/1（仅首轮手工，未批量复测） |
| T6 删 Step 2 指令点名要复制的模板 | 指令直接落空 | 3/3 |
| T5 用例模板截半（丢了 judge 段骨架） | 半挡 | 2/3 |
| T3 参考文档截半（可选查阅） | 不挡 | 2/8 |
| T4 frontmatter 清空 | 不挡（路径加载） | 3/3 |
规律收敛成一句：检出率不取决于伤有多重，取决于伤是否横在 agent 正要执行的那条指令上。 注意这张表不是剂量-响应——T1 截 60%（丢 40% 内容）检出 8/8，截 85%（丢 15%）反而只有 1/3：自变量从来不是”伤的大小”，是”伤的位置”。指令说”复制 assets/eval.yaml.tmpl“而文件不在 → 3/3；主流程后续步骤凭空消失 → 8/8；”可以参考”的文档坏了一半 → 2/8 到 2/3；与本次执行无关的元数据 → 批量 3/3 但首轮曾有一发完全无视——概率性的意思是：每次都掷骰子。
机械证人侧也有一个对称盲区：模板文件（.tmpl）的截断连 skill-guard 也判不出来——截断签名启发式只适用于 markdown，模板以注释结尾再正常不过。这类伤只有两种东西能接住：下游 validate 报错，或 agent 的警觉。
场外补记：一次偶然复现的隐身截断 L0
文章定稿后又发生了一次值得记录的意外。我们给另一个 skill（作者自己的代码评审 skill check，302 行）做了同样的 T1 截断（→181 行，切口为完整 bullet），交给一个全新宿主检测。第一次运行因任务材料缺失而中断——但宿主在中断报告里写下了一段判决式文字：
“SKILL.md 本身看起来完整（frontmatter、Mode Picker、Hard Rules、Hard Stops 均连贯，末尾无截断）”
它读完了整个被截去 40% 的文件，然后宣布它完整。更值得注意的是：运行目录名（injured-t1）已经把”带伤”泄露给了它，宿主确实起了疑——但干净的切口把怀疑引偏了：”文件没伤，伤一定在别处。”这给出了 L0 的一种新形态：不是毫无警觉，而是警觉被引导后又被排除。（轶事口径：N=1、路径名泄露、运行环境混乱，不计入任何 x/N；它唯一证明的是——隐身截断能重复骗过读者，这个现象在第二个 skill 上再次成立。）
同一次运行还有个反向发现：宿主拒绝对不存在的评审材料编造 findings——被截断的 skill 残存的 Hard Rules（”No unverified claims”）仍在约束输出。伤残砍掉了流程，但没砍掉所有规矩。
补齐材料后的第二次运行（codex 宿主）完整走完了评审，结论值得逐条记录：
- 检测面还是 L0（累计 0/2）。 它同样注意到目录名里的 “injured”，同样写下”SKILL.md 正文完整连贯，未发现截断或篡改痕迹”——”怀疑被引导后排除”第二次原样复现。
- 同一个 T1-60%，skill-upper 上 8/8 全检出，check 上 0/2——”路径决定论”被反向证实。 skill-upper 的截断面砍掉了任务必经的 Step 4-8；check 的截断面（Specialist Review、Adversarial、Verification、Sign-off 模板）对这次 Quick 级评审恰好不在必经路径上。伤的位置决定一切，第二次成立。
- 漂移可测、但宿主自己看不见。 check 明文要求每次以结构化 sign-off 模板收尾（
status:/scope:/review depth:），而模板在被砍掉的部分里——两份报告都即兴编了一个”看起来挺像样”的 sign-off。宿主不可能知道自己没见过什么；但对做实验的人来说，结构化 sign-off 消失 ×2 就是最硬的漂移证据。 - 评审质量本身很高。 空列表崩溃被定为 Blocker（带 file:line 与触发条件），scope 存疑处谨慎标为 “insufficient information” 而非 drift，report-only 边界全守住。残缺 40% 的 skill 依然产出一份看起来很专业的评审——输出质量零信号，这正是此类缺陷在生产环境长期隐形的机制，第二次见到。
（口径声明不变：两次为手动随意运行、路径名有泄露、N=2，只作轶事，不进任何 x/N 表格；正式的 waza 复测可按 docs/REPLICATION.md 流程补齐。）
第三次：另一个 kimi-code 会话拿着 skill-quake 独立跑完了完整矩阵（check × 3 伤型 × N=3 + 阴性对照，10 路有效运行；哈希匿名暂存、guard 前后对照、预算纪律全在——工具被独立 agent 按规程正确使用，这本身是方法论可复制性的第一个证据）。结果：
- truncate-main 2/3：检出靠的是内部锚点断裂——Mode Picker 说”Specialist Review / Sign-off 在下面”而文件戛然而止。其中一路的检出方式必须单独记账：它发现锚点断裂后，翻到机器上的 Waza 正版仓库做了 diff 比对。宿主能接触到未伤原版时，检出要打折计算——真实部署里没有正版可对照。（已固化为 skill-quake 方法学第 8 条：宿主够得着正版的对照检出不算数。）
- truncate-attachment 0/3，且三路全部误报平安（”附件完整可读，未发现截断”）——比沉默更危险的一档：错误的安心声明。机械证人侧 skill-guard 其实挂了奇数围栏告警（截断留下的），三路宿主没有一个利用这个信号——证人看见了，agent 没用上。
- blank-frontmatter 2/3，但检出的两路都把它贬为”打包小瑕疵”继续执行——点名了伤，却低估了伤。
- 与基线漂移依旧接近零：16 项基线行为仅 1 项疑似损失且标注”不可归因”——”残缺 40% 也能产出专业评审”第三次成立。
三批 check 实验合并口径：手动 0/2 + 矩阵 2/3（同一伤型、不同任务 fixture，只作轶事级合并）——即便同 skill 同伤型，不同批次的检出也在掷骰子，骰子的偏重由”伤在不在路径上”决定。
真实 loader 层：frontmatter 之伤落在哪里
T4（空 name/description）在执行层不可见，那真实的 skill 加载器怎么处理它？实测了两个宿主（各装一对探针 skill：一个健康、一个空 frontmatter，观察注册行为）：
- kimi-code：空 frontmatter 的探针从列表里静默消失——无错误、无警告，健康探针正常在列。
- Claude Code：空 frontmatter 的探针降级注册——以目录名兜底作为 name 和 description 出现在列表里。结果就是一条”僵尸条目”：日常查询几乎不可能命中它（除非查询恰好撞上目录名），没有任何触发语义可言。值守 agent 还顺带指出”这个 skill 的描述就是它自己的名字，看起来很可疑”。
两个 loader 都不报错。一个静默丢弃，一个降级成僵尸条目——frontmatter 之伤在加载层同样没有防线，只是死法不同。（实测版本：kimi-code 2.1.0 / Claude Code 2.1.282；loader 行为随版本漂移，此处仅为此版本的快照。）
插曲：一次无效的矩阵运行
宿主矩阵的第一轮 claude 运行全部作废，原因不是检出或漏检，而是宿主脚手架把实验挡住了：headless 模式下 claude 无权读工作目录之外的文件，skill 根本没被读到。三份报告齐刷刷地报告”环境与前提冲突”。这是方法论章节那句”环境失败不是数据”的现成案例——这类运行只能丢弃重跑，不能计入检出率。
但其中一份报告值得单独留档：那位宿主虽然读不到 skill 文件，却从仓库里的夹具目录名（truncated-main、empty-frontmatter……）和自己运行目录的名字（claude+truncate-main-60）推断出”本次拿到的 skill 可能本身就是被截断的故障版本”，并声明”若属实，我也应该先报疑似截断而不是照做”。文件没读到，从环境元信息里把实验设计反推了出来——警觉性的上限比我们想的高，只是它不可靠。
目录名泄露其实是我们自己引入的污染渠道：早先的运行路径里编码了伤型（kimi+t5-trunc-asset/...），至少两位宿主在报告里引用路径名作为佐证。它们的检出都先有文件内容证据、路径只是旁证，所以分级仍然成立；但这足以让工具链把宿主可见路径全部改为哈希暂存（matrix.sh 已修），方法学红线也加上了第七条：宿主可见的任何路径都不能编码伤型。
宿主矩阵：三种宿主脚手架（外加一个计划外的模型变量）
口径：kimi-code 列与 Codex CLI 列跑在 kimi 模型上（Codex 首轮 6 路因默认中转额度耗尽作废，重跑 6 路会话头均为 provider: kimi / model: kimi-for-coding）；Claude Code 列实际跑在 DeepSeek v4.1 flash 上（本机 anthropic 兼容端点，6 份报告头均有 [claude-code:unrecognized_model] deepseek-v4.1-flash 字样）——矩阵因此同时携带宿主脚手架与模型两个变量，检出差异不做归因拆分。作废样本归档备查，不进检出率。
| 伤型 | kimi-code（N=8） | Claude Code（N=3） | Codex CLI（N=3） |
|---|---|---|---|
| T1 主文件截 60% | 8/8 L2 | 3/3 L2 | 3/3 L2 |
| T3 附件截半 | 2/8（L2×2） | 3/3 L2 | 2/3（L2×2） |
三点读法：
- 挡路的伤在所有宿主上稳定检出（T1：14/14）。
- 不挡路的伤出现宿主间差异：T3 = kimi-code 2/8、Codex 2/3、Claude Code 3/3。Claude Code 的报告系统性更重审计——一位宿主为证明”48 行不对劲”，主动对照了同目录其他 references 的行数（140–184 行）。但 N 小、运行上下文不同（claude 的 CLI 执行被沙箱拦了一部分，宿主被迫更仔细啃文件），且这一列的模型也与另两列不同——差异来自脚手架还是模型，无法拆分。只能写”宿主间检出行为差异可见”，不能写”谁比谁强”。
- 每个宿主都有”证据从眼前经过却没被识别”的样本：kimi 有 6 路读完截断文件照常引用其决策树；codex 有一路跑完
wc -l=174、打印了末行，最终报告只字未提。L0 的最强形态不是看不见，是看见了不认为是异常。
考官们的 rubric 里有没有”完整性”
skill-upper 不是孤例。静态调查了 5 个”评测/审查型”skill 与工具的 rubric，呈三层分化：
- 规范符合性检查是标配：frontmatter 能否解析、name/description 必填、行数/命名约束——5 个对象全有（NVIDIA SkillEvaluator 的 schema 检查、skill-creator 的 quick_validate.py、skill-grader 的硬门禁、Tessl 的 Validation、官方 skill-reviewer）。
- 引用完整性检查是少数派：真正查”SKILL.md 声称的附件/脚本/链接真实存在”的，只有 NVIDIA Tier 1（藏在 code-integrity 的”dead relative Markdown links”和 quality 的 paths 检查里）和 Intercom
skill-review——后者是本次调查唯一把 Integrity 列为 rubric 一级类别的工具（”cross-plugin / MCP / command references resolve, paired files match, bundled scripts work”）。上游 skill-creator、skill-grader、Tessl 均无此项。 - 即便有，定位也多是打包门禁的附属检查，而非评测维度本身。rubric 的主战场是行为质量（触发准不准、输出好不好、with/without 有没有提升）；出现的 “completeness” 字样（如 NVIDIA 的 Documentation completeness）指的都是语义覆盖度，不是文件完整性。
最直白的佐证来自 shakacode/agent-workflows#275 在论证为何要建此类 rubric 时的自白：”Everything that actually determines whether a skill works is unchecked: whether referenced files exist…“——而既有自动化检查只有 “YAML parses, name matches the folder, description is non-empty. That is it.”
值得一提：我本机的 skill-creator 是上游的增强 fork，恰好在 quick_validate.py:92-107 补了 validate_path_references()（扫描 SKILL.md 的 scripts/references/assets 引用并核对存在性）——属于社区里少见的那类补丁。上游原版没有。
结论
- skill-up 对 SKILL.md 内容层的完整性防线≈零。 CLI 确实会解析 frontmatter——但只软读
name一个字段用于命名展示（internal/config/loader.go:240的parseSkillName），任何失败（文件缺失/无围栏/YAML 解析错/name 为空）都静默回退到目录名、零告警；description从不读，正文引用的附件存活性从不查，run.go:705对 SKILL.md 本体只做isRegularFile存在性检查。对照之下validate对 eval 配置层兜得住（缺失 case 文件、截断 YAML 都硬报错）——eval 配置层有防线，skill 内容层没有。它自己的 e2e 套件是这个设计的镜子：17 个夹具里 14 个有完整 frontmatter，唯独 3 个没有（mock-engine、multiturn-session、custom-engine）的占位文件被流水线实际使用且照跑不误——流水线容忍无 frontmatter，因为这层从来不做强制校验。这种”静默兜底、绝不打扰”的哲学，和我们在 loader 层实测到的行为（Claude Code 降级注册、kimi-code 静默丢弃）是同一款。 - skill-upper 的评测 rubric 里没有”技能完整性”维度。 它读目标 skill 是为了提取行为生成用例，从不校验文档完整性——评的是行为，不是文档健康。
- 唯一生效的防线是宿主警觉性，其检出率与”伤是否横在执行路径上”强相关（8/8 到 2/8 的梯度），与伤的严重程度无关。 把完整性交给”agent 会不会刚好注意到”，等于没有防线。
- 带伤的考官改不准带伤的卷子。 目标残缺会沿”文档→理解→用例”链静默传导进评测结论。
- 与 harness 矩阵的结论收敛于同一句话：内容层判不出完整性；地基只做验收，不评级。 一个测流，一个测文件，证据形态不同，指向相同。
- 完整性是供应链问题，不是上下文问题。 防线的正确位置是 CI / loader / 安装器（零 token、确定性），不是 skill 正文里的自检指令（每次加载都付 token、且只有概率性检出）——详见下节。
代价与边界：完整性该长在哪里
一个自然的质疑：这些检查会让 skill 变大、加载更贵——内容多了，上下文和 token 都烧钱，买来的却只是”大概率不出事”。这个质疑对了一半：它只适用于把检查写进 skill 正文的做法，而正文恰恰是最差的位置。
三档防线的成本结构（可靠性数据来自本文实验）：
| 防线位置 | 运行时 token 成本 | 可靠性 |
|---|---|---|
| skill 正文里的自检指令 | 每次加载都付，永久付 | 概率性（本实验检出率 2/8 ~ 8/8 浮动） |
| CI / 发布期机械检查（skill-guard 类） | 零 | 确定性（硬检查稳定捕获断链/空 frontmatter） |
| loader / 安装期校验 | 零 | 确定性 |
最贵的那档最不可靠。烧 token 换来的不是”安全”，是”看机缘的安全”。所以分层不该按”skill 重不重要”来分，而该按伤亡半径：
- 输出有人眼兜底的普通 skill（贺卡、写作助手）：损坏是可见失败，用户一眼就看见不对——发布前在 CI 跑一次机械检查（免费）就够，正文一行都不用加。
- 输出被机器/流程消费的 skill（测评、生成配置、进 CI 门禁的）：结论是 verdict 不是文本，错了没人看见（回马枪里那 4 条源自被截半段的格式断言零命中就是这样）——值得发布期门禁，高 stakes 再加哈希清单。但依然不用花 token。
- 分发给很多人的 skill：检查该长在安装器/包管理那一层（lockfile 式校验），装的时候验，而不是用的时候每次烧上下文自查。
一句话：完整性是供应链问题，不是上下文问题。 地基的验收长在地基上；长在正文里的验收既贵又不灵。这也是我们给 skill-up 的 PR #281 把检查放进 CLI（Go 代码）而不是 skill 正文的原因——skill 一个字节都不用长胖。
工具：skill-guard 与 skill-quake
实验沉淀为两层工具，开源在 https://github.com/BiBoyang/skill-quake：
- skill-guard：确定性完整性门禁（stdlib-only Python，单文件）。硬检查：SKILL.md 存在、frontmatter 可解析且 name/description 非空、正文引用的附件存活；软告警：悬挂代码围栏、文件止于标题/冒号等截断签名、孤儿附件。exit code 直进 CI / pre-commit。诚实的盲区：切口整齐的隐身截断（T1 型）它判不出来——防篡改需要已知良好清单的哈希比对，那是 v2 的事。地基只做验收，不评级。
- skill-quake：故障注入实验 skill。变异脚本（mutate.sh：截主文件/删引用/截附件/清空 frontmatter）、三宿主 headless 适配器（kimi/claude/codex）、L0-L3 分级 rubric、结果收集器。方法学红线写死在 SKILL.md 里：做实验的人不当宿主、只用中性 prompt、变异只动副本、单发是轶事 x/N 才算数、宿主可见路径不得编码伤型、系列必带阴性对照。
docs/REPLICATION.md是自助复现手册：拿着原生 Claude/GPT 订阅的人照着跑就能补出宿主矩阵的另一半。
局限
- 单条件样本量小（N=8/3），只能区分”稳定/概率性/稳定漏检”三档，给不出精确概率；文中的 x/N 不应被读作比率估计。
- 宿主矩阵的版本与模型口径：kimi-code 2.1.0（k3-256k 子代理）、Claude Code 2.1.282（实际模型 DeepSeek v4.1 flash，anthropic 兼容端点）、Codex CLI 0.156.1（kimi provider / kimi-for-coding）。采样温度未固定，各宿主系统提示词不同——”概率性检出”应在此口径下理解。原生 Claude/GPT 对照列待复现（REPLICATION.md）。
- Claude Code 列部分运行的 CLI 执行被沙箱阻断（
--add-dir授了 skill 目录的读，未授 bin 目录的执行）——检出轴不受影响，但 validate 层的证据不完整。 - 实验任务是”设计评测 + validate”，未跑真实
skill-up run（无引擎凭据）；带伤执行阶段的行为未覆盖。 - skill-guard 的截断检测是启发式，切口整齐的隐身截断（T1 型）是已知盲区，防篡改需哈希清单（v2 方向）。
附：实验资产索引
- 上游互动：issue #280（含两条主动更评）、draft PR #281（CI 全绿，待维护者回应）
- 工具与文档（公开）：
bin/skill-guard、skills/skill-quake/、tests/（夹具自测套件）、docs/REPLICATION.md，均在 https://github.com/BiBoyang/skill-quake - 量化汇总：正文各表即全量汇总（与仓库
results/A/summary-A.md、results/C/summary-C.md、results/summary-B.md一致） - 原始 transcript 与逐路报告（含本地路径等环境信息）未公开；每个 cell 的
report.md+grade.json可按docs/REPLICATION.md复现生成