Selvage Code Review Skill

Argument Parsing

Parse $ARGUMENTS to determine the diff scope:

If $ARGUMENTS does not match any pattern above, default to unstaged diff_scope.

Workflow

Step 1: Get Review Context

Call mcp__selvage__get_review_context with the parsed parameters.

Inspect the response and branch on the result:

Case A - Inline context (no context_id in response):

• •The review_targets field contains all file contexts inline.
• •Proceed directly to Step 2 with the full context.

Case B - Split context (context_id is present in response):

• •The context was too large to return inline.
• •The response includes context_id and file_list (list of file paths).
• •For each file in file_list, call mcp__selvage__get_file_review_context with the context_id and file_path.
• •Call these in parallel where possible to minimize latency.
• •Collect all returned review_target results, then proceed to Step 2.

Step 2: Perform Review

Using the system_prompt from Step 1 as your review guidelines:

1. •Follow the system_prompt instructions exactly - it contains the review criteria and context interpretation rules.
2. •Review each file in the collected review targets:
   • •Analyze hunks (changed code sections) for bugs, security issues, performance problems, and design concerns.
   • •Pay attention to context_type in each target:
     • •SMART_CONTEXT: AST-analyzed related code blocks - use these to understand the broader code structure around changes.
     • •FALLBACK_CONTEXT: Text-based pattern matches - still useful but less precise than AST analysis.
     • •FULL_CONTEXT: Complete file content - typically for new or heavily rewritten files.
3. •Verification Principle: When you identify a potential issue but are not certain, verify it before reporting:
   • •Use Read to examine the actual source file for additional context.
   • •Use Grep to search for related patterns, usages, or definitions across the codebase.
   • •Use Glob to find related files if needed.
   • •Only report issues you are confident about after verification.

Step 3: Report Results

Present the review as free-form text (not JSON). Structure your response as:

1. •Summary: Brief overview of the changes and overall quality assessment (2-3 sentences).
2. •Issues Found: List each issue with:
   • •Severity indicator: [error], [warning], or [info]
   • •Category: bug, security, performance, style, or design
   • •File and location reference
   • •Clear description of the problem
   • •Concrete suggestion for how to fix it
   • •Code snippet if helpful
3. •Score: Overall code quality score from 0-10.
4. •Recommendations: Actionable next steps for the developer.

If no issues are found, state that the changes look good and provide a brief positive summary.