# Self Review

> Use before opening a PR, or whenever asked to self-review a diffusers contribution. Applies the same rubric as the `@claude` CI (checks the diff against references/review-rules.md, traces call paths for dead code). Reports findings grouped by severity, flagging what to fix before submitting (blocking issues + dead code) vs what to leave for the actual review. Report-only — does not edit files.

- Skill: `huggingface/self-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add huggingface/self-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/huggingface/self-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Hugging Face (https://skillmd.com/u/huggingface)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/huggingface/self-review

---


# Self-review

Runs the same rubric as the `@claude` CI reviewer, so you catch issues before a
maintainer does — but over your **whole** PR diff. (The CI scopes itself to
`src/diffusers/`, `tests/`, and `.ai/`; for your own PR, also review your docs
and scripts.) You're already on the branch with the conventions loaded, so: get
the
diff → review it against the rubric → report → iterate with the contributor
until it's ready, then remind them to share the final notes on the PR.

## 1. Get the diff

```bash
git diff main...HEAD          # use your target branch if not main
```

If the branch trails `main` and the diff looks polluted with unrelated merged
files, scope to your own commits: `git log main..HEAD --oneline`, then
`git show <commit>`.

## 2. Read the rubric

`references/review-rules.md` is the canonical rubric (the CI pins it from `main`) — read
it and review against it; don't rely on a remembered copy. For the areas you
touched, also read `references/code_style.md`, `references/models.md`, `references/pipelines.md`,
`references/modular.md`, `references/testing.md`, or `references/pitfalls.md`.

## 3. Report

- **Blocking issues** — numbered. Each: title → explanation → `file.py:line` →
  impact. Cite the rule, e.g. *Per `references/models.md`: "…only keep the inference path."*
- **Non-blocking issues** — same format, lower severity.
- **Dead code (advisory)** — a table: `path:line` · Likely-dead / Used · reason.
- **Summary** — short synthesis and a verdict (**READY** / **NEEDS CHANGES**),
  spelling out:
  - **Fix before submitting** — all blocking issues, and remove the flagged dead code.
  - **Leave for the actual review** — non-blocking issues that aren't obviously
    correct; raise these with the reviewer rather than guessing at them now.

Report only — do not edit files. Be concrete, cite the rule, review the whole
diff, and don't invent issues or flag pure style.

## 4. Iterate until ready, then share

Expect several rounds: the contributor addresses findings, you review again.
Keep working with them to fix as much as possible until the verdict is
**READY** — the **Leave for the actual review** items are the only ones that
should reach the reviewer unresolved. End the final round's report by
reminding the contributor to share it on the PR (description or a comment) —
it saves the reviewer a few rounds of back-and-forth. Never commit the notes as
part of the diff.