{"owner":"unkeyed","repo":"unkey","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":3553,"categories":["claude-rule","root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"unkey":{"command":"npx","args":["-y","@modelcontextprotocol/server-unkey"]}}},"found":["CLAUDE.md","AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"CLAUDE.md":"@AGENTS.md\n\n<!-- polylane:start -->\n## Investigating production with Polylane\n\n[Polylane](https://polylane.com/?ref=github.onboarding-pr) is an AI production engineer: it watches deploys, telemetry, incidents, and the infrastructure this repository ships to, investigates problems as they happen, and proposes fixes as pull requests. It is connected to this repository and available to coding agents through the [Polylane MCP server](https://mcp.polylane.com/mcp).\n\n- When a question involves production behaviour (an error, a spike, a deploy, a missing signal), query Polylane through its MCP tools before reasoning from the code alone.\n- When debugging a failure, start from the incident or issue Polylane recorded: it carries the evidence an investigation already gathered.\n- Polylane reviews pull requests in this repository against the live infrastructure. Read its review comment before merging changes that touch production paths.\n<!-- polylane:end -->\n","AGENTS.md":"# AGENTS.md - Unkey agent guide\n\nThis file is the first stop for agents working in this repo. Keep changes small,\ntyped, verified, and routed through `mise`.\n\n## Scoped guidance and additional context\n\nBefore changing a file, read this guide and every nested `AGENTS.md` along the\npath to that file. Do this explicitly if your harness does not load nested\nguidance automatically. For new files, check their parent directories. Repeat\nthe check when work crosses into another service or package.\n\nNested guidance applies to its directory and descendants. Keep the root rules\nand add the more specific local constraints. Each service under `svc/` has an\n`AGENTS.md`; `svc/ctrl/worker/` has additional Restate guidance. Keep shared rules\nhere and service-specific constraints near the code, without copying them into\nparallel instruction files.\n\nThe root `contributing/` directory holds testing, code quality,\nand screenshot and recording standards. These standards stay in the repository,\nnot in Notion. Read the relevant guide for your task.\n\nBroader engineering context, design discussions, and operational workflows are in\n[Notion's Engineering wiki](https://app.notion.com/p/ed5512d643f38377b0d38164de40681e).\nWhen repository guidance does not answer a task-relevant question, use the\nNotion MCP server to search for the service or topic and fetch the relevant\npages. Search results alone are not the full context. Distinguish proposals\nand historical plans from accepted decisions, and check implementation claims\nagainst the code.\n\nIf Notion MCP is unavailable, the relevant page is inaccessible, or a material\ndecision is still unclear, ask your operator for the missing context. Do not\ninvent requirements or silently resolve conflicting guidance. Continue work\nthat does not depend on the missing information.\n\n## Communication\n\n- Be concise.\n- Say what changed and how you verified it.\n- If you provide a plan, end with unresolved questions, if any.\n- Preserve pre-existing uncommitted changes and unrelated work. Modify existing\n  code as needed for the requested task.\n- Complete authorized work through verification. Resolve routine implementation\n  choices using repository patterns. Ask only when missing information materially\n  affects scope or correctness; continue independent work while waiting.\n\n## Source of truth\n\n- Tooling and task runner: `.mise/config.toml`, `.mise/mise.lock`, and\n  `.mise/tasks/*`.\n- Engineering standards: `contributing/`. These are normative\n  standards for writing code, not only reference material for the docs site.\n- Product docs: `docs/`.\n- Go tooling: `go.mod`, `go.sum`, and `.golangci.yaml`. Rask is pinned as a\n  tool in `.mise/config.toml`; it has no config file of its own.\n- Web workspace: `web/package.json`, `web/pnpm-workspace.yaml`, and\n  `web/pnpm-lock.yaml`.\n\n## Repository map\n\n- `cmd/`: development commands and utilities.\n- `build/`: CLI and service entrypoints.\n- `svc/`: Go services (`api`, `ctrl`, `frontline`, `heimdall`, `kitchensink`,\n  `krane`, `logdrain`, `vault`).\n- `pkg/`: shared Go libraries.\n- `internal/services/`: shared internal Go services.\n- `proto/` and `gen/`: protobuf definitions and generated code.\n- `web/`: TypeScript apps (`web/apps/`) and shared packages, database schema,\n  and tooling. Shared code lives in `web/internal/`; there is no\n  `web/packages/`.\n- `docs/`: Mintlify product documentation.\n- `contributing/`: Engineering workflow and coding standards.\n- `dev/`: local development, Tilt, Kubernetes, and formatting config.\n\n## Tooling rules\n\nUse `mise` for all installs, tasks, and direct tool execution. Makefiles are\nlegacy and should not be used.\n\n```bash\n# Install pinned toolchain\n./dev/install-mise\nmise install\n\n# Discover tasks\nmise tasks\nmise run help\n```\n\nPrefer `mise run <task>` when a task covers the required scope. Use\n`mise exec -- <tool>` when no task applies or a broader task would touch\nunrelated files, such as when formatting changed files.\n\n### Common tasks\n\n```bash\nmise run build          # lint and Go build, writes ./bin/unkey\nmise run lint           # golangci-lint checks\nmise run test           # run Go test suite through Rask\nmise run fmt            # dprint, go fmt, buf format, pnpm fmt\nmise run generate       # SQL, protobuf, Go generators, fmt\nmise run generate-bpf   # heimdall eBPF bindings\nmise run dev            # local Kubernetes/Tilt dev environment\nmise run dashboard      # dashboard-focused local setup\nmise run down           # stop minikube, preserve data (exit Tilt first)\nmise run tunnel         # port-forward 80/443 for *.unkey.local\nmise run unkey -- ...   # run the Unkey CLI\n```\n\n### Direct tool examples\n\n```bash\nmise exec -- rask ./pkg/cache\nmise exec -- pnpm --dir=web test\nmise exec -- go test -fuzz=FuzzInRange -fuzztime=30s ./pkg/assert/\n```\n\n## Code standards\n\n- Make minimal, surgical changes.\n- Preserve type safety. Do not add TypeScript `any`, non-null assertions, or\n  unsafe casts.\n- Model domain states explicitly. Parse untyped input at boundaries.\n- Prefer existing packages, helpers, and patterns before adding new ones.\n- Avoid new dependencies unless the local implementation would be worse.\n- Keep variable scope small.\n- Name from most to least significant, with qualifiers last: `freqMax`, not\n  `maxFreq`. Follow this even when nearby code does not. See\n  [Naming](contributing/quality/code-quality.md#naming).\n- Handle every error. If a state is impossible, assert it rather than ignoring it.\n- Add tests for Go behavior and pure TypeScript functions. Do not add React\n  component, hook, or render tests unless asked.\n- Do not write raw SQL in tests. Use seed and harness helpers, then generated\n  sqlc queries from `pkg/db`. If no query exists, add one to\n  `pkg/db/queries/` and run `mise run generate`. For ClickHouse, append\n  `pkg/clickhouse/schema` structs.\n- Do not write raw JSON strings in tests. Encode and decode typed structs,\n  preferably existing OpenAPI or handler request and response types.\n- Do not hardcode IDs in tests. Generate them with `uid.New(uid.<Entity>Prefix)`\n  from `pkg/uid`.\n- Exceptions to these rules, such as malformed input or exact-byte tests, are in\n  `contributing/quality/testing/anti-patterns.md`.\n- Be extremely conservative with code comments. \n\n## Code comments\n\n- Avoid code comments by default.\n- Only add a comment when the code itself cannot clearly communicate why something is necessary.\n- Never comment what the code does.\n- Comments should be rare and reserved for essential context that a future reader would otherwise be unable to infer, such as non-obvious constraints, intentional trade-offs, or decisions that cannot be expressed through the code itself.\n- Do not add comments solely to explain changes to the current reviewer, unless explicitly asked.\n\n## Go conventions\n\n- Build Go through `mise run build` and test Go through Rask with\n  `mise run test` or `mise exec -- rask ./path`.\n- Use `mise exec -- go test` for targeted fuzzing, which needs Go's fuzz runner.\n- Use `github.com/stretchr/testify/require` in tests.\n- Use `t.Helper()` in test helpers.\n- Use `t.Cleanup()` for resources.\n- Prefer `fault` for contextual errors and `assert` for invariants.\n- After changing generated inputs, run `mise run generate`.\n\n## TypeScript conventions\n\n- Run pnpm through mise: `mise exec -- pnpm --dir=web ...`.\n- Keep package manager changes scoped to `web/` unless a repo task says\n  otherwise.\n- Do not bypass formatter or type checks by weakening types.\n- Use the local app/package patterns in `web/` before introducing abstractions.\n\n## Documentation conventions\n\n- Follow `contributing/quality/documentation.md` for symbol,\n  package, and site documentation.\n- Product docs live in `docs/` and need `docs/docs.json` nav\n  entries when adding pages.\n- Use `bash` for shell code blocks.\n- Prefer root-relative internal doc links.\n- Do not use em dashes in docs.\n\n## Verification\n\nDuring development, choose the smallest check that proves the change. The build\nand pre-push requirements below still apply.\n\n- Go source change: targeted `mise exec -- rask ./path`.\n- Go file added or imports changed: `mise run build` (includes lint).\n- Shared Go behavior or broad service change: `mise run test` when practical.\n- TypeScript change: targeted `mise exec -- pnpm --dir=web ...` command.\n- Formatting-sensitive change: format changed files through `mise exec` or a\n  scoped task. Use repository-wide `mise run fmt` only when that scope is needed.\n- Docs-only change: link/content review. Note if no formatter applies.\n- Before pushing: `mise run test`.\n- Never install tooling or build an environment to verify a change. If the\n  existing checks cannot cover it, say so instead.\n\nAfter applicable checks pass, repeat or broaden verification only for subsequent\nchanges, failures, or unresolved risks. Report failed or skipped verification\nhonestly.\n\n## PlanetScale and Query Insights\n\nUnkey runs on PlanetScale Vitess. Every production MySQL query should carry SQLCommenter tags so Query Insights can attribute load by service, operation, and deploy.\n\n- Go: inject tags through `db.Config.Tags` and `sqlcomment.ForService` in service `run.go`. See [`pkg/mysql/sqlcomment`](pkg/mysql/sqlcomment/doc.go).\n- TypeScript: use `createCommentedPool` from `@unkey/db` instead of raw `mysql.createPool`.\n- Never put high-cardinality values (user ids, key ids, request ids) in SQL comments.\n\n## High-signal references\n\nRead the page that covers the area before writing code in it. These pages define\nhow Unkey code is written; this file only summarizes them.\n\n- Local development: `contributing/local/development.md`.\n- Build workflow: `contributing/tooling/builds.md`.\n- Code quality: `contributing/quality/code-quality.md`.\n- Testing: `contributing/quality/testing/index.md`.\n- Documentation: `contributing/quality/documentation.md`.\n\n<!-- polylane:start -->\n## Investigating production with Polylane\n\n[Polylane](https://polylane.com/?ref=github.onboarding-pr) is an AI production engineer: it watches deploys, telemetry, incidents, and the infrastructure this repository ships to, investigates problems as they happen, and proposes fixes as pull requests. It is connected to this repository and available to coding agents through the [Polylane MCP server](https://mcp.polylane.com/mcp).\n\n- When a question involves production behaviour (an error, a spike, a deploy, a missing signal), query Polylane through its MCP tools before reasoning from the code alone.\n- When debugging a failure, start from the incident or issue Polylane recorded: it carries the evidence an investigation already gathered.\n- Polylane reviews pull requests in this repository against the live infrastructure. Read its review comment before merging changes that touch production paths.\n<!-- polylane:end -->\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/unkeyed/unkey/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/unkeyed/unkey/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/unkeyed/unkey/HEAD/.claude-plugin/plugin.json)"},"files":{"CLAUDE.md":"@AGENTS.md\n\n<!-- polylane:start -->\n## Investigating production with Polylane\n\n[Polylane](https://polylane.com/?ref=github.onboarding-pr) is an AI production engineer: it watches deploys, telemetry, incidents, and the infrastructure this repository ships to, investigates problems as they happen, and proposes fixes as pull requests. It is connected to this repository and available to coding agents through the [Polylane MCP server](https://mcp.polylane.com/mcp).\n\n- When a question involves production behaviour (an error, a spike, a deploy, a missing signal), query Polylane through its MCP tools before reasoning from the code alone.\n- When debugging a failure, start from the incident or issue Polylane recorded: it carries the evidence an investigation already gathered.\n- Polylane reviews pull requests in this repository against the live infrastructure. Read its review comment before merging changes that touch production paths.\n<!-- polylane:end -->\n","AGENTS.md":"# AGENTS.md - Unkey agent guide\n\nThis file is the first stop for agents working in this repo. Keep changes small,\ntyped, verified, and routed through `mise`.\n\n## Scoped guidance and additional context\n\nBefore changing a file, read this guide and every nested `AGENTS.md` along the\npath to that file. Do this explicitly if your harness does not load nested\nguidance automatically. For new files, check their parent directories. Repeat\nthe check when work crosses into another service or package.\n\nNested guidance applies to its directory and descendants. Keep the root rules\nand add the more specific local constraints. Each service under `svc/` has an\n`AGENTS.md`; `svc/ctrl/worker/` has additional Restate guidance. Keep shared rules\nhere and service-specific constraints near the code, without copying them into\nparallel instruction files.\n\nThe root `contributing/` directory holds testing, code quality,\nand screenshot and recording standards. These standards stay in the repository,\nnot in Notion. Read the relevant guide for your task.\n\nBroader engineering context, design discussions, and operational workflows are in\n[Notion's Engineering wiki](https://app.notion.com/p/ed5512d643f38377b0d38164de40681e).\nWhen repository guidance does not answer a task-relevant question, use the\nNotion MCP server to search for the service or topic and fetch the relevant\npages. Search results alone are not the full context. Distinguish proposals\nand historical plans from accepted decisions, and check implementation claims\nagainst the code.\n\nIf Notion MCP is unavailable, the relevant page is inaccessible, or a material\ndecision is still unclear, ask your operator for the missing context. Do not\ninvent requirements or silently resolve conflicting guidance. Continue work\nthat does not depend on the missing information.\n\n## Communication\n\n- Be concise.\n- Say what changed and how you verified it.\n- If you provide a plan, end with unresolved questions, if any.\n- Preserve pre-existing uncommitted changes and unrelated work. Modify existing\n  code as needed for the requested task.\n- Complete authorized work through verification. Resolve routine implementation\n  choices using repository patterns. Ask only when missing information materially\n  affects scope or correctness; continue independent work while waiting.\n\n## Source of truth\n\n- Tooling and task runner: `.mise/config.toml`, `.mise/mise.lock`, and\n  `.mise/tasks/*`.\n- Engineering standards: `contributing/`. These are normative\n  standards for writing code, not only reference material for the docs site.\n- Product docs: `docs/`.\n- Go tooling: `go.mod`, `go.sum`, and `.golangci.yaml`. Rask is pinned as a\n  tool in `.mise/config.toml`; it has no config file of its own.\n- Web workspace: `web/package.json`, `web/pnpm-workspace.yaml`, and\n  `web/pnpm-lock.yaml`.\n\n## Repository map\n\n- `cmd/`: development commands and utilities.\n- `build/`: CLI and service entrypoints.\n- `svc/`: Go services (`api`, `ctrl`, `frontline`, `heimdall`, `kitchensink`,\n  `krane`, `logdrain`, `vault`).\n- `pkg/`: shared Go libraries.\n- `internal/services/`: shared internal Go services.\n- `proto/` and `gen/`: protobuf definitions and generated code.\n- `web/`: TypeScript apps (`web/apps/`) and shared packages, database schema,\n  and tooling. Shared code lives in `web/internal/`; there is no\n  `web/packages/`.\n- `docs/`: Mintlify product documentation.\n- `contributing/`: Engineering workflow and coding standards.\n- `dev/`: local development, Tilt, Kubernetes, and formatting config.\n\n## Tooling rules\n\nUse `mise` for all installs, tasks, and direct tool execution. Makefiles are\nlegacy and should not be used.\n\n```bash\n# Install pinned toolchain\n./dev/install-mise\nmise install\n\n# Discover tasks\nmise tasks\nmise run help\n```\n\nPrefer `mise run <task>` when a task covers the required scope. Use\n`mise exec -- <tool>` when no task applies or a broader task would touch\nunrelated files, such as when formatting changed files.\n\n### Common tasks\n\n```bash\nmise run build          # lint and Go build, writes ./bin/unkey\nmise run lint           # golangci-lint checks\nmise run test           # run Go test suite through Rask\nmise run fmt            # dprint, go fmt, buf format, pnpm fmt\nmise run generate       # SQL, protobuf, Go generators, fmt\nmise run generate-bpf   # heimdall eBPF bindings\nmise run dev            # local Kubernetes/Tilt dev environment\nmise run dashboard      # dashboard-focused local setup\nmise run down           # stop minikube, preserve data (exit Tilt first)\nmise run tunnel         # port-forward 80/443 for *.unkey.local\nmise run unkey -- ...   # run the Unkey CLI\n```\n\n### Direct tool examples\n\n```bash\nmise exec -- rask ./pkg/cache\nmise exec -- pnpm --dir=web test\nmise exec -- go test -fuzz=FuzzInRange -fuzztime=30s ./pkg/assert/\n```\n\n## Code standards\n\n- Make minimal, surgical changes.\n- Preserve type safety. Do not add TypeScript `any`, non-null assertions, or\n  unsafe casts.\n- Model domain states explicitly. Parse untyped input at boundaries.\n- Prefer existing packages, helpers, and patterns before adding new ones.\n- Avoid new dependencies unless the local implementation would be worse.\n- Keep variable scope small.\n- Name from most to least significant, with qualifiers last: `freqMax`, not\n  `maxFreq`. Follow this even when nearby code does not. See\n  [Naming](contributing/quality/code-quality.md#naming).\n- Handle every error. If a state is impossible, assert it rather than ignoring it.\n- Add tests for Go behavior and pure TypeScript functions. Do not add React\n  component, hook, or render tests unless asked.\n- Do not write raw SQL in tests. Use seed and harness helpers, then generated\n  sqlc queries from `pkg/db`. If no query exists, add one to\n  `pkg/db/queries/` and run `mise run generate`. For ClickHouse, append\n  `pkg/clickhouse/schema` structs.\n- Do not write raw JSON strings in tests. Encode and decode typed structs,\n  preferably existing OpenAPI or handler request and response types.\n- Do not hardcode IDs in tests. Generate them with `uid.New(uid.<Entity>Prefix)`\n  from `pkg/uid`.\n- Exceptions to these rules, such as malformed input or exact-byte tests, are in\n  `contributing/quality/testing/anti-patterns.md`.\n- Be extremely conservative with code comments. \n\n## Code comments\n\n- Avoid code comments by default.\n- Only add a comment when the code itself cannot clearly communicate why something is necessary.\n- Never comment what the code does.\n- Comments should be rare and reserved for essential context that a future reader would otherwise be unable to infer, such as non-obvious constraints, intentional trade-offs, or decisions that cannot be expressed through the code itself.\n- Do not add comments solely to explain changes to the current reviewer, unless explicitly asked.\n\n## Go conventions\n\n- Build Go through `mise run build` and test Go through Rask with\n  `mise run test` or `mise exec -- rask ./path`.\n- Use `mise exec -- go test` for targeted fuzzing, which needs Go's fuzz runner.\n- Use `github.com/stretchr/testify/require` in tests.\n- Use `t.Helper()` in test helpers.\n- Use `t.Cleanup()` for resources.\n- Prefer `fault` for contextual errors and `assert` for invariants.\n- After changing generated inputs, run `mise run generate`.\n\n## TypeScript conventions\n\n- Run pnpm through mise: `mise exec -- pnpm --dir=web ...`.\n- Keep package manager changes scoped to `web/` unless a repo task says\n  otherwise.\n- Do not bypass formatter or type checks by weakening types.\n- Use the local app/package patterns in `web/` before introducing abstractions.\n\n## Documentation conventions\n\n- Follow `contributing/quality/documentation.md` for symbol,\n  package, and site documentation.\n- Product docs live in `docs/` and need `docs/docs.json` nav\n  entries when adding pages.\n- Use `bash` for shell code blocks.\n- Prefer root-relative internal doc links.\n- Do not use em dashes in docs.\n\n## Verification\n\nDuring development, choose the smallest check that proves the change. The build\nand pre-push requirements below still apply.\n\n- Go source change: targeted `mise exec -- rask ./path`.\n- Go file added or imports changed: `mise run build` (includes lint).\n- Shared Go behavior or broad service change: `mise run test` when practical.\n- TypeScript change: targeted `mise exec -- pnpm --dir=web ...` command.\n- Formatting-sensitive change: format changed files through `mise exec` or a\n  scoped task. Use repository-wide `mise run fmt` only when that scope is needed.\n- Docs-only change: link/content review. Note if no formatter applies.\n- Before pushing: `mise run test`.\n- Never install tooling or build an environment to verify a change. If the\n  existing checks cannot cover it, say so instead.\n\nAfter applicable checks pass, repeat or broaden verification only for subsequent\nchanges, failures, or unresolved risks. Report failed or skipped verification\nhonestly.\n\n## PlanetScale and Query Insights\n\nUnkey runs on PlanetScale Vitess. Every production MySQL query should carry SQLCommenter tags so Query Insights can attribute load by service, operation, and deploy.\n\n- Go: inject tags through `db.Config.Tags` and `sqlcomment.ForService` in service `run.go`. See [`pkg/mysql/sqlcomment`](pkg/mysql/sqlcomment/doc.go).\n- TypeScript: use `createCommentedPool` from `@unkey/db` instead of raw `mysql.createPool`.\n- Never put high-cardinality values (user ids, key ids, request ids) in SQL comments.\n\n## High-signal references\n\nRead the page that covers the area before writing code in it. These pages define\nhow Unkey code is written; this file only summarizes them.\n\n- Local development: `contributing/local/development.md`.\n- Build workflow: `contributing/tooling/builds.md`.\n- Code quality: `contributing/quality/code-quality.md`.\n- Testing: `contributing/quality/testing/index.md`.\n- Documentation: `contributing/quality/documentation.md`.\n\n<!-- polylane:start -->\n## Investigating production with Polylane\n\n[Polylane](https://polylane.com/?ref=github.onboarding-pr) is an AI production engineer: it watches deploys, telemetry, incidents, and the infrastructure this repository ships to, investigates problems as they happen, and proposes fixes as pull requests. It is connected to this repository and available to coding agents through the [Polylane MCP server](https://mcp.polylane.com/mcp).\n\n- When a question involves production behaviour (an error, a spike, a deploy, a missing signal), query Polylane through its MCP tools before reasoning from the code alone.\n- When debugging a failure, start from the incident or issue Polylane recorded: it carries the evidence an investigation already gathered.\n- Polylane reviews pull requests in this repository against the live infrastructure. Read its review comment before merging changes that touch production paths.\n<!-- polylane:end -->\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/unkeyed/unkey/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/unkeyed/unkey/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/unkeyed/unkey/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/unkeyed/unkey/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md - Unkey agent guide\n\nThis file is the first stop for agents working in this repo. Keep changes small,\ntyped, verified, and routed through `mise`.\n\n## Scoped guidance and additional context\n\nBefore changing a file, read this guide and every nested `AGENTS.md` along the\npath to that file. Do this explicitly if your harness does not load nested\nguidance automatically. For new files, check their parent directories. Repeat\nthe check when work crosses into another service or package.\n\nNested guidance applies to its directory and descendants. Keep the root rules\nand add the more specific local constraints. Each service under `svc/` has an\n`AGENTS.md`; `svc/ctrl/worker/` has additional Restate guidance. Keep shared rules\nhere and service-specific constraints near the code, without copying them into\nparallel instruction files.\n\nThe root `contributing/` directory holds testing, code quality,\nand screenshot and recording standards. These standards stay in the repository,\nnot in Notion. Read the relevant guide for your task.\n\nBroader engineering context, design discussions, and operational workflows are in\n[Notion's Engineering wiki](https://app.notion.com/p/ed5512d643f38377b0d38164de40681e).\nWhen repository guidance does not answer a task-relevant question, use the\nNotion MCP server to search for the service or topic and fetch the relevant\npages. Search results alone are not the full context. Distinguish proposals\nand historical plans from accepted decisions, and check implementation claims\nagainst the code.\n\nIf Notion MCP is unavailable, the relevant page is inaccessible, or a material\ndecision is still unclear, ask your operator for the missing context. Do not\ninvent requirements or silently resolve conflicting guidance. Continue work\nthat does not depend on the missing information.\n\n## Communication\n\n- Be concise.\n- Say what changed and how you verified it.\n- If you provide a plan, end with unresolved questions, if any.\n- Preserve pre-existing uncommitted changes and unrelated work. Modify existing\n  code as needed for the requested task.\n- Complete authorized work through verification. Resolve routine implementation\n  choices using repository patterns. Ask only when missing information materially\n  affects scope or correctness; continue independent work while waiting.\n\n## Source of truth\n\n- Tooling and task runner: `.mise/config.toml`, `.mise/mise.lock`, and\n  `.mise/tasks/*`.\n- Engineering standards: `contributing/`. These are normative\n  standards for writing code, not only reference material for the docs site.\n- Product docs: `docs/`.\n- Go tooling: `go.mod`, `go.sum`, and `.golangci.yaml`. Rask is pinned as a\n  tool in `.mise/config.toml`; it has no config file of its own.\n- Web workspace: `web/package.json`, `web/pnpm-workspace.yaml`, and\n  `web/pnpm-lock.yaml`.\n\n## Repository map\n\n- `cmd/`: development commands and utilities.\n- `build/`: CLI and service entrypoints.\n- `svc/`: Go services (`api`, `ctrl`, `frontline`, `heimdall`, `kitchensink`,\n  `krane`, `logdrain`, `vault`).\n- `pkg/`: shared Go libraries.\n- `internal/services/`: shared internal Go services.\n- `proto/` and `gen/`: protobuf definitions and generated code.\n- `web/`: TypeScript apps (`web/apps/`) and shared packages, database schema,\n  and tooling. Shared code lives in `web/internal/`; there is no\n  `web/packages/`.\n- `docs/`: Mintlify product documentation.\n- `contributing/`: Engineering workflow and coding standards.\n- `dev/`: local development, Tilt, Kubernetes, and formatting config.\n\n## Tooling rules\n\nUse `mise` for all installs, tasks, and direct tool execution. Makefiles are\nlegacy and should not be used.\n\n```bash\n# Install pinned toolchain\n./dev/install-mise\nmise install\n\n# Discover tasks\nmise tasks\nmise run help\n```\n\nPrefer `mise run <task>` when a task covers the required scope. Use\n`mise exec -- <tool>` when no task applies or a broader task would touch\nunrelated files, such as when formatting changed files.\n\n### Common tasks\n\n```bash\nmise run build          # lint and Go build, writes ./bin/unkey\nmise run lint           # golangci-lint checks\nmise run test           # run Go test suite through Rask\nmise run fmt            # dprint, go fmt, buf format, pnpm fmt\nmise run generate       # SQL, protobuf, Go generators, fmt\nmise run generate-bpf   # heimdall eBPF bindings\nmise run dev            # local Kubernetes/Tilt dev environment\nmise run dashboard      # dashboard-focused local setup\nmise run down           # stop minikube, preserve data (exit Tilt first)\nmise run tunnel         # port-forward 80/443 for *.unkey.local\nmise run unkey -- ...   # run the Unkey CLI\n```\n\n### Direct tool examples\n\n```bash\nmise exec -- rask ./pkg/cache\nmise exec -- pnpm --dir=web test\nmise exec -- go test -fuzz=FuzzInRange -fuzztime=30s ./pkg/assert/\n```\n\n## Code standards\n\n- Make minimal, surgical changes.\n- Preserve type safety. Do not add TypeScript `any`, non-null assertions, or\n  unsafe casts.\n- Model domain states explicitly. Parse untyped input at boundaries.\n- Prefer existing packages, helpers, and patterns before adding new ones.\n- Avoid new dependencies unless the local implementation would be worse.\n- Keep variable scope small.\n- Name from most to least significant, with qualifiers last: `freqMax`, not\n  `maxFreq`. Follow this even when nearby code does not. See\n  [Naming](contributing/quality/code-quality.md#naming).\n- Handle every error. If a state is impossible, assert it rather than ignoring it.\n- Add tests for Go behavior and pure TypeScript functions. Do not add React\n  component, hook, or render tests unless asked.\n- Do not write raw SQL in tests. Use seed and harness helpers, then generated\n  sqlc queries from `pkg/db`. If no query exists, add one to\n  `pkg/db/queries/` and run `mise run generate`. For ClickHouse, append\n  `pkg/clickhouse/schema` structs.\n- Do not write raw JSON strings in tests. Encode and decode typed structs,\n  preferably existing OpenAPI or handler request and response types.\n- Do not hardcode IDs in tests. Generate them with `uid.New(uid.<Entity>Prefix)`\n  from `pkg/uid`.\n- Exceptions to these rules, such as malformed input or exact-byte tests, are in\n  `contributing/quality/testing/anti-patterns.md`.\n- Be extremely conservative with code comments. \n\n## Code comments\n\n- Avoid code comments by default.\n- Only add a comment when the code itself cannot clearly communicate why something is necessary.\n- Never comment what the code does.\n- Comments should be rare and reserved for essential context that a future reader would otherwise be unable to infer, such as non-obvious constraints, intentional trade-offs, or decisions that cannot be expressed through the code itself.\n- Do not add comments solely to explain changes to the current reviewer, unless explicitly asked.\n\n## Go conventions\n\n- Build Go through `mise run build` and test Go through Rask with\n  `mise run test` or `mise exec -- rask ./path`.\n- Use `mise exec -- go test` for targeted fuzzing, which needs Go's fuzz runner.\n- Use `github.com/stretchr/testify/require` in tests.\n- Use `t.Helper()` in test helpers.\n- Use `t.Cleanup()` for resources.\n- Prefer `fault` for contextual errors and `assert` for invariants.\n- After changing generated inputs, run `mise run generate`.\n\n## TypeScript conventions\n\n- Run pnpm through mise: `mise exec -- pnpm --dir=web ...`.\n- Keep package manager changes scoped to `web/` unless a repo task says\n  otherwise.\n- Do not bypass formatter or type checks by weakening types.\n- Use the local app/package patterns in `web/` before introducing abstractions.\n\n## Documentation conventions\n\n- Follow `contributing/quality/documentation.md` for symbol,\n  package, and site documentation.\n- Product docs live in `docs/` and need `docs/docs.json` nav\n  entries when adding pages.\n- Use `bash` for shell code blocks.\n- Prefer root-relative internal doc links.\n- Do not use em dashes in docs.\n\n## Verification\n\nDuring development, choose the smallest check that proves the change. The build\nand pre-push requirements below still apply.\n\n- Go source change: targeted `mise exec -- rask ./path`.\n- Go file added or imports changed: `mise run build` (includes lint).\n- Shared Go behavior or broad service change: `mise run test` when practical.\n- TypeScript change: targeted `mise exec -- pnpm --dir=web ...` command.\n- Formatting-sensitive change: format changed files through `mise exec` or a\n  scoped task. Use repository-wide `mise run fmt` only when that scope is needed.\n- Docs-only change: link/content review. Note if no formatter applies.\n- Before pushing: `mise run test`.\n- Never install tooling or build an environment to verify a change. If the\n  existing checks cannot cover it, say so instead.\n\nAfter applicable checks pass, repeat or broaden verification only for subsequent\nchanges, failures, or unresolved risks. Report failed or skipped verification\nhonestly.\n\n## PlanetScale and Query Insights\n\nUnkey runs on PlanetScale Vitess. Every production MySQL query should carry SQLCommenter tags so Query Insights can attribute load by service, operation, and deploy.\n\n- Go: inject tags through `db.Config.Tags` and `sqlcomment.ForService` in service `run.go`. See [`pkg/mysql/sqlcomment`](pkg/mysql/sqlcomment/doc.go).\n- TypeScript: use `createCommentedPool` from `@unkey/db` instead of raw `mysql.createPool`.\n- Never put high-cardinality values (user ids, key ids, request ids) in SQL comments.\n\n## High-signal references\n\nRead the page that covers the area before writing code in it. These pages define\nhow Unkey code is written; this file only summarizes them.\n\n- Local development: `contributing/local/development.md`.\n- Build workflow: `contributing/tooling/builds.md`.\n- Code quality: `contributing/quality/code-quality.md`.\n- Testing: `contributing/quality/testing/index.md`.\n- Documentation: `contributing/quality/documentation.md`.\n\n<!-- polylane:start -->\n## Investigating production with Polylane\n\n[Polylane](https://polylane.com/?ref=github.onboarding-pr) is an AI production engineer: it watches deploys, telemetry, incidents, and the infrastructure this repository ships to, investigates problems as they happen, and proposes fixes as pull requests. It is connected to this repository and available to coding agents through the [Polylane MCP server](https://mcp.polylane.com/mcp).\n\n- When a question involves production behaviour (an error, a spike, a deploy, a missing signal), query Polylane through its MCP tools before reasoning from the code alone.\n- When debugging a failure, start from the incident or issue Polylane recorded: it carries the evidence an investigation already gathered.\n- Polylane reviews pull requests in this repository against the live infrastructure. Read its review comment before merging changes that touch production paths.\n<!-- polylane:end -->\n","isInternal":false,"tokens":2452,"sizeBytes":10812},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/unkeyed/unkey/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"@AGENTS.md\n\n<!-- polylane:start -->\n## Investigating production with Polylane\n\n[Polylane](https://polylane.com/?ref=github.onboarding-pr) is an AI production engineer: it watches deploys, telemetry, incidents, and the infrastructure this repository ships to, investigates problems as they happen, and proposes fixes as pull requests. It is connected to this repository and available to coding agents through the [Polylane MCP server](https://mcp.polylane.com/mcp).\n\n- When a question involves production behaviour (an error, a spike, a deploy, a missing signal), query Polylane through its MCP tools before reasoning from the code alone.\n- When debugging a failure, start from the incident or issue Polylane recorded: it carries the evidence an investigation already gathered.\n- Polylane reviews pull requests in this repository against the live infrastructure. Read its review comment before merging changes that touch production paths.\n<!-- polylane:end -->\n","isInternal":false,"tokens":201,"sizeBytes":960},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/unkeyed/unkey/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/unkeyed/unkey/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":192},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/unkeyed/unkey/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/unkeyed/unkey/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":178},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/unkeyed/unkey/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/unkeyed/unkey/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":171}],"systemPromptSnippet":"<yakaai_skills repo=\"unkeyed/unkey\">\n<!-- File: AGENTS.md (Tokens: ~2452 | Category: root-instruction) -->\n# AGENTS.md - Unkey agent guide\n\nThis file is the first stop for agents working in this repo. Keep changes small,\ntyped, verified, and routed through `mise`.\n\n## Scoped guidance and additional context\n\nBefore changing a file, read this guide and every nested `AGENTS.md` along the\npath to that file. Do this explicitly if your harness does not load nested\nguidance automatically. For new files, check their parent directories. Repeat\nthe check when work crosses into another service or package.\n\nNested guidance applies to its directory and descendants. Keep the root rules\nand add the more specific local constraints. Each service under `svc/` has an\n`AGENTS.md`; `svc/ctrl/worker/` has additional Restate guidance. Keep shared rules\nhere and service-specific constraints near the code, without copying them into\nparallel instruction files.\n\nThe root `contributing/` directory holds testing, code quality,\nand screenshot and recording standards. These standards stay in the repository,\nnot in Notion. Read the relevant guide for your task.\n\nBroader engineering context, design discussions, and operational workflows are in\n[Notion's Engineering wiki](https://app.notion.com/p/ed5512d643f38377b0d38164de40681e).\nWhen repository guidance does not answer a task-relevant question, use the\nNotion MCP server to search for the service or topic and fetch the relevant\npages. Search results alone are not the full context. Distinguish proposals\nand historical plans from accepted decisions, and check implementation claims\nagainst the code.\n\nIf Notion MCP is unavailable, the relevant page is inaccessible, or a material\ndecision is still unclear, ask your operator for the missing context. Do not\ninvent requirements or silently resolve conflicting guidance. Continue work\nthat does not depend on the missing information.\n\n## Communication\n\n- Be concise.\n- Say what changed and how you verified it.\n- If you provide a plan, end with unresolved questions, if any.\n- Preserve pre-existing uncommitted changes and unrelated work. Modify existing\n  code as needed for the requested task.\n- Complete authorized work through verification. Resolve routine implementation\n  choices using repository patterns. Ask only when missing information materially\n  affects scope or correctness; continue independent work while waiting.\n\n## Source of truth\n\n- Tooling and task runner: `.mise/config.toml`, `.mise/mise.lock`, and\n  `.mise/tasks/*`.\n- Engineering standards: `contributing/`. These are normative\n  standards for writing code, not only reference material for the docs site.\n- Product docs: `docs/`.\n- Go tooling: `go.mod`, `go.sum`, and `.golangci.yaml`. Rask is pinned as a\n  tool in `.mise/config.toml`; it has no config file of its own.\n- Web workspace: `web/package.json`, `web/pnpm-workspace.yaml`, and\n  `web/pnpm-lock.yaml`.\n\n## Repository map\n\n- `cmd/`: development commands and utilities.\n- `build/`: CLI and service entrypoints.\n- `svc/`: Go services (`api`, `ctrl`, `frontline`, `heimdall`, `kitchensink`,\n  `krane`, `logdrain`, `vault`).\n- `pkg/`: shared Go libraries.\n- `internal/services/`: shared internal Go services.\n- `proto/` and `gen/`: protobuf definitions and generated code.\n- `web/`: TypeScript apps (`web/apps/`) and shared packages, database schema,\n  and tooling. Shared code lives in `web/internal/`; there is no\n  `web/packages/`.\n- `docs/`: Mintlify product documentation.\n- `contributing/`: Engineering workflow and coding standards.\n- `dev/`: local development, Tilt, Kubernetes, and formatting config.\n\n## Tooling rules\n\nUse `mise` for all installs, tasks, and direct tool execution. Makefiles are\nlegacy and should not be used.\n\n```bash\n# Install pinned toolchain\n./dev/install-mise\nmise install\n\n# Discover tasks\nmise tasks\nmise run help\n```\n\nPrefer `mise run <task>` when a task covers the required scope. Use\n`mise exec -- <tool>` when no task applies or a broader task would touch\nunrelated files, such as when formatting changed files.\n\n### Common tasks\n\n```bash\nmise run build          # lint and Go build, writes ./bin/unkey\nmise run lint           # golangci-lint checks\nmise run test           # run Go test suite through Rask\nmise run fmt            # dprint, go fmt, buf format, pnpm fmt\nmise run generate       # SQL, protobuf, Go generators, fmt\nmise run generate-bpf   # heimdall eBPF bindings\nmise run dev            # local Kubernetes/Tilt dev environment\nmise run dashboard      # dashboard-focused local setup\nmise run down           # stop minikube, preserve data (exit Tilt first)\nmise run tunnel         # port-forward 80/443 for *.unkey.local\nmise run unkey -- ...   # run the Unkey CLI\n```\n\n### Direct tool examples\n\n```bash\nmise exec -- rask ./pkg/cache\nmise exec -- pnpm --dir=web test\nmise exec -- go test -fuzz=FuzzInRange -fuzztime=30s ./pkg/assert/\n```\n\n## Code standards\n\n- Make minimal, surgical changes.\n- Preserve type safety. Do not add TypeScript `any`, non-null assertions, or\n  unsafe casts.\n- Model domain states explicitly. Parse untyped input at boundaries.\n- Prefer existing packages, helpers, and patterns before adding new ones.\n- Avoid new dependencies unless the local implementation would be worse.\n- Keep variable scope small.\n- Name from most to least significant, with qualifiers last: `freqMax`, not\n  `maxFreq`. Follow this even when nearby code does not. See\n  [Naming](contributing/quality/code-quality.md#naming).\n- Handle every error. If a state is impossible, assert it rather than ignoring it.\n- Add tests for Go behavior and pure TypeScript functions. Do not add React\n  component, hook, or render tests unless asked.\n- Do not write raw SQL in tests. Use seed and harness helpers, then generated\n  sqlc queries from `pkg/db`. If no query exists, add one to\n  `pkg/db/queries/` and run `mise run generate`. For ClickHouse, append\n  `pkg/clickhouse/schema` structs.\n- Do not write raw JSON strings in tests. Encode and decode typed structs,\n  preferably existing OpenAPI or handler request and response types.\n- Do not hardcode IDs in tests. Generate them with `uid.New(uid.<Entity>Prefix)`\n  from `pkg/uid`.\n- Exceptions to these rules, such as malformed input or exact-byte tests, are in\n  `contributing/quality/testing/anti-patterns.md`.\n- Be extremely conservative with code comments. \n\n## Code comments\n\n- Avoid code comments by default.\n- Only add a comment when the code itself cannot clearly communicate why something is necessary.\n- Never comment what the code does.\n- Comments should be rare and reserved for essential context that a future reader would otherwise be unable to infer, such as non-obvious constraints, intentional trade-offs, or decisions that cannot be expressed through the code itself.\n- Do not add comments solely to explain changes to the current reviewer, unless explicitly asked.\n\n## Go conventions\n\n- Build Go through `mise run build` and test Go through Rask with\n  `mise run test` or `mise exec -- rask ./path`.\n- Use `mise exec -- go test` for targeted fuzzing, which needs Go's fuzz runner.\n- Use `github.com/stretchr/testify/require` in tests.\n- Use `t.Helper()` in test helpers.\n- Use `t.Cleanup()` for resources.\n- Prefer `fault` for contextual errors and `assert` for invariants.\n- After changing generated inputs, run `mise run generate`.\n\n## TypeScript conventions\n\n- Run pnpm through mise: `mise exec -- pnpm --dir=web ...`.\n- Keep package manager changes scoped to `web/` unless a repo task says\n  otherwise.\n- Do not bypass formatter or type checks by weakening types.\n- Use the local app/package patterns in `web/` before introducing abstractions.\n\n## Documentation conventions\n\n- Follow `contributing/quality/documentation.md` for symbol,\n  package, and site documentation.\n- Product docs live in `docs/` and need `docs/docs.json` nav\n  entries when adding pages.\n- Use `bash` for shell code blocks.\n- Prefer root-relative internal doc links.\n- Do not use em dashes in docs.\n\n## Verification\n\nDuring development, choose the smallest check that proves the change. The build\nand pre-push requirements below still apply.\n\n- Go source change: targeted `mise exec -- rask ./path`.\n- Go file added or imports changed: `mise run build` (includes lint).\n- Shared Go behavior or broad service change: `mise run test` when practical.\n- TypeScript change: targeted `mise exec -- pnpm --dir=web ...` command.\n- Formatting-sensitive change: format changed files through `mise exec` or a\n  scoped task. Use repository-wide `mise run fmt` only when that scope is needed.\n- Docs-only change: link/content review. Note if no formatter applies.\n- Before pushing: `mise run test`.\n- Never install tooling or build an environment to verify a change. If the\n  existing checks cannot cover it, say so instead.\n\nAfter applicable checks pass, repeat or broaden verification only for subsequent\nchanges, failures, or unresolved risks. Report failed or skipped verification\nhonestly.\n\n## PlanetScale and Query Insights\n\nUnkey runs on PlanetScale Vitess. Every production MySQL query should carry SQLCommenter tags so Query Insights can attribute load by service, operation, and deploy.\n\n- Go: inject tags through `db.Config.Tags` and `sqlcomment.ForService` in service `run.go`. See [`pkg/mysql/sqlcomment`](pkg/mysql/sqlcomment/doc.go).\n- TypeScript: use `createCommentedPool` from `@unkey/db` instead of raw `mysql.createPool`.\n- Never put high-cardinality values (user ids, key ids, request ids) in SQL comments.\n\n## High-signal references\n\nRead the page that covers the area before writing code in it. These pages define\nhow Unkey code is written; this file only summarizes them.\n\n- Local development: `contributing/local/development.md`.\n- Build workflow: `contributing/tooling/builds.md`.\n- Code quality: `contributing/quality/code-quality.md`.\n- Testing: `contributing/quality/testing/index.md`.\n- Documentation: `contributing/quality/documentation.md`.\n\n<!-- polylane:start -->\n## Investigating production with Polylane\n\n[Polylane](https://polylane.com/?ref=github.onboarding-pr) is an AI production engineer: it watches deploys, telemetry, incidents, and the infrastructure this repository ships to, investigates problems as they happen, and proposes fixes as pull requests. It is connected to this repository and available to coding agents through the [Polylane MCP server](https://mcp.polylane.com/mcp).\n\n- When a question involves production behaviour (an error, a spike, a deploy, a missing signal), query Polylane through its MCP tools before reasoning from the code alone.\n- When debugging a failure, start from the incident or issue Polylane recorded: it carries the evidence an investigation already gathered.\n- Polylane reviews pull requests in this repository against the live infrastructure. Read its review comment before merging changes that touch production paths.\n<!-- polylane:end -->\n\n<!-- File: CLAUDE.md (Tokens: ~201 | Category: claude-rule) -->\n@AGENTS.md\n\n<!-- polylane:start -->\n## Investigating production with Polylane\n\n[Polylane](https://polylane.com/?ref=github.onboarding-pr) is an AI production engineer: it watches deploys, telemetry, incidents, and the infrastructure this repository ships to, investigates problems as they happen, and proposes fixes as pull requests. It is connected to this repository and available to coding agents through the [Polylane MCP server](https://mcp.polylane.com/mcp).\n\n- When a question involves production behaviour (an error, a spike, a deploy, a missing signal), query Polylane through its MCP tools before reasoning from the code alone.\n- When debugging a failure, start from the incident or issue Polylane recorded: it carries the evidence an investigation already gathered.\n- Polylane reviews pull requests in this repository against the live infrastructure. Read its review comment before merging changes that touch production paths.\n<!-- polylane:end -->\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/unkeyed/unkey/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/unkeyed/unkey/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/unkeyed/unkey/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}