Autoreview
Skill robzilla1738/roberts-skills/plugins/autoreview/skills/autoreview
Provider-agnostic agent skills and plugins for AI coding assistants. By Robert Courson.
npx -y skills add robzilla1738/roberts-skills --skill autoreviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.4 KB, as published. Nobody here has run it
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.