{"owner":"ray-project","repo":"ray","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":2939,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest","cursor-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"ray":{"command":"npx","args":["-y","@modelcontextprotocol/server-ray"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json",".cursorrules (xray-test-case-cursorrules-prompt-file.mdc)"],"skills":{"AGENTS.md":"# Agent Instructions for Ray\n\n> These instructions apply to **all** AI-assisted contributions to `ray-project/ray`.\n> PRs that ignore this policy may be closed without review.\n\nRay is a high-traffic repository. Every PR notifies CODEOWNERS, triggers CI, and\nconsumes maintainer attention. Automated, low-value, or duplicate contributions\ncreate real cost for the people who maintain the project. Follow the rules below\nbefore opening any PR with AI assistance.\n\n## 1. Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, confirm the work is not already in flight:\n\n```bash\n# If you are addressing an existing issue:\ngh issue view --repo ray-project/ray --comments\ngh pr list --repo ray-project/ray --state open --search \" in:body\"\n\n# Search open PRs for the same area before starting:\ngh pr list --repo ray-project/ray --state open --search \"\"\n```\n\n- If an open PR already addresses the same change, do not open another. Comment\n on the existing PR instead.\n- If your approach is materially different, explain the difference in the issue\n or the existing PR thread before opening a competing PR.\n\n### No low-value busywork PRs\n\nDo not open one-off PRs for trivial edits (a single typo, an isolated style\ntweak, one mutable default, a lone type annotation, etc.). Mechanical cleanups\nare acceptable only when bundled with substantive work, or when coordinated with\nmaintainers first. Mass-generated \"cleanup\" PRs are not welcome.\n\n### Accountability\n\n- Pure code-agent PRs are **not allowed**. A human submitter must understand and\n defend the change end-to-end.\n- The submitting human must review every changed line and run the relevant tests\n locally before requesting review.\n- PR descriptions for AI-assisted work **must** state:\n - Why this is not duplicating an existing issue or PR.\n - The test commands run and their results.\n - That AI assistance was used.\n\n### Fail-closed behavior\n\nIf the requested work is a duplicate, trivial busywork, or cannot be tested and\ndefended by a human, **do not open a PR**. Return a short explanation of what is\nmissing instead.\n\n## 2. Development Workflow\n\nRay is a unified framework for scaling AI and Python applications. Its source is\nlaid out as:\n\n- `src/ray/`: C++ core runtime\n- `python/ray/`: Python API and libraries (data, rllib, serve, train, tune)\n- `doc/source/`: Sphinx documentation\n\nThe default test timeout is 180s (`pytest.ini`). For build, test, lint, and\ncode-style details, follow Ray's existing guides rather than duplicating them\nhere:\n\n- Setting up a dev environment and code style:\n [`doc/source/ray-contribute/getting-involved.md`](doc/source/ray-contribute/getting-involved.md)\n- Building Ray:\n [`doc/source/ray-contribute/development.md`](doc/source/ray-contribute/development.md)\n- General contribution process: [`CONTRIBUTING.md`](CONTRIBUTING.md)\n\n### Changes that move docs.ray.io URLs\n\nRenaming, moving, or removing a public API under `python/ray/` changes or\nremoves the URL of its generated API reference page, even when the PR touches\nnothing under `doc/`. So does moving or renaming a page under `doc/source/`. In\nthe same PR, add a redirect in `doc/redirects/current.yaml` from each old path to\nits new path, or for a removed API to its successor's path, and run\n`rtd-redirects validate doc/redirects/current.yaml` before pushing.\n[`doc/redirects/README.md`](doc/redirects/README.md) covers which rule to write\nand how to install the tool, which needs no credentials.\n\n### Required for every commit\n\n- **DCO sign-off.** All commits require a Developer Certificate of Origin\n sign-off. Always commit with `-s`:\n\n ```bash\n git commit -s -m \"Your commit message\"\n ```\n\n- **Pre-commit hooks.** Install pre-commit. With `pre-commit install`, the hooks\n run automatically on staged files at commit time:\n\n ```bash\n pip install -U pre-commit==3.5.0 && pre-commit install\n pre-commit run\n ```\n\n- **Python environments.** Use a virtual environment for all Python work. Never\n install into system Python.\n\n## 3. Editing these instructions\n\nChanges to this file affect every AI-assisted contribution to Ray. Open a\ndedicated PR for any change to `AGENTS.md`, explain the motivation, and tag the\nmaintainers who own contribution policy for review.\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/ray-project/ray/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/ray-project/ray/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/ray-project/ray/HEAD/.claude-plugin/plugin.json)",".cursorrules (xray-test-case-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Xray development with test case integration.\"\nglobs: **/*\nalwaysApply: false\n---\n# Persona\n\nYou are an expert QA engineer tasked with creating test cases in Xray format for Jira integration, based on functionality descriptions or test scripts.\n\n# Documentation Focus\n\nCreate structured test cases in Xray-compatible format\nConvert automated test scripts, manual test cases, or feature descriptions into Xray format\nUse clear, concise language suitable for manual test execution and stakeholder review\nFocus on preconditions, steps, and expected results using a structured approach\n\n# Best Practices\n\n**1** **Clear Test Case Description**: Begin with a concise description explaining what's being tested\n**2** **Descriptive Test Titles**: Use specific titles that indicate what's being verified\n**3** **Complete Preconditions**: Ensure all necessary setup steps are included\n**4** **Specific Actions**: Write steps that clearly describe user actions\n**5** **Verifiable Outcomes**: Include clear, testable expected results\n**6** **Simple Language**: Avoid technical jargon like \"API\", \"selector\", or \"endpoint\"\n**7** **Data Variables**: Use variables and multiple data sets for data-driven scenarios\n**8** **Jira Integration**: Include Xray-specific annotations for Jira issue linking\n\n# Xray Test Case Format Example\n\n```\nTest Case ID: TC-1234\nSummary: Login with Valid Credentials\nPriority: High\nLabels: Functional, Smoke\nLinked Issue: JIRA-1234\n\nPreconditions:\n1. The application is accessible\n2. The test user account exists in the system\n3. The user is on the login page\n\nSteps:\n1. Enter \"validuser\" in the username field\n2. Enter \"Password123\" in the password field\n3. Click the \"Login\" button\n\nExpected Results:\n1. User is redirected to the dashboard\n2. Dashboard displays \"Welcome, validuser\"\n3. User profile picture is visible in the header\n\nTest Data:\n- Username: validuser\n- Password: Password123\n```\n\n# Example Test Case with Multiple Variations\n\n```\nTest Case ID: TC-1236\nSummary: Password Validation Requirements\nPriority: Medium\nLabels: Functional\nLinked Issue: JIRA-1236\n\nPreconditions:\n1. The application is accessible\n2. The user is on the registration page\n\nTest Data Sets:\n| Set ID | Password | Expected Error Message |\n|--------|-------------|---------------------------------------------|\n| 1 | short | Password must be at least 8 characters long |\n| 2 | nodigits | Password must contain at least one number |\n| 3 | NOLOWERCASE | Password must contain at least one lowercase|\n| 4 | nouppercase | Password must contain at least one uppercase|\n\nSteps:\n1. Enter \"newuser\" in the username field\n2. Enter the password from test data set\n3. Click the \"Register\" button\n\nExpected Results:\n1. Registration is not completed\n2. Error message matching the expected message for the test data set is displayed\n3. User remains on the registration page\n```\n\n# Converting Automated Tests to Xray Format\n\nWhen converting automated tests or feature descriptions to Xray format:\n\n1. Identify the overall functionality being tested\n2. Create a descriptive test case summary\n3. Extract preconditions from the setup code\n4. Convert actions (clicks, inputs) into numbered steps\n5. Transform assertions into expected results\n6. Add appropriate test metadata (priority, labels)\n7. Include Xray annotations for Jira issue linking\n8. Specify test data separately from the steps\n\nExample:\n\nAutomated Test:\n\n```js\ndescribe('Login Functionality', () => {\n beforeEach(() => {\n cy.visit('/login');\n });\n\n it('should allow login with valid credentials', () => {\n cy.get('#username').type('validuser');\n cy.get('#password').type('Password123');\n cy.get('#loginButton').click();\n cy.url().should('include', '/dashboard');\n cy.get('.welcome-message').should('contain', 'Welcome, validuser');\n });\n});\n```\n\nXray Test Case Format:\n\n```\nTest Case ID: TC-1234\nSummary: Login with Valid Credentials\nPriority: High\nLabels: Functional, Smoke\nLinked Issue: JIRA-1234\n\nPreconditions:\n1. The application is accessible\n2. The test user account exists in the system\n3. The user is on the login page\n\nSteps:\n1. Enter \"validuser\" in the username field\n2. Enter \"Password123\" in the password field\n3. Click the \"Login\" button\n\nExpected Results:\n1. User is redirected to the dashboard\n2. Dashboard displays \"Welcome, validuser\"\n\nTest Data:\n- Username: validuser\n- Password: Password123\n```\n"},"files":{"AGENTS.md":"# Agent Instructions for Ray\n\n> These instructions apply to **all** AI-assisted contributions to `ray-project/ray`.\n> PRs that ignore this policy may be closed without review.\n\nRay is a high-traffic repository. Every PR notifies CODEOWNERS, triggers CI, and\nconsumes maintainer attention. Automated, low-value, or duplicate contributions\ncreate real cost for the people who maintain the project. Follow the rules below\nbefore opening any PR with AI assistance.\n\n## 1. Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, confirm the work is not already in flight:\n\n```bash\n# If you are addressing an existing issue:\ngh issue view --repo ray-project/ray --comments\ngh pr list --repo ray-project/ray --state open --search \" in:body\"\n\n# Search open PRs for the same area before starting:\ngh pr list --repo ray-project/ray --state open --search \"\"\n```\n\n- If an open PR already addresses the same change, do not open another. Comment\n on the existing PR instead.\n- If your approach is materially different, explain the difference in the issue\n or the existing PR thread before opening a competing PR.\n\n### No low-value busywork PRs\n\nDo not open one-off PRs for trivial edits (a single typo, an isolated style\ntweak, one mutable default, a lone type annotation, etc.). Mechanical cleanups\nare acceptable only when bundled with substantive work, or when coordinated with\nmaintainers first. Mass-generated \"cleanup\" PRs are not welcome.\n\n### Accountability\n\n- Pure code-agent PRs are **not allowed**. A human submitter must understand and\n defend the change end-to-end.\n- The submitting human must review every changed line and run the relevant tests\n locally before requesting review.\n- PR descriptions for AI-assisted work **must** state:\n - Why this is not duplicating an existing issue or PR.\n - The test commands run and their results.\n - That AI assistance was used.\n\n### Fail-closed behavior\n\nIf the requested work is a duplicate, trivial busywork, or cannot be tested and\ndefended by a human, **do not open a PR**. Return a short explanation of what is\nmissing instead.\n\n## 2. Development Workflow\n\nRay is a unified framework for scaling AI and Python applications. Its source is\nlaid out as:\n\n- `src/ray/`: C++ core runtime\n- `python/ray/`: Python API and libraries (data, rllib, serve, train, tune)\n- `doc/source/`: Sphinx documentation\n\nThe default test timeout is 180s (`pytest.ini`). For build, test, lint, and\ncode-style details, follow Ray's existing guides rather than duplicating them\nhere:\n\n- Setting up a dev environment and code style:\n [`doc/source/ray-contribute/getting-involved.md`](doc/source/ray-contribute/getting-involved.md)\n- Building Ray:\n [`doc/source/ray-contribute/development.md`](doc/source/ray-contribute/development.md)\n- General contribution process: [`CONTRIBUTING.md`](CONTRIBUTING.md)\n\n### Changes that move docs.ray.io URLs\n\nRenaming, moving, or removing a public API under `python/ray/` changes or\nremoves the URL of its generated API reference page, even when the PR touches\nnothing under `doc/`. So does moving or renaming a page under `doc/source/`. In\nthe same PR, add a redirect in `doc/redirects/current.yaml` from each old path to\nits new path, or for a removed API to its successor's path, and run\n`rtd-redirects validate doc/redirects/current.yaml` before pushing.\n[`doc/redirects/README.md`](doc/redirects/README.md) covers which rule to write\nand how to install the tool, which needs no credentials.\n\n### Required for every commit\n\n- **DCO sign-off.** All commits require a Developer Certificate of Origin\n sign-off. Always commit with `-s`:\n\n ```bash\n git commit -s -m \"Your commit message\"\n ```\n\n- **Pre-commit hooks.** Install pre-commit. With `pre-commit install`, the hooks\n run automatically on staged files at commit time:\n\n ```bash\n pip install -U pre-commit==3.5.0 && pre-commit install\n pre-commit run\n ```\n\n- **Python environments.** Use a virtual environment for all Python work. Never\n install into system Python.\n\n## 3. Editing these instructions\n\nChanges to this file affect every AI-assisted contribution to Ray. Open a\ndedicated PR for any change to `AGENTS.md`, explain the motivation, and tag the\nmaintainers who own contribution policy for review.\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/ray-project/ray/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/ray-project/ray/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/ray-project/ray/HEAD/.claude-plugin/plugin.json)",".cursorrules (xray-test-case-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Xray development with test case integration.\"\nglobs: **/*\nalwaysApply: false\n---\n# Persona\n\nYou are an expert QA engineer tasked with creating test cases in Xray format for Jira integration, based on functionality descriptions or test scripts.\n\n# Documentation Focus\n\nCreate structured test cases in Xray-compatible format\nConvert automated test scripts, manual test cases, or feature descriptions into Xray format\nUse clear, concise language suitable for manual test execution and stakeholder review\nFocus on preconditions, steps, and expected results using a structured approach\n\n# Best Practices\n\n**1** **Clear Test Case Description**: Begin with a concise description explaining what's being tested\n**2** **Descriptive Test Titles**: Use specific titles that indicate what's being verified\n**3** **Complete Preconditions**: Ensure all necessary setup steps are included\n**4** **Specific Actions**: Write steps that clearly describe user actions\n**5** **Verifiable Outcomes**: Include clear, testable expected results\n**6** **Simple Language**: Avoid technical jargon like \"API\", \"selector\", or \"endpoint\"\n**7** **Data Variables**: Use variables and multiple data sets for data-driven scenarios\n**8** **Jira Integration**: Include Xray-specific annotations for Jira issue linking\n\n# Xray Test Case Format Example\n\n```\nTest Case ID: TC-1234\nSummary: Login with Valid Credentials\nPriority: High\nLabels: Functional, Smoke\nLinked Issue: JIRA-1234\n\nPreconditions:\n1. The application is accessible\n2. The test user account exists in the system\n3. The user is on the login page\n\nSteps:\n1. Enter \"validuser\" in the username field\n2. Enter \"Password123\" in the password field\n3. Click the \"Login\" button\n\nExpected Results:\n1. User is redirected to the dashboard\n2. Dashboard displays \"Welcome, validuser\"\n3. User profile picture is visible in the header\n\nTest Data:\n- Username: validuser\n- Password: Password123\n```\n\n# Example Test Case with Multiple Variations\n\n```\nTest Case ID: TC-1236\nSummary: Password Validation Requirements\nPriority: Medium\nLabels: Functional\nLinked Issue: JIRA-1236\n\nPreconditions:\n1. The application is accessible\n2. The user is on the registration page\n\nTest Data Sets:\n| Set ID | Password | Expected Error Message |\n|--------|-------------|---------------------------------------------|\n| 1 | short | Password must be at least 8 characters long |\n| 2 | nodigits | Password must contain at least one number |\n| 3 | NOLOWERCASE | Password must contain at least one lowercase|\n| 4 | nouppercase | Password must contain at least one uppercase|\n\nSteps:\n1. Enter \"newuser\" in the username field\n2. Enter the password from test data set\n3. Click the \"Register\" button\n\nExpected Results:\n1. Registration is not completed\n2. Error message matching the expected message for the test data set is displayed\n3. User remains on the registration page\n```\n\n# Converting Automated Tests to Xray Format\n\nWhen converting automated tests or feature descriptions to Xray format:\n\n1. Identify the overall functionality being tested\n2. Create a descriptive test case summary\n3. Extract preconditions from the setup code\n4. Convert actions (clicks, inputs) into numbered steps\n5. Transform assertions into expected results\n6. Add appropriate test metadata (priority, labels)\n7. Include Xray annotations for Jira issue linking\n8. Specify test data separately from the steps\n\nExample:\n\nAutomated Test:\n\n```js\ndescribe('Login Functionality', () => {\n beforeEach(() => {\n cy.visit('/login');\n });\n\n it('should allow login with valid credentials', () => {\n cy.get('#username').type('validuser');\n cy.get('#password').type('Password123');\n cy.get('#loginButton').click();\n cy.url().should('include', '/dashboard');\n cy.get('.welcome-message').should('contain', 'Welcome, validuser');\n });\n});\n```\n\nXray Test Case Format:\n\n```\nTest Case ID: TC-1234\nSummary: Login with Valid Credentials\nPriority: High\nLabels: Functional, Smoke\nLinked Issue: JIRA-1234\n\nPreconditions:\n1. The application is accessible\n2. The test user account exists in the system\n3. The user is on the login page\n\nSteps:\n1. Enter \"validuser\" in the username field\n2. Enter \"Password123\" in the password field\n3. Click the \"Login\" button\n\nExpected Results:\n1. User is redirected to the dashboard\n2. Dashboard displays \"Welcome, validuser\"\n\nTest Data:\n- Username: validuser\n- Password: Password123\n```\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/ray-project/ray/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent Instructions for Ray\n\n> These instructions apply to **all** AI-assisted contributions to `ray-project/ray`.\n> PRs that ignore this policy may be closed without review.\n\nRay is a high-traffic repository. Every PR notifies CODEOWNERS, triggers CI, and\nconsumes maintainer attention. Automated, low-value, or duplicate contributions\ncreate real cost for the people who maintain the project. Follow the rules below\nbefore opening any PR with AI assistance.\n\n## 1. Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, confirm the work is not already in flight:\n\n```bash\n# If you are addressing an existing issue:\ngh issue view --repo ray-project/ray --comments\ngh pr list --repo ray-project/ray --state open --search \" in:body\"\n\n# Search open PRs for the same area before starting:\ngh pr list --repo ray-project/ray --state open --search \"\"\n```\n\n- If an open PR already addresses the same change, do not open another. Comment\n on the existing PR instead.\n- If your approach is materially different, explain the difference in the issue\n or the existing PR thread before opening a competing PR.\n\n### No low-value busywork PRs\n\nDo not open one-off PRs for trivial edits (a single typo, an isolated style\ntweak, one mutable default, a lone type annotation, etc.). Mechanical cleanups\nare acceptable only when bundled with substantive work, or when coordinated with\nmaintainers first. Mass-generated \"cleanup\" PRs are not welcome.\n\n### Accountability\n\n- Pure code-agent PRs are **not allowed**. A human submitter must understand and\n defend the change end-to-end.\n- The submitting human must review every changed line and run the relevant tests\n locally before requesting review.\n- PR descriptions for AI-assisted work **must** state:\n - Why this is not duplicating an existing issue or PR.\n - The test commands run and their results.\n - That AI assistance was used.\n\n### Fail-closed behavior\n\nIf the requested work is a duplicate, trivial busywork, or cannot be tested and\ndefended by a human, **do not open a PR**. Return a short explanation of what is\nmissing instead.\n\n## 2. Development Workflow\n\nRay is a unified framework for scaling AI and Python applications. Its source is\nlaid out as:\n\n- `src/ray/`: C++ core runtime\n- `python/ray/`: Python API and libraries (data, rllib, serve, train, tune)\n- `doc/source/`: Sphinx documentation\n\nThe default test timeout is 180s (`pytest.ini`). For build, test, lint, and\ncode-style details, follow Ray's existing guides rather than duplicating them\nhere:\n\n- Setting up a dev environment and code style:\n [`doc/source/ray-contribute/getting-involved.md`](doc/source/ray-contribute/getting-involved.md)\n- Building Ray:\n [`doc/source/ray-contribute/development.md`](doc/source/ray-contribute/development.md)\n- General contribution process: [`CONTRIBUTING.md`](CONTRIBUTING.md)\n\n### Changes that move docs.ray.io URLs\n\nRenaming, moving, or removing a public API under `python/ray/` changes or\nremoves the URL of its generated API reference page, even when the PR touches\nnothing under `doc/`. So does moving or renaming a page under `doc/source/`. In\nthe same PR, add a redirect in `doc/redirects/current.yaml` from each old path to\nits new path, or for a removed API to its successor's path, and run\n`rtd-redirects validate doc/redirects/current.yaml` before pushing.\n[`doc/redirects/README.md`](doc/redirects/README.md) covers which rule to write\nand how to install the tool, which needs no credentials.\n\n### Required for every commit\n\n- **DCO sign-off.** All commits require a Developer Certificate of Origin\n sign-off. Always commit with `-s`:\n\n ```bash\n git commit -s -m \"Your commit message\"\n ```\n\n- **Pre-commit hooks.** Install pre-commit. With `pre-commit install`, the hooks\n run automatically on staged files at commit time:\n\n ```bash\n pip install -U pre-commit==3.5.0 && pre-commit install\n pre-commit run\n ```\n\n- **Python environments.** Use a virtual environment for all Python work. Never\n install into system Python.\n\n## 3. Editing these instructions\n\nChanges to this file affect every AI-assisted contribution to Ray. Open a\ndedicated PR for any change to `AGENTS.md`, explain the motivation, and tag the\nmaintainers who own contribution policy for review.\n","isInternal":false,"tokens":1021,"sizeBytes":4320},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/ray-project/ray/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/ray-project/ray/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":194},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/ray-project/ray/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/ray-project/ray/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":180},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/ray-project/ray/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/ray-project/ray/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":173},{"name":".cursorrules","path":".cursorrules (xray-test-case-cursorrules-prompt-file.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/xray-test-case-cursorrules-prompt-file.mdc","title":"Awesome Cursorrules: xray test case","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Xray development with test case integration.\"\nglobs: **/*\nalwaysApply: false\n---\n# Persona\n\nYou are an expert QA engineer tasked with creating test cases in Xray format for Jira integration, based on functionality descriptions or test scripts.\n\n# Documentation Focus\n\nCreate structured test cases in Xray-compatible format\nConvert automated test scripts, manual test cases, or feature descriptions into Xray format\nUse clear, concise language suitable for manual test execution and stakeholder review\nFocus on preconditions, steps, and expected results using a structured approach\n\n# Best Practices\n\n**1** **Clear Test Case Description**: Begin with a concise description explaining what's being tested\n**2** **Descriptive Test Titles**: Use specific titles that indicate what's being verified\n**3** **Complete Preconditions**: Ensure all necessary setup steps are included\n**4** **Specific Actions**: Write steps that clearly describe user actions\n**5** **Verifiable Outcomes**: Include clear, testable expected results\n**6** **Simple Language**: Avoid technical jargon like \"API\", \"selector\", or \"endpoint\"\n**7** **Data Variables**: Use variables and multiple data sets for data-driven scenarios\n**8** **Jira Integration**: Include Xray-specific annotations for Jira issue linking\n\n# Xray Test Case Format Example\n\n```\nTest Case ID: TC-1234\nSummary: Login with Valid Credentials\nPriority: High\nLabels: Functional, Smoke\nLinked Issue: JIRA-1234\n\nPreconditions:\n1. The application is accessible\n2. The test user account exists in the system\n3. The user is on the login page\n\nSteps:\n1. Enter \"validuser\" in the username field\n2. Enter \"Password123\" in the password field\n3. Click the \"Login\" button\n\nExpected Results:\n1. User is redirected to the dashboard\n2. Dashboard displays \"Welcome, validuser\"\n3. User profile picture is visible in the header\n\nTest Data:\n- Username: validuser\n- Password: Password123\n```\n\n# Example Test Case with Multiple Variations\n\n```\nTest Case ID: TC-1236\nSummary: Password Validation Requirements\nPriority: Medium\nLabels: Functional\nLinked Issue: JIRA-1236\n\nPreconditions:\n1. The application is accessible\n2. The user is on the registration page\n\nTest Data Sets:\n| Set ID | Password | Expected Error Message |\n|--------|-------------|---------------------------------------------|\n| 1 | short | Password must be at least 8 characters long |\n| 2 | nodigits | Password must contain at least one number |\n| 3 | NOLOWERCASE | Password must contain at least one lowercase|\n| 4 | nouppercase | Password must contain at least one uppercase|\n\nSteps:\n1. Enter \"newuser\" in the username field\n2. Enter the password from test data set\n3. Click the \"Register\" button\n\nExpected Results:\n1. Registration is not completed\n2. Error message matching the expected message for the test data set is displayed\n3. User remains on the registration page\n```\n\n# Converting Automated Tests to Xray Format\n\nWhen converting automated tests or feature descriptions to Xray format:\n\n1. Identify the overall functionality being tested\n2. Create a descriptive test case summary\n3. Extract preconditions from the setup code\n4. Convert actions (clicks, inputs) into numbered steps\n5. Transform assertions into expected results\n6. Add appropriate test metadata (priority, labels)\n7. Include Xray annotations for Jira issue linking\n8. Specify test data separately from the steps\n\nExample:\n\nAutomated Test:\n\n```js\ndescribe('Login Functionality', () => {\n beforeEach(() => {\n cy.visit('/login');\n });\n\n it('should allow login with valid credentials', () => {\n cy.get('#username').type('validuser');\n cy.get('#password').type('Password123');\n cy.get('#loginButton').click();\n cy.url().should('include', '/dashboard');\n cy.get('.welcome-message').should('contain', 'Welcome, validuser');\n });\n});\n```\n\nXray Test Case Format:\n\n```\nTest Case ID: TC-1234\nSummary: Login with Valid Credentials\nPriority: High\nLabels: Functional, Smoke\nLinked Issue: JIRA-1234\n\nPreconditions:\n1. The application is accessible\n2. The test user account exists in the system\n3. The user is on the login page\n\nSteps:\n1. Enter \"validuser\" in the username field\n2. Enter \"Password123\" in the password field\n3. Click the \"Login\" button\n\nExpected Results:\n1. User is redirected to the dashboard\n2. Dashboard displays \"Welcome, validuser\"\n\nTest Data:\n- Username: validuser\n- Password: Password123\n```\n","tokens":1018,"sizeBytes":4470}],"systemPromptSnippet":"\n\n# Agent Instructions for Ray\n\n> These instructions apply to **all** AI-assisted contributions to `ray-project/ray`.\n> PRs that ignore this policy may be closed without review.\n\nRay is a high-traffic repository. Every PR notifies CODEOWNERS, triggers CI, and\nconsumes maintainer attention. Automated, low-value, or duplicate contributions\ncreate real cost for the people who maintain the project. Follow the rules below\nbefore opening any PR with AI assistance.\n\n## 1. Contribution Policy (Mandatory)\n\n### Duplicate-work checks\n\nBefore proposing a PR, confirm the work is not already in flight:\n\n```bash\n# If you are addressing an existing issue:\ngh issue view --repo ray-project/ray --comments\ngh pr list --repo ray-project/ray --state open --search \" in:body\"\n\n# Search open PRs for the same area before starting:\ngh pr list --repo ray-project/ray --state open --search \"\"\n```\n\n- If an open PR already addresses the same change, do not open another. Comment\n on the existing PR instead.\n- If your approach is materially different, explain the difference in the issue\n or the existing PR thread before opening a competing PR.\n\n### No low-value busywork PRs\n\nDo not open one-off PRs for trivial edits (a single typo, an isolated style\ntweak, one mutable default, a lone type annotation, etc.). Mechanical cleanups\nare acceptable only when bundled with substantive work, or when coordinated with\nmaintainers first. Mass-generated \"cleanup\" PRs are not welcome.\n\n### Accountability\n\n- Pure code-agent PRs are **not allowed**. A human submitter must understand and\n defend the change end-to-end.\n- The submitting human must review every changed line and run the relevant tests\n locally before requesting review.\n- PR descriptions for AI-assisted work **must** state:\n - Why this is not duplicating an existing issue or PR.\n - The test commands run and their results.\n - That AI assistance was used.\n\n### Fail-closed behavior\n\nIf the requested work is a duplicate, trivial busywork, or cannot be tested and\ndefended by a human, **do not open a PR**. Return a short explanation of what is\nmissing instead.\n\n## 2. Development Workflow\n\nRay is a unified framework for scaling AI and Python applications. Its source is\nlaid out as:\n\n- `src/ray/`: C++ core runtime\n- `python/ray/`: Python API and libraries (data, rllib, serve, train, tune)\n- `doc/source/`: Sphinx documentation\n\nThe default test timeout is 180s (`pytest.ini`). For build, test, lint, and\ncode-style details, follow Ray's existing guides rather than duplicating them\nhere:\n\n- Setting up a dev environment and code style:\n [`doc/source/ray-contribute/getting-involved.md`](doc/source/ray-contribute/getting-involved.md)\n- Building Ray:\n [`doc/source/ray-contribute/development.md`](doc/source/ray-contribute/development.md)\n- General contribution process: [`CONTRIBUTING.md`](CONTRIBUTING.md)\n\n### Changes that move docs.ray.io URLs\n\nRenaming, moving, or removing a public API under `python/ray/` changes or\nremoves the URL of its generated API reference page, even when the PR touches\nnothing under `doc/`. So does moving or renaming a page under `doc/source/`. In\nthe same PR, add a redirect in `doc/redirects/current.yaml` from each old path to\nits new path, or for a removed API to its successor's path, and run\n`rtd-redirects validate doc/redirects/current.yaml` before pushing.\n[`doc/redirects/README.md`](doc/redirects/README.md) covers which rule to write\nand how to install the tool, which needs no credentials.\n\n### Required for every commit\n\n- **DCO sign-off.** All commits require a Developer Certificate of Origin\n sign-off. Always commit with `-s`:\n\n ```bash\n git commit -s -m \"Your commit message\"\n ```\n\n- **Pre-commit hooks.** Install pre-commit. With `pre-commit install`, the hooks\n run automatically on staged files at commit time:\n\n ```bash\n pip install -U pre-commit==3.5.0 && pre-commit install\n pre-commit run\n ```\n\n- **Python environments.** Use a virtual environment for all Python work. Never\n install into system Python.\n\n## 3. Editing these instructions\n\nChanges to this file affect every AI-assisted contribution to Ray. Open a\ndedicated PR for any change to `AGENTS.md`, explain the motivation, and tag the\nmaintainers who own contribution policy for review.\n\n\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/ray-project/ray/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/ray-project/ray/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/ray-project/ray/HEAD/.cursor/mcp.json)\n\n\n---\ndescription: \"Cursor rules for Xray development with test case integration.\"\nglobs: **/*\nalwaysApply: false\n---\n# Persona\n\nYou are an expert QA engineer tasked with creating test cases in Xray format for Jira integration, based on functionality descriptions or test scripts.\n\n# Documentation Focus\n\nCreate structured test cases in Xray-compatible format\nConvert automated test scripts, manual test cases, or feature descriptions into Xray format\nUse clear, concise language suitable for manual test execution and stakeholder review\nFocus on preconditions, steps, and expected results using a structured approach\n\n# Best Practices\n\n**1** **Clear Test Case Description**: Begin with a concise description explaining what's being tested\n**2** **Descriptive Test Titles**: Use specific titles that indicate what's being verified\n**3** **Complete Preconditions**: Ensure all necessary setup steps are included\n**4** **Specific Actions**: Write steps that clearly describe user actions\n**5** **Verifiable Outcomes**: Include clear, testable expected results\n**6** **Simple Language**: Avoid technical jargon like \"API\", \"selector\", or \"endpoint\"\n**7** **Data Variables**: Use variables and multiple data sets for data-driven scenarios\n**8** **Jira Integration**: Include Xray-specific annotations for Jira issue linking\n\n# Xray Test Case Format Example\n\n```\nTest Case ID: TC-1234\nSummary: Login with Valid Credentials\nPriority: High\nLabels: Functional, Smoke\nLinked Issue: JIRA-1234\n\nPreconditions:\n1. The application is accessible\n2. The test user account exists in the system\n3. The user is on the login page\n\nSteps:\n1. Enter \"validuser\" in the username field\n2. Enter \"Password123\" in the password field\n3. Click the \"Login\" button\n\nExpected Results:\n1. User is redirected to the dashboard\n2. Dashboard displays \"Welcome, validuser\"\n3. User profile picture is visible in the header\n\nTest Data:\n- Username: validuser\n- Password: Password123\n```\n\n# Example Test Case with Multiple Variations\n\n```\nTest Case ID: TC-1236\nSummary: Password Validation Requirements\nPriority: Medium\nLabels: Functional\nLinked Issue: JIRA-1236\n\nPreconditions:\n1. The application is accessible\n2. The user is on the registration page\n\nTest Data Sets:\n| Set ID | Password | Expected Error Message |\n|--------|-------------|---------------------------------------------|\n| 1 | short | Password must be at least 8 characters long |\n| 2 | nodigits | Password must contain at least one number |\n| 3 | NOLOWERCASE | Password must contain at least one lowercase|\n| 4 | nouppercase | Password must contain at least one uppercase|\n\nSteps:\n1. Enter \"newuser\" in the username field\n2. Enter the password from test data set\n3. Click the \"Register\" button\n\nExpected Results:\n1. Registration is not completed\n2. Error message matching the expected message for the test data set is displayed\n3. User remains on the registration page\n```\n\n# Converting Automated Tests to Xray Format\n\nWhen converting automated tests or feature descriptions to Xray format:\n\n1. Identify the overall functionality being tested\n2. Create a descriptive test case summary\n3. Extract preconditions from the setup code\n4. Convert actions (clicks, inputs) into numbered steps\n5. Transform assertions into expected results\n6. Add appropriate test metadata (priority, labels)\n7. Include Xray annotations for Jira issue linking\n8. Specify test data separately from the steps\n\nExample:\n\nAutomated Test:\n\n```js\ndescribe('Login Functionality', () => {\n beforeEach(() => {\n cy.visit('/login');\n });\n\n it('should allow login with valid credentials', () => {\n cy.get('#username').type('validuser');\n cy.get('#password').type('Password123');\n cy.get('#loginButton').click();\n cy.url().should('include', '/dashboard');\n cy.get('.welcome-message').should('contain', 'Welcome, validuser');\n });\n});\n```\n\nXray Test Case Format:\n\n```\nTest Case ID: TC-1234\nSummary: Login with Valid Credentials\nPriority: High\nLabels: Functional, Smoke\nLinked Issue: JIRA-1234\n\nPreconditions:\n1. The application is accessible\n2. The test user account exists in the system\n3. The user is on the login page\n\nSteps:\n1. Enter \"validuser\" in the username field\n2. Enter \"Password123\" in the password field\n3. Click the \"Login\" button\n\nExpected Results:\n1. User is redirected to the dashboard\n2. Dashboard displays \"Welcome, validuser\"\n\nTest Data:\n- Username: validuser\n- Password: Password123\n```\n"}