mcpField
R
requesting-code-review

requesting-code-review

github.com/sickn33Testing & quality48.7k459 installsUpdated 1d ago
Repository

About requesting-code-review

requesting-code-review is a workflow skill for requesting authorized code review at key development milestones. It explains how to provide commit references and implementation context, then triage reviewer feedback; it does not grant delegation or permission to disclose code externally.

Key features

  1. 01Identify required review milestones
  2. 02Collect base and head commit SHAs
  3. 03Prepare reviewer context with a template
  4. 04Triage critical, important, and minor feedback
  5. 05Account for dirty and untracked changes

Use cases

  1. 01Review a feature before merging
  2. 02Request feedback after each development task
  3. 03Get a fresh perspective when stuck
  4. 04Check a baseline before refactoring

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill requesting-code-review

After installing, type/requesting-code-reviewin Claude Code to confirm it loaded.

Bundled filescode-reviewer.md

Details

From the project README

Requesting Code Review

Use an available authorized reviewer to catch issues before they cascade. The named superpowers agent/Task API is host-specific; this guide does not grant delegation or external-code disclosure permission.

Core principle: Review early, review often.

When to Request Review

Mandatory:

  • After each task in subagent-driven development
  • After completing major feature
  • Before merge to main

Optional but valuable:

  • When stuck (fresh perspective)
  • Before refactoring (baseline check)
  • After fixing complex bug

How to Request

1. Get git SHAs:

BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

2. Dispatch code-reviewer subagent:

Use Task tool with superpowers:code-reviewer type, fill template at code-reviewer.md

Placeholders:

  • {WHAT_WAS_IMPLEMENTED} - What you just built
  • {PLAN_OR_REQUIREMENTS} - What it should do
  • {BASE_SHA} - Starting commit
  • {HEAD_SHA} - Ending commit
  • {DESCRIPTION} - Brief summary

3. Act on feedback:

  • Fix Critical issues immediately
  • Fix Important issues before proceeding
  • Note Minor issues for later
  • Push back if reviewer is wrong (with reasoning)

Example

[Just completed Task 2: Add verification function]

You: Let me request code review before proceeding.

BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)

[Dispatch superpowers:code-reviewer subagent]
  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types

[Subagent returns]:
  Strengths: Clean architecture, real tests
  Issues:
    Important: Missing progress indicators
    Minor: Magic number (100) for reporting interval
  Assessment: Ready to proceed

You: [Fix progress indicators]
[Continue to Task 3]

Integration with Workflows

Subagent-Driven Development:

  • Review after EACH task
  • Catch issues before they compound
  • Fix before moving to next task

Executing Plans:

  • Review after each batch (3 tasks)
  • Get feedback, apply, continue

Ad-Hoc Development:

  • Review before merge
  • Review when stuck

Red Flags

Never:

  • Skip review because "it's simple"
  • Ignore Critical issues
  • Proceed with unfixed Important issues
  • Argue with valid technical feedback

If reviewer wrong:

  • Push back with technical reasoning
  • Show code/tests that prove it works
  • Request clarification

See bundled template at: code-reviewer.md. Use full resolved commit IDs and include dirty/untracked changes separately; HEAD-to-HEAD review does not cover them.

When to Use

This skill is applicable to execute the workflow or actions described in the overview.

Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Comments

Markdown supported