Diffusers Agent Rules

A Python library for diffusion models and generative image, video, and audio pipelines.

Overview

Both root instruction files link to .ai/AGENTS.md. The guide covers setup, actions that need human approval, and which references or skills to read. Its self-review steps are shared with the project's CI reviewer.

Documents

├──  · symlink → .ai/AGENTS.md
├──  · symlink → .ai/AGENTS.md
└── .ai
    ├── references
    │   ├── 
    │   ├── 
    │   ├── 
    │   ├── 
    │   ├── 
    │   ├── 
    │   └── 
    ├── skills
    │   ├── custom-blocks
    │   │   └── 
    │   ├── diffusers-cli
    │   │   └── 
    │   ├── model-integration
    │   │   └── 
    │   └── self-review
    │       └── 
    └── 

Techniques in this file

01 / Router files

Separate persistent references from task workflows

Model conventions, pipeline patterns, tests, and reporting each have a reference guide. Adding or converting a model is routed to a skill, distinguishing ongoing conventions from an end-to-end procedure.

Source excerpt starting at line 67.
- **Models** — see [models.md](references/models.md) for model conventions, attention pattern, implementation rules, dependencies, and gotchas. For adding or converting a model, use the [model-integration](skills/model-integration/SKILL.md) skill.

02 / Contribution etiquette

Make exact wording part of the approval boundary

Human review covers commit messages, comments, docstrings, and public discussion, not only pull-request descriptions. Ask whether the user will author the text or wants a draft, and keep drafting separate from publishing.

Source excerpt starting at line 54.
Everything a PR reviewer sees must come from a human, or be approved by one for the exact wording. That includes commit messages, code comments and docstrings, PR titles and descriptions, and any PR or issue comment, review, or reply. Ask whether the user wants you to draft that text or will write it themselves. Keep drafts short and easy to understand. When you hand one over, remind them to read it for real and check that it reads well for other humans.

03 / Behavioral framing

Explain how old skill symlinks can alter the source

The setup section calls out a previous installation method that linked tool folders into .ai. Removing those links is necessary because a new install would otherwise write through them into the shared source directory.

Source excerpt starting at line 27.
Skills used to be installed through the `Makefile`, which symlinked the project-level `.claude/skills` and`.agents/skills` at `.ai/skills` in this repo. Remove those links if they exist — otherwise the install writes throughthem into `.ai/` itself:

04 / Pointing at the source of truth

Use the same review rules locally and in CI

The pre-PR self-review points at a named rules file and a dedicated skill. The guide states that the CI reviewer uses the same pass, giving local preparation a shared standard.

Source excerpt starting at line 84.
Before opening a PR, run self-review against [review-rules.md](references/review-rules.md). The [self-review skill](skills/self-review/SKILL.md) runs this as the same pass the `@claude` CI reviewer uses. Share the final report on the PR (description or comment) — see the skill for details.

Ideas for your repo

  1. Separate reference conventions from procedural skill entry points.
  2. State approval boundaries for each kind of published text.
  3. Explain write-through hazards when changing a symlink-based setup.
  4. Share the same review rules between local workflows and CI.
Sponsored byModem

Give your agents the whole story.

These instructions explain how to work in Diffusers. Modem shows your agents what customers said, who is affected, and what changed.

See how Modem works