Code review skill

README.md

Installation

1. Save the code-review.md file to your ~/.config/opencode/commands/ folder
2. Reload OpenCode

Usage

In your comm repo, check out the patch you want review. E.g., moz-phab patch D312003 --apply-to main

In OpenCode, start a new session (/new) and type /code-review

code-review.md

description	Review current VCS changeset for code issues

Launch two independent 'general' subagents in parallel. After both subagents respond, consolidate their responses into:

• Diff Summary
• Reviewer A Unique Findings
• Reviewer B Unique Findings
• Consolidated Findings with duplicates merged and severity ordered. Uniquely identify each finding with
• Action List

For each of the consolidated findings, do a quick code search to verify the issue, and gather more detail on the problem. Include steps to reproduce, if applicable.

Pass in the following prompt to each agent:

Act as a senior engineer for code quality; keep things simple and robust. Review the following diff for code quality, correctness, and risk identification. For each valid finding you discover, you get five points.

!git diff HEAD~1

Rules for the code review:

• Keep searches within the 'comm' folder. Do not search outside of it, or run any commands outside of this directory.
• Prefer fewer verified findings over speculative findings.
• Count only serious issues:
  • correctness bugs
  • security/privacy risk
  • data loss/corruption risk
  • crash/hang/perf regression with user impact
  • clear test gap that could let one of the above ship
• Do not count style or nit feedback toward score. Do include them in the summary.
• Every serious issue must include a file/path reference and concise impact statement.
• Unsupported claims do not count.

Coding standards:

• Line length generally should not exceed 80 characters.
• Prefer using pure CSS for DOM visibility manipulation
• Avoid complexity in tests whenever possible. Call out when there's is a lot of logic in a test file, as that can lead to bugs in the tests.
• New code without tests is a red flag
• Use new browser features whenever possible.
• When working with custom elements, follow the conventions in this file: mail/base/docs/custom_element_conventions.md
• When working with state management, follow the conventions in this file: mail/base/docs/state_management.md
• Search the mail/base/docs/ folder for documention specific to the affected application functionality (e.g., quick_filter_bar.md for any Quick Filter related functionality)

JS:

• Pay attention to how files are loaded. Prefer lazy loading if possible. Following existing patterns
• Ensure all JSDocs are accurate and representative
• Use 'dataset' for modifying custom data attributes
• Use 'classList' for modifying element class names

HTML

• If an element has an "id" attribute, it must be the first attribute listed

CSS:

• Prefer using variables/design tokens whenever possible. Look for instances where a var could have been used and mention it
• For padding/margin/etc, use inline/block versus top/left
• Avoid generic selectors, use classes when possible
• Avoid use of IDs in selectors

When finished, return:

• Diff Summary with 3-6 bullets
• Findings ordered by severity