状态稳定
类型原子 Skill
领域软件测试
生命周期测试设计
适合角色QA / BA / PM / DEV
语言中文 / 英文
评测有评测 ✓
同步日期2026-09-15
解决什么问题
它把当前 Skill 的方法整理成可以直接执行、评审和复用的质量输入。
- 不发明阈值、优先级、状态迁移、角色权限、默认例外或适用范围。
- 不把示例、建议、文档存在或名称匹配写成已执行、已通过、已批准或已发布。
- 每条 BR-## 至少包含规则、来源、主体/对象、触发、前置条件、动作/结果、约束/不变量、例外、证据、未知项、影响和验证方法。
- 把多个相似句子合并成一条却丢失版本或地区范围。
适用场景
推荐使用
- 需要把分散的自然语言规则整理成可比较、可验证的 BR-## 条目。
- 需要识别角色、对象、触发、前置条件、动作、结果、不变量和例外。
- 需要在材料不完整或来源冲突时先交付有证据边界的规则初版。
常见误区
- 把多个相似句子合并成一条却丢失版本或地区范围。
- 用“通常”“及时”“合理”等常识替材料补出阈值。
- 只输出规则正文，不保留来源、例外、证据和未决问题。
输入
最低输入
- 当前任务范围、目标和待处理对象。
推荐输入
- 项目目标
- 测试范围
- 约束条件
可选上下文
- 相关代码或配置
- 历史结果
- 日志与指标
输出
输出会围绕该 Skill 的方法形成可执行结果，并明确事实、假设、风险和下一步。
不安装也能判断输出价值
- 01已记录六类输入审计项和适用范围
- 02每条 BR-## 都可追溯到最小来源证据
- 03事实、推断、建议和 Human 决策已分开
- 04例外、冲突、未知项和验证提示没有被省略
查看完整输出结构
- 05没有把静态材料或规则清单写成运行结果、审批或发布结论
工作原理
- 01先阅读并遵循 prompts/business-rule-extraction.md，审计目标、版本、时间和适用范围。
- 02将输入分为 known、missing、conflicting、stale、out_of_scope 和 assumptions；保留每个来源的原文和定位。
- 03只在材料支持时合并句子；否则拆成原子规则，并为每条规则建立 BR-##、来源和最小证据。
- 04分离直接事实、证据推断、建议和 Human 决策；单独列出例外、未知项、影响和验证提示。
- 05信息不足时交付受限初版，提出可指派、可关闭的补证问题，不把假设升级为事实。
安装与快速开始
安装命令 / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/business-rule-extraction
-gbusiness-rule-extraction.prompt
@skill business-rule-extraction
结合当前项目上下文，按该 Skill 的要求给出可执行结果。
补充上下文：
[粘贴项目背景或需求]---
name: business-rule-extraction
description: Use this skill when requirements, policies, contracts, or workflows need traceable business rules extracted before design or testing; triggers include 业务规则提取, business rule extraction, and policy rule inventory.
---
# 业务规则提取
从需求、政策、契约、流程、验收标准和用户提供的例子中提取可追溯的原子业务规则，保留来源、适用范围、例外和未知项。它是规则盘点与后续评审的输入，不是业务、合规或发布审批。
## 何时使用
- 需要把分散的自然语言规则整理成可比较、可验证的 `BR-##` 条目。
- 需要识别角色、对象、触发、前置条件、动作、结果、不变量和例外。
- 需要在材料不完整或来源冲突时先交付有证据边界的规则初版。
不适用于凭常识补造规则、决定最终优先级、执行系统验证或替业务角色批准政策。
## 输出格式选项
- 默认输出 Markdown；用户要求表格、CSV 或 JSON 时，保留相同的证据、状态、影响、责任角色和验证字段。
- 不把结构化格式或静态清单写成执行、通过、批准或发布证据。
## 如何使用
1. 先读取本 Skill 的主 Prompt，并提供目标、范围、材料、环境和已有证据。
2. 按 Prompt 的输入审计和输出合同执行；缺少信息时交付带边界的初版。
3. 对每条发现保留来源、证据状态、影响、责任角色、关闭条件和验证方法。
## 工作方式
1. 先阅读并遵循 `prompts/business-rule-extraction.md`，审计目标、版本、时间和适用范围。
2. 将输入分为 `known`、`missing`、`conflicting`、`stale`、`out_of_scope` 和 `assumptions`；保留每个来源的原文和定位。
3. 只在材料支持时合并句子；否则拆成原子规则，并为每条规则建立 `BR-##`、来源和最小证据。
4. 分离直接事实、证据推断、建议和 Human 决策；单独列出例外、未知项、影响和验证提示。
5. 信息不足时交付受限初版，提出可指派、可关闭的补证问题，不把假设升级为事实。
## 核心约束
- 不发明阈值、优先级、状态迁移、角色权限、默认例外或适用范围。
- 不把示例、建议、文档存在或名称匹配写成已执行、已通过、已批准或已发布。
- 每条 `BR-##` 至少包含规则、来源、主体/对象、触发、前置条件、动作/结果、约束/不变量、例外、证据、未知项、影响和验证方法。
- 冲突保留双方来源；无法证明时使用 `missing`、`stale` 或 `unassessed`，不要静默选择一方。
## 参考文件
- 每次产出前必须阅读 `prompts/business-rule-extraction.md`。
- 需要回归时读取 `evals/eval.yaml` 和匹配的 `evals/cases/`；这些文件不证明真实业务语义已执行。
- 需要检查触发行为时使用 `evals/trigger-prompts.csv` 与 `evals/local-rules.json` 运行仓库 trace runner；没有 `skill.selection` 证据时报告 `BLOCKED`。
- 以上是仓库根目录下的开发验证步骤；独立安装的 Skill 包不包含仓库级 runner，运行时不依赖该脚本。
## 最佳实践
- 优先处理高影响且可验证的缺口，使用最小实验或补证动作降低不确定性。
- 将事实、证据支持的推断、建议和 Human 决策分开，避免把假设升级为结论。
## 交付前自检
- [ ] 已记录六类输入审计项和适用范围
- [ ] 每条 `BR-##` 都可追溯到最小来源证据
- [ ] 事实、推断、建议和 Human 决策已分开
- [ ] 例外、冲突、未知项和验证提示没有被省略
- [ ] 没有把静态材料或规则清单写成运行结果、审批或发布结论
## 常见误区
- 把多个相似句子合并成一条却丢失版本或地区范围。
- 用“通常”“及时”“合理”等常识替材料补出阈值。
- 只输出规则正文，不保留来源、例外、证据和未决问题。