code-review
starsforks
How to install code-review?
omnigentx/jarvis/code-review
$npx -y skills add omnigentx/jarvis --skill code-reviewProtocol for reviewing code and providing structured verdicts
SKILL.md
| 1 | # Code Review Skill |
| 2 | |
| 3 | You are performing a code review. Follow this protocol for consistent, actionable feedback. |
| 4 | |
| 5 | ## Review Process |
| 6 | |
| 7 | ### Step 1: Understand the Context |
| 8 | - Read the project brief and any related documentation in the workspace |
| 9 | - Understand what the author was trying to accomplish |
| 10 | - Check `team_roster.json` to know who wrote what |
| 11 | |
| 12 | ### Step 2: Review the Code |
| 13 | - Read all relevant files in the workspace |
| 14 | - Check for: |
| 15 | - **Correctness** — Does the code do what it's supposed to? |
| 16 | - **Quality** — Is it readable, maintainable, well-structured? |
| 17 | - **Edge cases** — Are there unhandled scenarios? |
| 18 | - **Security** — Any obvious security issues? |
| 19 | - **Performance** — Any obvious performance problems? |
| 20 | |
| 21 | ### Step 3: Write Your Review |
| 22 | Write your review to: `reviews/<step_name>_review.md` |
| 23 | |
| 24 | Include: |
| 25 | 1. **Summary** — Overall assessment |
| 26 | 2. **Issues found** — Specific problems with file/line references |
| 27 | 3. **Suggestions** — Improvements that aren't blockers |
| 28 | 4. **Verdict** — Your final decision |
| 29 | |
| 30 | ### Step 4: Declare Verdict |
| 31 | |
| 32 | **Always end your review with one of these exact strings:** |
| 33 | |
| 34 | ✅ When code is acceptable: |
| 35 | ``` |
| 36 | [DECISION] VERDICT: PASS — <brief reason> |
| 37 | ``` |
| 38 | |
| 39 | ❌ When code needs fixes: |
| 40 | ``` |
| 41 | [DECISION] VERDICT: FAIL — <brief reason with key issues> |
| 42 | ``` |
| 43 | |
| 44 | ## Communication |
| 45 | |
| 46 | After writing your review: |
| 47 | - Use `send_email(to="<author_name>", body="...", my_name="<your_name>")` to notify the author |
| 48 | - Include a summary of key issues if FAIL |
| 49 | - Be constructive — suggest fixes, don't just point out problems |
| 50 | |
| 51 | ## As a Code Author (receiving review) |
| 52 | |
| 53 | When you receive a FAIL verdict: |
| 54 | 1. Read the review feedback carefully |
| 55 | 2. Fix the identified issues in your workspace files |
| 56 | 3. Message the reviewer: `send_email(to="<reviewer_name>", body="Fixes applied, ready for re-review", my_name="<your_name>")` |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
