requirement-gap-analysis

Requirement Gap Analysis (Chinese Version)

When to Use

You need to discover ambiguity, omissions, conflicts, unverifiable items, and cross-role dependency gaps in requirements.
You need to conduct a risk review of existing solutions, results, or evidence, and form actionable improvement items.
The input is incomplete, but a usable initial version with assumptions and information gaps still needs to be provided first.

The default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enumeration values, and required items.

First read and follow prompts/requirement-gap-analysis.md 's input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, constraints, evidence, and success criteria that genuinely affect judgment.
First conduct an input audit, then distinguish confirmed facts, reasonable assumptions, and issues to be confirmed.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or verified.
When information is insufficient, do not stop at asking questions: first deliver a constrained initial version, and state which conclusions cannot currently hold.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized input, item-by-item expectations, and recalculation basis.
Each execution must read prompts/requirement-gap-analysis.md; it is the complete execution specification of this Skill.
When evaluating or regressing this Skill, read evals/eval.yaml and the matching evals/cases/ test cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Build a requirements checklist based on scope/version and applicable roles, states, rules, exceptions, and closure conditions; note the source and coverage of provided materials for each item, and do not force a generic checklist onto an inapplicable product.
List MISSING_RULE (confirmed relevant but the rule is undefined), MISSING_MATERIAL (referenced material not provided), CONFLICT (provided rules conflict), N/A (not applicable with a scope reason), and COMPLETE separately.
For gaps, provide the original requirement ID, missing content, affected scenarios, blocking degree, owner, and minimum clarification; an empty document or unseen fields do not automatically prove a product defect.
Closure requires authoritative supplementary rules/source version and testable expectations, and updates the traceability; suggested filling methods remain proposals without approval, and a sufficiently defined correct comparison must not be reported as a gap.

Do not make business decisions on behalf of stakeholders
Distinguish facts, inferences, and questions
Prioritize gaps that would cause rework or incidents
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide a verification method.
Priority must state the basis in business impact, likelihood of occurrence, or detectability.

Covered: objectives and scope, roles, rules, states, exceptions, data, permissions, dependencies, non-functional requirements, acceptance, and rollback.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priorities, evidence, owners, or next steps.
The output includes verifiable judgment criteria rather than generalities.
No unauthorized production write operations or destructive actions were performed.

Listing only checkpoints without specifying input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of trade-offs.
Replacing domain judgment with tool names or general theories.
Directly refusing when input is incomplete, or conversely pretending the conclusion is already certain.

Start with the paths most likely to cause business loss, security issues, or release blockers.
Use the smallest verifiable experiment to reduce uncertainty, and record the reproduction conditions.
Make the output directly executable and reviewable by another engineer.