菜单
面向疑难 bug 和性能回归的纪律化诊断循环。复现 → 最小化 → 提出假设 → 插桩 → 修复 → 回归测试。当用户说 "diagnose this" / "debug this"、"诊断一下" / "排查一下"、报告 bug、说某处坏了/抛异常/失败，或描述性能回归时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
RodSki 用例 / 模型 / 数据 / 关键字编写权威指南。当用户询问如何写 RodSki 用例、 如何写 model.xml、关键字（type / verify / send / DB / run / navigate / wait / get / set / screenshot / assert / clear / upload_file / launch / evaluate / close / check） 怎么用、data.sqlite 怎么填、Case XML 三阶段（pre_process / test_case / post_process） 格式、scenario 容器、测试计划 plan/*.xml、GlobalValue 引用、Return 索引、视觉定位器 vision/ocr/vision_bbox、桌面端 / 移动端自动化时触发。完整内容按章节拆分在 reference/*.md， Agent 命中后按需 Read 对应章节。
在任意 RodSki 用例仓库中编写、修改、调试或审查 RodSki 自动化测试模块。Codex 处理 RodSki case/*.xml、model/model.xml、data/globalvalue.xml、data/data.sqlite、plan/*.xml、TEST_CASE_WRITING_GUIDE.md 合规、RodSki CLI 校验、UI/API/DB 测试用例，或 AI 生成 RodSki 用例的风格一致性时使用。中文触发：写测试用例、修改用例、修复用例、调试失败结果、审查 RodSki 用例、检查 guide 合规、修改 case/model/data/plan、处理 data.sqlite/globalvalue.xml、运行 rodski dry-run 或 data validate。
用于 RodSki 框架源码、XML 活文档协议、关键字实现、XSD schema、CLI、视觉/Desktop/API/DB 能力和 demo 验收链路。处理 RodSki 用例、model.xml、data.sqlite/globalvalue.xml、plan/*.xml 或 TEST_CASE_WRITING_GUIDE.md 合规任务时，优先使用 rodski-case-writer。
Submit RodSki test case assets to the shared GitLab repository from a submitter's own testcase roots. Use when the user asks to push or submit RodSki case/data/fun/model assets to GitLab. The submitter must provide their own GitLab username, personal branch, and owner directory; never target main/master/head, never write passwords into skill files, and never clean sibling submitter folders.
RodSki 用例换环境助手。Use when the user asks to convert, migrate, audit, compare, sync missing, or verify RodSki test cases between environments such as beta/ci/stage/prod, especially requests mentioning “换环境”, “转换环境”, “补齐用例”, “缺少用例”, environment URL, database address, globalvalue.xml, model hardcoded URL, data.sqlite, beta_old/ci_new, or finding environment values that should change. This skill first supplements missing case/data/model/fun assets from old to new when applicable, then changes only URL and database-address values, keeps case writing and business data unchanged, and treats old/source cases as read-only.
RodSki 用例 / 模型 / 数据 / 关键字编写权威指南。当用户询问如何写 RodSki 用例、 如何写 model.xml、关键字（type / verify / send / DB / run / navigate / wait / get / set / screenshot / assert / clear / upload_file / launch / evaluate / close / check） 怎么用、data.sqlite 怎么填、Case XML 三阶段（pre_process / test_case / post_process） 格式、scenario 容器、测试计划 plan/*.xml、GlobalValue 引用、Return 索引、视觉定位器 vision/ocr/vision_bbox、桌面端 / 移动端自动化时触发。完整内容按章节拆分在 reference/*.md， Agent 命中后按需 Read 对应章节。
| name | diagnose |
| description | 面向疑难 bug 和性能回归的纪律化诊断循环。复现 → 最小化 → 提出假设 → 插桩 → 修复 → 回归测试。当用户说 "diagnose this" / "debug this"、"诊断一下" / "排查一下"、报告 bug、说某处坏了/抛异常/失败，或描述性能回归时使用。 |
一套面向疑难 bug 的纪律。除非有明确理由，否则不要跳过任一阶段。
探查代码库时，借助项目的领域术语表建立相关模块的清晰心智模型，并查看你要改动区域的 ADR。
这才是这套技能的核心。 其余都是机械步骤。只要你为这个 bug 拥有一个快速、确定、可由 agent 自行运行的通过/失败信号，你就一定能找到根因——二分、假设验证、插桩都只是消费这个信号。如果没有这个信号，盯着代码看再久也救不了你。
在这里投入超出比例的精力。要主动出击，要有创造力，绝不轻言放弃。
git bisect run。scripts/hitl-loop.template.sh 驱动人，让循环仍然是结构化的。捕获的输出回流给你。建好正确的反馈循环，bug 就解决了 90%。
把循环当作一个产品来对待。一旦有了某个循环，就追问：
一个 30 秒且不稳定的循环，比没有循环强不了多少。一个 2 秒且确定的循环，是调试的超能力。
目标不是干净复现，而是更高的复现率。把触发条件循环 100 次、并行化、加压、收窄时序窗口、注入 sleep。50% 概率的偶发 bug 可调试；1% 的不行——持续抬高复现率，直到它可调试为止。
停下来，明确说出来。列出你尝试过的方法。向用户索要：(a) 能复现问题的环境访问权，(b) 一份捕获产物（HAR 文件、日志转储、core dump、带时间戳的录屏），或 (c) 在生产环境加临时插桩的许可。不要在没有循环的情况下就去提假设。
在你拥有一个自己相信的循环之前，不要进入阶段 2。
跑循环。亲眼看着 bug 出现。
确认：
复现出 bug 之前，不要继续往下走。
在验证任何假设之前，先生成 3–5 个排好序的假设。只生成单一假设会让你锚定在第一个看似合理的念头上。
每个假设都必须可证伪：说清它做出的预测。
格式："如果 是根因，那么 <改变 Y> 会让 bug 消失 / <改变 Z> 会让它更严重。"
如果你说不出这个预测，那这个假设只是一种感觉——丢弃它，或把它打磨锐利。
在验证前把排好序的列表给用户看。 他们往往有领域知识能瞬间重排（"我们刚给 #3 上线了一个改动"），或知道哪些假设已经被排除。便宜的检查点，省下大量时间。不要为此阻塞——如果用户不在，就按你的排序继续。
每个探针都必须对应阶段 3 的某个具体预测。一次只改一个变量。
工具偏好：
给每条调试日志打标签，例如 [DEBUG-a4f2]。最后清理就变成一次 grep。没打标签的日志会残留；打了标签的日志会被清掉。
性能分支。 对性能回归，日志通常是错的方向。应改为：先建立基线测量（计时夹具、performance.now()、profiler、查询计划），再做二分。先测量，后修复。
在修复之前先写回归测试——但前提是存在一个正确的接缝。
正确的接缝是指：测试在调用点上触发的是真实的 bug 模式。如果唯一可用的接缝太浅（bug 需要多个调用方却只能写单调用方测试、单元测试无法复现触发 bug 的调用链），在那里写回归测试只会带来虚假的信心。
如果不存在正确的接缝，这本身就是一个发现。 记下它。是代码库架构在阻止这个 bug 被锁定。把它标记给下一阶段。
如果存在正确的接缝：
宣告完成前必须满足：
[DEBUG-...] 插桩已移除（grep 该前缀）然后追问：什么本可以预防这个 bug？ 如果答案涉及架构改动（缺好的测试接缝、调用方纠缠、隐藏耦合），把具体细节记为后续建议。在修复落地之后再提建议，而不是之前——此刻你掌握的信息比开始时多得多。