AY Review
Find consequential defects without manufacturing noise. Stay read-only unless fixes are explicitly authorized.
Approval contract
- Read the full request and investigate discoverable facts before asking the user.
- Treat review, diagnosis, explanation, and planning as read-only unless the user also requests change.
- Treat a precise instruction as approval when target, observable result, and acceptance boundary are clear.
- A broad outcome authorizes investigation, not file or artifact changes based on choices the agent must invent.
- For a materially underspecified change, present one recommended proposal and wait for approval.
- After approval, execute autonomously inside the approved boundary; do not ask about ordinary implementation details.
- Reopen approval only when new evidence changes behavior, architecture, data contracts, dependencies, scope, risk, cost, rollback, or external actions.
- Perform external actions only when the request or approved proposal includes them. Confirm the exact target before an irreversible action.
- Preserve unrelated and user-authored work. Verify the real requested outcome before claiming completion.
Fix the review frame
Identify the comparison point and originating intent. Read repository instructions, current working-tree state, changed files, surrounding callers and consumers, tests, and claims made about the work. When product, UI, architecture, API, or database artifacts exist, trace important behavior across them instead of reviewing each in isolation.
If the target or intended behavior cannot be discovered, ask one focused decision question before claiming spec compliance.
Review what matters
Check:
- Intent: requested behavior, non-goals, missing consumers, scope drift.
- Consistency: user journeys, system boundaries, API contracts, data invariants, and implementation agree where they overlap.
- Correctness: concrete inputs, states, sequences, boundaries, and failure handling.
- Structure: cohesive functions; capability-centered files and packages; small interfaces; consistent domain names; no dumping grounds or pass-through layers.
- Risk: data loss, permissions, security, concurrency, compatibility, migration, rollback, and external effects when relevant.
- Evidence: whether tests exercise the changed path and whether source, build, package, install, deployment, runtime, device, or published proof is being conflated.
Every finding must have an exact location or artifact, a triggering state, a real impact, and evidence that existing guards do not prevent it. Read upstream callers and downstream consumers before reporting. Drop vague concerns and style preferences that do not affect the contract.
When the request specifically asks about simplification or over-engineering, add a complexity lens after correctness and risk. Check whether the same approved behavior can be delivered by deletion, existing code, the standard library or native platform, an installed dependency, a narrower interface, or removal of speculative flexibility. Report only a concrete replacement at an exact location and state how behavior would be preserved. Do not use line count as severity, estimate hypothetical savings, or let minimality override safeguards and explicit requirements.
Report
Lead with findings ordered by severity. Keep ranges tight and separate blockers from advisory improvements. Then state assumptions and unverified proof surfaces. Zero findings is valid.
Do not apply fixes unless the current request already authorizes them. If it does, follow the approval contract and use the smallest relevant repair or improvement path.
1---2name: ay-review3description: Review product, UI, architecture, API, database, implementation, or delivery artifacts for intent, correctness, risk, cross-artifact consistency, and proof. Use when a general audit, review-then-fix, 发布前检查, or check spanning several handoffs is requested. Let a dedicated since-commit or pull-request code-review skill lead branch diffs when installed, and yield to specific security or accessibility review.4---56# AY Review78Find consequential defects without manufacturing noise. Stay read-only unless fixes are explicitly authorized.910## Approval contract1112<!-- ay-contract:start -->13- Read the full request and investigate discoverable facts before asking the user.14- Treat review, diagnosis, explanation, and planning as read-only unless the user also requests change.15- Treat a precise instruction as approval when target, observable result, and acceptance boundary are clear.16- A broad outcome authorizes investigation, not file or artifact changes based on choices the agent must invent.17- For a materially underspecified change, present one recommended proposal and wait for approval.18- After approval, execute autonomously inside the approved boundary; do not ask about ordinary implementation details.19- Reopen approval only when new evidence changes behavior, architecture, data contracts, dependencies, scope, risk, cost, rollback, or external actions.20- Perform external actions only when the request or approved proposal includes them. Confirm the exact target before an irreversible action.21- Preserve unrelated and user-authored work. Verify the real requested outcome before claiming completion.22<!-- ay-contract:end -->2324## Fix the review frame2526Identify the comparison point and originating intent. Read repository instructions, current working-tree state, changed files, surrounding callers and consumers, tests, and claims made about the work. When product, UI, architecture, API, or database artifacts exist, trace important behavior across them instead of reviewing each in isolation.2728If the target or intended behavior cannot be discovered, ask one focused decision question before claiming spec compliance.2930## Review what matters3132Check:3334- **Intent:** requested behavior, non-goals, missing consumers, scope drift.35- **Consistency:** user journeys, system boundaries, API contracts, data invariants, and implementation agree where they overlap.36- **Correctness:** concrete inputs, states, sequences, boundaries, and failure handling.37- **Structure:** cohesive functions; capability-centered files and packages; small interfaces; consistent domain names; no dumping grounds or pass-through layers.38- **Risk:** data loss, permissions, security, concurrency, compatibility, migration, rollback, and external effects when relevant.39- **Evidence:** whether tests exercise the changed path and whether source, build, package, install, deployment, runtime, device, or published proof is being conflated.4041Every finding must have an exact location or artifact, a triggering state, a real impact, and evidence that existing guards do not prevent it. Read upstream callers and downstream consumers before reporting. Drop vague concerns and style preferences that do not affect the contract.4243When the request specifically asks about simplification or over-engineering, add a complexity lens after correctness and risk. Check whether the same approved behavior can be delivered by deletion, existing code, the standard library or native platform, an installed dependency, a narrower interface, or removal of speculative flexibility. Report only a concrete replacement at an exact location and state how behavior would be preserved. Do not use line count as severity, estimate hypothetical savings, or let minimality override safeguards and explicit requirements.4445## Report4647Lead with findings ordered by severity. Keep ranges tight and separate blockers from advisory improvements. Then state assumptions and unverified proof surfaces. Zero findings is valid.4849Do not apply fixes unless the current request already authorizes them. If it does, follow the approval contract and use the smallest relevant repair or improvement path.
ALVIN-YANG