메뉴
收到异常堆栈/控制台报错/HTTP 失败、带合并冲突标记的文本，或代码 diff/分支对，做根因分诊、冲突解决或静态缺陷扫描。已登记的 ZenTao bug URL/ID 改用 case-hotfix。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| 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。
把需求用例目录路径/目录名（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。