AGENT SKILL

requesting-code-review

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

适用职业开发工程师
使用场景代码审查
License 许可
MIT
最近更新
2026-11-10
Stars
★ 0
Forks
0

01 前言 Front Matter

name
requesting-code-review
metadata
{ "owner": "tze", "status": "active", "authors": [ "obra/superpowers (upstream)", "Claude Fable 5.1" ], "last_reviewed": "2026-09-04" }
description
Use when completing tasks, implementing major features, or before merging to verify work meets requirements

02 资源文件 3

03 SKILL.md 正文

Requesting Code Review

Dispatch a reviewer subagent — a general-purpose agent given the bundled code-reviewer.md prompt — to catch issues before they cascade.

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:

Dispatch a general-purpose subagent (Agent tool) with the prompt template at code-reviewer.md, placeholders filled:

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 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

Task-by-task subagent 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

Template: code-reviewer.md

04 同仓库更多 Skills

tzeusy-org
tzeusy-org/ai-bootstrap

user-run

Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable /home/orca/.tmp/<slug>/run.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: "I'll run it for you", "permission denied on docker.sock", "needs sudo", "sudo: a password is required", "run as tze", "/user-run".

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

receiving-code-review

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

开发工程师代码审查
★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

finishing-a-development-branch

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

executing-plans

Use when you have a written implementation plan to execute in a separate session with review checkpoints

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

dispatching-parallel-agents

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

brainstorming

Use before creative work — creating features, building components, adding functionality, or modifying behavior — to explore user intent, requirements, and design before implementation. One question at a time; 2–3 approaches; design validated in sections.

视觉设计
★ 0