requirement-ambiguity-analysis

Requirements Ambiguity Analysis

Identify expressions in requirements that cannot be understood uniquely or cannot be determined, preserve the original sentence and source, explain which distinguishing condition is missing, and how the issue can be closed by the responsible role. It analyzes under-specification and does not choose an interpretation on behalf of the user.

When to Use

Requirements contain undefined terms such as "timely", "quickly", "when necessary", "normal", "support", etc.
Roles, objects, scope, quantities, conditions, time, states, or acceptance determinations have multiple possible interpretations.
It is necessary to determine whether a sentence is ordinary ambiguity or already constitutes a cross-source conflict.

Not applicable to final adjudication where explicit mutually exclusive rules already exist, test execution, or completing business rules from common sense.

Output Format Options

Default output is Markdown; when the user requests tables, CSV, or JSON, preserve the same evidence, status, impact, responsible role, and verification fields.
Do not write structured formats or static checklists as execution, pass, approval, or release evidence.

How to Use

First read this Skill's main Prompt, and provide the goal, scope, materials, environment, and existing evidence.
Execute according to the Prompt's input audit and output contract; when information is missing, deliver a bounded initial version.
For each finding, preserve the source, evidence status, impact, responsible role, closure conditions, and verification method.

Working Approach

Read and follow prompts/requirement-ambiguity-analysis.md。
First perform an input audit, distinguishing known, missing, conflicting, stale, out-of-scope, and minimal assumptions.
Preserve each ambiguous original sentence, source, applicable scope, and missing distinguishing item one by one; list possible interpretations, but do not choose one of them.
Sort by delivery, quality, and testability impact, and provide assignable, closable issues and verification methods.
If materials are explicitly mutually exclusive, mark them as conflicts and recommend using requirement-conflict-detection; write only the Skill name, do not link its internal files.

Domain Execution Points

The above uppercase determinations are only used for the item-by-item decision appendix; the original RA finding still uses ambiguous/missing/untestable/conflict/stale/out_of_scope. CLEAR is the correct control, placed in the overview and explained as testable, and no issues are manufactured to satisfy the finding template.

Preserve requirement ID, source, version, and original text; first distinguish AMBIGUOUS for multiple interpretations of the same sentence, MISSING_RULE for no rule, CONFLICT for contradictory sources, and CLEAR for explicitly testable, and do not falsely report normal shorthand just to make up findings.
For each ambiguity, list at least two reasonable interpretations, applicable conditions, different business/test consequences, and supporting original text; when there is no second reasonable interpretation, check whether it is actually missing information.
Use minimal discriminating questions to distinguish interpretations, such as the starting event, comparison operator, concurrent submission point, or inclusion scope; provide suggested options, but preserve the product owner's final decision.
Mark explicit standards as CLEAR and give observable expectations; do not fill in self-defined time limits, thresholds, or business rules for unknown results. Prioritize clarification by impact and implementation blockage.

Core Constraints

Use RA-## to identify findings; at least distinguish ambiguous、missing、untestable、conflict and out_of_scope。
Do not fill in missing thresholds, roles, formats, time limits, states, or permissions from common sense.
For each important finding, preserve source, the original sentence, missing distinguishing item, possible interpretations, impact, priority, question, responsible role, and verification method.
When information is insufficient, still provide a minimal usable initial version, and explicitly list assumptions and 3–5 high-value questions.
Do not decide which interpretation is the final requirement, and do not adjudicate on behalf of product, business, or compliance roles.

Reference Files

When calibrating domain outcomes, correct comparisons, or evidence gaps, read the desensitized input, item-by-item expectations, and recalculation basis of references/domain-decision-example.md .
Must read before every output prompts/requirement-ambiguity-analysis.md。
When regression against this Skill is needed, use evals/eval.yaml and evals/cases/; file structure or rule evaluation does not represent real project effectiveness.
When discovery behavior needs to be verified, use evals/trigger-prompts.csv and evals/local-rules.json to run the repository's scripts/run_skill_trace_eval.py; when skill.selection evidence is missing, you must report BLOCKED, and must not infer that triggering succeeded.
The above are development verification steps under the repository root directory; an independently installed Skill package does not include the repository-level runner, and does not depend on that script at runtime.

Best Practices

Prioritize high-impact and verifiable gaps, and use minimal experiments or supplementary evidence actions to reduce uncertainty.
Separate facts, evidence-supported inferences, recommendations, and Human decisions, to avoid escalating assumptions into conclusions.

Pre-delivery Self-check

has cited the ambiguous original sentence and source
has stated the missing decidable distinguishing items, rather than only saying "there is ambiguity"
has separated possible understandings from the final adjudication
has given the responsible role, closure conditions, and verification method for P0/P1 issues
has routed clear conflicts out, without silently choosing a side

Common Misconceptions

Treating "the industry usually does this" as a requirement fact.
Only rewriting the sentence, without explaining what impact different understandings would cause.
Forcibly merging two versions or rules with different scopes of application.
Refusing to output any usable initial version on the grounds of "insufficient information".