code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Code Review Skill

Conduct a thorough, read-only code review for quality, security, and
maintainability with severity-rated feedback.

## When to Use

This skill activates when:
- User requests "review this code", "code review"
- Before merging a pull request
- After implementing a major feature
- User wants quality assessment

Plain `/omagy:code-review` is read-only. It does not edit files, run automatic
fixes, persist workflow gate state, or promise follow-up implementation. If the
user explicitly asks to review and fix, run this review first and then route the
findings into `/omagy:ralph` or `/omagy:ultrawork`.

## GPT-5.5 Guidance Alignment

- Default to outcome-first progress and completion reporting: state the target
  result, evidence, validation status, and stop condition before adding process
  detail.
- Treat newer user task updates as local overrides for the active workflow
  branch while preserving earlier non-conflicting constraints.
- If correctness depends on additional inspection, retrieval, execution, or
  verification, keep using the relevant tools until the review is grounded; stop
  once enough evidence exists.
- Continue through clear, low-risk, reversible next steps automatically; ask
  only when the next step is materially branching, destructive, credentialed,
  external-production, or preference-dependent.

Delegates to the `code-reviewer` and `architect` agents in parallel for a
two-lane review. When the scoped files or task are security-sensitive, add a
conditional `security-reviewer` lane instead of using a standalone
`/omagy:security-review` command.

1. **Identify Changes**
   - Run `git diff` to find changed files when the current scope is a git
     repository.
   - Determine scope of review: specific files, current project directory,
     explicit path, branch, PR, or entire change set.
   - If `git diff` is unavailable but the current directory is clearly the
     project under review, use the current project directory as the scope.
   - Do not scan sibling repositories to pick a target implicitly.
   - Stay inside the current review scope. Do not inspect Antigravity brain,
     transcript, conversation, or generated log directories unless the user
     explicitly includes them in the review scope.
   - If there is no changed-file or PR scope and the review falls back to the
     current project directory, treat the result as a broad project audit, not a
     merge gate for a specific change. In audit mode, report dormant, internal,
     or future-workflow risks as WATCH unless they break a current entrypoint or
     create a concrete security, data-loss, or production incident risk.

2. **Launch Parallel Review Lanes**
   - **`code-reviewer` lane** - owns spec compliance, security, code quality,
     performance, and maintainability findings
   - **`architect` lane** - owns the devil's-advocate / design-tradeoff
     perspective
   - **`security-reviewer` lane** - conditional lane for auth, secrets,
     permissions, injection, sandbox, plugin, MCP, subprocess, dependency,
     supply-chain, PII, or compliance risk
   - Both lanes run in parallel and produce distinct outputs before final
     synthesis

3. **Review Categories**
   - **Security** - Hardcoded secrets, injection risks, XSS, CSRF
   - **Code Quality** - Function size, complexity, nesting depth
   - **Performance** - Algorithm efficiency, N+1 queries, caching
   - **Best Practices** - Naming, documentation, error handling
   - **Maintainability** - Duplication, coupling, testability

4. **Severity Rating**
   - **CRITICAL** - Security vulnerability (must fix before merge)
   - **HIGH** - Bug or major code smell (should fix before merge)
   - **MEDIUM** - Minor issue (fix when possible)
   - **LOW** - Style/suggestion (consider fixing)

5. **Architectural Status Contract**
   - **CLEAR** - No unresolved architectural blocker was found
   - **WATCH** - Non-blocking design/tradeoff concern that must appear in the
     final synthesis
   - **BLOCK** - Unresolved design concern that prevents a merge-ready verdict

6. **Specific Recommendations**
   - File:line locations for each issue
   - Concrete fix suggestions
   - Code examples where applicable

7. **Final Synthesis**
   - Combine the `code-reviewer` recommendation and the architect status into
     one final verdict
   - Deterministic merge gating rules:
     - If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**
     - If security status is **BLOCK**, final recommendation is **REQUEST CHANGES**
     - Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final
       recommendation is **REQUEST CHANGES**
     - Else if security status is **WATCH**, final recommendation is **COMMENT**
     - Else if architect status is **WATCH**, final recommendation is **COMMENT**
     - Else final recommendation follows the `code-reviewer` lane
   - The final report must make architect blockers impossible to miss
   - The final report must make security blockers impossible to miss

## Agent Delegation

Use agy's native subagent capability directly. The intended call shape is:

```json
{
  "Subagents": [
    {
      "TypeName": "code-reviewer",
      "Role": "code-reviewer",
      "Prompt": "CODE REVIEW TASK\n\nReview code changes for quality, security, and maintainability.\n\nThis is the code/spec/security lane. Do not absorb architectural ownership.\n\nScope: [git diff, current project directory, PR, or specific files]\n\nStay inside the scope. Do not inspect Antigravity brain, transcript, conversation, or generated log directories unless explicitly included.\n\nReview Checklist:\n- Security vulnerabilities (OWASP Top 10)\n- Code quality (complexity, duplication)\n- Performance issues (N+1, inefficient algorithms)\n- Best practices (naming, documentation, error handling)\n- Maintainability (coupling, testability)\n\nOutput: Code review report with:\n- Files reviewed count\n- Issues by severity (CRITICAL, HIGH, MEDIUM, LOW)\n- Specific file:line locations\n- Fix recommendations\n- Approval recommendation (APPROVE / REQUEST CHANGES / COMMENT)"
    },
    {
      "TypeName": "architect",
      "Role": "architect",
      "Prompt": "ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK\n\nReview the same code changes from the architecture/tradeoff perspective.\n\nScope: [same scope as code-reviewer]\n\nStay inside the scope. Do not inspect Antigravity brain, transcript, conversation, or generated log directories unless explicitly included.\n\nFocus:\n- System boundaries and interfaces\n- Hidden coupling or long-term maintainability risks\n- Tradeoff tension the main reviewer might miss\n- Strongest counterargument against approving as-is\n\nBLOCK only when the scoped change or current audited entrypoint is not merge-ready because of a concrete unresolved design risk. In broad project audit mode, dormant/internal/future-workflow risks are WATCH unless they break a current entrypoint or create concrete security, data-loss, or production incident risk.\n\nOutput:\n- Architectural Status: CLEAR / WATCH / BLOCK\n- File:line evidence for each concern\n- Concrete tradeoff or design recommendation"

From shayne-snap/oh-my-antigravity, MIT.

More from shayne-snap/oh-my-antigravity