本文へ移動
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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

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月12日 更新

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月12日 更新

Financial factsheet analysis with key metrics extraction and investment rationale

日本語の概要は準備中です。原文の説明を表示しています。

Unique-AG/ai52026年10月12日 更新

ci-fix

無料

Diagnose and fix CI failures without leaving your editor.

日本語の概要は準備中です。原文の説明を表示しています。

Unique-AG/ai52026年10月12日 更新

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月12日 更新

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月12日 更新

Unique-AG のスキルをすべて見る

このスキルの問題を報告する