agentleFS
limoaCatherinelimoaCatherine/game-studio-harness/skills/client-bugfix/SKILL.md

client-bugfix

Skill4 starsChanged 53 days agoMITView on GitHub

按复现→取证→假说→最小改动→回归点验证修客户端缺陷。触发:修 bug、客户端修复、崩溃修复。

The file

Files
SKILL.md

客户端缺陷修复

何时用

  • 缺陷已立项,要改代码前先稳住复现
  • 崩溃/卡死/显示错,缺栈或日志证据
  • 需要最小修复并证明相关路径不再失败
  • 三次假说仍无根因,需停手上报阻断而非盲改

怎么做

1. 缩最短复现

  1. 打开缺陷单,成对写下「期望行为」与「实际行为」各一句;写清可观察结果。
  2. 记下环境维:构建号/SHA、平台与机型、画质档、语言、必要进度态;缺则先向报告人补齐。
  3. 按单上步骤操作一遍;能复现则删减无关前置,直到仍失败的最短编号路径;第三人应能照做。
  4. 频率写「总是/常见/偶发+触发条件」。
  5. 不稳定复现:先开日志开关、换同平台另一构建、或固定随机种子;仍不稳则标 CANNOT VERIFY 所需项,补齐证据后再开改。
  6. 若仅特定存档触发:复制坏档到隔离目录,对比好档差异字段,把触发字段写进复现前置。

做到:第三人可照最短步骤复现;期望/实际成对;环境字段齐;不稳定则已写阻断项。

不合格:不稳定却强行开改 → 标 CANNOT VERIFY,回本步补证据。

2. 收证据包

  1. 崩溃:导出符号化栈;无符号则先取本构建符号包再取证。
  2. 日志:截取失败前后各 30~60 秒关键通道;关键字定位首次坏行;摘录存为 repro_<bugid>_log.txt。
  3. 画面/流程:失败瞬间截图或短录像;卡顿另存 Profiler 尖峰帧摘要与伴随操作。
  4. 变更面:用版本库 CLI 日志与二分标出首次坏提交候选 SHA 与触文件。
  5. 证据目录:bugs/<id>/ 下放置 repro_steps.md、log.txt、stack.txt、截图、profiler 摘要;缺哪类在单里写「缺什么才能验」。

做到:证据包可指向文件/帧号/提交;开改依据是栈/日志/对照,不是「感觉像」。

不合格:仅凭「感觉像」无栈/日志/对照 → 停手回本步补证据。

3. 假说排序与单条验证

  1. 列 2~4 条假说,按先验排序:①最近相关提交 ②空引用/生命周期 ③竞态/时序 ④资源/表配置与代码假设不一致。
  2. 每条假说写「若真,应看到的证据」与「一次最小实验」(断点、临时断言、对照关闭某系统、好档/坏档对比)。
  3. 一次只验证一条;记录确认/否定/不确定。否定则划掉再测下一条。
  4. 连续三条假说失败:停手,把实验日志与仍开放假说写回缺陷单,标阻断;不做扩大重构碰运气。
  5. 根因确认标准:能稳定指出哪一行/哪张表/哪个资源在复现步骤下导致期望失败,并用对照实验证明改该点即可改变结果。
  6. 区分「根因」与「触发条件」:修根因,而不只关掉该触发技能。

做到:已确认根因有可复现证明;或明确阻断与已否定假说列表。

不合格:把触发条件当根因 → 回本步区分根因与触发。

4. 最小改动

  1. 只改证明根因所需的代码/配置/资源引用;diff 应能一句话解释「为何这几行消除该根因」。
  2. 本 diff 只含根因所需行:无关重命名、整文件格式化、顺手改数值另开提交/单。
  3. 本地按原最短复现:改前应失败、改后应通过;相关单测能抓住该根因则先补再合入。
  4. 若必须加兜底:兜底日志要带原因码,且另开「根治」项;FIXED 结论只在根因已修且原步骤通过时写。
  5. 改动涉及存档/协议字段时,交 save-schema-pass / server-api-contract,不在本缺陷里偷偷改。

做到:diff 范围可解释;原步骤本地已失败→通过;相关测已绿或已补。

不合格:兜底掩盖无原因码或未修根因却写 FIXED → 回本步改根因点。

5. 选回归点并验证

  1. 回归点挑选:①原复现步骤 ②同系统邻接路径 ③历史同文件热点曾坏过的用例 ④同列表抽样。
  2. 跑相关自动子集;手工跑邻接 3~5 条;记录通过/失败。
  3. Grep 同类模式:空引用模式、错误 API 用法、同样未校验的表字段;命中则评估同修或另开单。
  4. 结论只允许:FIXED / STILL PRESENT / CANNOT VERIFY(写缺什么);写回缺陷单「验证」区。

做到:原步骤不再复现;邻接与同类模式有结果;结论枚举正确。

不合格:原步骤未再跑或邻接全跳 → 回本步补回归。

做到

  • 第三人可照最短步骤复现且证据包路径齐全
  • 根因有对照实验证明;最小 diff 使原步骤失败→通过
  • 邻接与同类模式有结果;结论枚举正确写入缺陷单

失败回哪一步

  • 期望/实际不成对、环境缺构建号、复现不稳 → 回步骤 1
  • 无符号化栈、无日志摘录 → 回步骤 2
  • 三条假说失败、根因未指到行/表/资源 → 回步骤 3(停手上报阻断)
  • diff 含顺手重构、原步骤未本地失败→通过 → 回步骤 4
  • 邻接未跑、同类模式未检索、结论缺证据 → 回步骤 5

下一步常接:bug-report-write(补单)→ regression-pack。存档/加密类根因交 save-schema-pass,不在本技能加厚。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.