Public/automatic
1
0
Fork 0
mirror of https://github.com/vladmandic/automatic synced 2026-09-20 01:31:13 +02:00
Code Issues Packages Projects Releases Wiki Activity

validate reference, lint and update diffusers

Browse Source 
Signed-off-by: vladmandic <mandic00@live.com>
This commit is contained in:
vladmandic
2026-04-15 10:10:05 +02:00
parent 1a2d255bba
commit d29c133891
9 changed files with 273 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/copilot-instructions.md
+8
View File
@@ -109,6 +109,14 @@ Use these repo-local skills for recurring SD.Next model integration work:
File: `.github/skills/analyze-model/SKILL.md`
Use when analyzing an external model URL to identify implementation style and estimate how difficult it is to port into SD.Next.
- `diffusers-code`
File: `.github/skills/diffusers-code/SKILL.md`
Use when creating or editing code that must comply with Hugging Face diffusers conventions, including preparing PR-ready changes targeting diffusers.
- `reference-catalog`
File: `.github/skills/reference-catalog/SKILL.md`
Use when maintaining and validating model reference catalogs in `data/reference*.json`, including duplicate checks and thumbnail alignment.
- `fix-lint`
File: `.github/skills/fix-lint/SKILL.md`
Use when running the full lint workflow in required order (`pre-commit`, `eslint`, `ruff`, `pylint`) and fixing findings as needed, while ignoring lint issues explicitly marked with `TODO`.
.github/skills/README.md
+8
View File
@@ -44,6 +44,14 @@ This folder contains repo-local Copilot skills for recurring SD.Next tasks.
File: `analyze-model/SKILL.md`
Use when analyzing an external model URL to classify implementation style and estimate SD.Next porting difficulty before coding.
- `diffusers-code`
File: `diffusers-code/SKILL.md`
Use when creating or editing code to be compliant with Hugging Face diffusers conventions, including PR-ready change preparation for diffusers.
- `reference-catalog`
File: `reference-catalog/SKILL.md`
Use when maintaining and validating model reference catalogs in `data/reference*.json`, including duplicate checks and thumbnail alignment.
- `fix-lint`
File: `fix-lint/SKILL.md`
Use when running the full lint workflow in strict order and fixing issues as needed (`pre-commit`, `eslint`, `ruff`, `pylint`), while ignoring findings explicitly marked with `TODO`.
.github/skills/diffusers-code/SKILL.md
+162
View File
@@ -0,0 +1,162 @@
---
name: diffusers-code
description: "Create or edit code that is compliant with Hugging Face diffusers conventions, including models, pipelines, schedulers, tests, docs, and PR preparation targeting diffusers."
argument-hint: "Describe the target feature/bug, affected diffusers components, reference implementation links, and whether to prepare a PR-ready change"
---
# Diffusers Code Implementation And PR Skill
Use this skill to implement, edit, review, and prepare pull-request-ready changes for the diffusers library with high compliance to diffusers conventions.
## When To Use
- Adding or editing diffusers models, pipelines, schedulers, or loaders
- Fixing bugs in inference code paths in diffusers-compatible style
- Refactoring existing diffusers code while preserving behavior
- Adding tests and docs for diffusers changes
- Preparing a PR that targets the diffusers repository
## Primary Objectives
1. Keep behavior explicit, minimal, and inference-focused.
2. Match existing diffusers architecture and code patterns.
3. Preserve numerical behavior unless a behavior change is explicitly required.
4. Produce change sets that are clean, reviewable, and PR-ready.
## Hard Rules
- Keep logic simple and readable in the main forward or call path.
- Avoid defensive, speculative, or fallback code paths unless required by existing diffusers APIs.
- Do not silently guess intent. For unsupported inputs, raise concise errors.
- Do not introduce new mandatory dependencies without maintainer agreement.
- If optional dependencies are needed, guard imports and provide proper dummy paths.
- Keep implementation torch.compile-friendly: avoid graph-break patterns in core model paths.
- Prefer native PyTorch tensor ops over external reshape helpers.
## Code Structure Rules
### Models
- Use ModelMixin patterns and register constructor args with register_to_config.
- Keep layer invocation visible in forward, avoid hiding key module calls in extra helpers.
- Avoid hardcoded dtypes in forward paths; infer from tensors or module dtype.
- Follow existing model family patterns in src/diffusers/models/transformers.
### Attention
- Keep Attention class and processor together in the model file when following the standard diffusers pattern.
- Processor should perform the compute path and use dispatch_attention_fn pattern where applicable.
- Ensure processor registration and available processor declarations are complete.
### Pipelines
- Inherit from DiffusionPipeline.
- Decorate inference __call__ with @torch.no_grad().
- Support generator for reproducibility when workflow requires it.
- Support output_type="latent" where latent output skip is expected.
- Use self.progress_bar(timesteps) in denoising loops.
- Do not build variant behavior by subclassing an unrelated existing pipeline class.
### Schedulers
- Use SchedulerMixin and ConfigMixin.
- Keep scheduler config semantics consistent with existing scheduler implementations.
## Import And Registration Rules
- Register new classes in relevant __init__.py lazy import structures.
- Ensure import structure entries are complete for all newly exposed objects.
- Validate that public imports from diffusers work after edits.
## Copied Code Rules
- Respect # Copied from linkage.
- Do not manually diverge copied blocks unless intentionally breaking linkage.
- Run make fix-copies after changes that touch copied sources or copied blocks.
## Change Workflow
1. Gather context
- Confirm target files, model family, and expected behavior.
- Obtain reference implementation and runnable inference flow when porting.
2. Plan minimal scope
- Separate structural adaptation from algorithmic changes.
- Keep one coherent workflow per change set.
3. Implement
- Edit only required files.
- Preserve naming, config shape, and API contracts unless change requires otherwise.
4. Validate
- Run focused tests first, then broader checks as needed.
- Confirm imports and serialization/deserialization behavior.
5. Polish
- Run make style.
- Run make fix-copies.
- Re-run impacted tests.
## Testing Expectations
Include tests for the exact behavior being changed:
- Model tests for shape, dtype/device behavior, serialization, and config parity
- Pipeline tests for deterministic generation paths, outputs, and parameter handling
- Scheduler tests when scheduler logic or config behavior changes
- Regression tests for any bug fix
When parity with a reference implementation is required:
- Add component-level parity checks
- Add end-to-end parity checks
- Use explicit tolerances and deterministic seeds
## PR Preparation For Diffusers
When asked to prepare a PR targeting diffusers, produce:
1. Scope statement
- One-paragraph summary: problem, solution, and non-goals.
2. Change map
- File-by-file list describing what changed and why.
3. Validation evidence
- Commands run, tests passed, and any skipped tests with reasons.
4. Compatibility notes
- Backward compatibility, serialization impact, and optional dependency impact.
5. Reviewer guidance
- Key files to review first, known tradeoffs, and follow-up items.
### PR Quality Checklist
- [ ] Minimal focused diff
- [ ] No unrelated refactors mixed with behavior changes
- [ ] New/updated tests for changed behavior
- [ ] Docs updated when public APIs or user-facing behavior changed
- [ ] make style completed
- [ ] make fix-copies completed
- [ ] Relevant test suites pass
- [ ] Commit messages are clear and scoped
## Common Failure Modes To Prevent
- Missing lazy import registration causes runtime ImportError
- New config params not registered, causing from_pretrained mismatch
- Pipeline __call__ missing @torch.no_grad(), causing memory growth
- Hardcoded dtype assumptions break mixed precision usage
- Hidden behavior changes introduced during structural refactor
- Unnecessary dependency additions for simple tensor reshaping
## Output Contract For This Skill
When using this skill, provide:
- Implementation summary
- Exact files changed
- Validation summary with command outcomes
- Residual risks or deferred follow-ups
- PR-ready summary text when requested
.github/skills/reference-catalog/SKILL.md
+85
View File
@@ -0,0 +1,85 @@
---
name: reference-catalog
description: "Maintain and validate SD.Next model reference catalogs in data/reference*.json, including schema consistency, deduplication, link checks, and thumbnail alignment."
argument-hint: "Describe which catalog files to audit (or use all), whether to only report or also fix, and whether to include thumbnail sync in models/Reference"
---
# Reference Catalog Maintenance
Use this skill to audit and update SD.Next model reference catalogs with minimal, safe, and deterministic edits.
## When To Use
- Adding or updating model entries in `data/reference*.json`
- Cleaning duplicates, stale entries, or inconsistent metadata
- Verifying category placement across `base/cloud/quant/distilled/nunchaku/community`
- Syncing catalog entries with thumbnail files in `models/Reference`
## Catalog Files In Scope
- `data/reference.json` (base)
- `data/reference-cloud.json`
- `data/reference-quant.json`
- `data/reference-distilled.json`
- `data/reference-nunchaku.json`
- `data/reference-community.json`
## Core Rules
- Do not move entries between categories unless explicitly requested or strongly evidenced.
- Keep changes targeted to only affected records.
- Preserve existing field names and conventions used by neighboring entries.
- Prefer deterministic normalization (stable key order, consistent value style).
- Do not overwrite real thumbnails with placeholders.
## Validation Checklist
1. Structural validity
- Confirm JSON parses cleanly.
- Ensure top-level structure matches existing catalog conventions.
2. Entry integrity
- Required identifiers exist and are non-empty.
- URLs/repo references are syntactically valid.
- No malformed numeric/string fields compared with peer entries.
3. Cross-catalog consistency
- Detect likely duplicates across `reference*.json` files.
- Flag conflicting metadata for the same model key/name.
- Report category conflicts; only auto-fix when rules are explicit.
4. Thumbnail alignment
- Check expected thumbnail presence under `models/Reference`.
- If missing and requested, create zero-byte placeholder only.
- Never replace existing non-empty image assets with placeholders.
5. Deterministic formatting
- Keep formatting style consistent with nearby file conventions.
- Avoid broad reformatting unrelated to edited records.
## Safe Edit Workflow
1. Identify target entries and category intent.
2. Audit only relevant catalog files first.
3. Propose minimal edits (or apply when asked).
4. Re-validate JSON and duplicate checks.
5. Summarize exact changed records and rationale.
## Common Failure Modes To Prevent
- Adding a model to wrong category file
- Duplicating near-identical entries under different names
- Breaking JSON structure while editing by hand
- Inconsistent key naming across similar entries
- Creating placeholder thumbnail over an existing asset
## Output Contract
When using this skill, provide:
- Files audited
- Validation findings grouped by severity
- Exact records changed (before/after summary)
- Duplicate/conflict report across catalogs
- Thumbnail sync result for `models/Reference`
- Residual risks or follow-up items