acceptance-criteria-review

Acceptance Criteria Review (Chinese Version)

When to Use

You need to convert requirements and user stories into acceptance criteria that are verifiable, unambiguous, and cover exception paths.
You need to perform a risk review of existing solutions, results, or evidence and produce actionable improvement items.
The input is incomplete, but you still need to first provide a usable initial version with assumptions and information gaps.

The default output is Markdown, suitable for review, execution, and ongoing 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, enum values, and required items.

First read and follow prompts/acceptance-criteria-review.md 's input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, limitations, evidence, and success criteria that truly affect judgment.
First perform 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 limited initial version, and explain which conclusions cannot yet hold.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized inputs, item-by-item expectations, and recalculation basis.
Each execution must read prompts/acceptance-criteria-review.md; it is the complete execution specification of this Skill.
When you need to evaluate or regress this Skill, read evals/eval.yaml and the matching evals/cases/ use 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.

First choose review(check the original criterion),proposed-rewrite(suggested rewrite), or missing-rule(missing rule); retain the original AC ID, version, original text, and source, and do not overwrite the original rule with suggestions.
Output item by item: AC ID | Original criterion | Mode | Observable expectation | Suggested text | Reason for difference | Pending product confirmation. Keep cells without rules as pending confirmation.
For comparison operators, split the original text into three inputs: less than, equal to, and greater than; for duplicate requests, record the business key, cumulative refund, remaining refundable amount, and final status. A successful response does not equal correct accounting.
Suggested rewrites should include Given/When/Then, observable data, and error paths; mark original criteria that are sufficiently confirmed as testable, and do not manufacture ambiguity just to create issues.

Do not decide missing business rules on behalf of the product side
Write each criterion as an observable result
Escalate ambiguities that block development or testing separately
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 explain the basis in terms of business impact, likelihood of occurrence, or detectability.

Covered: testability and observable results, normal, exceptional, and boundary paths, role permissions, data rules, state transitions, dependencies and failure handling, non-functional constraints, and requirement ambiguities.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priority, evidence, an owner, or a next step.
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 theory.
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 something another engineer can directly execute and review.