Zen review

Determine whether the change satisfies its brief and what must be fixed or demonstrated. Review the implementation itself, not only its author's report.

1. Pin the task/spec and actual base/head plus dirty changes. Inspect new/untracked files as well as tracked diffs. Confirm the selected artifact and accepted scope changes. If the base cannot be established, say which comparison is unavailable.
2. Trace changed paths through callers, types, state, IO and failure boundaries. Compare each criterion with actual behavior. Focus on defects that can be triggered: authorization, lost/duplicate data, stale updates, cancellation/recovery, compatibility and incorrect user outcomes. Explain tradeoffs without inventing speculative blockers.
3. Check evidence quality. Distinguish inspected source, tests you ran, implementer self-reports, simulated-provider fixtures and real end-to-end observations. Read relevant run events when available; do not call a missing check Passed.
4. Reproduce important findings with a bounded check where feasible. Do not mutate production, rerun a paid provider or change credential state merely to review. If visual, inspect the rendered states and reference at desktop/mobile sizes; source CSS is insufficient.
5. Write actionable findings with severity/impact, trigger, source location, observed/expected behavior and a focused remedy. Avoid duplicating the same root cause or presenting style preference as a defect unless it violates the brief/system.
6. Maintain an acceptance/evidence matrix. Record documentation that is stale and any proposed correction. A branch milestone remains pending until merge ancestry is verified; deployment is a different claim.
7. Persist a linked DOC/LOG review report via the current tools, using the review format. Return fix work to a task/follow-up through the authorized owner path. The current MCP cannot resume a provider session.

Outcome

State findings first, then criterion coverage, actual validation and remaining uncertainty. If no actionable findings exist, say so along with the limits of the review; do not imply unrun integrations passed. Leave successful work in Review for the owner. Neither a reviewer role nor a passing report authorizes commit, push, merge, deployment or Done.

Without connected records, the same review can be returned as a labelled draft or captured through the initialized standalone writer. Keep the actual diff and evidence references usable by the next implementer.

Skill settings

The owner's settings for this skill arrive in a "Skill settings" block. Honour them.

• strictness (light, standard or strict; default standard):
  • Light: report only serious problems, meaning bugs, security issues, data loss and broken acceptance criteria.
  • Standard: also report clear improvements that a reviewer would expect to be fixed.
  • Strict: also report style, naming and maintainability points, each marked as optional.

Whatever the strictness, every finding still needs its file, its line, a concrete failure scenario and, for the most serious findings, proof. Zero findings is a valid result when the change is sound.