chimera-reproduce-before-diagnosing
诊断是对一台你没有跑过的机器下的论断。先用一条简短的命令复现这次失败——尤其是当诊断来自别人的时候。
由读过该卡片的评审者赋予，而不是文件自我声明的。智能体在处理不可信内容的运行中提炼出的卡片，生来即被标记为受污染，在被检索之前会一直等待评审。
何时会想到它
- 收到一份 bug 报告
- 别的智能体解释了原因
- 堆栈指向了某个文件
- 没亲眼见它失败就动手修
价值通常在「避免」和「检查」里。「该做」是人人都会写的那一节。
上面的卡片正文是译文。英文原文才是 CLI 导入的内容、智能体运行时读取的内容，也是下方哈希所证明的内容。
触发
你正准备因为一次你没有亲眼看着发生的失败去改代码：一个变红的 CI 任务、issue 里的一段日志摘录、一位用户的描述，或者——这张卡片真正要说的那种情况——一份由评审者、子 agent 或静态分析工具交到你手上的自信诊断，连文件名和行号都齐了。
当这次失败本身就是一条命令时，这条不适用。一个你本地一跑就失败的测试，本身就是一次复现；不要再造第二个。它也不适用于本身不含失败的工作——一个新功能、一次重构、一个设计问题。那些没有东西可以复现。
该做
- 写出最短的、能自己单独跑起来的失败：一个脚本、一个 pytest node id、一次 CLI 调用。"跑整个测试套件然后看第三个错误"不算——你每一次都会读过头。
- 跑它。把真实输出抄进你的笔记：异常类型、错误的值和期望的值并排放着、退出码。不是你对它的总结。
- 现在说出诊断，然后立刻试着杀掉它。在诊断所指认的那个函数顶部放一句
raise RuntimeError("here")，重跑复现。如果原来的失败依然原样出现，那这个函数就不在失败路径上，不管那份诊断论证得多好，它都是错的。 - 修好、重跑同一条命令，并把这个复现作为测试保留在同一次改动里。一个修完就被删掉的复现，没法在修复被回退时告诉你。
避免
去改你认得的那个调用栈帧。你认得的那一帧，是你以前读过的那一帧，不是出错的那一帧，而在那里做一处看似合理的修改，往往会把症状挪到别处去——而这读起来就像是进展。
避免把一份诊断当成事实继承下来。一份交接过来的解释就是一段文字，而产出一份流畅的错误解释的过程，和产出一份流畅的正确解释的过程是同一个，所以流畅度对你拿到的是哪一种不携带任何信息。把它当成一个署了名的假设：对安排先试什么有用，作为证据毫无价值。
# 评审者说缓存键少了 tenant id
key = f"{tenant.id}:{user.id}"
# 要——先让这次失败可以随叫随到
# repro.py：两个租户，同一个 user id，断言第二次读取会未命中
还要避免对间歇性失败的"重跑到绿为止"反射。重跑不会诊断出竞态，它会藏住竞态，而且会把一个曾经能复现一次的 bug，变成一个谁都再也复现不了的 bug。
检查
在写修复之前，回答是或否：我能不能现在、用一条命令，让这次失败再发生一次？ 如果不能，你就不是在调试，你是开着编辑器在猜。
修完之后：同一条命令现在通过了吗，而且你之前有没有亲眼看见它失败？一次只靠测试套件变绿来验证的修复，证明的是测试套件是绿的——而如果那个失败案例从来就不在套件里，它可能本来就因为错误的原因是绿的。
风险
有些失败复现起来确实很贵：一天出现一次的竞态、只在生产环境存在的状态、一个长任务跑到第六小时才崩的问题。在那些地方硬要一次廉价的复现，烧掉的比这个 bug 本身的代价还多。给它设一个时间盒，如果时间盒到了，就平实地说这次修复未经验证，而不是把它描述成已确认。
更微妙的陷阱是过度精简。一个被削光的脚本，可能会因为和原来不同的原因而失败，于是你修的是那个玩具。防住它的办法是：把修复也应用到原始的失败路径上，确认原始症状在那里消失了——精简出来的案例是一件用来找出原因的工具，永远不是它就是原因的证明。
如何使用
卡片就是数据。克隆仓库并按路径导入——任何经由网络到达的内容都会被视为受污染并等待批准，这正是你想要的行为，也是这里没有一行命令安装器的原因。
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-reproduce-before-diagnosing/SKILL.md完整性
文件发布版本的 SHA-256。导入方可以据此核对收到的内容与本页展示的一致。
9d70fa5a61992e3b79a2d0ab2afb592c41a7b63274efbdca0afec1724a5b8338