{"owner":"huggingface","repo":"transformers","hasSkills":true,"totalSkillsCount":6,"totalTokensCount":3258,"categories":["claude-rule","root-instruction","copilot-instructions","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"transformers":{"command":"npx","args":["-y","@modelcontextprotocol/server-transformers"]}}},"found":["CLAUDE.md","AGENTS.md",".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"CLAUDE.md":"## Commands\n\n- `make style` — ruff format + lint (required for code style checks).\n- `make typing` — ty type checker and model structure rules.\n- `make fix-repo` — the `make style` fixes plus copies, modular conversions, doc TOCs, docstrings.\n- `make check-repo` — `make typing` plus consistency checks.\n- `RUN_SLOW=1 pytest ...` — many tests are marked slow and skipped in CI.\n\nRun `make style` (or `make fix-repo`) as the last step before opening a PR.\n\n## Local agent setup\n\nHosted review agents read this file via the root `AGENTS.md` / `CLAUDE.md` symlinks. Local agents wire their own assets: `make codex` (→ `.agents/`), `make claude` (→ `.claude/`).\n\n## Before opening a PR\n\n- Coordinate on the matching issue first. Do not open a PR for someone else's issue without explicit approval from its author or a maintainer in the thread; if approval is unclear, ask instead of drafting.\n- Check for overlapping work, and do not open a second PR for a fix already covered:\n\n  ```bash\n  gh issue view <issue_number> --repo huggingface/transformers --comments\n  gh pr list --repo huggingface/transformers --state open --search \"<issue_number> in:body\"\n  gh pr list --repo huggingface/transformers --state open --search \"<short area keywords>\"\n  ```\n\n  If your approach is materially different, say why a second PR is needed in the issue.\n- No one-off PRs for tiny edits (a single typo, an isolated lint fix). Mechanical cleanups are fine, but not as a first contribution.\n- First-time contributors should not submit agent-written PRs or issues — see `CONTRIBUTING.md` and the PR template. Code agents must warn users who are not already contributors, including the risk of being blocked.\n\n## Copies and modular models\n\nModel files in `src/transformers/models/` avoid inheriting from each other, so duplication is managed two ways — modular is the current one, copies are legacy:\n\n1. `# Copied from ...` marks a copied class or function. `make fix-repo` re-syncs it, so editing inside such a block is reverted — edit the source it copies from, or deliberately break the link. **Do not add new `# Copied from` statements**; write a modular file instead.\n2. A `modular_<name>.py` **may** inherit from other models; `make fix-repo` generates the standalone `modeling_*.py` and friends from it. Never edit a generated file when a modular one exists. Guide: [modular_transformers.md](../docs/source/en/modular_transformers.md).\n\nTwo modular traps:\n\n- **Other models inherit your modular file.** `modular_deepseek_vl.py` also generates `modeling_deepseek_vl_hybrid.py`. Run `make fix-repo` and check everything it rewrote; hand-editing only the generated file you had in mind leaves the rest stale and `Check repository consistency` red.\n- **`attr = AttributeError()` deletes an inherited attribute** — it is an instruction to the converter, not a bug or placeholder. `raise AttributeError(\"...\")` in a method body does the same for a method. Substituting a \"real\" value silently changes behaviour (`_no_split_modules = AttributeError()` → `[]` changes how the model may be sharded). See [Removing attributes](../docs/source/en/modular_transformers.md#removing-attributes) and [Deleting unused methods](../docs/source/en/modular_transformers.md#deleting-unused-methods).\n","AGENTS.md":"## Commands\n\n- `make style` — ruff format + lint (required for code style checks).\n- `make typing` — ty type checker and model structure rules.\n- `make fix-repo` — the `make style` fixes plus copies, modular conversions, doc TOCs, docstrings.\n- `make check-repo` — `make typing` plus consistency checks.\n- `RUN_SLOW=1 pytest ...` — many tests are marked slow and skipped in CI.\n\nRun `make style` (or `make fix-repo`) as the last step before opening a PR.\n\n## Local agent setup\n\nHosted review agents read this file via the root `AGENTS.md` / `CLAUDE.md` symlinks. Local agents wire their own assets: `make codex` (→ `.agents/`), `make claude` (→ `.claude/`).\n\n## Before opening a PR\n\n- Coordinate on the matching issue first. Do not open a PR for someone else's issue without explicit approval from its author or a maintainer in the thread; if approval is unclear, ask instead of drafting.\n- Check for overlapping work, and do not open a second PR for a fix already covered:\n\n  ```bash\n  gh issue view <issue_number> --repo huggingface/transformers --comments\n  gh pr list --repo huggingface/transformers --state open --search \"<issue_number> in:body\"\n  gh pr list --repo huggingface/transformers --state open --search \"<short area keywords>\"\n  ```\n\n  If your approach is materially different, say why a second PR is needed in the issue.\n- No one-off PRs for tiny edits (a single typo, an isolated lint fix). Mechanical cleanups are fine, but not as a first contribution.\n- First-time contributors should not submit agent-written PRs or issues — see `CONTRIBUTING.md` and the PR template. Code agents must warn users who are not already contributors, including the risk of being blocked.\n\n## Copies and modular models\n\nModel files in `src/transformers/models/` avoid inheriting from each other, so duplication is managed two ways — modular is the current one, copies are legacy:\n\n1. `# Copied from ...` marks a copied class or function. `make fix-repo` re-syncs it, so editing inside such a block is reverted — edit the source it copies from, or deliberately break the link. **Do not add new `# Copied from` statements**; write a modular file instead.\n2. A `modular_<name>.py` **may** inherit from other models; `make fix-repo` generates the standalone `modeling_*.py` and friends from it. Never edit a generated file when a modular one exists. Guide: [modular_transformers.md](../docs/source/en/modular_transformers.md).\n\nTwo modular traps:\n\n- **Other models inherit your modular file.** `modular_deepseek_vl.py` also generates `modeling_deepseek_vl_hybrid.py`. Run `make fix-repo` and check everything it rewrote; hand-editing only the generated file you had in mind leaves the rest stale and `Check repository consistency` red.\n- **`attr = AttributeError()` deletes an inherited attribute** — it is an instruction to the converter, not a bug or placeholder. `raise AttributeError(\"...\")` in a method body does the same for a method. Substituting a \"real\" value silently changes behaviour (`_no_split_modules = AttributeError()` → `[]` changes how the model may be sharded). See [Removing attributes](../docs/source/en/modular_transformers.md#removing-attributes) and [Deleting unused methods](../docs/source/en/modular_transformers.md#deleting-unused-methods).\n",".github/copilot-instructions.md":"# copilot-instructions.md Guide for Hugging Face Transformers\n\nThis copilot-instructions.md file provides guidance for code agents working with this codebase.\n\n## Core Project Structure\n\n- `/src/transformers`: This contains the core source code for the library\n  - `/models`: Code for individual models. Models inherit from base classes in the root `/src/transformers` directory.\n- `/tests`: This contains the core test classes for the library. These are usually inherited rather than directly run.\n  - `/models`: Tests for individual models. Model tests inherit from common tests in the root `/tests` directory.\n- `/docs`: This contains the documentation for the library, including guides, tutorials, and API references.\n\n## Coding Conventions for Hugging Face Transformers\n\n- PRs should be as brief as possible. Bugfix PRs in particular can often be only one or two lines long, and do not need large comments, docstrings or new functions in this case. Aim to minimize the size of the diff.\n- When writing tests, they should be added to an existing file. The only exception is for PRs to add a new model, when a new test directory should be created for that model.\n- Code style is enforced in the CI. You can install the style tools with `pip install -e .[quality]`. You can then run `make fixup` to apply style and consistency fixes to your code.\n\n## Copying and inheritance\n\nMany models in the codebase have similar code, but it is not shared by inheritance because we want each model file to be self-contained.\nWe use two mechanisms to keep this code in sync:\n\n- \"Copied from\" syntax. Functions or entire classes can have a comment at the top like this: `# Copied from transformers.models.llama.modeling_llama.rotate_half` or `# Copied from transformers.models.t5.modeling_t5.T5LayerNorm with T5->MT5`\n  These comments are actively checked by the style tools, and copies will automatically be updated when the base code is updated. If you need to update a copied function, you should\n  either update the base function and use `make fixup` to propagate the change to all copies, or simply remove the `# Copied from` comment if that is inappropriate.\n- \"Modular\" files. These files briefly define models by composing them using inheritance from other models. They are not meant to be used directly. Instead, the style tools\n  automatically generate a complete modeling file, like `modeling_bert.py`, from the modular file like `modular_bert.py`. If a model has a modular file, the modeling file\n  should never be edited directly! Instead, changes should be made in the modular file, and then you should run `make fixup` to update the modeling file automatically.\n\nWhen adding new models, you should prefer `modular` style and inherit as many classes as possible from existing models.\n\n## Testing\n\nAfter making changes, you should usually run `make fixup` to ensure any copies and modular files are updated, and then test all affected models. This includes both\nthe model you made the changes in and any other models that were updated by `make fixup`. Tests can be run with `pytest tests/models/[name]/test_modeling_[name].py`\nIf your changes affect code in other classes like tokenizers or processors, you should run those tests instead, like `test_processing_[name].py` or `test_tokenization_[name].py`.\n\nIn order to run tests, you may need to install dependencies. You can do this with `pip install -e .[testing]`. You will probably also need to `pip install torch accelerate` if your environment does not already have them.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/plugin.json)"},"files":{"CLAUDE.md":"## Commands\n\n- `make style` — ruff format + lint (required for code style checks).\n- `make typing` — ty type checker and model structure rules.\n- `make fix-repo` — the `make style` fixes plus copies, modular conversions, doc TOCs, docstrings.\n- `make check-repo` — `make typing` plus consistency checks.\n- `RUN_SLOW=1 pytest ...` — many tests are marked slow and skipped in CI.\n\nRun `make style` (or `make fix-repo`) as the last step before opening a PR.\n\n## Local agent setup\n\nHosted review agents read this file via the root `AGENTS.md` / `CLAUDE.md` symlinks. Local agents wire their own assets: `make codex` (→ `.agents/`), `make claude` (→ `.claude/`).\n\n## Before opening a PR\n\n- Coordinate on the matching issue first. Do not open a PR for someone else's issue without explicit approval from its author or a maintainer in the thread; if approval is unclear, ask instead of drafting.\n- Check for overlapping work, and do not open a second PR for a fix already covered:\n\n  ```bash\n  gh issue view <issue_number> --repo huggingface/transformers --comments\n  gh pr list --repo huggingface/transformers --state open --search \"<issue_number> in:body\"\n  gh pr list --repo huggingface/transformers --state open --search \"<short area keywords>\"\n  ```\n\n  If your approach is materially different, say why a second PR is needed in the issue.\n- No one-off PRs for tiny edits (a single typo, an isolated lint fix). Mechanical cleanups are fine, but not as a first contribution.\n- First-time contributors should not submit agent-written PRs or issues — see `CONTRIBUTING.md` and the PR template. Code agents must warn users who are not already contributors, including the risk of being blocked.\n\n## Copies and modular models\n\nModel files in `src/transformers/models/` avoid inheriting from each other, so duplication is managed two ways — modular is the current one, copies are legacy:\n\n1. `# Copied from ...` marks a copied class or function. `make fix-repo` re-syncs it, so editing inside such a block is reverted — edit the source it copies from, or deliberately break the link. **Do not add new `# Copied from` statements**; write a modular file instead.\n2. A `modular_<name>.py` **may** inherit from other models; `make fix-repo` generates the standalone `modeling_*.py` and friends from it. Never edit a generated file when a modular one exists. Guide: [modular_transformers.md](../docs/source/en/modular_transformers.md).\n\nTwo modular traps:\n\n- **Other models inherit your modular file.** `modular_deepseek_vl.py` also generates `modeling_deepseek_vl_hybrid.py`. Run `make fix-repo` and check everything it rewrote; hand-editing only the generated file you had in mind leaves the rest stale and `Check repository consistency` red.\n- **`attr = AttributeError()` deletes an inherited attribute** — it is an instruction to the converter, not a bug or placeholder. `raise AttributeError(\"...\")` in a method body does the same for a method. Substituting a \"real\" value silently changes behaviour (`_no_split_modules = AttributeError()` → `[]` changes how the model may be sharded). See [Removing attributes](../docs/source/en/modular_transformers.md#removing-attributes) and [Deleting unused methods](../docs/source/en/modular_transformers.md#deleting-unused-methods).\n","AGENTS.md":"## Commands\n\n- `make style` — ruff format + lint (required for code style checks).\n- `make typing` — ty type checker and model structure rules.\n- `make fix-repo` — the `make style` fixes plus copies, modular conversions, doc TOCs, docstrings.\n- `make check-repo` — `make typing` plus consistency checks.\n- `RUN_SLOW=1 pytest ...` — many tests are marked slow and skipped in CI.\n\nRun `make style` (or `make fix-repo`) as the last step before opening a PR.\n\n## Local agent setup\n\nHosted review agents read this file via the root `AGENTS.md` / `CLAUDE.md` symlinks. Local agents wire their own assets: `make codex` (→ `.agents/`), `make claude` (→ `.claude/`).\n\n## Before opening a PR\n\n- Coordinate on the matching issue first. Do not open a PR for someone else's issue without explicit approval from its author or a maintainer in the thread; if approval is unclear, ask instead of drafting.\n- Check for overlapping work, and do not open a second PR for a fix already covered:\n\n  ```bash\n  gh issue view <issue_number> --repo huggingface/transformers --comments\n  gh pr list --repo huggingface/transformers --state open --search \"<issue_number> in:body\"\n  gh pr list --repo huggingface/transformers --state open --search \"<short area keywords>\"\n  ```\n\n  If your approach is materially different, say why a second PR is needed in the issue.\n- No one-off PRs for tiny edits (a single typo, an isolated lint fix). Mechanical cleanups are fine, but not as a first contribution.\n- First-time contributors should not submit agent-written PRs or issues — see `CONTRIBUTING.md` and the PR template. Code agents must warn users who are not already contributors, including the risk of being blocked.\n\n## Copies and modular models\n\nModel files in `src/transformers/models/` avoid inheriting from each other, so duplication is managed two ways — modular is the current one, copies are legacy:\n\n1. `# Copied from ...` marks a copied class or function. `make fix-repo` re-syncs it, so editing inside such a block is reverted — edit the source it copies from, or deliberately break the link. **Do not add new `# Copied from` statements**; write a modular file instead.\n2. A `modular_<name>.py` **may** inherit from other models; `make fix-repo` generates the standalone `modeling_*.py` and friends from it. Never edit a generated file when a modular one exists. Guide: [modular_transformers.md](../docs/source/en/modular_transformers.md).\n\nTwo modular traps:\n\n- **Other models inherit your modular file.** `modular_deepseek_vl.py` also generates `modeling_deepseek_vl_hybrid.py`. Run `make fix-repo` and check everything it rewrote; hand-editing only the generated file you had in mind leaves the rest stale and `Check repository consistency` red.\n- **`attr = AttributeError()` deletes an inherited attribute** — it is an instruction to the converter, not a bug or placeholder. `raise AttributeError(\"...\")` in a method body does the same for a method. Substituting a \"real\" value silently changes behaviour (`_no_split_modules = AttributeError()` → `[]` changes how the model may be sharded). See [Removing attributes](../docs/source/en/modular_transformers.md#removing-attributes) and [Deleting unused methods](../docs/source/en/modular_transformers.md#deleting-unused-methods).\n",".github/copilot-instructions.md":"# copilot-instructions.md Guide for Hugging Face Transformers\n\nThis copilot-instructions.md file provides guidance for code agents working with this codebase.\n\n## Core Project Structure\n\n- `/src/transformers`: This contains the core source code for the library\n  - `/models`: Code for individual models. Models inherit from base classes in the root `/src/transformers` directory.\n- `/tests`: This contains the core test classes for the library. These are usually inherited rather than directly run.\n  - `/models`: Tests for individual models. Model tests inherit from common tests in the root `/tests` directory.\n- `/docs`: This contains the documentation for the library, including guides, tutorials, and API references.\n\n## Coding Conventions for Hugging Face Transformers\n\n- PRs should be as brief as possible. Bugfix PRs in particular can often be only one or two lines long, and do not need large comments, docstrings or new functions in this case. Aim to minimize the size of the diff.\n- When writing tests, they should be added to an existing file. The only exception is for PRs to add a new model, when a new test directory should be created for that model.\n- Code style is enforced in the CI. You can install the style tools with `pip install -e .[quality]`. You can then run `make fixup` to apply style and consistency fixes to your code.\n\n## Copying and inheritance\n\nMany models in the codebase have similar code, but it is not shared by inheritance because we want each model file to be self-contained.\nWe use two mechanisms to keep this code in sync:\n\n- \"Copied from\" syntax. Functions or entire classes can have a comment at the top like this: `# Copied from transformers.models.llama.modeling_llama.rotate_half` or `# Copied from transformers.models.t5.modeling_t5.T5LayerNorm with T5->MT5`\n  These comments are actively checked by the style tools, and copies will automatically be updated when the base code is updated. If you need to update a copied function, you should\n  either update the base function and use `make fixup` to propagate the change to all copies, or simply remove the `# Copied from` comment if that is inappropriate.\n- \"Modular\" files. These files briefly define models by composing them using inheritance from other models. They are not meant to be used directly. Instead, the style tools\n  automatically generate a complete modeling file, like `modeling_bert.py`, from the modular file like `modular_bert.py`. If a model has a modular file, the modeling file\n  should never be edited directly! Instead, changes should be made in the modular file, and then you should run `make fixup` to update the modeling file automatically.\n\nWhen adding new models, you should prefer `modular` style and inherit as many classes as possible from existing models.\n\n## Testing\n\nAfter making changes, you should usually run `make fixup` to ensure any copies and modular files are updated, and then test all affected models. This includes both\nthe model you made the changes in and any other models that were updated by `make fixup`. Tests can be run with `pytest tests/models/[name]/test_modeling_[name].py`\nIf your changes affect code in other classes like tokenizers or processors, you should run those tests instead, like `test_processing_[name].py` or `test_tokenization_[name].py`.\n\nIn order to run tests, you may need to install dependencies. You can do this with `pip install -e .[testing]`. You will probably also need to `pip install torch accelerate` if your environment does not already have them.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/huggingface/transformers/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"## Commands\n\n- `make style` — ruff format + lint (required for code style checks).\n- `make typing` — ty type checker and model structure rules.\n- `make fix-repo` — the `make style` fixes plus copies, modular conversions, doc TOCs, docstrings.\n- `make check-repo` — `make typing` plus consistency checks.\n- `RUN_SLOW=1 pytest ...` — many tests are marked slow and skipped in CI.\n\nRun `make style` (or `make fix-repo`) as the last step before opening a PR.\n\n## Local agent setup\n\nHosted review agents read this file via the root `AGENTS.md` / `CLAUDE.md` symlinks. Local agents wire their own assets: `make codex` (→ `.agents/`), `make claude` (→ `.claude/`).\n\n## Before opening a PR\n\n- Coordinate on the matching issue first. Do not open a PR for someone else's issue without explicit approval from its author or a maintainer in the thread; if approval is unclear, ask instead of drafting.\n- Check for overlapping work, and do not open a second PR for a fix already covered:\n\n  ```bash\n  gh issue view <issue_number> --repo huggingface/transformers --comments\n  gh pr list --repo huggingface/transformers --state open --search \"<issue_number> in:body\"\n  gh pr list --repo huggingface/transformers --state open --search \"<short area keywords>\"\n  ```\n\n  If your approach is materially different, say why a second PR is needed in the issue.\n- No one-off PRs for tiny edits (a single typo, an isolated lint fix). Mechanical cleanups are fine, but not as a first contribution.\n- First-time contributors should not submit agent-written PRs or issues — see `CONTRIBUTING.md` and the PR template. Code agents must warn users who are not already contributors, including the risk of being blocked.\n\n## Copies and modular models\n\nModel files in `src/transformers/models/` avoid inheriting from each other, so duplication is managed two ways — modular is the current one, copies are legacy:\n\n1. `# Copied from ...` marks a copied class or function. `make fix-repo` re-syncs it, so editing inside such a block is reverted — edit the source it copies from, or deliberately break the link. **Do not add new `# Copied from` statements**; write a modular file instead.\n2. A `modular_<name>.py` **may** inherit from other models; `make fix-repo` generates the standalone `modeling_*.py` and friends from it. Never edit a generated file when a modular one exists. Guide: [modular_transformers.md](../docs/source/en/modular_transformers.md).\n\nTwo modular traps:\n\n- **Other models inherit your modular file.** `modular_deepseek_vl.py` also generates `modeling_deepseek_vl_hybrid.py`. Run `make fix-repo` and check everything it rewrote; hand-editing only the generated file you had in mind leaves the rest stale and `Check repository consistency` red.\n- **`attr = AttributeError()` deletes an inherited attribute** — it is an instruction to the converter, not a bug or placeholder. `raise AttributeError(\"...\")` in a method body does the same for a method. Substituting a \"real\" value silently changes behaviour (`_no_split_modules = AttributeError()` → `[]` changes how the model may be sharded). See [Removing attributes](../docs/source/en/modular_transformers.md#removing-attributes) and [Deleting unused methods](../docs/source/en/modular_transformers.md#deleting-unused-methods).\n","isInternal":false,"tokens":792,"sizeBytes":3287},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/huggingface/transformers/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"## Commands\n\n- `make style` — ruff format + lint (required for code style checks).\n- `make typing` — ty type checker and model structure rules.\n- `make fix-repo` — the `make style` fixes plus copies, modular conversions, doc TOCs, docstrings.\n- `make check-repo` — `make typing` plus consistency checks.\n- `RUN_SLOW=1 pytest ...` — many tests are marked slow and skipped in CI.\n\nRun `make style` (or `make fix-repo`) as the last step before opening a PR.\n\n## Local agent setup\n\nHosted review agents read this file via the root `AGENTS.md` / `CLAUDE.md` symlinks. Local agents wire their own assets: `make codex` (→ `.agents/`), `make claude` (→ `.claude/`).\n\n## Before opening a PR\n\n- Coordinate on the matching issue first. Do not open a PR for someone else's issue without explicit approval from its author or a maintainer in the thread; if approval is unclear, ask instead of drafting.\n- Check for overlapping work, and do not open a second PR for a fix already covered:\n\n  ```bash\n  gh issue view <issue_number> --repo huggingface/transformers --comments\n  gh pr list --repo huggingface/transformers --state open --search \"<issue_number> in:body\"\n  gh pr list --repo huggingface/transformers --state open --search \"<short area keywords>\"\n  ```\n\n  If your approach is materially different, say why a second PR is needed in the issue.\n- No one-off PRs for tiny edits (a single typo, an isolated lint fix). Mechanical cleanups are fine, but not as a first contribution.\n- First-time contributors should not submit agent-written PRs or issues — see `CONTRIBUTING.md` and the PR template. Code agents must warn users who are not already contributors, including the risk of being blocked.\n\n## Copies and modular models\n\nModel files in `src/transformers/models/` avoid inheriting from each other, so duplication is managed two ways — modular is the current one, copies are legacy:\n\n1. `# Copied from ...` marks a copied class or function. `make fix-repo` re-syncs it, so editing inside such a block is reverted — edit the source it copies from, or deliberately break the link. **Do not add new `# Copied from` statements**; write a modular file instead.\n2. A `modular_<name>.py` **may** inherit from other models; `make fix-repo` generates the standalone `modeling_*.py` and friends from it. Never edit a generated file when a modular one exists. Guide: [modular_transformers.md](../docs/source/en/modular_transformers.md).\n\nTwo modular traps:\n\n- **Other models inherit your modular file.** `modular_deepseek_vl.py` also generates `modeling_deepseek_vl_hybrid.py`. Run `make fix-repo` and check everything it rewrote; hand-editing only the generated file you had in mind leaves the rest stale and `Check repository consistency` red.\n- **`attr = AttributeError()` deletes an inherited attribute** — it is an instruction to the converter, not a bug or placeholder. `raise AttributeError(\"...\")` in a method body does the same for a method. Substituting a \"real\" value silently changes behaviour (`_no_split_modules = AttributeError()` → `[]` changes how the model may be sharded). See [Removing attributes](../docs/source/en/modular_transformers.md#removing-attributes) and [Deleting unused methods](../docs/source/en/modular_transformers.md#deleting-unused-methods).\n","isInternal":false,"tokens":792,"sizeBytes":3287},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/huggingface/transformers/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# copilot-instructions.md Guide for Hugging Face Transformers\n\nThis copilot-instructions.md file provides guidance for code agents working with this codebase.\n\n## Core Project Structure\n\n- `/src/transformers`: This contains the core source code for the library\n  - `/models`: Code for individual models. Models inherit from base classes in the root `/src/transformers` directory.\n- `/tests`: This contains the core test classes for the library. These are usually inherited rather than directly run.\n  - `/models`: Tests for individual models. Model tests inherit from common tests in the root `/tests` directory.\n- `/docs`: This contains the documentation for the library, including guides, tutorials, and API references.\n\n## Coding Conventions for Hugging Face Transformers\n\n- PRs should be as brief as possible. Bugfix PRs in particular can often be only one or two lines long, and do not need large comments, docstrings or new functions in this case. Aim to minimize the size of the diff.\n- When writing tests, they should be added to an existing file. The only exception is for PRs to add a new model, when a new test directory should be created for that model.\n- Code style is enforced in the CI. You can install the style tools with `pip install -e .[quality]`. You can then run `make fixup` to apply style and consistency fixes to your code.\n\n## Copying and inheritance\n\nMany models in the codebase have similar code, but it is not shared by inheritance because we want each model file to be self-contained.\nWe use two mechanisms to keep this code in sync:\n\n- \"Copied from\" syntax. Functions or entire classes can have a comment at the top like this: `# Copied from transformers.models.llama.modeling_llama.rotate_half` or `# Copied from transformers.models.t5.modeling_t5.T5LayerNorm with T5->MT5`\n  These comments are actively checked by the style tools, and copies will automatically be updated when the base code is updated. If you need to update a copied function, you should\n  either update the base function and use `make fixup` to propagate the change to all copies, or simply remove the `# Copied from` comment if that is inappropriate.\n- \"Modular\" files. These files briefly define models by composing them using inheritance from other models. They are not meant to be used directly. Instead, the style tools\n  automatically generate a complete modeling file, like `modeling_bert.py`, from the modular file like `modular_bert.py`. If a model has a modular file, the modeling file\n  should never be edited directly! Instead, changes should be made in the modular file, and then you should run `make fixup` to update the modeling file automatically.\n\nWhen adding new models, you should prefer `modular` style and inherit as many classes as possible from existing models.\n\n## Testing\n\nAfter making changes, you should usually run `make fixup` to ensure any copies and modular files are updated, and then test all affected models. This includes both\nthe model you made the changes in and any other models that were updated by `make fixup`. Tests can be run with `pytest tests/models/[name]/test_modeling_[name].py`\nIf your changes affect code in other classes like tokenizers or processors, you should run those tests instead, like `test_processing_[name].py` or `test_tokenization_[name].py`.\n\nIn order to run tests, you may need to install dependencies. You can do this with `pip install -e .[testing]`. You will probably also need to `pip install torch accelerate` if your environment does not already have them.\n","isInternal":false,"tokens":774,"sizeBytes":3529},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":203},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":189},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/huggingface/transformers/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":182}],"systemPromptSnippet":"<yakaai_skills repo=\"huggingface/transformers\">\n<!-- File: AGENTS.md (Tokens: ~792 | Category: root-instruction) -->\n## Commands\n\n- `make style` — ruff format + lint (required for code style checks).\n- `make typing` — ty type checker and model structure rules.\n- `make fix-repo` — the `make style` fixes plus copies, modular conversions, doc TOCs, docstrings.\n- `make check-repo` — `make typing` plus consistency checks.\n- `RUN_SLOW=1 pytest ...` — many tests are marked slow and skipped in CI.\n\nRun `make style` (or `make fix-repo`) as the last step before opening a PR.\n\n## Local agent setup\n\nHosted review agents read this file via the root `AGENTS.md` / `CLAUDE.md` symlinks. Local agents wire their own assets: `make codex` (→ `.agents/`), `make claude` (→ `.claude/`).\n\n## Before opening a PR\n\n- Coordinate on the matching issue first. Do not open a PR for someone else's issue without explicit approval from its author or a maintainer in the thread; if approval is unclear, ask instead of drafting.\n- Check for overlapping work, and do not open a second PR for a fix already covered:\n\n  ```bash\n  gh issue view <issue_number> --repo huggingface/transformers --comments\n  gh pr list --repo huggingface/transformers --state open --search \"<issue_number> in:body\"\n  gh pr list --repo huggingface/transformers --state open --search \"<short area keywords>\"\n  ```\n\n  If your approach is materially different, say why a second PR is needed in the issue.\n- No one-off PRs for tiny edits (a single typo, an isolated lint fix). Mechanical cleanups are fine, but not as a first contribution.\n- First-time contributors should not submit agent-written PRs or issues — see `CONTRIBUTING.md` and the PR template. Code agents must warn users who are not already contributors, including the risk of being blocked.\n\n## Copies and modular models\n\nModel files in `src/transformers/models/` avoid inheriting from each other, so duplication is managed two ways — modular is the current one, copies are legacy:\n\n1. `# Copied from ...` marks a copied class or function. `make fix-repo` re-syncs it, so editing inside such a block is reverted — edit the source it copies from, or deliberately break the link. **Do not add new `# Copied from` statements**; write a modular file instead.\n2. A `modular_<name>.py` **may** inherit from other models; `make fix-repo` generates the standalone `modeling_*.py` and friends from it. Never edit a generated file when a modular one exists. Guide: [modular_transformers.md](../docs/source/en/modular_transformers.md).\n\nTwo modular traps:\n\n- **Other models inherit your modular file.** `modular_deepseek_vl.py` also generates `modeling_deepseek_vl_hybrid.py`. Run `make fix-repo` and check everything it rewrote; hand-editing only the generated file you had in mind leaves the rest stale and `Check repository consistency` red.\n- **`attr = AttributeError()` deletes an inherited attribute** — it is an instruction to the converter, not a bug or placeholder. `raise AttributeError(\"...\")` in a method body does the same for a method. Substituting a \"real\" value silently changes behaviour (`_no_split_modules = AttributeError()` → `[]` changes how the model may be sharded). See [Removing attributes](../docs/source/en/modular_transformers.md#removing-attributes) and [Deleting unused methods](../docs/source/en/modular_transformers.md#deleting-unused-methods).\n\n<!-- File: CLAUDE.md (Tokens: ~792 | Category: claude-rule) -->\n## Commands\n\n- `make style` — ruff format + lint (required for code style checks).\n- `make typing` — ty type checker and model structure rules.\n- `make fix-repo` — the `make style` fixes plus copies, modular conversions, doc TOCs, docstrings.\n- `make check-repo` — `make typing` plus consistency checks.\n- `RUN_SLOW=1 pytest ...` — many tests are marked slow and skipped in CI.\n\nRun `make style` (or `make fix-repo`) as the last step before opening a PR.\n\n## Local agent setup\n\nHosted review agents read this file via the root `AGENTS.md` / `CLAUDE.md` symlinks. Local agents wire their own assets: `make codex` (→ `.agents/`), `make claude` (→ `.claude/`).\n\n## Before opening a PR\n\n- Coordinate on the matching issue first. Do not open a PR for someone else's issue without explicit approval from its author or a maintainer in the thread; if approval is unclear, ask instead of drafting.\n- Check for overlapping work, and do not open a second PR for a fix already covered:\n\n  ```bash\n  gh issue view <issue_number> --repo huggingface/transformers --comments\n  gh pr list --repo huggingface/transformers --state open --search \"<issue_number> in:body\"\n  gh pr list --repo huggingface/transformers --state open --search \"<short area keywords>\"\n  ```\n\n  If your approach is materially different, say why a second PR is needed in the issue.\n- No one-off PRs for tiny edits (a single typo, an isolated lint fix). Mechanical cleanups are fine, but not as a first contribution.\n- First-time contributors should not submit agent-written PRs or issues — see `CONTRIBUTING.md` and the PR template. Code agents must warn users who are not already contributors, including the risk of being blocked.\n\n## Copies and modular models\n\nModel files in `src/transformers/models/` avoid inheriting from each other, so duplication is managed two ways — modular is the current one, copies are legacy:\n\n1. `# Copied from ...` marks a copied class or function. `make fix-repo` re-syncs it, so editing inside such a block is reverted — edit the source it copies from, or deliberately break the link. **Do not add new `# Copied from` statements**; write a modular file instead.\n2. A `modular_<name>.py` **may** inherit from other models; `make fix-repo` generates the standalone `modeling_*.py` and friends from it. Never edit a generated file when a modular one exists. Guide: [modular_transformers.md](../docs/source/en/modular_transformers.md).\n\nTwo modular traps:\n\n- **Other models inherit your modular file.** `modular_deepseek_vl.py` also generates `modeling_deepseek_vl_hybrid.py`. Run `make fix-repo` and check everything it rewrote; hand-editing only the generated file you had in mind leaves the rest stale and `Check repository consistency` red.\n- **`attr = AttributeError()` deletes an inherited attribute** — it is an instruction to the converter, not a bug or placeholder. `raise AttributeError(\"...\")` in a method body does the same for a method. Substituting a \"real\" value silently changes behaviour (`_no_split_modules = AttributeError()` → `[]` changes how the model may be sharded). See [Removing attributes](../docs/source/en/modular_transformers.md#removing-attributes) and [Deleting unused methods](../docs/source/en/modular_transformers.md#deleting-unused-methods).\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~774 | Category: copilot-instructions) -->\n# copilot-instructions.md Guide for Hugging Face Transformers\n\nThis copilot-instructions.md file provides guidance for code agents working with this codebase.\n\n## Core Project Structure\n\n- `/src/transformers`: This contains the core source code for the library\n  - `/models`: Code for individual models. Models inherit from base classes in the root `/src/transformers` directory.\n- `/tests`: This contains the core test classes for the library. These are usually inherited rather than directly run.\n  - `/models`: Tests for individual models. Model tests inherit from common tests in the root `/tests` directory.\n- `/docs`: This contains the documentation for the library, including guides, tutorials, and API references.\n\n## Coding Conventions for Hugging Face Transformers\n\n- PRs should be as brief as possible. Bugfix PRs in particular can often be only one or two lines long, and do not need large comments, docstrings or new functions in this case. Aim to minimize the size of the diff.\n- When writing tests, they should be added to an existing file. The only exception is for PRs to add a new model, when a new test directory should be created for that model.\n- Code style is enforced in the CI. You can install the style tools with `pip install -e .[quality]`. You can then run `make fixup` to apply style and consistency fixes to your code.\n\n## Copying and inheritance\n\nMany models in the codebase have similar code, but it is not shared by inheritance because we want each model file to be self-contained.\nWe use two mechanisms to keep this code in sync:\n\n- \"Copied from\" syntax. Functions or entire classes can have a comment at the top like this: `# Copied from transformers.models.llama.modeling_llama.rotate_half` or `# Copied from transformers.models.t5.modeling_t5.T5LayerNorm with T5->MT5`\n  These comments are actively checked by the style tools, and copies will automatically be updated when the base code is updated. If you need to update a copied function, you should\n  either update the base function and use `make fixup` to propagate the change to all copies, or simply remove the `# Copied from` comment if that is inappropriate.\n- \"Modular\" files. These files briefly define models by composing them using inheritance from other models. They are not meant to be used directly. Instead, the style tools\n  automatically generate a complete modeling file, like `modeling_bert.py`, from the modular file like `modular_bert.py`. If a model has a modular file, the modeling file\n  should never be edited directly! Instead, changes should be made in the modular file, and then you should run `make fixup` to update the modeling file automatically.\n\nWhen adding new models, you should prefer `modular` style and inherit as many classes as possible from existing models.\n\n## Testing\n\nAfter making changes, you should usually run `make fixup` to ensure any copies and modular files are updated, and then test all affected models. This includes both\nthe model you made the changes in and any other models that were updated by `make fixup`. Tests can be run with `pytest tests/models/[name]/test_modeling_[name].py`\nIf your changes affect code in other classes like tokenizers or processors, you should run those tests instead, like `test_processing_[name].py` or `test_tokenization_[name].py`.\n\nIn order to run tests, you may need to install dependencies. You can do this with `pip install -e .[testing]`. You will probably also need to `pip install torch accelerate` if your environment does not already have them.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/huggingface/transformers/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}