Source profileQuality 98/100

event4u-app/agent-config/src/skills/requesting-code-review/SKILL.md

requesting-code-review

Use when asking for a review or creating a PR — self-review first, frame the right context, test plan included — even when the user just says 'open a PR' or 'ready to merge'.

Source repository stars: 7
Declared platforms: 0
Static risk flags: 0
Last source update: 2026-07-28
Source checked: 2026-07-28

Decision Compatibility Install Workflow Permissions Evidence Source

Decision brief

What it does—and where it fits

Use when asking for a review or creating a PR — self-review first, frame the right context, test plan included — even when the user just says 'open a PR' or 'ready to merge'.

Best for

About to run /create-pr or /prepare-for-review
A feature or bug fix is code-complete and the next step is "get
A stacked PR is ready and you need the parent branch reviewer to

Not for

"Small cleanup" titles on 800-line diffs
Test plan that says "should work"

Compatibility matrix

Platform support, with evidence labels

Platform	Status	Evidence	What to check
Codex	Not declared	No explicit evidence	Portability before use
Claude Code	Not declared	No explicit evidence	Portability before use
Cursor	Not declared	No explicit evidence	Portability before use
Gemini CLI	Not declared	No explicit evidence	Portability before use

Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource

npx skills add https://github.com/event4u-app/agent-config --skill "src/skills/requesting-code-review"

Safe inspection promptEditorial

Inspect the Agent Skill "requesting-code-review" from https://github.com/event4u-app/agent-config/blob/0adf49a8ae84b0ff6e2de8759eea43257e020eff/src/skills/requesting-code-review/SKILL.md at commit 0adf49a8ae84b0ff6e2de8759eea43257e020eff. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

01
Procedure
Before asking anyone else:
Read the full diff (git diff ...), not just the filesCheck for accidental debug output, dead code, leftover dd(),Check for secrets in diff — API keys, connection strings, tokens
02
1. Self-review first
Before asking anyone else:
Read the full diff (git diff ...), not just the filesCheck for accidental debug output, dead code, leftover dd(),Check for secrets in diff — API keys, connection strings, tokens
03
3. Write the review request context
Any review request must answer four questions. If any is missing, the reviewer will ask — and that round trip is preventable.
Any review request must answer four questions. If any is missing, the reviewer will ask — and that round trip is preventable.See create-pr-description for the full structured template, and conventional-commits-writing for the title format.
04
When to use
About to run /create-pr or /prepare-for-review A feature or bug fix is code-complete and the next step is "get eyes on it" A stacked PR is ready and you need the parent branch reviewer to context-switch smoothly Asking a human for a quick sanity check on a specific commit or diff
About to run /create-pr or /prepare-for-reviewA feature or bug fix is code-complete and the next step is "getA stacked PR is ready and you need the parent branch reviewer to
05
Goal
Give the reviewer exactly the context they need — what changed, why, how to verify — without forcing them to reconstruct your thought process. A well-framed review request halves review time and reduces back-and-forth on missing context.
Give the reviewer exactly the context they need — what changed, why, how to verify — without forcing them to reconstruct your thought process. A well-framed review request halves review time and reduces back-and-forth o…

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial

Signal	Value	Evidence type	Meaning
Quality score	98/100	Computed	Documentation, specificity, maintenance, and trust rules
Repository stars	7	Source	Repository attention, not individual Skill quality
Compatibility	0 platforms	Source	Declared in the catalog source record
Usage guide	automated source guide	Editorial	Generated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository: event4u-app/agent-config
Skill path: src/skills/requesting-code-review/SKILL.md
Commit: 0adf49a8ae84b0ff6e2de8759eea43257e020eff
License: MIT
Collected: 2026-07-28
Default branch: main

View the original SKILL.md

requesting-code-review

When to use

About to run /create-pr or /prepare-for-review
A feature or bug fix is code-complete and the next step is "get eyes on it"
A stacked PR is ready and you need the parent branch reviewer to context-switch smoothly
Asking a human for a quick sanity check on a specific commit or diff

Do NOT use when:

You are processing review feedback — use receiving-code-review
The branch is not yet code-complete — the review-request gate requires green tests and a clean diff
The change is documentation-only and has no behavior impact

Goal

Give the reviewer exactly the context they need — what changed, why, how to verify — without forcing them to reconstruct your thought process. A well-framed review request halves review time and reduces back-and-forth on missing context.

The Iron Law

NEVER REQUEST REVIEW FROM A BRANCH YOU HAVE NOT REVIEWED YOURSELF.

Self-review is the single cheapest filter. It catches the issues a human reviewer would flag in round one, so the human reviewer can spend time on the issues only they can see.

Procedure

1. Self-review first

Before asking anyone else:

Read the full diff (git diff <base>...<head>), not just the files you remember touching
Check for accidental debug output, dead code, leftover dd(), console.log, commented-out blocks
Check for secrets in diff — API keys, connection strings, tokens
Check file-system side effects — generated files, lockfile churn, IDE configs, .env changes
Run the linter + tests (see verify-before-complete)
If you find issues → fix them, do not ship them and hope the reviewer flags them

