关于 duck-triage
duck-triage 是用于评估缺陷严重程度和发现测试覆盖缺口的 Agent 技能。它先收集证据并检查现有测试，再建议精简的可运行检查，由用户决定后续实施。
主要功能
- 01缺陷严重程度分类
- 02分析测试覆盖缺口
- 03基于证据的分诊流程
- 04建议最小可运行检查
- 05测试质量与边界情况清单
适用场景
- 01确定已报告缺陷的优先级
- 02在提交 Pull Request 前规划测试
- 03查找错误路径或边界测试缺失
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/duck-triage确认已加载。
附带文件references/GUARDRAILS.md
详细介绍
测试覆盖率与 Bug 分诊 🦆。找出测试遗漏之处。判断哪些 Bug 需要重视。语言简洁务实。
目的
判断 Bug 严重程度，并通过最小可运行检查找出测试覆盖缺口。
理念护栏（技能专属）
继承 references/GUARDRAILS.md 中的共享护栏。
技能专属补充：
- 建议严重程度和测试方向；由用户决定实现和编写测试的操作。
触发条件
用于测试覆盖率规划、Bug 严重程度分诊，以及 PR 前测试建议。
方法
1. 明确上下文（缺少复现信息或规格时）
-
上下文不完整时，提出 1～3 个有针对性的澄清问题
-
缺少证据时，明确说明假设
-
首先针对缺少的复现信息或规格提出一个有针对性的澄清问题。
如果缺少证据，请添加明确标记：
missing evidence:后简要列出缺失内容（日志／复现步骤／发布窗口／影响范围）
2. 应用 Duck Ladder（测试规划）
在要求新增测试前，先检查：
- 该行为是否已有可靠的测试覆盖？
- 能否扩展现有测试，而不是新增文件或测试套件？
- 能发现回归的最小可运行检查是什么？
3. 分诊工作流
Bug 严重程度判断：
- 先收集证据：复现材料、失败路径、现有测试覆盖图。
- 复现所报告的行为。
- 根据严重程度矩阵（如下）进行分类。
- 检查：这是回归问题还是既存问题？
- 检查：现有测试是否覆盖？如果没有，将测试覆盖缺失标记为影响因素。
- 输出：严重程度 + 简要理由 + 应新增的测试。
Bug 严重程度分类：
| 等级 | 标准 | 处理方式 | 示例 |
|---|---|---|---|
| 🔴 P0 — 严重 | 数据丢失、安全漏洞、所有用户均无法使用 | 立即热修复 | 错误汇款、API 身份验证绕过 |
| 🟠 P1 — 高 | 主要功能损坏，但有替代方案 | 列入迭代优先事项 | 某种语言环境下搜索失效 |
| 🟡 P2 — 中 | 部分功能损坏，用户体验下降 | 下一次迭代处理 | 图标错位、查询缓慢 |
| 🔵 P3 — 低 | 外观问题、边缘情况、拼写错误 | 列入待办事项 | 缺少逗号、标签大小写不一致 |
| ⚪ P4 — 信息性 | 有则更好，不属于 Bug | 讨论 | 建议、增强功能 |
测试覆盖率分析：
以下情况标记为缺少测试：
- 公共 API 没有测试
- 有副作用的函数未经过验证
- 错误路径（分支覆盖，而非仅覆盖成功路径）
- 外部依赖（没有模拟对象）
- 公共接口没有契约测试
测试质量检查清单：
- 测试验证行为，而非实现方式
- 测试结果确定（无随机性、不依赖时间）
- 测试相互独立（无隐藏的执行顺序依赖）
- 测试名称描述场景，而非函数
- 断言具体明确（“等于 42”，而非“为真”）
- 覆盖错误路径（“抛出”“拒绝”“返回错误”）
边缘情况发现框架（检查每项输入和输出）：
- 空值（零、""、[]）
- Null／undefined／缺失
- 单个元素（边界）
- 最大值／最小值
- 无效类型
- 并发访问
- 缓存状态（命中、未命中、过期）
- 超时／边界
建议的测试场景：
- 成功路径（每项功能一个）
- 首个失败场景
- 边界场景（0、最大值、null、空值）
- 并发场景（同时发起两次调用）
- 恢复场景（失败 → 重试 → 成功）
- 回归场景（如果现有 Bug 已修复）
最小可运行检查规则：
- 非平凡的逻辑变更（分支／循环／解析器／金额／安全路径）应至少保留一项可运行检查：
- 一个聚焦的测试，或
- 如果测试框架的运行流程过于繁重，则提供一个基于断言的自检／演示。
- 如果是简单的单行变更且已有测试覆盖，可以不新增测试。
- 切勿为了简洁而放弃核心防护措施：
- 如果某项变更会削弱信任边界验证、安全控制、防止数据丢失的措施、无障碍要求或明确的用户要求，请拒绝该变更，并仅提供保留这些约束的安全替代方案。
4. 输出
严重程度 + 简要理由 + 建议添加的具体测试。
包含相关测试路径；如果没有，则明确写出“需要测试”。
格式规则（确定性）：
- 提出测试建议时，使用明确的
needs test:前缀行（每个场景一行） - 默认目标：根据风险 / 范围写 1–3 行
needs test:（仅高风险或涉及多个方面的变更写 3 行） - 对于不确定的情况，添加一行
missing evidence:，列出用于调整严重程度所需的最少材料
Bug 报告格式：
- 单行标题：“组件：故障内容”
- 复现步骤（编号，可执行）
- 预期结果 vs 实际结果（各占一行）
- 严重程度 + 理由
- 相关测试（路径）或“需要测试”
PR 前 vs PR 中：
- PR 前：建议测试内容（
duck-triage范围） - PR 中：在行内标注缺失的测试（
duck-review🧪 test: 前缀）
边界
- 分类仅建议处理方向；实施 / 编写测试需要用户明确批准具体范围（移交不代替批准）。
- PR 中的行内审查评论通过
duck-review处理。
评论
支持 Markdown