Requirement Ambiguity Analysis Skill: Turn Vague Wording into Closeable Questions
“The dashboard should load quickly for normal users” sounds reasonable until design and testing need to decide what quickly, normal, and load mean.
Why this Skill is needed
The Requirement Ambiguity Analysis Skill diagnoses under-specification while preserving the original wording and source. It lists plausible readings and the missing discriminator without silently choosing a business interpretation.
What the Skill does
The Skill makes ambiguity actionable without pretending to decide what the product owner meant.
Use this Skill before design or test planning when a requirement has unclear actors, objects, scope, quantity, timing, state, or acceptance criteria. It diagnoses and routes questions; it does not generate business rules.
A good finding uses an RA identifier, quotes the ambiguous statement, names the missing discriminator, lists possible readings, explains impact, and assigns a closeable question to an owner role.
Use it when a story uses words such as fast, timely, normal, appropriate, or when necessary, or when two teams can implement the same sentence differently.
What it does not do
The Requirement Ambiguity Analysis Skill can organize material, evidence, and next actions for Ambiguous statement. 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 |
|---|---|---|
| Ambiguous statement | Original wording and source location | Quoted evidence |
| Missing discriminator | Actor, threshold, state, timing, scope, or rule absent | Named gap |
| Possible readings | More than one plausible implementation meaning | Do not select one |
| Closeable question | Question an owner can answer and how to validate | Owner, priority, method |
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 Ambiguous statement, 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 Ambiguous statement, 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 |
|---|---|---|
| Requirement source | Exact story, acceptance criterion, version, and location | Do not analyze a paraphrase when source exists |
| Scope and actors | Product, role, state, platform, tenant, region, and time window | Mark applicability missing |
| Current evidence | Examples, prototypes, contracts, prior decisions, and related artifacts | Separate evidence from convention |
| Decision boundary | Role allowed to clarify and what cannot be inferred | Route the question instead of answering |
Use a request like this:
Use the requirement-ambiguity-analysis Skill.
Task: Analyze “the dashboard should load quickly for normal users and show relevant data when necessary.”
Inputs: [story version, product scope, user roles, prototype, performance context, existing decisions]
Scope: [web dashboard, authenticated users, first load and refresh]
Constraints: [do not choose a business threshold]
Preserve each ambiguous phrase, source, missing discriminator, possible readings, impact, owner question, close condition, and validation method. Use RA-## IDs and distinguish ambiguity from conflict.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: Make “fast” testable without defining it for the owner
For “load quickly,” the Skill can ask whether the measure applies to first contentful paint, usable interaction, or complete data load; which network and device; and which user cohort. It should not pick two seconds because that is common practice. The output is a decision request with a validation method, not an invented acceptance criterion.
The result shows that wording has multiple plausible readings from the supplied material. It does not decide the product rule, legal meaning, or final acceptance threshold.
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 Ambiguous statement 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 Ambiguous statement |
| Finding | The condition or result for Ambiguous statement 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 |
|---|---|---|
| Ambiguous statement | Original wording and source location | Quoted evidence |
| Missing discriminator | Actor, threshold, state, timing, scope, or rule absent | Named gap |
| Possible readings | More than one plausible implementation meaning | Do not select one |
| Closeable question | Question an owner can answer and how to validate | Owner, priority, method |
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
Supply the exact requirement and source, scope, actors, known examples, related design or contract, and the role allowed to clarify it. Incomplete input is acceptable, but ask three to five high-value questions.
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 Quality Review:checks broader readiness before design or testing.
- Requirement Consistency Analysis:compares terms and rules across artifacts.
- Requirement Conflict Detection:handles explicit mutually exclusive statements.
Common traps
- Replacing an ambiguous word with a familiar threshold and presenting the rewrite as the requirement.
- Treating a missing second source as a conflict instead of a missing discriminator.
- Listing ambiguity without preserving the original statement, owner, close condition, or validation method.
Install and invoke
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/requirement-ambiguity-analysis -gUse the requirement-ambiguity-analysis 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
Can the Skill rewrite the requirement?
It can suggest a clarification question or candidate wording, but it must keep the source and avoid presenting an unapproved interpretation as final.
What if only one requirement document exists?
Ambiguity can still be found within one source. Conflict requires mutually exclusive evidence; do not invent a second side.
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 Ambiguity Analysis 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 Ambiguity Analysis prompt:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/requirement-ambiguity-analysis/prompts/requirement-ambiguity-analysis.md
- Requirement Ambiguity Analysis Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/requirement-ambiguity-analysis
- Requirement Ambiguity Analysis details:https://inaodeng.com/en/qaskills/requirement-ambiguity-analysis/
- Awesome QA Skills on GitHub:https://github.com/naodeng/awesome-qa-skills