penpot/.opencode/commands/review.md

Act as a senior software engineer and perform a thorough code review.

Instructions

1. Load the code-review-and-quality skill — it defines the five axes, core principles (DRY, KISS, YAGNI), severity taxonomy, and output format.
2. Determine the diff or code to review from the provided context.
3. Skip generated files, lockfile-only changes, and unrelated modifications unless they introduce security risks.
4. Read the diff and the surrounding context for each changed file.
5. Review across all five axes: correctness, readability, architecture, security, performance.
6. Produce the review using this structure:
   • Summary: One-paragraph overview of the change and its impact
   • Critical/High Findings: Blockers that must be fixed (with file:line, severity, description, and proposed fix)
   • Other Findings: Medium/Low issues and suggestions
   • Testing Recommendations: Missing test coverage or test quality issues
   • Positive Observations: What was done well (brief, specific)
   • Verdict: Approve / Request Changes / Needs Discussion
7. For each finding:
   • State the severity (Critical / High / Medium / Low / Suggestion)
   • Identify the file and line
   • Describe failure circumstances
   • For Critical/High: Provide a concrete fix with a code snippet showing the corrected code
   • For Medium/Low: Describe the fix clearly; code snippet optional
   • If multiple approaches exist, briefly note trade-offs
8. Perform a second review pass if the change is complex:
   • Complex indicators: Critical/High findings, multiple files (>5), architectural changes, security-sensitive code, >300 lines changed
   • Skip for simple changes: Typo fixes, formatting, small bug fixes (<50 lines), single-file changes with no findings
   • Second pass checks:
     • Validate severity assignments: Are Critical/High findings truly blockers?
     • Catch missed issues: Edge cases, error paths, test gaps overlooked in first pass
     • Remove false positives: Discard findings that aren't real issues
     • Verify fixes: Are the proposed solutions actually correct and complete?

Strong Rules

1. Do not invent problems. Every finding must be real and actionable.
2. Do not modify any code and do not create a commit — this command only reviews.
3. Be specific and constructive. "This could be better" is not helpful — explain why and how.
4. Prioritize by impact. One structural issue outweighs ten nits.
5. If tests are missing for new functionality, flag it as High severity.

Context

$ARGUMENTS

Expected Format

## Review Summary
[1-2 sentences on what the change does and overall assessment]

## Critical/High Findings
### [Severity] file.ts:123
**Issue**: [Description of the problem]
**Impact**: [What could go wrong]
**Fix**:
```[language]
// Current code
[problematic code]

// Fixed code
[corrected code]

[Optional: note trade-offs if multiple approaches exist]

Other Findings

[Severity] file.ts:456

Issue: [Description] Fix: [Clear description; code snippet optional]

Testing Recommendations

[List specific test cases that should be added]

Positive Observations

[2-3 specific things done well]

Verdict

[Approve / Request Changes / Needs Discussion] [If Request Changes: list the must-fix items]