autoreview

name	autoreview
description	Hard acceptance gate: review all session changes for production quality before marking work complete. Use when the user invokes /review, asks for a session review, production-quality check, final acceptance review, or before considering a task done.
disable-model-invocation	true
version	2026-05-28.1

Skill: Autoreview Session Changes for Production Quality

Purpose

Before considering the task complete, review all changes made in this session and bring them up to production-quality, industry-standard implementation.

This skill is a hard acceptance gate. The work is not done until this review is complete and any discovered issues are fixed properly.

Instructions

Review every file, decision, and implementation change made during this session.

Do not leave behind tech debt, shortcuts, brittle logic, temporary fixes, TODOs, dead code, duplicated logic, unnecessary complexity, or bandaids.

If any shortcut was taken, replace it with the correct long-term implementation before finishing.

Review Checklist

1. Correctness

   • Verify the implementation fully satisfies the user request.
   • Check edge cases, error handling, empty states, invalid inputs, and failure paths.
   • Confirm there are no hidden regressions.

2. Code Quality

   • Remove duplicated, dead, unused, or overly clever code.
   • Simplify unnecessarily complex logic.
   • Use clear names, consistent patterns, and idiomatic structure.
   • Keep concerns separated and avoid mixing unrelated responsibilities.

3. Architecture

   • Ensure the solution fits the existing project architecture.
   • Avoid one-off hacks that bypass established patterns.
   • Refactor properly instead of patching around poor structure.
   • Do not introduce unnecessary dependencies or abstractions.

4. Maintainability

   • Remove temporary comments, TODOs, console logs, debug code, and stale branches.
   • Make the implementation easy for another engineer to understand and extend.
   • Ensure future changes will not require working around this solution.

5. Security and Reliability

   • Validate inputs where appropriate.
   • Avoid unsafe assumptions.
   • Ensure secrets, credentials, private data, and environment-specific values are not exposed.
   • Handle failures gracefully.

6. Testing and Verification

   • Add or update tests for meaningful behavior when appropriate.
   • Run the relevant test, lint, typecheck, build, or validation commands available in the project.
   • If a validation step cannot be run, clearly explain why.

7. Final Cleanup

   • Re-read the final diff.
   • Confirm the final state is clean, intentional, and production-ready.
   • Do not claim completion if known issues remain.

Acceptance Criteria

The task may only be marked complete when:

• All session changes have been reviewed.
• Any shortcuts have been replaced with proper implementations.
• No known tech debt or bandaids remain.
• Relevant validation has been run or explicitly accounted for.
• The final implementation is clean, maintainable, and aligned with industry standards.

Required Final Response

End with a concise review summary including:

• What was reviewed.
• What was improved or corrected during the review.
• What validation was run.
• Any remaining risks or limitations, if any.

If there are remaining risks, be direct and specific. Do not hide them.