Code Review Skill
This skill defines how to perform structured, objective code reviews.
When to Use
Use this skill when:
- Asked to review a pull request, merge request, or branch.
- Evaluating changed, added, or deleted files for correctness and quality.
Review Process
1. Branch and Merge Target
- Confirm the current branch is a feature, bugfix, or PR/MR branch — not the project's primary branch (e.g.
main, master, develop, or equivalent).
- Verify the branch is up-to-date with the target branch.
- Identify the target branch for the merge.
2. Change Discovery
- List all changed, added, and deleted files.
- For each change, look up the commit title and review how connected components are implemented.
- Never assume a change or fix is correct without investigating the implementation details.
- If a change remains difficult to understand after several attempts, note this explicitly in your report.
3. Per-File Review
For every changed file, check:
| Area |
What to verify |
| Location |
File is in the correct directory |
| Naming |
File name follows naming conventions |
| Responsibility |
The file's responsibility is clear; reason for its change is understandable |
| Readability |
Variable, function, and class names are descriptive and consistent |
| Logic & correctness |
No logic errors or missing edge cases |
| Maintainability |
Code is modular; no unnecessary duplication |
| Error handling |
Errors and exceptions are handled appropriately |
| Security |
No input validation issues; no secrets committed to code |
| Performance |
No obvious performance issues or inefficiencies |
| Documentation |
Public APIs, complex logic, and new modules are documented |
| Test coverage |
New or changed logic has sufficient tests |
| Style |
Code matches the project's style guide and coding patterns |
For generated files: confirm they are up-to-date and not manually modified.
4. Overall Change Set
- Verify the change set is focused and scoped to its stated purpose — no unrelated or unnecessary changes.
- Check that the PR/MR description accurately reflects the changes made.
- Confirm new or updated tests cover new or changed logic.
- Evaluate whether tests could actually fail, or only verify a mock implementation.
5. CI and Tests
- Ensure all tests pass in the continuous integration system.
- Fetch online documentation when unsure about best practices for a particular package or library.
Feedback Standards
- Be objective and reasonable — avoid automatic praise or flattery.
- Take a devil's advocate approach: give honest, thoughtful feedback.
- Provide clear, constructive feedback for any issues found, with suggestions for improvement.
- Include requests for clarification for anything that is unclear.
Output Format
Provide your review as a chat response, covering conclusions and recommendations per file, including:
- Summary of what changed and why
- Issues found (with severity: suggestion / minor / major)
- Specific recommendations or questions per file
- Overall verdict: approved, approved with suggestions, or changes requested
1---2name: code-review-23description: Performs thorough code reviews for Flutter/Dart pull requests and merge requests. Use when asked to review a PR, MR, branch, or a set of changed files. Follows a structured checklist covering correctness, security, style, testing, and documentation.4---56# Code Review Skill78This skill defines how to perform structured, objective code reviews.910## When to Use1112Use this skill when:1314* Asked to review a pull request, merge request, or branch.15* Evaluating changed, added, or deleted files for correctness and quality.1617---1819## Review Process2021### 1. Branch and Merge Target2223- Confirm the current branch is a **feature, bugfix, or PR/MR branch** — not the project's primary branch (e.g. `main`, `master`, `develop`, or equivalent).24- Verify the branch is **up-to-date** with the target branch.25- Identify the **target branch** for the merge.2627### 2. Change Discovery2829- List all **changed, added, and deleted files**.30- For each change, look up the **commit title** and review how connected components are implemented.31- **Never assume** a change or fix is correct without investigating the implementation details.32- If a change remains difficult to understand after several attempts, **note this explicitly** in your report.3334### 3. Per-File Review3536For every changed file, check:3738| Area | What to verify |39|---|---|40| **Location** | File is in the correct directory |41| **Naming** | File name follows naming conventions |42| **Responsibility** | The file's responsibility is clear; reason for its change is understandable |43| **Readability** | Variable, function, and class names are descriptive and consistent |44| **Logic & correctness** | No logic errors or missing edge cases |45| **Maintainability** | Code is modular; no unnecessary duplication |46| **Error handling** | Errors and exceptions are handled appropriately |47| **Security** | No input validation issues; no secrets committed to code |48| **Performance** | No obvious performance issues or inefficiencies |49| **Documentation** | Public APIs, complex logic, and new modules are documented |50| **Test coverage** | New or changed logic has sufficient tests |51| **Style** | Code matches the project's style guide and coding patterns |5253For **generated files**: confirm they are up-to-date and not manually modified.5455### 4. Overall Change Set5657- Verify the change set is **focused and scoped** to its stated purpose — no unrelated or unnecessary changes.58- Check that the **PR/MR description** accurately reflects the changes made.59- Confirm **new or updated tests** cover new or changed logic.60- Evaluate whether tests could **actually fail**, or only verify a mock implementation.6162### 5. CI and Tests6364- Ensure **all tests pass** in the continuous integration system.65- Fetch **online documentation** when unsure about best practices for a particular package or library.6667---6869## Feedback Standards7071- Be **objective and reasonable** — avoid automatic praise or flattery.72- Take a **devil's advocate approach**: give honest, thoughtful feedback.73- Provide **clear, constructive feedback** for any issues found, with suggestions for improvement.74- Include **requests for clarification** for anything that is unclear.7576---7778## Output Format7980Provide your review as a **chat response**, covering conclusions and recommendations **per file**, including:81821. Summary of what changed and why832. Issues found (with severity: suggestion / minor / major)843. Specific recommendations or questions per file854. Overall verdict: approved, approved with suggestions, or changes requested
involvex