{"owner":"verl-project","repo":"verl","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":1540,"categories":["anthropic-skill","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":[".agent/skills/pr/SKILL.md",".agent/skills/issue/SKILL.md","AGENTS.md"],"skills":{".agent/skills/pr/SKILL.md":"---\nname: pr\ndescription: Create or update a pull request following verl project conventions.\nuser_invocable: true\n---\n\nWhen the user asks to create or update a PR, follow these steps:\n\n### 1. Gather Context\n\nRead the following and understand the current branch's changes compared to main:\n\n- [`CONTRIBUTING.md`](CONTRIBUTING.md)\n- [`PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md)\n\nIf a PR already exists for this branch, also read its current title, body, and review comments.\n\n### 2. Compose PR Title and Body\n\nFollow the PR template strictly for both title format and body sections. Only check checklist boxes for steps that have actually been completed.\n\nWhen updating, ensure the title and body still accurately reflect **all** changes on the branch, not just the latest commit.\n\nWrite the body as GitHub-flavored Markdown, not fixed-width plain text. Keep each paragraph and each list item on a single logical line and separate blocks with blank lines. Do not hard-wrap running prose at a column limit: GitHub renders a single newline inside a paragraph or list item as a space, so a manually wrapped sentence turns into unintended mid-sentence breaks in the rendered PR. Watch two easy-to-miss cases: a wrapped line whose continuation starts with `#<number>` (e.g. an issue reference like `#7060`) reads as a heading in the source and is easy to leave split, and list-item continuations that are indented but should still join their item. Let the editor soft-wrap; only insert a newline to start a new paragraph, list item, table row, or fenced code block. Before submitting, re-read the body (or the round-tripped version fetched back from GitHub) and confirm no paragraph or list item is split across multiple source lines.\n\n### 3. Pre-submit Checks\n\nRun pre-commit and fix any issues before creating or pushing.\n\n### 4. Create or Update the PR\n\n- **Create**: target `main` by default unless the user specifies otherwise.\n- **Update**: push new commits and update the title and body if the scope has changed. **Read the current PR title and body first** and incorporate any edits the user may have made directly on GitHub — never overwrite with a version generated from scratch.\n\nReturn the PR URL when done.\n",".agent/skills/issue/SKILL.md":"---\nname: issue\ndescription: Create or update a GitHub issue following verl project conventions.\nuser_invocable: true\n---\n\nWhen the user asks to create or update an issue, follow these steps:\n\n### 1. Gather Context\n\nRead the following to understand available issue types and their required fields:\n\n- [`bug-report.yml`](.github/ISSUE_TEMPLATE/bug-report.yml)\n- [`feature-request.yml`](.github/ISSUE_TEMPLATE/feature-request.yml)\n\nIf updating an existing issue, read its current title, body, labels, and comments first.\n\n### 2. Determine Issue Type\n\nBased on the user's description, select the appropriate template:\n\n- **Bug report** ([`bug-report.yml`](.github/ISSUE_TEMPLATE/bug-report.yml)) — something is broken or behaves unexpectedly\n- **Feature request** ([`feature-request.yml`](.github/ISSUE_TEMPLATE/feature-request.yml)) — a new capability or enhancement\n- **Blank issue** — if neither template fits\n\n### 3. Compose the Issue\n\nFill in the template fields based on information from the user and the codebase. For bug reports, run `python scripts/diagnose.py` to gather system info if possible.\n\nWhen updating, ensure the title and body still accurately reflect the current state of the issue.\n\n### 4. Check for Duplicates\n\nSearch for existing issues before creating:\n\n```\ngh issue list --repo verl-project/verl --state open --search \"<keywords>\"\n```\n\nIf a duplicate exists, inform the user instead of creating a new one.\n\n### 5. Create or Update the Issue\n\n- **Create**: add `good first issue` and/or `call for contribution` labels if the issue is straightforward and suitable for new contributors.\n- **Update**: update title, body, and labels as needed.\n\nReturn the issue URL when done.\n","AGENTS.md":"# Agent Instructions for verl\n\n> These instructions apply to **all** AI-assisted contributions to `verl-project/verl`.\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 verl-project/verl --comments\ngh pr list --repo verl-project/verl --state open --search \"<issue_number> in:body\"\ngh pr list --repo verl-project/verl --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  - 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### 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\nuv pip install pre-commit hydra-core\npre-commit install\n```\n\n### Commit messages\n\nAdd attribution using commit trailers such as `Co-authored-by:` (other projects use `Assisted-by:` or `Generated-by:`). For example:\n\n```text\nYour commit message here\n\nCo-authored-by: GitHub Copilot\nCo-authored-by: Claude\nCo-authored-by: gemini-code-assist\nSigned-off-by: Your Name <your.email@example.com>\n```\n\n### Resolving agent reviews\n\nReview comments from agent bots (e.g., gemini-code-assist) can be outdated or wrong. Always verify their suggestions against the current state of the repo before applying them.\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\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\n## Acknowledgements\n\nAdapted from the [vLLM project](https://github.com/vllm-project/vllm)'s [`AGENTS.md`](https://github.com/vllm-project/vllm/blob/main/AGENTS.md).\n"},"files":{".agent/skills/pr/SKILL.md":"---\nname: pr\ndescription: Create or update a pull request following verl project conventions.\nuser_invocable: true\n---\n\nWhen the user asks to create or update a PR, follow these steps:\n\n### 1. Gather Context\n\nRead the following and understand the current branch's changes compared to main:\n\n- [`CONTRIBUTING.md`](CONTRIBUTING.md)\n- [`PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md)\n\nIf a PR already exists for this branch, also read its current title, body, and review comments.\n\n### 2. Compose PR Title and Body\n\nFollow the PR template strictly for both title format and body sections. Only check checklist boxes for steps that have actually been completed.\n\nWhen updating, ensure the title and body still accurately reflect **all** changes on the branch, not just the latest commit.\n\nWrite the body as GitHub-flavored Markdown, not fixed-width plain text. Keep each paragraph and each list item on a single logical line and separate blocks with blank lines. Do not hard-wrap running prose at a column limit: GitHub renders a single newline inside a paragraph or list item as a space, so a manually wrapped sentence turns into unintended mid-sentence breaks in the rendered PR. Watch two easy-to-miss cases: a wrapped line whose continuation starts with `#<number>` (e.g. an issue reference like `#7060`) reads as a heading in the source and is easy to leave split, and list-item continuations that are indented but should still join their item. Let the editor soft-wrap; only insert a newline to start a new paragraph, list item, table row, or fenced code block. Before submitting, re-read the body (or the round-tripped version fetched back from GitHub) and confirm no paragraph or list item is split across multiple source lines.\n\n### 3. Pre-submit Checks\n\nRun pre-commit and fix any issues before creating or pushing.\n\n### 4. Create or Update the PR\n\n- **Create**: target `main` by default unless the user specifies otherwise.\n- **Update**: push new commits and update the title and body if the scope has changed. **Read the current PR title and body first** and incorporate any edits the user may have made directly on GitHub — never overwrite with a version generated from scratch.\n\nReturn the PR URL when done.\n",".agent/skills/issue/SKILL.md":"---\nname: issue\ndescription: Create or update a GitHub issue following verl project conventions.\nuser_invocable: true\n---\n\nWhen the user asks to create or update an issue, follow these steps:\n\n### 1. Gather Context\n\nRead the following to understand available issue types and their required fields:\n\n- [`bug-report.yml`](.github/ISSUE_TEMPLATE/bug-report.yml)\n- [`feature-request.yml`](.github/ISSUE_TEMPLATE/feature-request.yml)\n\nIf updating an existing issue, read its current title, body, labels, and comments first.\n\n### 2. Determine Issue Type\n\nBased on the user's description, select the appropriate template:\n\n- **Bug report** ([`bug-report.yml`](.github/ISSUE_TEMPLATE/bug-report.yml)) — something is broken or behaves unexpectedly\n- **Feature request** ([`feature-request.yml`](.github/ISSUE_TEMPLATE/feature-request.yml)) — a new capability or enhancement\n- **Blank issue** — if neither template fits\n\n### 3. Compose the Issue\n\nFill in the template fields based on information from the user and the codebase. For bug reports, run `python scripts/diagnose.py` to gather system info if possible.\n\nWhen updating, ensure the title and body still accurately reflect the current state of the issue.\n\n### 4. Check for Duplicates\n\nSearch for existing issues before creating:\n\n```\ngh issue list --repo verl-project/verl --state open --search \"<keywords>\"\n```\n\nIf a duplicate exists, inform the user instead of creating a new one.\n\n### 5. Create or Update the Issue\n\n- **Create**: add `good first issue` and/or `call for contribution` labels if the issue is straightforward and suitable for new contributors.\n- **Update**: update title, body, and labels as needed.\n\nReturn the issue URL when done.\n","AGENTS.md":"# Agent Instructions for verl\n\n> These instructions apply to **all** AI-assisted contributions to `verl-project/verl`.\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 verl-project/verl --comments\ngh pr list --repo verl-project/verl --state open --search \"<issue_number> in:body\"\ngh pr list --repo verl-project/verl --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  - 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### 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\nuv pip install pre-commit hydra-core\npre-commit install\n```\n\n### Commit messages\n\nAdd attribution using commit trailers such as `Co-authored-by:` (other projects use `Assisted-by:` or `Generated-by:`). For example:\n\n```text\nYour commit message here\n\nCo-authored-by: GitHub Copilot\nCo-authored-by: Claude\nCo-authored-by: gemini-code-assist\nSigned-off-by: Your Name <your.email@example.com>\n```\n\n### Resolving agent reviews\n\nReview comments from agent bots (e.g., gemini-code-assist) can be outdated or wrong. Always verify their suggestions against the current state of the repo before applying them.\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\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\n## Acknowledgements\n\nAdapted from the [vLLM project](https://github.com/vllm-project/vllm)'s [`AGENTS.md`](https://github.com/vllm-project/vllm/blob/main/AGENTS.md).\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/verl-project/verl/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent Instructions for verl\n\n> These instructions apply to **all** AI-assisted contributions to `verl-project/verl`.\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 verl-project/verl --comments\ngh pr list --repo verl-project/verl --state open --search \"<issue_number> in:body\"\ngh pr list --repo verl-project/verl --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  - 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### 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\nuv pip install pre-commit hydra-core\npre-commit install\n```\n\n### Commit messages\n\nAdd attribution using commit trailers such as `Co-authored-by:` (other projects use `Assisted-by:` or `Generated-by:`). For example:\n\n```text\nYour commit message here\n\nCo-authored-by: GitHub Copilot\nCo-authored-by: Claude\nCo-authored-by: gemini-code-assist\nSigned-off-by: Your Name <your.email@example.com>\n```\n\n### Resolving agent reviews\n\nReview comments from agent bots (e.g., gemini-code-assist) can be outdated or wrong. Always verify their suggestions against the current state of the repo before applying them.\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\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\n## Acknowledgements\n\nAdapted from the [vLLM project](https://github.com/vllm-project/vllm)'s [`AGENTS.md`](https://github.com/vllm-project/vllm/blob/main/AGENTS.md).\n","isInternal":false,"tokens":678,"sizeBytes":2883},{"name":"SKILL.md","path":".agent/skills/issue/SKILL.md","rawUrl":"https://raw.githubusercontent.com/verl-project/verl/HEAD/.agent/skills/issue/SKILL.md","title":"issue","category":"anthropic-skill","format":"markdown","content":"---\nname: issue\ndescription: Create or update a GitHub issue following verl project conventions.\nuser_invocable: true\n---\n\nWhen the user asks to create or update an issue, follow these steps:\n\n### 1. Gather Context\n\nRead the following to understand available issue types and their required fields:\n\n- [`bug-report.yml`](.github/ISSUE_TEMPLATE/bug-report.yml)\n- [`feature-request.yml`](.github/ISSUE_TEMPLATE/feature-request.yml)\n\nIf updating an existing issue, read its current title, body, labels, and comments first.\n\n### 2. Determine Issue Type\n\nBased on the user's description, select the appropriate template:\n\n- **Bug report** ([`bug-report.yml`](.github/ISSUE_TEMPLATE/bug-report.yml)) — something is broken or behaves unexpectedly\n- **Feature request** ([`feature-request.yml`](.github/ISSUE_TEMPLATE/feature-request.yml)) — a new capability or enhancement\n- **Blank issue** — if neither template fits\n\n### 3. Compose the Issue\n\nFill in the template fields based on information from the user and the codebase. For bug reports, run `python scripts/diagnose.py` to gather system info if possible.\n\nWhen updating, ensure the title and body still accurately reflect the current state of the issue.\n\n### 4. Check for Duplicates\n\nSearch for existing issues before creating:\n\n```\ngh issue list --repo verl-project/verl --state open --search \"<keywords>\"\n```\n\nIf a duplicate exists, inform the user instead of creating a new one.\n\n### 5. Create or Update the Issue\n\n- **Create**: add `good first issue` and/or `call for contribution` labels if the issue is straightforward and suitable for new contributors.\n- **Update**: update title, body, and labels as needed.\n\nReturn the issue URL when done.\n","frontmatter":{"name":"issue","description":"Create or update a GitHub issue following verl project conventions.","user_invocable":true},"isInternal":false,"tokens":383,"sizeBytes":1703},{"name":"SKILL.md","path":".agent/skills/pr/SKILL.md","rawUrl":"https://raw.githubusercontent.com/verl-project/verl/HEAD/.agent/skills/pr/SKILL.md","title":"pr","category":"anthropic-skill","format":"markdown","content":"---\nname: pr\ndescription: Create or update a pull request following verl project conventions.\nuser_invocable: true\n---\n\nWhen the user asks to create or update a PR, follow these steps:\n\n### 1. Gather Context\n\nRead the following and understand the current branch's changes compared to main:\n\n- [`CONTRIBUTING.md`](CONTRIBUTING.md)\n- [`PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md)\n\nIf a PR already exists for this branch, also read its current title, body, and review comments.\n\n### 2. Compose PR Title and Body\n\nFollow the PR template strictly for both title format and body sections. Only check checklist boxes for steps that have actually been completed.\n\nWhen updating, ensure the title and body still accurately reflect **all** changes on the branch, not just the latest commit.\n\nWrite the body as GitHub-flavored Markdown, not fixed-width plain text. Keep each paragraph and each list item on a single logical line and separate blocks with blank lines. Do not hard-wrap running prose at a column limit: GitHub renders a single newline inside a paragraph or list item as a space, so a manually wrapped sentence turns into unintended mid-sentence breaks in the rendered PR. Watch two easy-to-miss cases: a wrapped line whose continuation starts with `#<number>` (e.g. an issue reference like `#7060`) reads as a heading in the source and is easy to leave split, and list-item continuations that are indented but should still join their item. Let the editor soft-wrap; only insert a newline to start a new paragraph, list item, table row, or fenced code block. Before submitting, re-read the body (or the round-tripped version fetched back from GitHub) and confirm no paragraph or list item is split across multiple source lines.\n\n### 3. Pre-submit Checks\n\nRun pre-commit and fix any issues before creating or pushing.\n\n### 4. Create or Update the PR\n\n- **Create**: target `main` by default unless the user specifies otherwise.\n- **Update**: push new commits and update the title and body if the scope has changed. **Read the current PR title and body first** and incorporate any edits the user may have made directly on GitHub — never overwrite with a version generated from scratch.\n\nReturn the PR URL when done.\n","frontmatter":{"name":"pr","description":"Create or update a pull request following verl project conventions.","user_invocable":true},"isInternal":false,"tokens":479,"sizeBytes":2234}],"systemPromptSnippet":"<yakaai_skills repo=\"verl-project/verl\">\n<!-- File: AGENTS.md (Tokens: ~678 | Category: root-instruction) -->\n# Agent Instructions for verl\n\n> These instructions apply to **all** AI-assisted contributions to `verl-project/verl`.\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 verl-project/verl --comments\ngh pr list --repo verl-project/verl --state open --search \"<issue_number> in:body\"\ngh pr list --repo verl-project/verl --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  - 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### 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\nuv pip install pre-commit hydra-core\npre-commit install\n```\n\n### Commit messages\n\nAdd attribution using commit trailers such as `Co-authored-by:` (other projects use `Assisted-by:` or `Generated-by:`). For example:\n\n```text\nYour commit message here\n\nCo-authored-by: GitHub Copilot\nCo-authored-by: Claude\nCo-authored-by: gemini-code-assist\nSigned-off-by: Your Name <your.email@example.com>\n```\n\n### Resolving agent reviews\n\nReview comments from agent bots (e.g., gemini-code-assist) can be outdated or wrong. Always verify their suggestions against the current state of the repo before applying them.\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\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\n## Acknowledgements\n\nAdapted from the [vLLM project](https://github.com/vllm-project/vllm)'s [`AGENTS.md`](https://github.com/vllm-project/vllm/blob/main/AGENTS.md).\n\n<!-- File: .agent/skills/issue/SKILL.md (Tokens: ~383 | Category: anthropic-skill) -->\n---\nname: issue\ndescription: Create or update a GitHub issue following verl project conventions.\nuser_invocable: true\n---\n\nWhen the user asks to create or update an issue, follow these steps:\n\n### 1. Gather Context\n\nRead the following to understand available issue types and their required fields:\n\n- [`bug-report.yml`](.github/ISSUE_TEMPLATE/bug-report.yml)\n- [`feature-request.yml`](.github/ISSUE_TEMPLATE/feature-request.yml)\n\nIf updating an existing issue, read its current title, body, labels, and comments first.\n\n### 2. Determine Issue Type\n\nBased on the user's description, select the appropriate template:\n\n- **Bug report** ([`bug-report.yml`](.github/ISSUE_TEMPLATE/bug-report.yml)) — something is broken or behaves unexpectedly\n- **Feature request** ([`feature-request.yml`](.github/ISSUE_TEMPLATE/feature-request.yml)) — a new capability or enhancement\n- **Blank issue** — if neither template fits\n\n### 3. Compose the Issue\n\nFill in the template fields based on information from the user and the codebase. For bug reports, run `python scripts/diagnose.py` to gather system info if possible.\n\nWhen updating, ensure the title and body still accurately reflect the current state of the issue.\n\n### 4. Check for Duplicates\n\nSearch for existing issues before creating:\n\n```\ngh issue list --repo verl-project/verl --state open --search \"<keywords>\"\n```\n\nIf a duplicate exists, inform the user instead of creating a new one.\n\n### 5. Create or Update the Issue\n\n- **Create**: add `good first issue` and/or `call for contribution` labels if the issue is straightforward and suitable for new contributors.\n- **Update**: update title, body, and labels as needed.\n\nReturn the issue URL when done.\n\n<!-- File: .agent/skills/pr/SKILL.md (Tokens: ~479 | Category: anthropic-skill) -->\n---\nname: pr\ndescription: Create or update a pull request following verl project conventions.\nuser_invocable: true\n---\n\nWhen the user asks to create or update a PR, follow these steps:\n\n### 1. Gather Context\n\nRead the following and understand the current branch's changes compared to main:\n\n- [`CONTRIBUTING.md`](CONTRIBUTING.md)\n- [`PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md)\n\nIf a PR already exists for this branch, also read its current title, body, and review comments.\n\n### 2. Compose PR Title and Body\n\nFollow the PR template strictly for both title format and body sections. Only check checklist boxes for steps that have actually been completed.\n\nWhen updating, ensure the title and body still accurately reflect **all** changes on the branch, not just the latest commit.\n\nWrite the body as GitHub-flavored Markdown, not fixed-width plain text. Keep each paragraph and each list item on a single logical line and separate blocks with blank lines. Do not hard-wrap running prose at a column limit: GitHub renders a single newline inside a paragraph or list item as a space, so a manually wrapped sentence turns into unintended mid-sentence breaks in the rendered PR. Watch two easy-to-miss cases: a wrapped line whose continuation starts with `#<number>` (e.g. an issue reference like `#7060`) reads as a heading in the source and is easy to leave split, and list-item continuations that are indented but should still join their item. Let the editor soft-wrap; only insert a newline to start a new paragraph, list item, table row, or fenced code block. Before submitting, re-read the body (or the round-tripped version fetched back from GitHub) and confirm no paragraph or list item is split across multiple source lines.\n\n### 3. Pre-submit Checks\n\nRun pre-commit and fix any issues before creating or pushing.\n\n### 4. Create or Update the PR\n\n- **Create**: target `main` by default unless the user specifies otherwise.\n- **Update**: push new commits and update the title and body if the scope has changed. **Read the current PR title and body first** and incorporate any edits the user may have made directly on GitHub — never overwrite with a version generated from scratch.\n\nReturn the PR URL when done.\n</yakaai_skills>"}