Requesting code review

Skill yangshu2087/Codex/.agents/skills/requesting-code-review

Meta workspace for Codex configuration, shared skills, and maintenance scripts.

Install

npx -y skills add yangshu2087/Codex --skill requesting-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

SKILL.md

3.3 KB, 758 tokens by cl100k_base, as published. Nobody here has run it

Requesting Code Review

Use this skill to run a focused review before moving on, opening a PR, or declaring a change done. Prefer a review that is grounded in the actual git diff and requirements, not in vague recollection.

Core principle: Review early, review often.

When to Request Review

Mandatory:

After each major implementation batch
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 merge-base HEAD origin/main 2>/dev/null || git rev-parse HEAD~1)
HEAD_SHA=$(git rev-parse HEAD)

If origin/main is unavailable, replace it with the right base branch or explicit commit.

2. Gather review context:

git diff --stat "$BASE_SHA..$HEAD_SHA"
git diff "$BASE_SHA..$HEAD_SHA"

Also collect the requirement source you are reviewing against:

plan doc
ticket
acceptance criteria
user request in this thread

3. Run the review in Codex:

Default: ask for a review in the current Codex session and use the checklist in code-reviewer.md
If /review is available and the repo is ready, use it
Only use a separate reviewer agent when the user explicitly asks for delegation or subagents

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

4. 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 merge-base HEAD origin/main)
HEAD_SHA=$(git rev-parse HEAD)

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

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

Implementation Batches:

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
Review against memory alone instead of the actual diff

If reviewer wrong:

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

See checklist at: requesting-code-review/code-reviewer.md

Gives 2 of the 12 instructions most code review skills give in 758 tokens

Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06

push back with technical reasoning if wrongin 60 of 610, across 24 files
ask for clarification on unclear itemsin 51 of 610, across 16 files
fix critical issues immediatelyhere, and in 45 of 610, across 29 files
implement one item at a timein 45 of 610, across 11 files
group findings by severityin 44 of 610, across 43 files
verify feedback against the codebasein 42 of 610, across 8 files
dispatch a code reviewer subagentin 39 of 610, across 23 files
fix important issues before proceedinghere, and in 37 of 610, across 22 files
test each fix individuallyin 35 of 610, across 7 files
reply in github comment threadsin 33 of 610, across 5 files
check for security vulnerabilitiesin 31 of 610, across 27 files
factualize corrections without over-explainingin 30 of 610, across 2 files

Said here and by no other author read

gather git diff and review context
collect requirement sources for review

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.