Requirement Conflict Detection Skill: Separate Real Contradictions from Scope Differences
Two documents can look contradictory and still be correct when one applies to a different tenant, version, region, or user state. Conflict detection must test the boundary before escalating the contradiction.
Why this Skill is needed
The Requirement Conflict Detection Skill compares mutually exclusive rules without choosing precedence. It preserves both statements, conditions, evidence, and decision owner so a missing applicability boundary is not mistaken for a product conflict.
What the Skill does
The first question is not which document sounds stronger; it is whether both rules apply to the same thing.
Use this Skill when requirements, policies, contracts, or acceptance artifacts may allow and prohibit the same behavior within one scope. It diagnoses conflict; it does not accept risk, invent a compromise, or decide which source wins.
A good finding uses an RF identifier, preserves both statements and sources, verifies shared object and scope, identifies minimum evidence, and asks a Human a closeable precedence question.
Use it when one artifact allows a behavior and another forbids it, or a change exposes different rules for the same role, state, field, or action.
What it does not do
The Requirement Conflict Detection Skill can organize material, evidence, and next actions for Source pair. It does not replace:
- Confirmation of rules, scope, and risk by the accountable domain owner.
- A real environment, account, dataset, log, or run record; static analysis does not become runtime evidence by itself.
- Authorization for release, compliance, production actions, or residual-risk acceptance.
- A Human decision when supplied sources conflict.
What it checks
The value of this Skill is not another keyword list. It connects each focus area to an observable input, a judgment, and a way to close the loop. Start with a small matrix based on the source Skill’s output contract:
| Focus | Question before analysis | Handoff output |
|---|---|---|
| Source pair | Both original statements and versions | Traceable evidence |
| Applicability check | Whether actor, object, region, state, and time match | Shared scope or missing boundary |
| Conflict status | Conflict, ambiguous, missing, stale, or unassessed | Do not silently downgrade |
| Decision request | Question, owner, close condition, and validation | Human precedence boundary |
If a row has only a conventional expectation and no source or validation method, keep it open instead of turning it into a pass.
Audit inputs before you start
Before analyzing Source pair, classify the input into six evidence states. A gap is not automatically a failure, but it must not disappear inside the conclusion.
| State | Meaning | How this Skill should handle it |
|---|---|---|
| known | Directly supported by the supplied material | Keep the source, version, and time with the judgment |
| missing | Needed for this pass but not supplied | Name the smallest evidence action and limit the conclusion |
| conflicting | Sources disagree | Show both sources and route the conflict to an owner |
| stale | Present but outside the relevant version or time window | Mark freshness; old evidence is not current proof |
| out_of_scope | Related but excluded from this pass | Keep the boundary explicit |
| assumptions | Temporarily adopted to continue analysis | State how and when the assumption will be checked |
Keep the input version, scope, environment, evidence locations, and accountable owner together. Without a run record, deliver analysis, design, or a validation plan—not an execution pass.
From problem to structured Finding
Connect the source, scope, evidence state, analysis, owner, action, close condition, and validation before writing the conclusion. The case below keeps this Skill’s identifier and domain context.
Keep the decision layers separate
For Source pair, do not compress four different kinds of language into “recommended to pass”:
| Layer | How to write it | Application here |
|---|---|---|
| Fact | What the supplied material directly shows | Cite the source, version, input, or run record for the focus |
| Evidence-backed Inference | What several facts support together | Show the inference chain and retain uncertainty |
| Recommendation | The smallest next action | Name the evidence, review, execution, or regression path |
| Human Decision | What an accountable person must decide | Leave scope, risk acceptance, resources, and release meaning to the owner |
A complete case
This case follows Input, Analysis, Finding, Decision, and Validation. When material is incomplete, keep missing, conflicting, or assumptions visible instead of turning them into a pass.
Input
| Material | What to provide | What to do when it is missing |
|---|---|---|
| Source pair | Requirement, policy, contract, design, or acceptance statements with versions | Do not summarize away either source |
| Applicability | Actor, state, platform, tenant, region, time, and release scope | Treat missing scope as missing evidence |
| Conflict candidate | Object, action, quantity, or constraint that appears mutually exclusive | Do not label a boundary difference conflict |
| Decision owner | Role that can approve precedence or request a specification update | Do not choose precedence in analysis |
Use a request like this:
Use the requirement-conflict-detection Skill.
Task: Determine whether a privacy policy's 30-day deletion rule conflicts with an analytics contract's 90-day retention rule for EU customer events.
Inputs: [policy versions, contract, tenant and region scope, data classification, effective dates]
Scope: [EU production data and customer events]
Constraints: [no final legal interpretation, no data changes]
Preserve both statements, check applicability first, classify conflict versus missing or stale evidence, and provide RF-## findings with a decision question, owner, close condition, and validation method.Analysis
Use the input, matrix, and evidence state to form the judgment before writing the Finding; keep missing material as a gap.
Finding
Focused example: Test retention rules without choosing a legal winner
The policy says EU customer events must be deleted after 30 days, while the analytics contract says events are retained for 90 days. The Skill should verify whether the contract covers the same event class and region, preserve both sources, and route precedence to privacy and product owners. If the contract is global and excludes EU data, the apparent conflict becomes a scope difference.
The analysis proves how supplied rules relate under the supplied scope. It does not provide legal advice, approve retention, or change data.
Example finding: turn one problem into a handoff
The field example below shows the recording pattern; it is not an execution result.
If the supplied material cannot prove that Source pair meets its contract, write the finding like this. It does not invent the missing rule or turn missing evidence into a failure.
| Field | Example wording |
|---|---|
| Source and scope | Record the requirement, version, environment, and the concrete object for Source pair |
| Finding | The condition or result for Source pair is not yet traceable to evidence |
| Evidence state | missing / assumptions; use conflicting when sources disagree |
| Impact and priority | Name the affected user, journey, or delivery decision without inflating severity |
| Owner and Human decision | Ask the product, engineering, security, or test owner to confirm the rule and trade-off |
| Action and close condition | Add the smallest missing evidence; close only when source, judgment, and owner can be reviewed |
| Validation | Name one repeatable check, query, or run and retain the raw artifact |
The point is to let the next person walk from the finding back to the source and run an action that can change the decision.
Decision
The accountable owner confirms the decision question and risk trade-off; the Skill does not make that choice.
Validation
Before closing the finding, run the stated validation and retain the raw artifact. Without an execution record, the status remains unverified.
How a Finding enters the next stage
Handoff output
| Output field | Why it exists | Example status |
|---|---|---|
| Source pair | Both original statements and versions | Traceable evidence |
| Applicability check | Whether actor, object, region, state, and time match | Shared scope or missing boundary |
| Conflict status | Conflict, ambiguous, missing, stale, or unassessed | Do not silently downgrade |
| Decision request | Question, owner, close condition, and validation | Human precedence boundary |
Every conclusion should point to a source, evidence state, and next action. If evidence is missing, use pending, blocked, unassessed, or NOT_SCORED instead of filling the gap with confidence.
Next-stage route
At minimum, hand off the source, evidence state, owner, close condition, and validation action; the next-stage conclusion remains bounded by the evidence state.
How to prepare better input
Provide source text, versions, effective dates, data object definition, actor, tenant, region, platform, and state. If a boundary is missing, classify it missing or stale before calling it conflict.
A useful handoff includes input versions, scope, time window, evidence index, assumptions, Human decision boundary, and the smallest validation action.
Working with other Skills
- Requirement Ambiguity Analysis:separates unclear wording from mutually exclusive rules.
- Requirement Consistency Analysis:compares artifacts before conflict routing.
- Security Requirement Review:examines high-impact security constraints.
Common traps
- Choosing the stricter or newer-sounding rule without checking scope and authority.
- Merging two rules into an unapproved compromise sentence.
- Calling a missing version or region boundary a conflict and sending teams to fix the wrong problem.
Install and invoke
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/requirement-conflict-detection -gUse the requirement-conflict-detection Skill.
Include objective, scope, versions, evidence paths, constraints, and decision boundary.
Audit inputs first, preserve evidence states, and finish with owner, close condition, and validation method.FAQ
Should the Skill decide which requirement wins?
No. It preserves evidence and asks the accountable Human to decide precedence, risk acceptance, or specification change.
What if the sources use different versions?
Check effective dates and applicability. Mark stale or unassessed when the comparison window is unknown; do not treat version drift as a current conflict automatically.
The Skill is most useful when attached to one real project artifact and kept with its source evidence. Start narrow, validate the uncertain part, and expand only when evidence supports it.
References
Source Skill and execution contract
The complete execution contract lives in Requirement Conflict Detection prompt. The source directory may also contain evaluation cases and supporting material.
Static plans, file presence, and dry runs keep their evidence state. They do not become runtime proof, an all-passed claim, or release approval.
Reference links
- Requirement Conflict Detection prompt:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/requirement-conflict-detection/prompts/requirement-conflict-detection.md
- Requirement Conflict Detection Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/requirement-conflict-detection
- Requirement Conflict Detection details:https://inaodeng.com/en/qaskills/requirement-conflict-detection/
- Awesome QA Skills on GitHub:https://github.com/naodeng/awesome-qa-skills