Skip to content
cccskills
FreePublished on GitHub

pr-self-review

Guide authors through a structured self-review before requesting peer review.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md4.4 KB
  • assets/self-review-checklist.template1.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

What I do

I help you review your own pull request through a structured five-category checklist before you request external review:

  1. Description Accuracy — Does the PR description match what you actually changed?
  2. Scope — Are all files in the diff intentionally included? Any surprises?
  3. Artifact Cleanup — Any leftover debug code, console logs, TODOs, or commented-out lines?
  4. Test Coverage — Does every changed function/method have at least one test?
  5. Single Concern — Could this PR be split into two separate PRs?

By catching issues before external review, you save reviewers' time and reduce review cycles.

Supporting files in this skill:

  • assets/self-review-checklist.template — The five-category checklist as a markdown file you can copy into a PR comment

When to use me

Use when you want to:

  • Review your own PR before requesting external review
  • Catch obvious mistakes and missed artifacts before reviewers see them
  • Ensure your PR is focused on a single concern
  • Verify test coverage for all your changes
  • Reduce back-and-forth on revision cycles

PR lifecycle focus

Stage: Author pre-review checklist (after implementation, before external review).

Use Instead [if available]

  • Use pr-create when you need to draft the PR title/body before opening it.
  • Use pr-review when reviewing someone else's PR as a reviewer.
  • Use pr-split when the core question is whether to split a large PR.

Example usage

"Review my own PR before I request review" "Walk me through a self-review checklist" "Help me check my PR for debug code and missing tests"


Workflow

Here's how I guide you through self-review:

Step 1: Get the Diff

I'll ask for your PR diff or a link to the open PR if not provided in context.

Step 2: Description Check

I'll ask: Does the PR description accurately describe every file in the diff?

  • Read the description you wrote
  • Review the actual diff
  • Flag any mismatches (e.g., "description says 'add auth', but diff also changes payment logic")

Step 3: Scope Check

I'll ask: Are all files in the diff intentionally included?

  • Look for files that seem unrelated to the stated purpose
  • Flag any surprises (e.g., "why is the config file changed when this is a feature PR?")
  • Ask you to confirm each unexpected file is intentional

Step 4: Artifact Cleanup Check

I'll ask: Are there any obvious leftover debug artifacts? I'll flag obvious issues like:

  • console.log, print, println, println! (debug output)
  • debugger, pdb, debug! (breakpoints)
  • .only, .skip on test cases (ensures tests run)
  • Large commented-out code blocks

For TODO/FIXME comments, I'll ask: did you intend to resolve these before requesting review?

Note: Thorough artifact detection is your reviewers' job—this catches the obvious ones you might have missed.

Step 5: Test Coverage Check

I'll ask: Does every changed function/method have test coverage?

  • For each changed function or method, confirm at least one test covers it
  • Check that test files were also changed to add new tests
  • Flag any logic changes with no corresponding tests

Step 6: Concern Focus Check

I'll ask: Is this PR focused on a single concern, or does it mix unrelated changes?

  • Look for multiple distinct concerns (e.g., "auth changes + refactoring + documentation")
  • Ask: "Could this be two PRs?"
  • If yes, recommend splitting the PR using the /pr-split skill

Step 7: Summary

I'll summarize the findings:

  • ✅ Ready to request review
  • ⚠️ Minor issues to resolve before review
  • ⛔ Major issues blocking external review

Tips for Success

  • Review as a stranger would — Imagine someone unfamiliar with your code reading your diff
  • Be honest about artifacts — Debug code hidden from reviewers wastes their time
  • Verify test coverage manually — Don't assume tests exist; confirm they do
  • Check the PR description against reality — Description drift is the most common pre-review failure
  • Consider scope early — If you spot multiple concerns now, split the PR before requesting review
  • Copy the checklist into your PR — Leave a visible record that you self-reviewed

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Implement comprehensive error handling for Python code paths to keep services resilient and user-friendly. Use when failures are currently silent or exceptions leak through.

The English summary is being prepared. Showing the original description.

Unique-AG/ai5Updated Oct 20, 2026

Tabular and numerical data analysis with descriptive statistics and insights. Use when the user provides data, tables, CSVs, or numbers and wants analysis.

The English summary is being prepared. Showing the original description.

Unique-AG/ai5Updated Oct 20, 2026

Financial factsheet analysis with key metrics extraction and investment rationale

The English summary is being prepared. Showing the original description.

Unique-AG/ai5Updated Oct 20, 2026

ci-fix

Free

Diagnose and fix CI failures without leaving your editor.

The English summary is being prepared. Showing the original description.

Unique-AG/ai5Updated Oct 20, 2026

Reproduce ai-repo PR checks locally with Poe and CI scripts, including per-package typecheck and coverage behavior. Use when validating changes before push or when user asks which local commands match CI.

The English summary is being prepared. Showing the original description.

Unique-AG/ai5Updated Oct 20, 2026

Ask clarifying questions before implementing to ensure Python requirements are understood. Use when a task lacks detail, dependencies are unclear, or multiple interpretations are possible.

The English summary is being prepared. Showing the original description.

Unique-AG/ai5Updated Oct 20, 2026

See all skills by Unique-AG

Report a problem with this skill