TARE-Learn/deliverables/客户AI工程Skill交付包/skills/review-business-delivery/SKILL.md

name, description

name	description
review-business-delivery	Use when reviewing complex business delivery artifacts, AI-generated plans, PR diffs, or module designs for permission gaps, illegal state transitions, missing audit logs, weak exception handling, unclear dashboard metrics, missing tests, or incomplete acceptance evidence.

Review Business Delivery

Core Principle

Review behavior and risk before wording. Findings must be evidence-based, severity-ranked, and tied to a verification action.

The review output should help the team decide whether to accept, conditionally accept, or reject the delivery.

Inputs

Use any available inputs:

• Requirement scope and non-goals.
• RBAC matrix and permission control plan.
• State transition table and illegal transition list.
• Audit SOP and exception-state list.
• Dashboard metric dictionary and API acceptance record.
• Code diff, API contract, test result, Browser verification record, or PR description.
• Project rules and constraints.

If source evidence is missing, create an 证据缺口 section instead of guessing.

Review Flow

1. Confirm delivery scope: what is being reviewed and what is outside scope.
2. Check source evidence: paths, rules, design tables, test results, and verification records.
3. Review permission risk: page/menu, button, backend API, and data scope.
4. Review state risk: legal transitions, illegal transitions, terminal states, duplicate submits, and role restrictions.
5. Review audit risk: action coverage, field completeness, masking, failure behavior, and consistency with business writes.
6. Review exception risk: empty, missing, invalid, forbidden, duplicate, concurrent, and downstream failure states.
7. Review dashboard risk: formula, filter, dimension, data source, permission, empty state, and manual calculation.
8. Review tests and acceptance: commands, roles, sample data, browser evidence, and unresolved risks.
9. Output findings sorted by severity.

Severity

Level	Meaning
P0	Data loss, privilege bypass, irreversible wrong state, or release-blocking failure
P1	Security, permission, audit, or state-machine defect with realistic business impact
P2	Missing acceptance evidence, unclear metric, weak exception handling, or test gap
P3	Maintainability, naming, documentation, or minor consistency issue

Output Contract

## Review 结论

通过 / 有条件通过 / 不通过

## 问题清单

| 等级 | 模块 | 问题 | 证据 | 风险 | 修复建议 | 验收方式 |
| --- | --- | --- | --- | --- | --- | --- |

## 证据缺口

| 缺口 | 影响 | 需要谁补充 |
| --- | --- | --- |

## 待确认

| 问题 | 决策人 | 建议默认值 |
| --- | --- | --- |

Use the templates and checklists in assets/ when writing files.

Quality Gates

• Findings lead the response; summaries are secondary.
• Every P0/P1 finding cites a source path, table row, endpoint, role, state, metric, or verification record.
• Every finding has a concrete fix direction and acceptance method.
• Review does not accept frontend-only security controls.
• Missing tests or missing evidence are called out explicitly.
• Unclear business rules are marked 待确认, not invented.

Common Mistakes

• Do not write "整体不错" before listing risks.
• Do not merge all issues into one generic recommendation.
• Do not downgrade permission bypass, illegal state transitions, or missing audit for critical actions.
• Do not claim an issue is fixed without verification evidence.
• Do not review only code style when the requested delivery is business behavior.