agent doc: add a requirement for PR communications

.ai/AGENTS.md

@@ -49,6 +49,14 @@ codex plugin marketplace add huggingface/diffusers    # then install from the Pl
 ```
 
 
+## Human in the loop
+
+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.
+
+- **Don't commit unless the user approved the exact commit message, and never push or open a PR on
+  your own.** The user decides when anything is published, each time.
+- **Don't post to GitHub directly** — no comments, reviews, or replies. Draft when asked and hand the text to the user.
+
 ## Code formatting
 
 - `make style` and `make fix-copies` should be run before opening a PR

.ai/references/modular.md

@@ -317,6 +317,8 @@ ComponentSpec(
 
 10. **Raw `torch.randn(device=...)` for noise.** Use `randn_tensor(...)` from `utils/torch_utils`: it draws on the generator's device and moves the result, so CPU generators (what the test mixins pass) work, and the CUDA-generator path is bit-identical to `torch.randn`.
 
+11. **Helpers taking `components`.** Prefer explicit args, for example, `get_xx_prompt_embeds(text_encoder, tokenizer, prompt)` instead of `get_xx_prompt_embeds(components, prompt)`. Helpers and block methods should take only what they use so dependencies are visible and they can run without an assembled pipeline. Leave the full `components` object to `__call__`, which unpacks what its helpers need. See `get_qwen_prompt_embeds` in `qwenimage/encoders.py`.
+
 ## Conversion checklist
 
 - [ ] Read original pipeline's `__call__` end-to-end, map stages

docs/source/en/conceptual/contribution.md

@@ -608,6 +608,7 @@ AI-assisted contributions are welcome, but they must be coordinated, scoped, and
 - **Fix patterns, not one-offs.** If you spot an recurring issue, search the codebase for similar instances and open a *single* issue with a clear, systematic scope (e.g. "fix mutable defaults across all schedulers") rather than many issues or PRs for individual instances.
 - **Self-review before opening.** Run the [`self-review`](https://github.com/huggingface/diffusers/blob/main/.ai/skills/self-review/SKILL.md) skill — it reviews your diff against [`.ai/references/review-rules.md`](https://github.com/huggingface/diffusers/blob/main/.ai/references/review-rules.md), the same rubric the `@claude` CI reviewer uses — and address what it reports — it's a helper, not authoritative, and can be wrong. Focus on the blocking issues that make sense to you, and clean up dead/unused code as much as possible. If you disagree with a suggestion, it's fine to leave it for the reviewer to discuss after the PR is opened — the notes you share (see below) tell the reviewer it was a deliberate call.
 - **Share your self-review notes.** Please post the final self-review report — the round that reflects the diff you're submitting — on the PR, in the description or as a comment, including findings you intentionally did not fix and why. It helps the reviewer see what has already been checked and which calls were deliberate, and usually saves a few rounds of back-and-forth.
+- **Keep your PR communication concise.** Everything a reviewer reads on your PR — the description, commit messages, comments and replies, code comments — must be easy for a human to understand. If your agent drafted it, don't just skim it. Read it, and ask the agent to revise until it says something sensible and concise that you would write yourself. You are the author of everything you post.
 - **Include in the PR description:**
   - A **coordination link** to the issue or discussion where a maintainer acknowledged the work.
   - The **test commands you ran** and their results (paste relevant output, not just "tests pass").