Claude Cursor opencode Skill

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

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download modem-dev-ossrules-public_files_diffusers_.ai_skills_self-review-d2b6775.zip · 1 KB
Part of modem-dev/ossrules — 39 skills

Install

skills CLI npx skills add https://github.com/modem-dev/ossrules/tree/main/public/files/diffusers/.ai/skills/self-review
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install modem-dev-ossrules@llmmart
Git git clone https://github.com/modem-dev/ossrules.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole modem-dev/ossrules collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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.

Files (ossrules)
  • SKILL.md 2.8 KB
    ---
    name: self-review
    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.
    ---
    
    # 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.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related