Menu
收到异常堆栈/控制台报错/HTTP 失败、带合并冲突标记的文本，或代码 diff/分支对，做根因分诊、冲突解决或静态缺陷扫描。已登记的 ZenTao bug URL/ID 改用 case-hotfix。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
把需求用例目录路径/目录名（features/【v...】）、MD 用例、PRD、Lanhu、Playwright 脚本或运行失败结果，转为或修复为可真实跑通的 UI 自动化。仅发送一个需求功能目录路径或目录名即可直接触发（目录→自动化；用例产物文件→case-edit）。仅手动操作浏览器、仅写非 UI 用例请转至 case-draft；仅做静态扫描请转至 defect-analyze。
拿到 bug ID、ZenTao bug URL（zenpms.dtstack.cn/zentao/bug-view-NNN.html）、缺陷描述或修复说明，产出聚焦修复路径、可直接执行的单条 hotfix 回归用例（archive.md）。仅发送 bug-view-NNN URL 或 bug ID 即可直接触发，无需附带文字说明。要基于失败证据写通用 bug 报告请转至 defect-analyze；依完整 PRD 产用例请转至 case-draft。
拿到既有用例产物文件(.xmind/.csv/archive.md)路径，编辑、同步、归档、标准化或在 Archive·XMind·CSV 间转换，语义不变是底线。依 PRD/需求源产新用例改用 case-draft；只给需求功能目录路径/目录名改用 playwright-automation。
依 Lanhu/Axure 链接(lanhuapp.com，含 axure/产品设计 URL)、Markdown PRD、设计稿、截图、fixture 或功能描述等需求源，生成、扩写或复核 QA 测试用例，产出 archive.md + cases.xmind。仅发送一条 Lanhu/Axure 链接即可直接触发，无需附带文字说明。仅做 Archive/XMind/CSV 格式转换请转至 case-edit；基于已有用例做自动化请转至 playwright-automation；单条 bug 记录（bug ID / ZenTao bug URL bug-view-NNN）请转至 case-hotfix。
出现数据源/数据库/服务器连通性报错(如 JDBC No route to host、连接超时或被拒)，SSH 登录只读排查并修复，并记录凭据与排查知识。纯前端运行时报错且无需 SSH 登录改用 defect-analyze；只查改业务知识改用 knowledge-curate。
查询、记录或维护项目业务知识、规则、术语、模块事实，或问「XX 是什么」(项目业务概念)，统一记录于 _shared/knowledge/。触发短语如「记一下这个规则」「XX 术语什么意思」「更新模块知识」。只问源码实现细节，或需要编写用例、扫描 diff、做 UI 自动化，请转至对应 case-*/defect-analyze/playwright-automation。
| name | defect-analyze |
| description | 收到异常堆栈/控制台报错/HTTP 失败、带合并冲突标记的文本，或代码 diff/分支对，做根因分诊、冲突解决或静态缺陷扫描。已登记的 ZenTao bug URL/ID 改用 case-hotfix。 |
| argument-hint | <异常堆栈 | 冲突文本 | diff/分支对> |
| user-invocable | true |
| model | sonnet |
| effort | medium |
按输入类型分流到三种模式；无证据支撑的内容一律不写进报告。
以下场景不属本 skill 范围，请转至对应 skill：
flowchart TD
I[输入] --> R{输入类型?}
R -->|异常堆栈、console、HTTP 失败| BUG[bug 模式：组装 BugReport JSON]
R -->|带冲突标记的文本| CON[conflict 模式：组装 ConflictReport JSON]
R -->|diff、分支对、变更集| DIFF[diff 模式：子代理静态扫描]
BUG --> BR[kata defect-report render-bug]
CON --> CR[kata defect-report render-conflict]
DIFF --> DR[kata scan-report]
BR --> H[report.html]
CR --> H
DR --> H
H -. 仅 bug 模式 .-> Z[推送禅道]
bug：收到异常堆栈、控制台报错、HTTP 失败等可复现 bug 证据，先组装 BugReport JSON，再用 kata defect-report render-bug（仅 zentao variant）产出 report.html。
conflict：收到带合并冲突标记的文本，先组装 ConflictReport JSON，再用 kata defect-report render-conflict 产出 report.html。
diff：需对仓库 diff、分支对或变更文件集做静态扫描时，新开一个 general-purpose 子代理执行扫描，再经 kata scan-report 产出 report.html。对比分支用以下命令序列（--slug 不传时按分支对自动生成；完整字段以 kata scan-report create --help 为准）：
# 1. 初始化 audit：拉基线/被测分支并算 diff
kata scan-report create --project <name> --repo <repo> --base-branch <ref> --head-branch <ref>
# 2. 子代理逐个 bug 写回（add-bug / update-bug / set-meta），证据须落在 evidence_refs
# 3. 渲染 report.html
kata scan-report render --project <name> --slug <slug>
bug 模式：实际行为、预期行为、复现步骤、影响范围四项必须分开陈述，不得合并。
conflict 模式：给出解决方案前，先把冲突双方各自的意图和依据写清楚（side_a / side_b），不得单边裁决。
diff 模式：只报告能依据所给 diff 与周边代码复现出来的缺陷。
通用约束：
evidence_refs。workspace/{project}/.kata/repos/** 是只读源仓库；如需修改，必须先获得用户确认，并在源仓库工作区中操作。三种模式都产出 report.html，但落点分两处，不要合并：kata defect-report（bug / conflict 模式）写 defectDir（_shared/archive/reports/bugs/），kata scan-report（diff 模式）写 auditDir（_shared/archive/audits/）。都不写入 feature 目录。
bug 模式产出 report.html 后按节点推进，输出仅走固定模板，不得夹带无关内容：
用 AskUserQuestion 询问「是否推送禅道创建 bug？」（推荐「是」）。选「否」即结束，不做任何禅道写操作。
选「是」→ 将 BugReport JSON 落盘，执行 bun run .claude/plugins/zentao/create.ts --json <BugReport.json>（产品、指派人向林、severity 映射等取插件 yaml；正文复用 zentao variant）。
解析命令输出：ok:true 且有 url → 按下方固定模板回显；ok:true 但仅带 note（禅道返回 success 却无可解析链接）→ 回显 note 文案，提示去禅道按标题核对；ok:false → 仅回一行简明原因（登录失败 / 缺必填 / 网络不可达 / 创建被拒），不得编造。
成功模板：
禅道链接已生成，相关信息如下：
- 禅道地址：<zentao_url>
- Bug 标题：<title>
一个 bug 链接只承载一处主修复建议（取 fix_suggestions 首条）。分析中发现的额外问题（补单测、相邻隐患等）用 AskUserQuestion 单独询问是否另开 bug，不得归入同一 bug。