Use the review-changes command as the structured walk-through.

2. Establish the diff baseline

Determine the correct base commit:

# Simple branch from main
BASE=$(git merge-base HEAD main)

# Stacked PR — parent branch is base, not main
BASE=$(git merge-base HEAD <parent-branch>)

HEAD=$(git rev-parse HEAD)

The base matters for the reviewer's diff view — wrong base = they review 80 unrelated commits.

3. Write the review request context

Any review request must answer four questions. If any is missing, the reviewer will ask — and that round trip is preventable.

Question	Where it lives
What changed?	PR title (imperative, Conventional Commits) + summary bullets
Why?	Link to ticket / issue / Sentry event / user message
How do I verify it?	Test plan: commands to run, URLs to hit, expected behavior
What should I look at first?	Highlights: "pay attention to X because Y" or "skip Z, it is generated"

See create-pr-description for the full structured template, and conventional-commits-writing for the title format.

4. Keep the PR reviewable in size

Target < 400 lines of real diff (excluding generated / lockfiles)
If bigger — consider splitting into a stack (refactor PR → feature PR) so reviewers can handle each in one sitting
Flag generated files explicitly in the description so reviewers skip them
Never mix a refactor + behavior change in the same PR — reviewers cannot isolate the risk

5. Pick the right reviewer set

Architectural impact → the code owner for the affected area
Security-sensitive → a security-reviewer role if the project has one
Bots → let Copilot / Greptile / Augment run automatically; do not gate human review on bot completion
Cross-team change → each affected team's owner

If the project has a CODEOWNERS file, GitHub handles this automatically — do not override without a reason.

6. Send and wait — do not nudge early

After the PR is open:

Respond to questions, not to the implicit "where is my review?" schedule
If the review is blocking and overdue → a single short nudge is appropriate; do not re-open or force-push to bump the PR list

When review comments arrive → switch to receiving-code-review.

Output format

When handing the review request to the reviewer (PR body, Slack, email):

Title — Conventional Commit imperative
Summary — 2–5 bullets of what changed
Motivation — why, with ticket / Sentry / user-message link
Test plan — exact commands or URLs + expected result
Risk / scope notes — what the reviewer should pay attention to
Non-goals — what this PR deliberately does not do
Screenshots / logs — when UI or runtime behavior changed

Gotchas

"Ready for review" on a red CI run signals carelessness — wait for green or explain the specific failure
A 1000-line PR with "no behavior change" still needs review — the reviewer has no way to confirm "no behavior change" without reading every line
Auto-merge on approval bypasses re-review after later force-pushes — use deliberately, not by habit
A PR description that says "see the code" is not a description — reviewers need the why
Requesting review from someone without context (new hire, other team) without a longer pairing — they cannot do a deep review cold
Rebasing during review invalidates line-comments; let reviewers finish a round before rebasing when possible

Do NOT

Do NOT request review before self-review
Do NOT request review on a branch with failing CI (except when explicitly documenting "CI broken, please eyeball X only")
Do NOT mix unrelated changes in one PR
Do NOT force-push during active review without a good reason and a note to the reviewer
Do NOT leave the PR description empty
Do NOT request review from reviewers who lack context just to get approvals

Anti-patterns

"Small cleanup" titles on 800-line diffs
Test plan that says "should work"
Hiding a risky change inside a 40-file refactor PR
Pinging reviewers before CI goes green
Requesting review as a substitute for thinking the problem through

When to hand over to another skill / command

Self-review walkthrough → review-changes
Bringing a stacked branch up to date first → prepare-for-review
Writing the PR description → create-pr-description
Actually opening the PR → create-pr
Writing the commits themselves → commit, conventional-commits-writing
Verifying readiness → verify-before-complete
Processing the feedback when it arrives → receiving-code-review

Validation checklist

Before asking for review:

Self-review walkthrough done on the full diff
Linter + targeted tests + full test suite green
PR title follows Conventional Commits
PR description has summary, motivation, test plan, risk notes
Diff is reviewable in size (split if > 400 lines of real code)
CODEOWNERS / reviewer set is correct
No debug code, secrets, or stray files in the diff
No unrelated changes bundled in

Alternatives

Compare before choosing

Computed 66262,331

obra/superpowers

requesting-code-review

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

Computed 10042,015

coreyhaines31/marketingskills

ab-testing

When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

Computed 1007

event4u-app/agent-config

testing-anti-patterns

Use BEFORE writing/changing tests, adding mocks, or test-only methods on production classes — vs mocking-the-mock, production pollution, partial mocks, and overfit/tautological assertions

Computed 997

event4u-app/agent-config

design-review

Use when the user says "review the design", "check the UI", or wants a comprehensive UI/UX review. Uses a 7-phase methodology covering interaction, responsiveness, accessibility, and more.