{"owner":"vladmandic","repo":"sdnext","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".github/copilot-instructions.md"],"skills":{"AGENTS.md":"# SD.Next: AGENTS.md Project Guidelines\n\n**SD.Next** is a complex codebase with specific patterns and conventions:\n- Read main instructions file `.github/copilot-instructions.md` for general project guidelines, tools, structure, style, and conventions.\n- For core tasks, also review instructions `.github/instructions/core.instructions.md`\n- For UI tasks, also review instructions `.github/instructions/ui.instructions.md`\n\nFor specific SKILLS, also review the relevant skill files specified in `.github/skills/README.md` and listed `.github/skills/*/SKILL.md`\n\nFor specific GUIDELINES, also review the relevant guideline files specified in `wiki/Dev-*.md` and listed in `wiki/Dev-Home.md`\n",".github/copilot-instructions.md":"# SD.Next: AGENTS.md Project Guidelines\n\n**SD.Next** is a complex codebase with specific patterns and conventions.\nGeneral app structure is:\n- **Python** backend server  \n  Uses **Torch** for model inference, **FastAPI** for API routes and **Gradio** for creation of UI components.  \n- **JavaScript**/**CSS** frontend  \n\n## Instructions\n\nThis file contains general guidelines for contributing to the SD.Next codebase, including conventions, tools, and project structure. For more specific guidance on working with particular areas of the codebase, please refer to the instructions files linked below:\n- [Core Runtime Guidelines](instructions/core.instructions.md): Use when editing Python core runtime code, startup flow, model loading, API internals, backend/device logic, or shared state in modules and pipelines.\n- [UI And Frontend Guidelines](instructions/ui.instructions.md): Use when editing frontend UI code, JavaScript, HTML, CSS, localization files, or built-in UI extensions including modernui and kanvas.\n- [Hint Typography Guidelines](instructions/hints.instructions.md): Use when editing hint text or other UI strings in localization JSON files (`ui/locale/locale_*.json`, `ui/locale/override_*.json`).\n\n## Agent Guidelines\n\n1. Verify the user instruction against relevant guidelines in this file and linked instruction files before proceeding.\n2. If the instruction conflicts with any guideline, do not proceed. Explain which guideline(s) it conflicts with and how to adjust the instruction to comply.\n3. If the instruction is valid but unclear or incomplete, ask targeted follow-up questions before implementation. Do not assume user intent or requirements.\n4. When giving feedback, name the applicable guideline(s) and explain how each one applies.\n5. If the instruction is clear and compliant, proceed and keep resulting changes aligned with project coding style, conventions, and structure.\n\n## Language Guidelines\n\n- Use clear and concise language when communicating with users, providing feedback, and explaining guidelines.\n- Avoid unnecessary pleasantries or filler language; focus on the technical content and actionable feedback.\n- When asking follow-up questions for clarification, be direct and specific about the information needed to proceed with the instruction while ensuring that the questions are relevant to the project guidelines and conventions.\n\n## Tools\n\n- `venv` for Python environment management, activated with `source venv/bin/activate` (Linux) or `venv\\Scripts\\activate` (Windows).  \n  venv MUST be activated before running any Python commands or scripts to ensure correct dependencies and environment variables.  \n- `python` 3.10+.\n- `pyproject.toml` for Python configuration, including linting and type checking settings.\n- `eslint` configured for both core and UI code.\n- `pnpm` for managing JavaScript dependencies and scripts, with key commands defined in `package.json`.\n- `ruff` and `pylint` for Python linting, with configurations in `pyproject.toml` and executed via `pnpm ruff` and `pnpm pylint`.\n- `pre-commit` hooks which also check line-endings and other formatting issues, configured in `.pre-commit-config.yaml`.\n\n## Project Structure\n\n- Entry/startup flow: `webui.sh` -> `launch.py` -> `webui.py` -> modules under `modules/`.\n- Install: `installer.py` takes care of installing dependencies and setting up the environment.\n- Core runtime state is centralized in `modules/shared.py` (shared.opts, model state, backend/device state).\n- API/server routes are under `modules/api/`.\n- UI codebase is split between base JS in `javascript/` and actual UI in `extensions-builtin/sdnext-modernui/`.\n- Model and pipeline logic is split between `modules/sd_*` and `pipelines/`.\n- Additional plug-ins live in `scripts/` and are used only when specified.\n- Extensions live in `extensions-builtin/` and `extensions/` and are loaded dynamically.\n- Tests and CLI scripts are under `test/` and `cli/`, with some API smoke checks in `test/full-test.sh`.\n\n## Code Style\n\n- Prefer existing project patterns over strict generic style rules;  \n  this codebase intentionally allows patterns often flagged in default linters such as allowing long lines, etc.\n\n## Conventions\n\n- Keep PR-ready changes targeted to `dev` branch.\n- Use conventions from `CONTRIBUTING`.\n- Do not include unrelated edits or submodule changes when preparing contributions.\n- Use existing CLI/API tool patterns in `cli/` and `test/` when adding automation scripts.\n- Respect environment-driven behavior (`SD_*` flags and options) instead of hardcoding platform/model assumptions.\n- For startup/init edits, preserve error handling and partial-failure tolerance in parallel scans and extension loading.\n\n## File Creation\n\n- Any temporary scripts or markdown reports must be stored in `tmp/` folder\n- Any helper scripts, task execution scripts, or output capture that need temporary files should always use the repository-local `tmp/` folder\n- Any reusable test scripts must be stored in `test/` folder\n\n## Repo-Local Skills\n\nAll skills are defined in `.github/skills/` and indexed in `.github/skills/README.md`.\nUse these repo-local skills for recurring SD.Next model integration work:\n\n- `port-model`  \n  File: `.github/skills/port-model/SKILL.md`  \n  Use when adding a new model family, porting a standalone script into a Diffusers pipeline, or wiring an upstream Diffusers model into SD.Next.\n\n- `port-pipeline`  \n  File: `.github/skills/port-pipeline/SKILL.md`  \n  Use when porting a custom model pipeline implementation to a Diffusers pipeline class with behavior parity and no hard-coded device or attention assumptions.\n\n- `debug-model`  \n  File: `.github/skills/debug-model/SKILL.md`  \n  Use when a new or existing SD.Next/Diffusers model integration fails during detection, loading, prompt encoding, sampling, or output handling.\n\n- `check-api`  \n  File: `.github/skills/check-api/SKILL.md`  \n  Use when auditing API routes in `modules/api/api.py` and validating endpoint parameters plus request/response signatures.\n\n- `check-paths`  \n  File: `.github/skills/check-paths/SKILL.md`  \n  Use when auditing model-loading calls to verify `cache_dir` routing for `from_pretrained` and `from_single_file`.\n\n- `check-schedulers`  \n  File: `.github/skills/check-schedulers/SKILL.md`  \n  Use when auditing scheduler registrations in `modules/sd_samplers_diffusers.py` for class loadability, config validity, and `SamplerData` mapping correctness.\n\n- `check-models`  \n  File: `.github/skills/check-models/SKILL.md`  \n  Use when running end-to-end model integration audits across loaders, detect/routing parity, reference catalogs, and pipeline API contracts.\n\n- `check-processing`  \n  File: `.github/skills/check-processing/SKILL.md`  \n  Use when validating txt2img/img2img/control processing workflows from UI submit definitions through backend processing and Diffusers execution, including parameter, type, and initialization checks.\n\n- `check-scripts`  \n  File: `.github/skills/check-scripts/SKILL.md`  \n  Use when auditing scripts in `scripts/*.py` for standard `Script` overrides (`__init__`, `title`, `show`) and validating `ui()` output against `run()` or `process()` parameters.\n\n- `github-issues`  \n  File: `.github/skills/github-issues/SKILL.md`  \n  Use when reading SD.Next GitHub issues with `[Issues]` in title and producing a markdown report with short summary, status, and suggested next steps for each issue.\n\n- `github-features`  \n  File: `.github/skills/github-features/SKILL.md`  \n  Use when reading SD.Next GitHub issues with `[Feature]` in title and producing a markdown report with short summary, status, and suggested next steps for each issue.\n\n- `analyze-model`  \n  File: `.github/skills/analyze-model/SKILL.md`  \n  Use when analyzing an external model URL to identify implementation style and estimate how difficult it is to port into SD.Next.\n\n- `diffusers-code`  \n  File: `.github/skills/diffusers-code/SKILL.md`  \n  Use when creating or editing code that must comply with Hugging Face diffusers conventions, including preparing PR-ready changes targeting diffusers.\n\n- `reference-catalog`  \n  File: `.github/skills/reference-catalog/SKILL.md`  \n  Use when maintaining and validating model reference catalogs in `data/reference*.json`, including duplicate checks and thumbnail alignment.\n\n- `fix-lint`  \n  File: `.github/skills/fix-lint/SKILL.md`  \n  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`.\n\n- `todo`  \n  File: `.github/skills/todo/SKILL.md`  \n  Use when searching the full codebase for `TODO` markers and producing a markdown document with proposed next steps for each item.\n\n- `update-docs`  \n  File: `.github/skills/update-docs/SKILL.md`  \n  Use when reading markdown files from `wiki/` to correct markdown syntax, improve readability, and optionally normalize structure, links, and terminology while preserving technical meaning.\n\nWhen creating and updating skills, update this file and the index in `.github/skills/README.md` accordingly.\n"},"files":{"AGENTS.md":"# SD.Next: AGENTS.md Project Guidelines\n\n**SD.Next** is a complex codebase with specific patterns and conventions:\n- Read main instructions file `.github/copilot-instructions.md` for general project guidelines, tools, structure, style, and conventions.\n- For core tasks, also review instructions `.github/instructions/core.instructions.md`\n- For UI tasks, also review instructions `.github/instructions/ui.instructions.md`\n\nFor specific SKILLS, also review the relevant skill files specified in `.github/skills/README.md` and listed `.github/skills/*/SKILL.md`\n\nFor specific GUIDELINES, also review the relevant guideline files specified in `wiki/Dev-*.md` and listed in `wiki/Dev-Home.md`\n",".github/copilot-instructions.md":"# SD.Next: AGENTS.md Project Guidelines\n\n**SD.Next** is a complex codebase with specific patterns and conventions.\nGeneral app structure is:\n- **Python** backend server  \n  Uses **Torch** for model inference, **FastAPI** for API routes and **Gradio** for creation of UI components.  \n- **JavaScript**/**CSS** frontend  \n\n## Instructions\n\nThis file contains general guidelines for contributing to the SD.Next codebase, including conventions, tools, and project structure. For more specific guidance on working with particular areas of the codebase, please refer to the instructions files linked below:\n- [Core Runtime Guidelines](instructions/core.instructions.md): Use when editing Python core runtime code, startup flow, model loading, API internals, backend/device logic, or shared state in modules and pipelines.\n- [UI And Frontend Guidelines](instructions/ui.instructions.md): Use when editing frontend UI code, JavaScript, HTML, CSS, localization files, or built-in UI extensions including modernui and kanvas.\n- [Hint Typography Guidelines](instructions/hints.instructions.md): Use when editing hint text or other UI strings in localization JSON files (`ui/locale/locale_*.json`, `ui/locale/override_*.json`).\n\n## Agent Guidelines\n\n1. Verify the user instruction against relevant guidelines in this file and linked instruction files before proceeding.\n2. If the instruction conflicts with any guideline, do not proceed. Explain which guideline(s) it conflicts with and how to adjust the instruction to comply.\n3. If the instruction is valid but unclear or incomplete, ask targeted follow-up questions before implementation. Do not assume user intent or requirements.\n4. When giving feedback, name the applicable guideline(s) and explain how each one applies.\n5. If the instruction is clear and compliant, proceed and keep resulting changes aligned with project coding style, conventions, and structure.\n\n## Language Guidelines\n\n- Use clear and concise language when communicating with users, providing feedback, and explaining guidelines.\n- Avoid unnecessary pleasantries or filler language; focus on the technical content and actionable feedback.\n- When asking follow-up questions for clarification, be direct and specific about the information needed to proceed with the instruction while ensuring that the questions are relevant to the project guidelines and conventions.\n\n## Tools\n\n- `venv` for Python environment management, activated with `source venv/bin/activate` (Linux) or `venv\\Scripts\\activate` (Windows).  \n  venv MUST be activated before running any Python commands or scripts to ensure correct dependencies and environment variables.  \n- `python` 3.10+.\n- `pyproject.toml` for Python configuration, including linting and type checking settings.\n- `eslint` configured for both core and UI code.\n- `pnpm` for managing JavaScript dependencies and scripts, with key commands defined in `package.json`.\n- `ruff` and `pylint` for Python linting, with configurations in `pyproject.toml` and executed via `pnpm ruff` and `pnpm pylint`.\n- `pre-commit` hooks which also check line-endings and other formatting issues, configured in `.pre-commit-config.yaml`.\n\n## Project Structure\n\n- Entry/startup flow: `webui.sh` -> `launch.py` -> `webui.py` -> modules under `modules/`.\n- Install: `installer.py` takes care of installing dependencies and setting up the environment.\n- Core runtime state is centralized in `modules/shared.py` (shared.opts, model state, backend/device state).\n- API/server routes are under `modules/api/`.\n- UI codebase is split between base JS in `javascript/` and actual UI in `extensions-builtin/sdnext-modernui/`.\n- Model and pipeline logic is split between `modules/sd_*` and `pipelines/`.\n- Additional plug-ins live in `scripts/` and are used only when specified.\n- Extensions live in `extensions-builtin/` and `extensions/` and are loaded dynamically.\n- Tests and CLI scripts are under `test/` and `cli/`, with some API smoke checks in `test/full-test.sh`.\n\n## Code Style\n\n- Prefer existing project patterns over strict generic style rules;  \n  this codebase intentionally allows patterns often flagged in default linters such as allowing long lines, etc.\n\n## Conventions\n\n- Keep PR-ready changes targeted to `dev` branch.\n- Use conventions from `CONTRIBUTING`.\n- Do not include unrelated edits or submodule changes when preparing contributions.\n- Use existing CLI/API tool patterns in `cli/` and `test/` when adding automation scripts.\n- Respect environment-driven behavior (`SD_*` flags and options) instead of hardcoding platform/model assumptions.\n- For startup/init edits, preserve error handling and partial-failure tolerance in parallel scans and extension loading.\n\n## File Creation\n\n- Any temporary scripts or markdown reports must be stored in `tmp/` folder\n- Any helper scripts, task execution scripts, or output capture that need temporary files should always use the repository-local `tmp/` folder\n- Any reusable test scripts must be stored in `test/` folder\n\n## Repo-Local Skills\n\nAll skills are defined in `.github/skills/` and indexed in `.github/skills/README.md`.\nUse these repo-local skills for recurring SD.Next model integration work:\n\n- `port-model`  \n  File: `.github/skills/port-model/SKILL.md`  \n  Use when adding a new model family, porting a standalone script into a Diffusers pipeline, or wiring an upstream Diffusers model into SD.Next.\n\n- `port-pipeline`  \n  File: `.github/skills/port-pipeline/SKILL.md`  \n  Use when porting a custom model pipeline implementation to a Diffusers pipeline class with behavior parity and no hard-coded device or attention assumptions.\n\n- `debug-model`  \n  File: `.github/skills/debug-model/SKILL.md`  \n  Use when a new or existing SD.Next/Diffusers model integration fails during detection, loading, prompt encoding, sampling, or output handling.\n\n- `check-api`  \n  File: `.github/skills/check-api/SKILL.md`  \n  Use when auditing API routes in `modules/api/api.py` and validating endpoint parameters plus request/response signatures.\n\n- `check-paths`  \n  File: `.github/skills/check-paths/SKILL.md`  \n  Use when auditing model-loading calls to verify `cache_dir` routing for `from_pretrained` and `from_single_file`.\n\n- `check-schedulers`  \n  File: `.github/skills/check-schedulers/SKILL.md`  \n  Use when auditing scheduler registrations in `modules/sd_samplers_diffusers.py` for class loadability, config validity, and `SamplerData` mapping correctness.\n\n- `check-models`  \n  File: `.github/skills/check-models/SKILL.md`  \n  Use when running end-to-end model integration audits across loaders, detect/routing parity, reference catalogs, and pipeline API contracts.\n\n- `check-processing`  \n  File: `.github/skills/check-processing/SKILL.md`  \n  Use when validating txt2img/img2img/control processing workflows from UI submit definitions through backend processing and Diffusers execution, including parameter, type, and initialization checks.\n\n- `check-scripts`  \n  File: `.github/skills/check-scripts/SKILL.md`  \n  Use when auditing scripts in `scripts/*.py` for standard `Script` overrides (`__init__`, `title`, `show`) and validating `ui()` output against `run()` or `process()` parameters.\n\n- `github-issues`  \n  File: `.github/skills/github-issues/SKILL.md`  \n  Use when reading SD.Next GitHub issues with `[Issues]` in title and producing a markdown report with short summary, status, and suggested next steps for each issue.\n\n- `github-features`  \n  File: `.github/skills/github-features/SKILL.md`  \n  Use when reading SD.Next GitHub issues with `[Feature]` in title and producing a markdown report with short summary, status, and suggested next steps for each issue.\n\n- `analyze-model`  \n  File: `.github/skills/analyze-model/SKILL.md`  \n  Use when analyzing an external model URL to identify implementation style and estimate how difficult it is to port into SD.Next.\n\n- `diffusers-code`  \n  File: `.github/skills/diffusers-code/SKILL.md`  \n  Use when creating or editing code that must comply with Hugging Face diffusers conventions, including preparing PR-ready changes targeting diffusers.\n\n- `reference-catalog`  \n  File: `.github/skills/reference-catalog/SKILL.md`  \n  Use when maintaining and validating model reference catalogs in `data/reference*.json`, including duplicate checks and thumbnail alignment.\n\n- `fix-lint`  \n  File: `.github/skills/fix-lint/SKILL.md`  \n  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`.\n\n- `todo`  \n  File: `.github/skills/todo/SKILL.md`  \n  Use when searching the full codebase for `TODO` markers and producing a markdown document with proposed next steps for each item.\n\n- `update-docs`  \n  File: `.github/skills/update-docs/SKILL.md`  \n  Use when reading markdown files from `wiki/` to correct markdown syntax, improve readability, and optionally normalize structure, links, and terminology while preserving technical meaning.\n\nWhen creating and updating skills, update this file and the index in `.github/skills/README.md` accordingly.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# SD.Next: AGENTS.md Project Guidelines\n\n**SD.Next** is a complex codebase with specific patterns and conventions:\n- Read main instructions file `.github/copilot-instructions.md` for general project guidelines, tools, structure, style, and conventions.\n- For core tasks, also review instructions `.github/instructions/core.instructions.md`\n- For UI tasks, also review instructions `.github/instructions/ui.instructions.md`\n\nFor specific SKILLS, also review the relevant skill files specified in `.github/skills/README.md` and listed `.github/skills/*/SKILL.md`\n\nFor specific GUIDELINES, also review the relevant guideline files specified in `wiki/Dev-*.md` and listed in `wiki/Dev-Home.md`\n","category":"root","tokens":173},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","title":"copilot-instructions.md","content":"# SD.Next: AGENTS.md Project Guidelines\n\n**SD.Next** is a complex codebase with specific patterns and conventions.\nGeneral app structure is:\n- **Python** backend server  \n  Uses **Torch** for model inference, **FastAPI** for API routes and **Gradio** for creation of UI components.  \n- **JavaScript**/**CSS** frontend  \n\n## Instructions\n\nThis file contains general guidelines for contributing to the SD.Next codebase, including conventions, tools, and project structure. For more specific guidance on working with particular areas of the codebase, please refer to the instructions files linked below:\n- [Core Runtime Guidelines](instructions/core.instructions.md): Use when editing Python core runtime code, startup flow, model loading, API internals, backend/device logic, or shared state in modules and pipelines.\n- [UI And Frontend Guidelines](instructions/ui.instructions.md): Use when editing frontend UI code, JavaScript, HTML, CSS, localization files, or built-in UI extensions including modernui and kanvas.\n- [Hint Typography Guidelines](instructions/hints.instructions.md): Use when editing hint text or other UI strings in localization JSON files (`ui/locale/locale_*.json`, `ui/locale/override_*.json`).\n\n## Agent Guidelines\n\n1. Verify the user instruction against relevant guidelines in this file and linked instruction files before proceeding.\n2. If the instruction conflicts with any guideline, do not proceed. Explain which guideline(s) it conflicts with and how to adjust the instruction to comply.\n3. If the instruction is valid but unclear or incomplete, ask targeted follow-up questions before implementation. Do not assume user intent or requirements.\n4. When giving feedback, name the applicable guideline(s) and explain how each one applies.\n5. If the instruction is clear and compliant, proceed and keep resulting changes aligned with project coding style, conventions, and structure.\n\n## Language Guidelines\n\n- Use clear and concise language when communicating with users, providing feedback, and explaining guidelines.\n- Avoid unnecessary pleasantries or filler language; focus on the technical content and actionable feedback.\n- When asking follow-up questions for clarification, be direct and specific about the information needed to proceed with the instruction while ensuring that the questions are relevant to the project guidelines and conventions.\n\n## Tools\n\n- `venv` for Python environment management, activated with `source venv/bin/activate` (Linux) or `venv\\Scripts\\activate` (Windows).  \n  venv MUST be activated before running any Python commands or scripts to ensure correct dependencies and environment variables.  \n- `python` 3.10+.\n- `pyproject.toml` for Python configuration, including linting and type checking settings.\n- `eslint` configured for both core and UI code.\n- `pnpm` for managing JavaScript dependencies and scripts, with key commands defined in `package.json`.\n- `ruff` and `pylint` for Python linting, with configurations in `pyproject.toml` and executed via `pnpm ruff` and `pnpm pylint`.\n- `pre-commit` hooks which also check line-endings and other formatting issues, configured in `.pre-commit-config.yaml`.\n\n## Project Structure\n\n- Entry/startup flow: `webui.sh` -> `launch.py` -> `webui.py` -> modules under `modules/`.\n- Install: `installer.py` takes care of installing dependencies and setting up the environment.\n- Core runtime state is centralized in `modules/shared.py` (shared.opts, model state, backend/device state).\n- API/server routes are under `modules/api/`.\n- UI codebase is split between base JS in `javascript/` and actual UI in `extensions-builtin/sdnext-modernui/`.\n- Model and pipeline logic is split between `modules/sd_*` and `pipelines/`.\n- Additional plug-ins live in `scripts/` and are used only when specified.\n- Extensions live in `extensions-builtin/` and `extensions/` and are loaded dynamically.\n- Tests and CLI scripts are under `test/` and `cli/`, with some API smoke checks in `test/full-test.sh`.\n\n## Code Style\n\n- Prefer existing project patterns over strict generic style rules;  \n  this codebase intentionally allows patterns often flagged in default linters such as allowing long lines, etc.\n\n## Conventions\n\n- Keep PR-ready changes targeted to `dev` branch.\n- Use conventions from `CONTRIBUTING`.\n- Do not include unrelated edits or submodule changes when preparing contributions.\n- Use existing CLI/API tool patterns in `cli/` and `test/` when adding automation scripts.\n- Respect environment-driven behavior (`SD_*` flags and options) instead of hardcoding platform/model assumptions.\n- For startup/init edits, preserve error handling and partial-failure tolerance in parallel scans and extension loading.\n\n## File Creation\n\n- Any temporary scripts or markdown reports must be stored in `tmp/` folder\n- Any helper scripts, task execution scripts, or output capture that need temporary files should always use the repository-local `tmp/` folder\n- Any reusable test scripts must be stored in `test/` folder\n\n## Repo-Local Skills\n\nAll skills are defined in `.github/skills/` and indexed in `.github/skills/README.md`.\nUse these repo-local skills for recurring SD.Next model integration work:\n\n- `port-model`  \n  File: `.github/skills/port-model/SKILL.md`  \n  Use when adding a new model family, porting a standalone script into a Diffusers pipeline, or wiring an upstream Diffusers model into SD.Next.\n\n- `port-pipeline`  \n  File: `.github/skills/port-pipeline/SKILL.md`  \n  Use when porting a custom model pipeline implementation to a Diffusers pipeline class with behavior parity and no hard-coded device or attention assumptions.\n\n- `debug-model`  \n  File: `.github/skills/debug-model/SKILL.md`  \n  Use when a new or existing SD.Next/Diffusers model integration fails during detection, loading, prompt encoding, sampling, or output handling.\n\n- `check-api`  \n  File: `.github/skills/check-api/SKILL.md`  \n  Use when auditing API routes in `modules/api/api.py` and validating endpoint parameters plus request/response signatures.\n\n- `check-paths`  \n  File: `.github/skills/check-paths/SKILL.md`  \n  Use when auditing model-loading calls to verify `cache_dir` routing for `from_pretrained` and `from_single_file`.\n\n- `check-schedulers`  \n  File: `.github/skills/check-schedulers/SKILL.md`  \n  Use when auditing scheduler registrations in `modules/sd_samplers_diffusers.py` for class loadability, config validity, and `SamplerData` mapping correctness.\n\n- `check-models`  \n  File: `.github/skills/check-models/SKILL.md`  \n  Use when running end-to-end model integration audits across loaders, detect/routing parity, reference catalogs, and pipeline API contracts.\n\n- `check-processing`  \n  File: `.github/skills/check-processing/SKILL.md`  \n  Use when validating txt2img/img2img/control processing workflows from UI submit definitions through backend processing and Diffusers execution, including parameter, type, and initialization checks.\n\n- `check-scripts`  \n  File: `.github/skills/check-scripts/SKILL.md`  \n  Use when auditing scripts in `scripts/*.py` for standard `Script` overrides (`__init__`, `title`, `show`) and validating `ui()` output against `run()` or `process()` parameters.\n\n- `github-issues`  \n  File: `.github/skills/github-issues/SKILL.md`  \n  Use when reading SD.Next GitHub issues with `[Issues]` in title and producing a markdown report with short summary, status, and suggested next steps for each issue.\n\n- `github-features`  \n  File: `.github/skills/github-features/SKILL.md`  \n  Use when reading SD.Next GitHub issues with `[Feature]` in title and producing a markdown report with short summary, status, and suggested next steps for each issue.\n\n- `analyze-model`  \n  File: `.github/skills/analyze-model/SKILL.md`  \n  Use when analyzing an external model URL to identify implementation style and estimate how difficult it is to port into SD.Next.\n\n- `diffusers-code`  \n  File: `.github/skills/diffusers-code/SKILL.md`  \n  Use when creating or editing code that must comply with Hugging Face diffusers conventions, including preparing PR-ready changes targeting diffusers.\n\n- `reference-catalog`  \n  File: `.github/skills/reference-catalog/SKILL.md`  \n  Use when maintaining and validating model reference catalogs in `data/reference*.json`, including duplicate checks and thumbnail alignment.\n\n- `fix-lint`  \n  File: `.github/skills/fix-lint/SKILL.md`  \n  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`.\n\n- `todo`  \n  File: `.github/skills/todo/SKILL.md`  \n  Use when searching the full codebase for `TODO` markers and producing a markdown document with proposed next steps for each item.\n\n- `update-docs`  \n  File: `.github/skills/update-docs/SKILL.md`  \n  Use when reading markdown files from `wiki/` to correct markdown syntax, improve readability, and optionally normalize structure, links, and terminology while preserving technical meaning.\n\nWhen creating and updating skills, update this file and the index in `.github/skills/README.md` accordingly.\n","category":".github","tokens":2282}]}