بنقرة واحدة
defect-analyze
收到异常堆栈/控制台报错/HTTP 失败、带合并冲突标记的文本,或代码 diff/分支对,做根因分诊、冲突解决或静态缺陷扫描。已登记的 ZenTao bug URL/ID 改用 case-hotfix。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
收到异常堆栈/控制台报错/HTTP 失败、带合并冲突标记的文本,或代码 diff/分支对,做根因分诊、冲突解决或静态缺陷扫描。已登记的 ZenTao bug URL/ID 改用 case-hotfix。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
把需求用例目录路径/目录名(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。