Skip to content
cccskills
FreePublished on GitHub

self-review

Review a diffusers contribution before opening a pull request. Check the full change against project rules, trace potentially unused code, and receive a severity-based report separating required fixes from points to discuss with reviewers.

OriginalShow the original description

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.

See how to install

Good for

  • Checking a diffusers contribution before opening a pull request
  • Investigating potentially unused code in a change
  • Reviewing fixes again and preparing notes for reviewers

Files included (1)

  • SKILL.md2.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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

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.

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

custom-blocks

FreeSummary

Package an existing custom diffusers block into a directory ready for Hub upload. Select a class from a Python file and save its source, configuration, and associated files so others can load the block.

  • Preparing a custom block for Hub distribution
  • Selecting one block class from a Python file
  • Creating the directory layout needed to load a shared block
huggingface/diffusers34.8KUpdated Oct 18, 2026

diffusers-cli

FreeSummary

Run diffusers generation pipelines from a terminal and save their outputs. Inspect accepted inputs without downloading model weights, apply LoRA adapters during generation, run remotely through HF Jobs, and inspect software and GPU environment details.

  • Running one-off generation or batch jobs from a terminal
  • Checking a new model's basic operation
  • Inspecting accepted inputs before running a pipeline
huggingface/diffusers34.8KUpdated Oct 18, 2026

Integrate a model or pipeline into diffusers, from file structure and weight conversion to tests and documentation. Verify numerical agreement with the original implementation, with modular pipelines as the preferred starting point for new integrations.

  • Adding a new model and pipeline to diffusers
  • Converting a pipeline to modular format
  • Converting weights for a new version of a supported model
huggingface/diffusers34.8KUpdated Oct 18, 2026

See all skills by huggingface

Report a problem with this skill