Skip to main content

code-review

Code review best practices and guidelines

Source facts

Repository
ffsshhttiikk/opencode-agents-skills
Last source activity
February 28, 2026 at 22:48
Detected SKILL.md language
English
Stars
3
Forks
2

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
code-review
description
Code review best practices and guidelines
license
MIT
compatibility
opencode
metadata
{"audience":"developers","category":"code-quality"}
## What I do - Review code for quality, correctness, and maintainability - Provide constructive and actionable feedback - Check for security vulnerabilities - Ensure tests are adequate - Verify code follows project conventions - Suggest improvements without being prescriptive - Balance thoroughness with velocity - Learn from others' code ## When to use me When performing code reviews or addressing feedback. ## What to Look For ### Correctness - Does the code do what it's supposed to? - Are edge cases handled? - Are error conditions properly handled? - Is the logic sound and bug-free? ### Security - Input validation and sanitization - Authentication and authorization - Sensitive data handling - SQL injection, XSS, CSRF protection ### Performance - Unnecessary database queries (N+1 problem) - Inefficient algorithms or data structures - Missing indexes or caching - Memory leaks ### Maintainability - Readable and understandable code - Proper naming conventions - Code duplication - Dead code - Comments where needed ### Testing - Adequate test coverage - Meaningful test cases - Edge cases and error scenarios ## Feedback Guidelines ### DO - Be specific about what needs to change - Explain why something should be changed - Offer alternative solutions - Acknowledge good code - Focus on the code, not the person - Distinguish between must-haves and suggestions ### DON'T - Be rude or dismissive - Nitpick style preferences - Make personal comments - Block PRs for minor issues - Demand changes without explaining why - Be overly critical without suggestions ## Example Review Comments ### Critical Finding ```markdown **High: SQL Injection Vulnerability** The user input is directly concatenated into the SQL query: ```python query = f"SELECT * FROM users WHERE email = '{email}'" ``` **Risk**: An attacker could inject malicious SQL to extract or modify database data. **Fix**: Use parameterized queries: ```python cursor.execute("SELECT * FROM users WHERE email = ?", (email,)) ``` Required change - this is a security issue that must be fixed before merge. ``` ### Improvement Suggestion ```markdown **Medium: Consider using a context manager** The current code manually manages the database connection: ```python connection = get_db_connection() try: process_data(connection) finally: connection.close() ``` **Suggestion**: Using a context manager ensures proper cleanup even on exceptions: ```python with get_db_connection() as connection: process_data(connection) ``` This is more Pythonic and handles edge cases automatically. Not blocking, but recommended. ``` ### Style/Convention ```markdown **Low: Line length** This line exceeds our 100 character limit: ```python some_function(argument_one, argument_two, argument_three=some_value, argument_four=other_value) ``` **Fix**: Break onto multiple lines: ```python some_function( argument_one, argument_two, argument_three=some_value, argument_four=other_value, ) ``` We use Black formatter - running `black .` will auto-fix this. ``` ### Positive Reinforcement ```markdown **Great work!** The error handling here is excellent. Using a custom exception hierarchy makes the code very clear about what can go wrong and where. Thanks for the thorough docstrings too! ``` ## Review Checklist ``` [] Code compiles/runs without errors [] Tests pass (unit, integration, e2e) [] No security vulnerabilities [] Performance is acceptable [] Follows naming conventions [] Adequate error handling [] Input validation present [] No hardcoded secrets [] No debug code left in [] Documentation updated [] Comments are helpful [] No dead code [] No code duplication [] Logging is appropriate [] Metrics/monitoring if needed ``` ## Responding to Reviews ### When You Disagree 1. Understand the reviewer's perspective 2. Explain your reasoning 3. Provide evidence or examples 4. Seek common ground 5. Escalate if necessary (don't flame wars) ### When Making Changes 1. Address all feedback 2. Explain what you changed 3. Request re-review 4. Thank the reviewer ### Quick Wins - Fix typos and formatting - Rename variables for clarity - Add missing tests - Remove debug code - Add comments
View on GitHub