状态稳定
类型原子 Skill
领域软件测试
生命周期测试设计
适合角色BA / PM / DEV
语言中文 / 英文
评测有评测 ✓
同步日期2026-09-15
解决什么问题
它把当前 Skill 的方法整理成可以直接执行、评审和复用的质量输入。
- 使用 RF-## 标识发现；每条至少有双方陈述、来源、适用条件、最小证据、影响、优先级和待决策项。
- 不删除、改写或折中任一来源，不替 Human 选择 precedence、风险接受或最终规范。
- 同一规则在不同版本、平台、租户、地区或角色生效时，先报告范围差异；不能直接判定为冲突。
- 看到“must”和“should”就自行判定强弱并选一条。
适用场景
推荐使用
- 不同材料分别要求允许和禁止同一行为。
- 角色、状态、权限、数量、时间或接口约束在同一范围内互相排斥。
- 需要确认冲突是否真实存在，还是由版本、平台、租户或适用条件不同造成的表面差异。
常见误区
- 看到“must”和“should”就自行判定强弱并选一条。
- 忽略版本、平台、租户、地区或角色边界，制造跨范围冲突。
- 只有一条规则或缺少来源时，凭经验补出另一方。
- 用折中句覆盖原始双方，导致后续裁决无法追溯。
输入
最低输入
- 当前任务范围、目标和待处理对象。
推荐输入
- 项目目标
- 测试范围
- 约束条件
可选上下文
- 相关代码或配置
- 历史结果
- 日志与指标
输出
输出会围绕该 Skill 的方法形成可执行结果，并明确事实、假设、风险和下一步。
不安装也能判断输出价值
- 01每条 RF-## 都保留双方来源、版本/范围和最小证据
- 02已区分 conflict、ambiguous、missing、stale 和 unassessed
- 03未静默合并、改写或替双方决定优先级
- 04P0/P1 冲突有责任角色、待决策问题、关闭条件和验证方法
查看完整输出结构
- 05未把静态材料、实现存在或测试报告文字当成实际执行证据
工作原理
- 01阅读并遵循 prompts/requirement-conflict-detection.md。
- 02先审计来源、版本、时间、角色、平台、地区、租户和适用条件；范围不明时标记限制。
- 03将互斥陈述成对保留，确认它们是否针对同一对象、同一动作和同一适用范围。
- 04区分 conflict、ambiguous、missing、stale 和 unassessed，不把缺少证据升级成冲突。
- 05输出影响、优先级、待决策问题、建议责任角色、关闭条件和验证方法。
安装与快速开始
安装命令 / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/requirement-conflict-detection
-grequirement-conflict-detection.prompt
@skill requirement-conflict-detection
结合当前项目上下文，按该 Skill 的要求给出可执行结果。
补充上下文：
[粘贴项目背景或需求]---
name: requirement-conflict-detection
description: Use this skill when multiple requirement, policy, contract, or acceptance sources may contain mutually exclusive rules or constraints; triggers include 需求冲突检测, requirement conflict detection, and conflicting requirements.
---
# 需求冲突检测
从多份需求、政策、契约、设计或验收材料中识别同一适用范围内互相排斥的规则和约束。保留双方原始来源、适用条件和证据，将需要业务裁决的事项交给 Human，不替团队选择最终优先级。
## 何时使用
- 不同材料分别要求允许和禁止同一行为。
- 角色、状态、权限、数量、时间或接口约束在同一范围内互相排斥。
- 需要确认冲突是否真实存在，还是由版本、平台、租户或适用条件不同造成的表面差异。
不适用于只有一个来源且没有互斥陈述的普通需求审阅，也不用于替业务接受风险、裁决优先级或生成未经批准的折中规则。
## 输出格式选项
- 默认输出 Markdown；用户要求表格、CSV 或 JSON 时，保留相同的证据、状态、影响、责任角色和验证字段。
- 不把结构化格式或静态清单写成执行、通过、批准或发布证据。
## 如何使用
1. 先读取本 Skill 的主 Prompt，并提供目标、范围、材料、环境和已有证据。
2. 按 Prompt 的输入审计和输出合同执行；缺少信息时交付带边界的初版。
3. 对每条发现保留来源、证据状态、影响、责任角色、关闭条件和验证方法。
## 工作方式
1. 阅读并遵循 `prompts/requirement-conflict-detection.md`。
2. 先审计来源、版本、时间、角色、平台、地区、租户和适用条件；范围不明时标记限制。
3. 将互斥陈述成对保留，确认它们是否针对同一对象、同一动作和同一适用范围。
4. 区分 `conflict`、`ambiguous`、`missing`、`stale` 和 `unassessed`，不把缺少证据升级成冲突。
5. 输出影响、优先级、待决策问题、建议责任角色、关闭条件和验证方法。
## 核心约束
- 使用 `RF-##` 标识发现；每条至少有双方陈述、来源、适用条件、最小证据、影响、优先级和待决策项。
- 不删除、改写或折中任一来源，不替 Human 选择 precedence、风险接受或最终规范。
- 同一规则在不同版本、平台、租户、地区或角色生效时，先报告范围差异；不能直接判定为冲突。
- 缺少版本、范围、来源或上下文时，标记 `missing`/`stale`/`unassessed` 并提出补证问题。
- 不把静态文档中的“已通过”、已有实现或表格存在写成运行时验证结果。
## 参考文件
- 每次产出前必须阅读 `prompts/requirement-conflict-detection.md`。
- 需要回归本 Skill 时使用 `evals/eval.yaml` 和 `evals/cases/`；结构门禁不等于冲突语义已被运行验证。
- 需要验证发现行为时，使用 `evals/trigger-prompts.csv` 与 `evals/local-rules.json` 运行仓库的 `scripts/run_skill_trace_eval.py`；缺少 `skill.selection` 证据时必须报告 `BLOCKED`，不能推断触发成功。
- 以上是仓库根目录下的开发验证步骤；独立安装的 Skill 包不包含仓库级 runner，运行时不依赖该脚本。
## 最佳实践
- 优先处理高影响且可验证的缺口，使用最小实验或补证动作降低不确定性。
- 将事实、证据支持的推断、建议和 Human 决策分开，避免把假设升级为结论。
## 交付前自检
- [ ] 每条 `RF-##` 都保留双方来源、版本/范围和最小证据
- [ ] 已区分 `conflict`、`ambiguous`、`missing`、`stale` 和 `unassessed`
- [ ] 未静默合并、改写或替双方决定优先级
- [ ] P0/P1 冲突有责任角色、待决策问题、关闭条件和验证方法
- [ ] 未把静态材料、实现存在或测试报告文字当成实际执行证据
## 常见误区
- 看到“must”和“should”就自行判定强弱并选一条。
- 忽略版本、平台、租户、地区或角色边界，制造跨范围冲突。
- 只有一条规则或缺少来源时，凭经验补出另一方。
- 用折中句覆盖原始双方，导致后续裁决无法追溯。