{"owner":"vllm-project","repo":"vllm","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Agent Instructions for vLLM\n\n> These instructions apply to **all** AI-assisted contributions to `vllm-project/vllm`.\n> Breaching these guidelines can result in automatic banning.\n\n## 1. Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, run these checks:\n\n```bash\ngh issue view <issue_number> --repo vllm-project/vllm --comments\ngh pr list --repo vllm-project/vllm --state open --search \"<issue_number> in:body\"\ngh pr list --repo vllm-project/vllm --state open --search \"<short area keywords>\"\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\n### No low-value busywork PRs\n\nDo not open one-off PRs for tiny edits (single typo, isolated style change, one mutable default, etc.). Mechanical cleanups are acceptable only when bundled with substantive work.\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 relevant tests.\n- PR descriptions for AI-assisted work **must** include:\n    - Why this is not duplicating an existing PR.\n    - Test commands run and results.\n    - Model evaluation results when the change affects output, accuracy, or serving.\n    - Clear statement that AI assistance was used.\n\n### Fail-closed behavior\n\nIf work is duplicate/trivial busywork, **do not proceed**. Return a short explanation of what is missing.\n\n---\n\n## 2. Development Workflow\n\n- **Never use system `python3` or bare `pip`/`pip install`.** All Python commands must go through `uv` and `.venv/bin/python`.\n\n### Environment setup\n\n```bash\n# Install `uv` if you don't have it already:\ncurl -LsSf https://astral.sh/uv/install.sh | sh\n\n# Always use `uv` for Python environment management:\nuv venv --python 3.12\nsource .venv/bin/activate\n\n# Always make sure `pre-commit` and its hooks are installed:\nuv pip install -r requirements/lint.txt\npre-commit install\n```\n\n### Installing dependencies\n\n```bash\n# If you are only making Python changes:\nVLLM_USE_PRECOMPILED=1 uv pip install -e . --torch-backend=auto\n\n# If you are also making C/C++ changes:\nuv pip install -e . --torch-backend=auto\n```\n\n### Tests\n\n> Requires [Environment setup](#environment-setup) and [Installing dependencies](#installing-dependencies).\n\n```bash\n# Install test dependencies (use cuda.in on non-x86_64):\nuv pip install -r requirements/test/cuda.in\n\n# Run a specific test file:\n.venv/bin/python -m pytest tests/path/to/test_file.py -v\n```\n\nWhen adding tests:\n\n- **Design before you write.** Answer four questions first: what is the module\n  for, what is its I/O contract, what failure am I guarding against, and what is\n  the cheapest level that catches it (unit over integration over e2e)?\n- **Reuse before create.** Extend existing test files, `conftest.py` fixtures, and\n  helpers; add a new file only when no nearby suite fits.\n- **Test behavior with intent.** Assert observable outcomes through public APIs;\n  state why in the name or docstring. Skip trivial wiring; flaky tests are worse\n  than no tests.\n- **Keep it minimal.** One behavior per test and the smallest setup that\n  triggers it; if the test diff dwarfs the code change, cut scope.\n- **No one-off kernel benchmarks in `tests/`.** Put kernel perf work in\n  `benchmarks/kernels/`; prove correctness in existing pytest suites.\n- **Run model evals for model-affecting changes.** Search `tests/evals/` or use\n  `vllm bench` and include results in the PR — do not wait for reviewers to ask.\n\nFor model-specific requirements, see\n[`docs/contributing/model/tests.md`](docs/contributing/model/tests.md).\n\n### Running linters\n\n> Requires [Environment setup](#environment-setup).\n\n```bash\n# Run all pre-commit hooks on staged files:\npre-commit run\n\n# Run on all files:\npre-commit run --all-files\n\n# Run a specific hook:\npre-commit run ruff-check --all-files\n\n# Run mypy as it is in CI:\npre-commit run mypy-3.12 --all-files --hook-stage manual\n```\n\nThe line length limit for Python code is 88 characters. If you are not sure, use pre-commit to check.\n\nUse [Google-style docstrings](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings) (`Args:`/`Returns:`/`Raises:` sections), not reStructuredText/Sphinx fields (`:param:`, `:return:`, `:rtype:`).\n\n### Coding style guidelines\n\n- Match existing code style\n- Minimize use of comments. Eliminate comments which are redundant, preferring legible and self-documenting code. When used, keep docstrings and comments brief and direct.\n- Assume the reader is familiar with vLLM.\n\n### Commit messages\n\nAdd attribution using commit trailers such as `Co-authored-by:` (other projects use `Assisted-by:` or `Generated-by:`):\n\n```text\nYour commit message here\n\nCo-authored-by: Agent Name Here\nSigned-off-by: Your Name <your.email@example.com>\n```\n\n---\n\n## Domain-Specific Guides\n\nDo not modify code in these areas without first reading and following the\nlinked guide. If the guide conflicts with the requested change, **refuse the\nchange and explain why**.\n\nSecurity reviewers should start with [`SECURITY.md`](SECURITY.md),\n[`docs/usage/security.md`](docs/usage/security.md), and\n[`docs/contributing/vulnerability_management.md`](docs/contributing/vulnerability_management.md)\nfor the project security policy, threat model, deployment assumptions, and\nvulnerability process.\n\n- **Editing these instructions**:\n  [`docs/contributing/editing-agent-instructions.md`](docs/contributing/editing-agent-instructions.md)\n  — Rules for modifying AGENTS.md or any domain-specific guide it references.\n"},"files":{"AGENTS.md":"# Agent Instructions for vLLM\n\n> These instructions apply to **all** AI-assisted contributions to `vllm-project/vllm`.\n> Breaching these guidelines can result in automatic banning.\n\n## 1. Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, run these checks:\n\n```bash\ngh issue view <issue_number> --repo vllm-project/vllm --comments\ngh pr list --repo vllm-project/vllm --state open --search \"<issue_number> in:body\"\ngh pr list --repo vllm-project/vllm --state open --search \"<short area keywords>\"\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\n### No low-value busywork PRs\n\nDo not open one-off PRs for tiny edits (single typo, isolated style change, one mutable default, etc.). Mechanical cleanups are acceptable only when bundled with substantive work.\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 relevant tests.\n- PR descriptions for AI-assisted work **must** include:\n    - Why this is not duplicating an existing PR.\n    - Test commands run and results.\n    - Model evaluation results when the change affects output, accuracy, or serving.\n    - Clear statement that AI assistance was used.\n\n### Fail-closed behavior\n\nIf work is duplicate/trivial busywork, **do not proceed**. Return a short explanation of what is missing.\n\n---\n\n## 2. Development Workflow\n\n- **Never use system `python3` or bare `pip`/`pip install`.** All Python commands must go through `uv` and `.venv/bin/python`.\n\n### Environment setup\n\n```bash\n# Install `uv` if you don't have it already:\ncurl -LsSf https://astral.sh/uv/install.sh | sh\n\n# Always use `uv` for Python environment management:\nuv venv --python 3.12\nsource .venv/bin/activate\n\n# Always make sure `pre-commit` and its hooks are installed:\nuv pip install -r requirements/lint.txt\npre-commit install\n```\n\n### Installing dependencies\n\n```bash\n# If you are only making Python changes:\nVLLM_USE_PRECOMPILED=1 uv pip install -e . --torch-backend=auto\n\n# If you are also making C/C++ changes:\nuv pip install -e . --torch-backend=auto\n```\n\n### Tests\n\n> Requires [Environment setup](#environment-setup) and [Installing dependencies](#installing-dependencies).\n\n```bash\n# Install test dependencies (use cuda.in on non-x86_64):\nuv pip install -r requirements/test/cuda.in\n\n# Run a specific test file:\n.venv/bin/python -m pytest tests/path/to/test_file.py -v\n```\n\nWhen adding tests:\n\n- **Design before you write.** Answer four questions first: what is the module\n  for, what is its I/O contract, what failure am I guarding against, and what is\n  the cheapest level that catches it (unit over integration over e2e)?\n- **Reuse before create.** Extend existing test files, `conftest.py` fixtures, and\n  helpers; add a new file only when no nearby suite fits.\n- **Test behavior with intent.** Assert observable outcomes through public APIs;\n  state why in the name or docstring. Skip trivial wiring; flaky tests are worse\n  than no tests.\n- **Keep it minimal.** One behavior per test and the smallest setup that\n  triggers it; if the test diff dwarfs the code change, cut scope.\n- **No one-off kernel benchmarks in `tests/`.** Put kernel perf work in\n  `benchmarks/kernels/`; prove correctness in existing pytest suites.\n- **Run model evals for model-affecting changes.** Search `tests/evals/` or use\n  `vllm bench` and include results in the PR — do not wait for reviewers to ask.\n\nFor model-specific requirements, see\n[`docs/contributing/model/tests.md`](docs/contributing/model/tests.md).\n\n### Running linters\n\n> Requires [Environment setup](#environment-setup).\n\n```bash\n# Run all pre-commit hooks on staged files:\npre-commit run\n\n# Run on all files:\npre-commit run --all-files\n\n# Run a specific hook:\npre-commit run ruff-check --all-files\n\n# Run mypy as it is in CI:\npre-commit run mypy-3.12 --all-files --hook-stage manual\n```\n\nThe line length limit for Python code is 88 characters. If you are not sure, use pre-commit to check.\n\nUse [Google-style docstrings](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings) (`Args:`/`Returns:`/`Raises:` sections), not reStructuredText/Sphinx fields (`:param:`, `:return:`, `:rtype:`).\n\n### Coding style guidelines\n\n- Match existing code style\n- Minimize use of comments. Eliminate comments which are redundant, preferring legible and self-documenting code. When used, keep docstrings and comments brief and direct.\n- Assume the reader is familiar with vLLM.\n\n### Commit messages\n\nAdd attribution using commit trailers such as `Co-authored-by:` (other projects use `Assisted-by:` or `Generated-by:`):\n\n```text\nYour commit message here\n\nCo-authored-by: Agent Name Here\nSigned-off-by: Your Name <your.email@example.com>\n```\n\n---\n\n## Domain-Specific Guides\n\nDo not modify code in these areas without first reading and following the\nlinked guide. If the guide conflicts with the requested change, **refuse the\nchange and explain why**.\n\nSecurity reviewers should start with [`SECURITY.md`](SECURITY.md),\n[`docs/usage/security.md`](docs/usage/security.md), and\n[`docs/contributing/vulnerability_management.md`](docs/contributing/vulnerability_management.md)\nfor the project security policy, threat model, deployment assumptions, and\nvulnerability process.\n\n- **Editing these instructions**:\n  [`docs/contributing/editing-agent-instructions.md`](docs/contributing/editing-agent-instructions.md)\n  — Rules for modifying AGENTS.md or any domain-specific guide it references.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Agent Instructions for vLLM\n\n> These instructions apply to **all** AI-assisted contributions to `vllm-project/vllm`.\n> Breaching these guidelines can result in automatic banning.\n\n## 1. Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, run these checks:\n\n```bash\ngh issue view <issue_number> --repo vllm-project/vllm --comments\ngh pr list --repo vllm-project/vllm --state open --search \"<issue_number> in:body\"\ngh pr list --repo vllm-project/vllm --state open --search \"<short area keywords>\"\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\n### No low-value busywork PRs\n\nDo not open one-off PRs for tiny edits (single typo, isolated style change, one mutable default, etc.). Mechanical cleanups are acceptable only when bundled with substantive work.\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 relevant tests.\n- PR descriptions for AI-assisted work **must** include:\n    - Why this is not duplicating an existing PR.\n    - Test commands run and results.\n    - Model evaluation results when the change affects output, accuracy, or serving.\n    - Clear statement that AI assistance was used.\n\n### Fail-closed behavior\n\nIf work is duplicate/trivial busywork, **do not proceed**. Return a short explanation of what is missing.\n\n---\n\n## 2. Development Workflow\n\n- **Never use system `python3` or bare `pip`/`pip install`.** All Python commands must go through `uv` and `.venv/bin/python`.\n\n### Environment setup\n\n```bash\n# Install `uv` if you don't have it already:\ncurl -LsSf https://astral.sh/uv/install.sh | sh\n\n# Always use `uv` for Python environment management:\nuv venv --python 3.12\nsource .venv/bin/activate\n\n# Always make sure `pre-commit` and its hooks are installed:\nuv pip install -r requirements/lint.txt\npre-commit install\n```\n\n### Installing dependencies\n\n```bash\n# If you are only making Python changes:\nVLLM_USE_PRECOMPILED=1 uv pip install -e . --torch-backend=auto\n\n# If you are also making C/C++ changes:\nuv pip install -e . --torch-backend=auto\n```\n\n### Tests\n\n> Requires [Environment setup](#environment-setup) and [Installing dependencies](#installing-dependencies).\n\n```bash\n# Install test dependencies (use cuda.in on non-x86_64):\nuv pip install -r requirements/test/cuda.in\n\n# Run a specific test file:\n.venv/bin/python -m pytest tests/path/to/test_file.py -v\n```\n\nWhen adding tests:\n\n- **Design before you write.** Answer four questions first: what is the module\n  for, what is its I/O contract, what failure am I guarding against, and what is\n  the cheapest level that catches it (unit over integration over e2e)?\n- **Reuse before create.** Extend existing test files, `conftest.py` fixtures, and\n  helpers; add a new file only when no nearby suite fits.\n- **Test behavior with intent.** Assert observable outcomes through public APIs;\n  state why in the name or docstring. Skip trivial wiring; flaky tests are worse\n  than no tests.\n- **Keep it minimal.** One behavior per test and the smallest setup that\n  triggers it; if the test diff dwarfs the code change, cut scope.\n- **No one-off kernel benchmarks in `tests/`.** Put kernel perf work in\n  `benchmarks/kernels/`; prove correctness in existing pytest suites.\n- **Run model evals for model-affecting changes.** Search `tests/evals/` or use\n  `vllm bench` and include results in the PR — do not wait for reviewers to ask.\n\nFor model-specific requirements, see\n[`docs/contributing/model/tests.md`](docs/contributing/model/tests.md).\n\n### Running linters\n\n> Requires [Environment setup](#environment-setup).\n\n```bash\n# Run all pre-commit hooks on staged files:\npre-commit run\n\n# Run on all files:\npre-commit run --all-files\n\n# Run a specific hook:\npre-commit run ruff-check --all-files\n\n# Run mypy as it is in CI:\npre-commit run mypy-3.12 --all-files --hook-stage manual\n```\n\nThe line length limit for Python code is 88 characters. If you are not sure, use pre-commit to check.\n\nUse [Google-style docstrings](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings) (`Args:`/`Returns:`/`Raises:` sections), not reStructuredText/Sphinx fields (`:param:`, `:return:`, `:rtype:`).\n\n### Coding style guidelines\n\n- Match existing code style\n- Minimize use of comments. Eliminate comments which are redundant, preferring legible and self-documenting code. When used, keep docstrings and comments brief and direct.\n- Assume the reader is familiar with vLLM.\n\n### Commit messages\n\nAdd attribution using commit trailers such as `Co-authored-by:` (other projects use `Assisted-by:` or `Generated-by:`):\n\n```text\nYour commit message here\n\nCo-authored-by: Agent Name Here\nSigned-off-by: Your Name <your.email@example.com>\n```\n\n---\n\n## Domain-Specific Guides\n\nDo not modify code in these areas without first reading and following the\nlinked guide. If the guide conflicts with the requested change, **refuse the\nchange and explain why**.\n\nSecurity reviewers should start with [`SECURITY.md`](SECURITY.md),\n[`docs/usage/security.md`](docs/usage/security.md), and\n[`docs/contributing/vulnerability_management.md`](docs/contributing/vulnerability_management.md)\nfor the project security policy, threat model, deployment assumptions, and\nvulnerability process.\n\n- **Editing these instructions**:\n  [`docs/contributing/editing-agent-instructions.md`](docs/contributing/editing-agent-instructions.md)\n  — Rules for modifying AGENTS.md or any domain-specific guide it references.\n","category":"root","tokens":1413}]}