code-review
Code Review
Request or perform code review before issues compound.
Operating Mode
Act as a pragmatic review coordinator first, and a reviewer second.
Prioritize:
- clear review scope before opinions
- requirement alignment before style nits
- bugs and regressions before polish
- explicit evidence before confidence
Review early and review often.
Workflow
Follow this sequence unless the user asks for only one part of the review flow.
1. Define the review scope
Choose the smallest meaningful diff to review.
Prefer:
- branch review:
git merge-base origin/main HEADtoHEAD - task review: previous task commit to
HEAD - single-commit review:
HEAD~1toHEAD
Use commands such as:
git merge-base origin/main HEAD
git rev-parse HEAD
git log --oneline --decorate -n 10
If the change set is too large or mixes unrelated work, call that out and split the review scope before continuing.
2. Gather review context
Capture the minimum context a reviewer needs:
- what was implemented
- plan, requirements, or acceptance criteria
- known risks or edge cases
- tests added, updated, or still missing
- exact
BASE_SHAandHEAD_SHA
Do not rely on session history. Summarize the relevant context explicitly.
3. Choose the review path
If a dedicated review subagent or local review skill is available, dispatch it with the prepared scope and context.
If no dedicated reviewer is available, perform the review directly in the current session using the same scope and context.
When delegating, pass only the material needed for review:
- implementation summary
- requirements or plan reference
BASE_SHAHEAD_SHA- brief description of the change
4. Review the change set
Inspect the diff against the stated requirements.
Focus on:
- correctness bugs
- missing requirements
- behavioral regressions
- unsafe migrations or rollout risks
- missing or weak tests
- security, reliability, and performance issues when relevant
Prefer review commands such as:
git diff <base>..<head>
git log <base>..<head> --stat
For the detailed reviewer checklist and findings template, read references/reviewer-guide.md.
5. Return findings in severity order
Report findings first.
Use this structure:
# Review Findings
## Critical
- <issue with file/line and impact>
## Important
- <issue with file/line and impact>
## Minor
- <issue with file/line and impact>
## Open Questions
- <missing context or assumption>
## Assessment
- Ready to proceed / Fix important issues first / Blocked
Keep findings concrete. Include file and line references when available. If there are no findings, state that explicitly and note any residual risk or test gap.
6. Act on the review
- Fix Critical issues immediately.
- Fix Important issues before proceeding or merging.
- Track Minor issues deliberately instead of losing them.
- Push back on incorrect review comments with technical reasoning and evidence.
Do not wave through known Important issues just because the change is small.
Review Brief Template
Use this when preparing a review request:
# Review Request
## What Was Implemented
<what changed>
## Requirements
<plan, ticket, acceptance criteria, or intended behavior>
## Scope
- BASE_SHA: <sha>
- HEAD_SHA: <sha>
## Notes for Reviewer
- risks, edge cases, or areas needing extra scrutiny
Decision Rules
- Prefer reviewing a precise diff over reviewing an entire branch by default.
- Prefer merge-base for branch reviews and
HEAD~1only for truly single-commit reviews. - Escalate when scope is ambiguous, requirements are missing, or the diff contains unrelated changes.
- Treat missing tests as a real finding when behavior changed.
- Keep reviewer context concise and independent from hidden chain-of-thought or session history.
Red Flags
Stop and reassess if:
- the review scope is unclear
- the diff includes unrelated changes
- the requirements are too vague to judge correctness
- the review request lacks
BASE_SHAorHEAD_SHA - critical feedback is being ignored without evidence
More from flc1125/skills
subagent-orchestrator
Orchestrate subagent workflows for complex tasks that benefit from decomposition, role-based delegation, and parallel execution. Use when Codex should assemble a temporary team of subagents, choose roles from a reusable role library, create a controlled fallback role when no preset role fits, coordinate read-heavy work in parallel, or handle write-heavy work with ownership boundaries, staged execution, and an integrator-led merge path.
31experts
Assemble a panel of experts to assess a problem from multiple professional perspectives, surface agreement and disagreement, and deliver a chaired recommendation with clear tradeoffs. Use when the user wants multi-expert judgment, a second opinion, design critique, option comparison, or a recommendation backed by distinct expert viewpoints.
23github-create-pr
Create GitHub pull requests from a local branch using a reviewable workflow for branch checks, diff analysis, PR title/body writing, and gh CLI creation. Use when opening a PR, drafting or improving a PR description, preparing a branch for review, or adding reviewers on GitHub.
13async
Launch and coordinate Codex subagents as deferred tasks. Use when the user wants to start bounded subagent work now, keep the main thread moving without waiting by default, then later join, collect, or redirect that work through a stable task reference.
12study
Guide structured learning for a topic by diagnosing current level, defining stage goals, building a learning path, generating practice, and running review loops. Use when the user wants to learn something step by step, start from zero, build a study plan, prepare for an exam or skill, get guided practice, or continue a topic through staged coaching rather than a one-off answer.
12gitlab-create-mr
Create GitLab merge requests from a local branch using a reviewable workflow for branch checks, GitLab host detection, diff analysis, title and description writing, and `glab mr create`. Use when opening a GitLab merge request, drafting or improving merge request copy, preparing a branch for review, or working across GitLab.com and self-managed GitLab instances.
11