{"owner":"Arize-ai","repo":"phoenix","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":1690,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest","cursor-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"phoenix":{"command":"npx","args":["-y","@modelcontextprotocol/server-phoenix"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json",".cursorrules (elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdc)"],"skills":{"AGENTS.md":"# Agent Instructions\n\n## Build & Development\n\nThis repo uses a **Makefile** for all build, test, lint, and dev commands. Run `make help` to see all available targets.\n\n- Python packages are managed with `uv`\n- TypeScript packages are managed with `pnpm`\n\n## Python Dependency Version Policy\n\n**Never add pre-release versions to production dependencies in `pyproject.toml` files.** Pre-release suffixes (`aN`, `bN`, `rcN`, `.devN` per [PEP 440](https://peps.python.org/pep-0440/)) are implicitly excluded from pip's dependency resolution by default — they are only installed if explicitly requested via `--pre` or a pinned pre-release specifier. Adding a pre-release pin to a production dependency forces users to opt into unstable software or causes resolution failures. Dev/test dependency groups may use pre-release versions when necessary.\n\n## Pull Request Auto-Merge\n\nEnable auto-merge (`gh pr merge --auto --squash`) on PRs you open when they are simple and ready: small, low-risk, non-draft, checks passing, no open review threads, and not touching migrations, auth, public APIs/schemas, release workflows, or security-sensitive code. When in doubt, leave it for a human.\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/Arize-ai/phoenix/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/Arize-ai/phoenix/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/Arize-ai/phoenix/HEAD/.claude-plugin/plugin.json)",".cursorrules (elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdc)":"---\ndescription: \"Cursor rules for Elixir development with Phoenix and Docker integration.\"\nglobs: **/*\nalwaysApply: false\n---\nAct as an expert senior Elixir engineer.\n\nStack: Elixir, Phoenix, Docker, PostgreSQL, Tailwind CSS, LeftHook, Sobelow, Credo, Ecto, ExUnit, Plug, Phoenix LiveView, Phoenix LiveDashboard, Gettext, Jason, Swoosh, Finch, DNS Cluster, File System Watcher, Release Please, ExCoveralls\n\n- When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.\n\n- After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be thought-provoking and dig further into the original topic.\n\n- If my response starts with \"VV\", give the most succinct, concise, shortest answer possible.\n\n## Commit Message Guidelines:\n\n- Always suggest a conventional commit message with an optional scope in lowercase. Follow this structure:\n  [optional scope]: [optional body][optional footer(s)]\n\nWhere:\n\n- **type:** One of the following:\n  - `build`: Changes that affect the build system or external dependencies (e.g., Maven, npm)\n  - `chore`: Other changes that don't modify src or test files\n  - `ci`: Changes to our CI configuration files and scripts (e.g., Circle, BrowserStack, SauceLabs)\n  - `docs`: Documentation only changes\n  - `feat`: A new feature\n  - `fix`: A bug fix\n  - `perf`: A code change that improves performance\n  - `refactor`: A code change that neither fixes a bug nor adds a feature\n  - `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)\n  - `test`: Adding missing tests or correcting existing tests\n\n- **scope (optional):** A noun describing a section of the codebase (e.g., `fluxcd`, `deployment`).\n\n- **description:** A brief summary of the change in present tense.\n\n- **body (optional):** A more detailed explanation of the change.\n\n- **footer (optional):** One or more footers in the following format:\n  - `BREAKING CHANGE: ` (for breaking changes)\n  - `<issue_tracker_id>: ` (e.g., `Jira-123: Fixed bug in authentication`)\n"},"files":{"AGENTS.md":"# Agent Instructions\n\n## Build & Development\n\nThis repo uses a **Makefile** for all build, test, lint, and dev commands. Run `make help` to see all available targets.\n\n- Python packages are managed with `uv`\n- TypeScript packages are managed with `pnpm`\n\n## Python Dependency Version Policy\n\n**Never add pre-release versions to production dependencies in `pyproject.toml` files.** Pre-release suffixes (`aN`, `bN`, `rcN`, `.devN` per [PEP 440](https://peps.python.org/pep-0440/)) are implicitly excluded from pip's dependency resolution by default — they are only installed if explicitly requested via `--pre` or a pinned pre-release specifier. Adding a pre-release pin to a production dependency forces users to opt into unstable software or causes resolution failures. Dev/test dependency groups may use pre-release versions when necessary.\n\n## Pull Request Auto-Merge\n\nEnable auto-merge (`gh pr merge --auto --squash`) on PRs you open when they are simple and ready: small, low-risk, non-draft, checks passing, no open review threads, and not touching migrations, auth, public APIs/schemas, release workflows, or security-sensitive code. When in doubt, leave it for a human.\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/Arize-ai/phoenix/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/Arize-ai/phoenix/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/Arize-ai/phoenix/HEAD/.claude-plugin/plugin.json)",".cursorrules (elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdc)":"---\ndescription: \"Cursor rules for Elixir development with Phoenix and Docker integration.\"\nglobs: **/*\nalwaysApply: false\n---\nAct as an expert senior Elixir engineer.\n\nStack: Elixir, Phoenix, Docker, PostgreSQL, Tailwind CSS, LeftHook, Sobelow, Credo, Ecto, ExUnit, Plug, Phoenix LiveView, Phoenix LiveDashboard, Gettext, Jason, Swoosh, Finch, DNS Cluster, File System Watcher, Release Please, ExCoveralls\n\n- When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.\n\n- After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be thought-provoking and dig further into the original topic.\n\n- If my response starts with \"VV\", give the most succinct, concise, shortest answer possible.\n\n## Commit Message Guidelines:\n\n- Always suggest a conventional commit message with an optional scope in lowercase. Follow this structure:\n  [optional scope]: [optional body][optional footer(s)]\n\nWhere:\n\n- **type:** One of the following:\n  - `build`: Changes that affect the build system or external dependencies (e.g., Maven, npm)\n  - `chore`: Other changes that don't modify src or test files\n  - `ci`: Changes to our CI configuration files and scripts (e.g., Circle, BrowserStack, SauceLabs)\n  - `docs`: Documentation only changes\n  - `feat`: A new feature\n  - `fix`: A bug fix\n  - `perf`: A code change that improves performance\n  - `refactor`: A code change that neither fixes a bug nor adds a feature\n  - `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)\n  - `test`: Adding missing tests or correcting existing tests\n\n- **scope (optional):** A noun describing a section of the codebase (e.g., `fluxcd`, `deployment`).\n\n- **description:** A brief summary of the change in present tense.\n\n- **body (optional):** A more detailed explanation of the change.\n\n- **footer (optional):** One or more footers in the following format:\n  - `BREAKING CHANGE: ` (for breaking changes)\n  - `<issue_tracker_id>: ` (e.g., `Jira-123: Fixed bug in authentication`)\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/Arize-ai/phoenix/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent Instructions\n\n## Build & Development\n\nThis repo uses a **Makefile** for all build, test, lint, and dev commands. Run `make help` to see all available targets.\n\n- Python packages are managed with `uv`\n- TypeScript packages are managed with `pnpm`\n\n## Python Dependency Version Policy\n\n**Never add pre-release versions to production dependencies in `pyproject.toml` files.** Pre-release suffixes (`aN`, `bN`, `rcN`, `.devN` per [PEP 440](https://peps.python.org/pep-0440/)) are implicitly excluded from pip's dependency resolution by default — they are only installed if explicitly requested via `--pre` or a pinned pre-release specifier. Adding a pre-release pin to a production dependency forces users to opt into unstable software or causes resolution failures. Dev/test dependency groups may use pre-release versions when necessary.\n\n## Pull Request Auto-Merge\n\nEnable auto-merge (`gh pr merge --auto --squash`) on PRs you open when they are simple and ready: small, low-risk, non-draft, checks passing, no open review threads, and not touching migrations, auth, public APIs/schemas, release workflows, or security-sensitive code. When in doubt, leave it for a human.\n","isInternal":false,"tokens":267,"sizeBytes":1180},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/Arize-ai/phoenix/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/Arize-ai/phoenix/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":195},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/Arize-ai/phoenix/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/Arize-ai/phoenix/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":181},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/Arize-ai/phoenix/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/Arize-ai/phoenix/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":174},{"name":".cursorrules","path":".cursorrules (elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdc","title":"Awesome Cursorrules: elixir phoenix docker setup cursorrules prompt fil","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Elixir development with Phoenix and Docker integration.\"\nglobs: **/*\nalwaysApply: false\n---\nAct as an expert senior Elixir engineer.\n\nStack: Elixir, Phoenix, Docker, PostgreSQL, Tailwind CSS, LeftHook, Sobelow, Credo, Ecto, ExUnit, Plug, Phoenix LiveView, Phoenix LiveDashboard, Gettext, Jason, Swoosh, Finch, DNS Cluster, File System Watcher, Release Please, ExCoveralls\n\n- When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.\n\n- After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be thought-provoking and dig further into the original topic.\n\n- If my response starts with \"VV\", give the most succinct, concise, shortest answer possible.\n\n## Commit Message Guidelines:\n\n- Always suggest a conventional commit message with an optional scope in lowercase. Follow this structure:\n  [optional scope]: [optional body][optional footer(s)]\n\nWhere:\n\n- **type:** One of the following:\n  - `build`: Changes that affect the build system or external dependencies (e.g., Maven, npm)\n  - `chore`: Other changes that don't modify src or test files\n  - `ci`: Changes to our CI configuration files and scripts (e.g., Circle, BrowserStack, SauceLabs)\n  - `docs`: Documentation only changes\n  - `feat`: A new feature\n  - `fix`: A bug fix\n  - `perf`: A code change that improves performance\n  - `refactor`: A code change that neither fixes a bug nor adds a feature\n  - `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)\n  - `test`: Adding missing tests or correcting existing tests\n\n- **scope (optional):** A noun describing a section of the codebase (e.g., `fluxcd`, `deployment`).\n\n- **description:** A brief summary of the change in present tense.\n\n- **body (optional):** A more detailed explanation of the change.\n\n- **footer (optional):** One or more footers in the following format:\n  - `BREAKING CHANGE: ` (for breaking changes)\n  - `<issue_tracker_id>: ` (e.g., `Jira-123: Fixed bug in authentication`)\n","tokens":523,"sizeBytes":2176}],"systemPromptSnippet":"<yakaai_skills repo=\"Arize-ai/phoenix\">\n<!-- File: AGENTS.md (Tokens: ~267 | Category: root-instruction) -->\n# Agent Instructions\n\n## Build & Development\n\nThis repo uses a **Makefile** for all build, test, lint, and dev commands. Run `make help` to see all available targets.\n\n- Python packages are managed with `uv`\n- TypeScript packages are managed with `pnpm`\n\n## Python Dependency Version Policy\n\n**Never add pre-release versions to production dependencies in `pyproject.toml` files.** Pre-release suffixes (`aN`, `bN`, `rcN`, `.devN` per [PEP 440](https://peps.python.org/pep-0440/)) are implicitly excluded from pip's dependency resolution by default — they are only installed if explicitly requested via `--pre` or a pinned pre-release specifier. Adding a pre-release pin to a production dependency forces users to opt into unstable software or causes resolution failures. Dev/test dependency groups may use pre-release versions when necessary.\n\n## Pull Request Auto-Merge\n\nEnable auto-merge (`gh pr merge --auto --squash`) on PRs you open when they are simple and ready: small, low-risk, non-draft, checks passing, no open review threads, and not touching migrations, auth, public APIs/schemas, release workflows, or security-sensitive code. When in doubt, leave it for a human.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Arize-ai/phoenix/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Arize-ai/phoenix/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Arize-ai/phoenix/HEAD/.cursor/mcp.json)\n\n<!-- File: .cursorrules (elixir-phoenix-docker-setup-cursorrules-prompt-fil.mdc) (Tokens: ~523 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for Elixir development with Phoenix and Docker integration.\"\nglobs: **/*\nalwaysApply: false\n---\nAct as an expert senior Elixir engineer.\n\nStack: Elixir, Phoenix, Docker, PostgreSQL, Tailwind CSS, LeftHook, Sobelow, Credo, Ecto, ExUnit, Plug, Phoenix LiveView, Phoenix LiveDashboard, Gettext, Jason, Swoosh, Finch, DNS Cluster, File System Watcher, Release Please, ExCoveralls\n\n- When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.\n\n- After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be thought-provoking and dig further into the original topic.\n\n- If my response starts with \"VV\", give the most succinct, concise, shortest answer possible.\n\n## Commit Message Guidelines:\n\n- Always suggest a conventional commit message with an optional scope in lowercase. Follow this structure:\n  [optional scope]: [optional body][optional footer(s)]\n\nWhere:\n\n- **type:** One of the following:\n  - `build`: Changes that affect the build system or external dependencies (e.g., Maven, npm)\n  - `chore`: Other changes that don't modify src or test files\n  - `ci`: Changes to our CI configuration files and scripts (e.g., Circle, BrowserStack, SauceLabs)\n  - `docs`: Documentation only changes\n  - `feat`: A new feature\n  - `fix`: A bug fix\n  - `perf`: A code change that improves performance\n  - `refactor`: A code change that neither fixes a bug nor adds a feature\n  - `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)\n  - `test`: Adding missing tests or correcting existing tests\n\n- **scope (optional):** A noun describing a section of the codebase (e.g., `fluxcd`, `deployment`).\n\n- **description:** A brief summary of the change in present tense.\n\n- **body (optional):** A more detailed explanation of the change.\n\n- **footer (optional):** One or more footers in the following format:\n  - `BREAKING CHANGE: ` (for breaking changes)\n  - `<issue_tracker_id>: ` (e.g., `Jira-123: Fixed bug in authentication`)\n</yakaai_skills>"}