{"owner":"deepspeedai","repo":"DeepSpeed","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":2278,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"DeepSpeed":{"command":"npx","args":["-y","@modelcontextprotocol/server-DeepSpeed"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# AGENTS.md — Workspace-level instructions for AI coding agents\n\n> These rules apply to **all** AI-assisted contributions to `deepspeedai/DeepSpeed`.\n\n## Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, run these checks:\n\n```bash\ngh issue view --repo deepspeedai/DeepSpeed --comments\ngh pr list --repo deepspeedai/DeepSpeed --state open --search \" in:body\"\ngh pr list --repo deepspeedai/DeepSpeed --state open --search \"\"\n```\n\n- If an open PR already addresses the same fix, do not open another.\n- If your approach is materially different, explain the difference in the issue.\n- DeepSpeed carries long-lived parallel implementations (ZeRO 1/2 vs 3, fp16 vs bf16 optimizers, per-accelerator op builders). Before fixing a bug in one, check whether the sibling paths share the defect, and state in the PR which ones you checked.\n\n### New features need an accepted proposal first\n\nPer [`CONTRIBUTING.md`](CONTRIBUTING.md#new-feature-contribution-guidelines), a new feature starts with a proposal issue -- description, motivation, rough design, and planned experiments -- that maintainers accept before implementation begins. Do not open a feature PR with no accepted proposal; open the proposal issue instead.\n\n### No low-value busywork PRs\n\nDo not open one-off PRs for tiny edits (a single typo, an isolated style change, a lone type annotation). Mechanical cleanups are acceptable only when bundled with substantive work in the same area. This is the PR-level form of the rule against cosmetic changes below.\n\n### Accountability\n\n- Pure code-agent PRs are **not allowed**. A human submitter must understand and defend the change end-to-end.\n- The submitting human must review every changed line and run the relevant tests.\n- `Signed-off-by` is a [DCO](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin) attestation made by a person, not by an agent. Never sign off on a diff that no human has read.\n- PR descriptions for AI-assisted work **must** include:\n - Why this does not duplicate an existing PR or issue.\n - Test commands run and their results, including the hardware they ran on: device model and count, accelerator/driver version, and torch version.\n - Convergence, throughput, and peak-memory results when the change affects numerics, performance, or memory -- see [`CONTRIBUTING.md`](CONTRIBUTING.md#step-1-proposal-and-discussion) for the evidence bar.\n - Which cells of the compatibility matrix (ZeRO stage, offload, precision, parallelism) were validated, and which were not.\n - A clear statement that AI assistance was used.\n- Before opening or reviewing a PR, work through the [`/pr-checklist`](.agents/skills/pr-checklist/SKILL.md) skill: design fit, accelerator portability, backward compatibility, on-device validation, diff hygiene, and PR contents.\n\n### Fail-closed behavior\n\nIf the work is duplicate, trivial busywork, or an unproposed new feature, **do not proceed**. Return a short explanation of what is missing.\n\n---\n\n## DeepSpeed Project Rules\n\n### Commit & CI requirements\n\n- When creating commits, use `git commit --signoff`.\n- DCO compliance is enforced by the required CI check; do not report commit-signoff findings in code reviews.\n- Formatting: yapf (column_limit=119, `.style.yapf`) + flake8 (`.flake8`).\n- Always verify changed files pass pre-commit checks before committing: `pre-commit run --files `. Only check modified files, not the entire codebase. Config: `.pre-commit-config.yaml`.\n- `check-torchdist` hook: NEVER directly import torch's distributed module. Use `import deepspeed.comm as dist` instead.\n- New source files (`.py`, `.c`/`.cpp`/`.cu`/`.h`, and the other extensions matched by the `check-license` hook) require license header:\n ```\n # SPDX-License-Identifier: Apache-2.0\n # DeepSpeed Team\n ```\n\n### Code change discipline\n\n- NEVER make cosmetic/formatting-only changes to existing code. Only add/modify lines that are functionally necessary. Minimizing diff noise is critical for code review.\n- Delete dead code decisively — if code is unused at runtime (only referenced in tests), remove it along with its tests.\n- Prefer consolidating tests over proliferating test files.\n- Blend in: when modifying code, read the surrounding context and match the style of neighboring code (naming, spacing, patterns, idioms).\n- Write beginner-friendly code: avoid deeply nested expressions or chained logic. Break complex expressions into clear, named intermediate steps.\n- Comments should explain **why**, not **what**. Describe the purpose and reasoning, not the mechanics that the code already shows.\n- New features must include corresponding tests and documentation updates.\n- All changes must not cause `import deepspeed` to initialize CUDA; Keep heavy imports (> 0.1s) out of `import deepspeed`; Avoid changing `deepspeed/__init__.py` unless necessary.\n\n### Test discipline\n\n- Tests verify contracts, not implementations: a test is well-formed only if a different correct implementation of the same contract passes it.\n- Before writing a test, name the concrete incorrect behavior it would catch; if you cannot name one, do not write it.\n- Assert on observable outcomes through public/stable interfaces; do not assert private method return values or exact internal strings unless pinning a specific fixed bug (justify in a comment).\n- Anchor to an external oracle or an independently derived reference instead of re-implementing the logic under test.\n- Mocks must stand in for a collaborator's documented contract (schema, protocol), never for internals of the module under test.\n- Changes that affect the external contract at the training-loop or inference level require integration tests, not just unit tests (e.g. a minimal training loop with `SimpleModel`).\n- Integration tests must be executed on actual devices, not merely written: report the execution hardware spec and results in the PR.\n\n## Tool Caveats\n\n### Edit tool auto-formatter\n\nThe Edit tool has a hidden auto-formatter that silently changes quotes, whitespace, blank lines, and line wrapping. For format-sensitive modifications (e.g., when exact formatting matters for pre-commit), use `bash` with `sed`, `python`, or `cat` instead.\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/deepspeedai/DeepSpeed/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/deepspeedai/DeepSpeed/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/deepspeedai/DeepSpeed/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# AGENTS.md — Workspace-level instructions for AI coding agents\n\n> These rules apply to **all** AI-assisted contributions to `deepspeedai/DeepSpeed`.\n\n## Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, run these checks:\n\n```bash\ngh issue view --repo deepspeedai/DeepSpeed --comments\ngh pr list --repo deepspeedai/DeepSpeed --state open --search \" in:body\"\ngh pr list --repo deepspeedai/DeepSpeed --state open --search \"\"\n```\n\n- If an open PR already addresses the same fix, do not open another.\n- If your approach is materially different, explain the difference in the issue.\n- DeepSpeed carries long-lived parallel implementations (ZeRO 1/2 vs 3, fp16 vs bf16 optimizers, per-accelerator op builders). Before fixing a bug in one, check whether the sibling paths share the defect, and state in the PR which ones you checked.\n\n### New features need an accepted proposal first\n\nPer [`CONTRIBUTING.md`](CONTRIBUTING.md#new-feature-contribution-guidelines), a new feature starts with a proposal issue -- description, motivation, rough design, and planned experiments -- that maintainers accept before implementation begins. Do not open a feature PR with no accepted proposal; open the proposal issue instead.\n\n### No low-value busywork PRs\n\nDo not open one-off PRs for tiny edits (a single typo, an isolated style change, a lone type annotation). Mechanical cleanups are acceptable only when bundled with substantive work in the same area. This is the PR-level form of the rule against cosmetic changes below.\n\n### Accountability\n\n- Pure code-agent PRs are **not allowed**. A human submitter must understand and defend the change end-to-end.\n- The submitting human must review every changed line and run the relevant tests.\n- `Signed-off-by` is a [DCO](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin) attestation made by a person, not by an agent. Never sign off on a diff that no human has read.\n- PR descriptions for AI-assisted work **must** include:\n - Why this does not duplicate an existing PR or issue.\n - Test commands run and their results, including the hardware they ran on: device model and count, accelerator/driver version, and torch version.\n - Convergence, throughput, and peak-memory results when the change affects numerics, performance, or memory -- see [`CONTRIBUTING.md`](CONTRIBUTING.md#step-1-proposal-and-discussion) for the evidence bar.\n - Which cells of the compatibility matrix (ZeRO stage, offload, precision, parallelism) were validated, and which were not.\n - A clear statement that AI assistance was used.\n- Before opening or reviewing a PR, work through the [`/pr-checklist`](.agents/skills/pr-checklist/SKILL.md) skill: design fit, accelerator portability, backward compatibility, on-device validation, diff hygiene, and PR contents.\n\n### Fail-closed behavior\n\nIf the work is duplicate, trivial busywork, or an unproposed new feature, **do not proceed**. Return a short explanation of what is missing.\n\n---\n\n## DeepSpeed Project Rules\n\n### Commit & CI requirements\n\n- When creating commits, use `git commit --signoff`.\n- DCO compliance is enforced by the required CI check; do not report commit-signoff findings in code reviews.\n- Formatting: yapf (column_limit=119, `.style.yapf`) + flake8 (`.flake8`).\n- Always verify changed files pass pre-commit checks before committing: `pre-commit run --files `. Only check modified files, not the entire codebase. Config: `.pre-commit-config.yaml`.\n- `check-torchdist` hook: NEVER directly import torch's distributed module. Use `import deepspeed.comm as dist` instead.\n- New source files (`.py`, `.c`/`.cpp`/`.cu`/`.h`, and the other extensions matched by the `check-license` hook) require license header:\n ```\n # SPDX-License-Identifier: Apache-2.0\n # DeepSpeed Team\n ```\n\n### Code change discipline\n\n- NEVER make cosmetic/formatting-only changes to existing code. Only add/modify lines that are functionally necessary. Minimizing diff noise is critical for code review.\n- Delete dead code decisively — if code is unused at runtime (only referenced in tests), remove it along with its tests.\n- Prefer consolidating tests over proliferating test files.\n- Blend in: when modifying code, read the surrounding context and match the style of neighboring code (naming, spacing, patterns, idioms).\n- Write beginner-friendly code: avoid deeply nested expressions or chained logic. Break complex expressions into clear, named intermediate steps.\n- Comments should explain **why**, not **what**. Describe the purpose and reasoning, not the mechanics that the code already shows.\n- New features must include corresponding tests and documentation updates.\n- All changes must not cause `import deepspeed` to initialize CUDA; Keep heavy imports (> 0.1s) out of `import deepspeed`; Avoid changing `deepspeed/__init__.py` unless necessary.\n\n### Test discipline\n\n- Tests verify contracts, not implementations: a test is well-formed only if a different correct implementation of the same contract passes it.\n- Before writing a test, name the concrete incorrect behavior it would catch; if you cannot name one, do not write it.\n- Assert on observable outcomes through public/stable interfaces; do not assert private method return values or exact internal strings unless pinning a specific fixed bug (justify in a comment).\n- Anchor to an external oracle or an independently derived reference instead of re-implementing the logic under test.\n- Mocks must stand in for a collaborator's documented contract (schema, protocol), never for internals of the module under test.\n- Changes that affect the external contract at the training-loop or inference level require integration tests, not just unit tests (e.g. a minimal training loop with `SimpleModel`).\n- Integration tests must be executed on actual devices, not merely written: report the execution hardware spec and results in the PR.\n\n## Tool Caveats\n\n### Edit tool auto-formatter\n\nThe Edit tool has a hidden auto-formatter that silently changes quotes, whitespace, blank lines, and line wrapping. For format-sensitive modifications (e.g., when exact formatting matters for pre-commit), use `bash` with `sed`, `python`, or `cat` instead.\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/deepspeedai/DeepSpeed/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/deepspeedai/DeepSpeed/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/deepspeedai/DeepSpeed/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deepspeedai/DeepSpeed/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md — Workspace-level instructions for AI coding agents\n\n> These rules apply to **all** AI-assisted contributions to `deepspeedai/DeepSpeed`.\n\n## Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, run these checks:\n\n```bash\ngh issue view --repo deepspeedai/DeepSpeed --comments\ngh pr list --repo deepspeedai/DeepSpeed --state open --search \" in:body\"\ngh pr list --repo deepspeedai/DeepSpeed --state open --search \"\"\n```\n\n- If an open PR already addresses the same fix, do not open another.\n- If your approach is materially different, explain the difference in the issue.\n- DeepSpeed carries long-lived parallel implementations (ZeRO 1/2 vs 3, fp16 vs bf16 optimizers, per-accelerator op builders). Before fixing a bug in one, check whether the sibling paths share the defect, and state in the PR which ones you checked.\n\n### New features need an accepted proposal first\n\nPer [`CONTRIBUTING.md`](CONTRIBUTING.md#new-feature-contribution-guidelines), a new feature starts with a proposal issue -- description, motivation, rough design, and planned experiments -- that maintainers accept before implementation begins. Do not open a feature PR with no accepted proposal; open the proposal issue instead.\n\n### No low-value busywork PRs\n\nDo not open one-off PRs for tiny edits (a single typo, an isolated style change, a lone type annotation). Mechanical cleanups are acceptable only when bundled with substantive work in the same area. This is the PR-level form of the rule against cosmetic changes below.\n\n### Accountability\n\n- Pure code-agent PRs are **not allowed**. A human submitter must understand and defend the change end-to-end.\n- The submitting human must review every changed line and run the relevant tests.\n- `Signed-off-by` is a [DCO](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin) attestation made by a person, not by an agent. Never sign off on a diff that no human has read.\n- PR descriptions for AI-assisted work **must** include:\n - Why this does not duplicate an existing PR or issue.\n - Test commands run and their results, including the hardware they ran on: device model and count, accelerator/driver version, and torch version.\n - Convergence, throughput, and peak-memory results when the change affects numerics, performance, or memory -- see [`CONTRIBUTING.md`](CONTRIBUTING.md#step-1-proposal-and-discussion) for the evidence bar.\n - Which cells of the compatibility matrix (ZeRO stage, offload, precision, parallelism) were validated, and which were not.\n - A clear statement that AI assistance was used.\n- Before opening or reviewing a PR, work through the [`/pr-checklist`](.agents/skills/pr-checklist/SKILL.md) skill: design fit, accelerator portability, backward compatibility, on-device validation, diff hygiene, and PR contents.\n\n### Fail-closed behavior\n\nIf the work is duplicate, trivial busywork, or an unproposed new feature, **do not proceed**. Return a short explanation of what is missing.\n\n---\n\n## DeepSpeed Project Rules\n\n### Commit & CI requirements\n\n- When creating commits, use `git commit --signoff`.\n- DCO compliance is enforced by the required CI check; do not report commit-signoff findings in code reviews.\n- Formatting: yapf (column_limit=119, `.style.yapf`) + flake8 (`.flake8`).\n- Always verify changed files pass pre-commit checks before committing: `pre-commit run --files `. Only check modified files, not the entire codebase. Config: `.pre-commit-config.yaml`.\n- `check-torchdist` hook: NEVER directly import torch's distributed module. Use `import deepspeed.comm as dist` instead.\n- New source files (`.py`, `.c`/`.cpp`/`.cu`/`.h`, and the other extensions matched by the `check-license` hook) require license header:\n ```\n # SPDX-License-Identifier: Apache-2.0\n # DeepSpeed Team\n ```\n\n### Code change discipline\n\n- NEVER make cosmetic/formatting-only changes to existing code. Only add/modify lines that are functionally necessary. Minimizing diff noise is critical for code review.\n- Delete dead code decisively — if code is unused at runtime (only referenced in tests), remove it along with its tests.\n- Prefer consolidating tests over proliferating test files.\n- Blend in: when modifying code, read the surrounding context and match the style of neighboring code (naming, spacing, patterns, idioms).\n- Write beginner-friendly code: avoid deeply nested expressions or chained logic. Break complex expressions into clear, named intermediate steps.\n- Comments should explain **why**, not **what**. Describe the purpose and reasoning, not the mechanics that the code already shows.\n- New features must include corresponding tests and documentation updates.\n- All changes must not cause `import deepspeed` to initialize CUDA; Keep heavy imports (> 0.1s) out of `import deepspeed`; Avoid changing `deepspeed/__init__.py` unless necessary.\n\n### Test discipline\n\n- Tests verify contracts, not implementations: a test is well-formed only if a different correct implementation of the same contract passes it.\n- Before writing a test, name the concrete incorrect behavior it would catch; if you cannot name one, do not write it.\n- Assert on observable outcomes through public/stable interfaces; do not assert private method return values or exact internal strings unless pinning a specific fixed bug (justify in a comment).\n- Anchor to an external oracle or an independently derived reference instead of re-implementing the logic under test.\n- Mocks must stand in for a collaborator's documented contract (schema, protocol), never for internals of the module under test.\n- Changes that affect the external contract at the training-loop or inference level require integration tests, not just unit tests (e.g. a minimal training loop with `SimpleModel`).\n- Integration tests must be executed on actual devices, not merely written: report the execution hardware spec and results in the PR.\n\n## Tool Caveats\n\n### Edit tool auto-formatter\n\nThe Edit tool has a hidden auto-formatter that silently changes quotes, whitespace, blank lines, and line wrapping. For format-sensitive modifications (e.g., when exact formatting matters for pre-commit), use `bash` with `sed`, `python`, or `cat` instead.\n","isInternal":false,"tokens":1378,"sizeBytes":6282},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/deepspeedai/DeepSpeed/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/deepspeedai/DeepSpeed/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":200},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/deepspeedai/DeepSpeed/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/deepspeedai/DeepSpeed/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":186},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/deepspeedai/DeepSpeed/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/deepspeedai/DeepSpeed/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":179}],"systemPromptSnippet":"\n\n# AGENTS.md — Workspace-level instructions for AI coding agents\n\n> These rules apply to **all** AI-assisted contributions to `deepspeedai/DeepSpeed`.\n\n## Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, run these checks:\n\n```bash\ngh issue view --repo deepspeedai/DeepSpeed --comments\ngh pr list --repo deepspeedai/DeepSpeed --state open --search \" in:body\"\ngh pr list --repo deepspeedai/DeepSpeed --state open --search \"\"\n```\n\n- If an open PR already addresses the same fix, do not open another.\n- If your approach is materially different, explain the difference in the issue.\n- DeepSpeed carries long-lived parallel implementations (ZeRO 1/2 vs 3, fp16 vs bf16 optimizers, per-accelerator op builders). Before fixing a bug in one, check whether the sibling paths share the defect, and state in the PR which ones you checked.\n\n### New features need an accepted proposal first\n\nPer [`CONTRIBUTING.md`](CONTRIBUTING.md#new-feature-contribution-guidelines), a new feature starts with a proposal issue -- description, motivation, rough design, and planned experiments -- that maintainers accept before implementation begins. Do not open a feature PR with no accepted proposal; open the proposal issue instead.\n\n### No low-value busywork PRs\n\nDo not open one-off PRs for tiny edits (a single typo, an isolated style change, a lone type annotation). Mechanical cleanups are acceptable only when bundled with substantive work in the same area. This is the PR-level form of the rule against cosmetic changes below.\n\n### Accountability\n\n- Pure code-agent PRs are **not allowed**. A human submitter must understand and defend the change end-to-end.\n- The submitting human must review every changed line and run the relevant tests.\n- `Signed-off-by` is a [DCO](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin) attestation made by a person, not by an agent. Never sign off on a diff that no human has read.\n- PR descriptions for AI-assisted work **must** include:\n - Why this does not duplicate an existing PR or issue.\n - Test commands run and their results, including the hardware they ran on: device model and count, accelerator/driver version, and torch version.\n - Convergence, throughput, and peak-memory results when the change affects numerics, performance, or memory -- see [`CONTRIBUTING.md`](CONTRIBUTING.md#step-1-proposal-and-discussion) for the evidence bar.\n - Which cells of the compatibility matrix (ZeRO stage, offload, precision, parallelism) were validated, and which were not.\n - A clear statement that AI assistance was used.\n- Before opening or reviewing a PR, work through the [`/pr-checklist`](.agents/skills/pr-checklist/SKILL.md) skill: design fit, accelerator portability, backward compatibility, on-device validation, diff hygiene, and PR contents.\n\n### Fail-closed behavior\n\nIf the work is duplicate, trivial busywork, or an unproposed new feature, **do not proceed**. Return a short explanation of what is missing.\n\n---\n\n## DeepSpeed Project Rules\n\n### Commit & CI requirements\n\n- When creating commits, use `git commit --signoff`.\n- DCO compliance is enforced by the required CI check; do not report commit-signoff findings in code reviews.\n- Formatting: yapf (column_limit=119, `.style.yapf`) + flake8 (`.flake8`).\n- Always verify changed files pass pre-commit checks before committing: `pre-commit run --files `. Only check modified files, not the entire codebase. Config: `.pre-commit-config.yaml`.\n- `check-torchdist` hook: NEVER directly import torch's distributed module. Use `import deepspeed.comm as dist` instead.\n- New source files (`.py`, `.c`/`.cpp`/`.cu`/`.h`, and the other extensions matched by the `check-license` hook) require license header:\n ```\n # SPDX-License-Identifier: Apache-2.0\n # DeepSpeed Team\n ```\n\n### Code change discipline\n\n- NEVER make cosmetic/formatting-only changes to existing code. Only add/modify lines that are functionally necessary. Minimizing diff noise is critical for code review.\n- Delete dead code decisively — if code is unused at runtime (only referenced in tests), remove it along with its tests.\n- Prefer consolidating tests over proliferating test files.\n- Blend in: when modifying code, read the surrounding context and match the style of neighboring code (naming, spacing, patterns, idioms).\n- Write beginner-friendly code: avoid deeply nested expressions or chained logic. Break complex expressions into clear, named intermediate steps.\n- Comments should explain **why**, not **what**. Describe the purpose and reasoning, not the mechanics that the code already shows.\n- New features must include corresponding tests and documentation updates.\n- All changes must not cause `import deepspeed` to initialize CUDA; Keep heavy imports (> 0.1s) out of `import deepspeed`; Avoid changing `deepspeed/__init__.py` unless necessary.\n\n### Test discipline\n\n- Tests verify contracts, not implementations: a test is well-formed only if a different correct implementation of the same contract passes it.\n- Before writing a test, name the concrete incorrect behavior it would catch; if you cannot name one, do not write it.\n- Assert on observable outcomes through public/stable interfaces; do not assert private method return values or exact internal strings unless pinning a specific fixed bug (justify in a comment).\n- Anchor to an external oracle or an independently derived reference instead of re-implementing the logic under test.\n- Mocks must stand in for a collaborator's documented contract (schema, protocol), never for internals of the module under test.\n- Changes that affect the external contract at the training-loop or inference level require integration tests, not just unit tests (e.g. a minimal training loop with `SimpleModel`).\n- Integration tests must be executed on actual devices, not merely written: report the execution hardware spec and results in the PR.\n\n## Tool Caveats\n\n### Edit tool auto-formatter\n\nThe Edit tool has a hidden auto-formatter that silently changes quotes, whitespace, blank lines, and line wrapping. For format-sensitive modifications (e.g., when exact formatting matters for pre-commit), use `bash` with `sed`, `python`, or `cat` instead.\n\n\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deepspeedai/DeepSpeed/HEAD/.claude-plugin/marketplace.json)\n\n\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deepspeedai/DeepSpeed/HEAD/.claude-plugin/plugin.json)\n\n\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deepspeedai/DeepSpeed/HEAD/.cursor/mcp.json)\n"}