mirror of
https://github.com/penpot/penpot.git
synced 2026-09-24 12:56:15 +00:00
80 lines
3.3 KiB
Markdown
80 lines
3.3 KiB
Markdown
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]
|
|
```
|