본문으로 건너뛰기
cccskills
무료GitHub에 공개

pr-self-review

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(2)

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

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Unique-AG/ai52026년 10월 20일 업데이트

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Unique-AG/ai52026년 10월 20일 업데이트

Financial factsheet analysis with key metrics extraction and investment rationale

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Unique-AG/ai52026년 10월 20일 업데이트

ci-fix

무료

Diagnose and fix CI failures without leaving your editor.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Unique-AG/ai52026년 10월 20일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Unique-AG/ai52026년 10월 20일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Unique-AG/ai52026년 10월 20일 업데이트

Unique-AG의 스킬 모두 보기

이 스킬의 문제 신고