From apollo-skills
Generates version-aware YAML configs for Apollo Router v1.x/v2.x in federated GraphQL supergraphs. Covers setup, routing, CORS, plugins, telemetry, and troubleshooting.
npx claudepluginhub apollographql/skills --plugin apollo-skillsThis skill is limited to using the following tools:
Apollo Router is a high-performance graph router written in Rust for running Apollo Federation 2 supergraphs. It sits in front of your subgraphs and handles query planning, execution, and response composition.
divergence-map.mdreferences/configuration.mdreferences/connectors.mdreferences/headers.mdreferences/plugins.mdreferences/telemetry.mdreferences/troubleshooting.mdtemplates/v1/development.yamltemplates/v1/production.yamltemplates/v1/sections/auth.yamltemplates/v1/sections/cors.yamltemplates/v1/sections/headers.yamltemplates/v1/sections/limits.yamltemplates/v1/sections/telemetry.yamltemplates/v1/sections/traffic-shaping.yamltemplates/v2/development.yamltemplates/v2/production.yamltemplates/v2/sections/auth.yamltemplates/v2/sections/connectors.yamltemplates/v2/sections/cors.yamlGenerates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Apollo Router is a high-performance graph router written in Rust for running Apollo Federation 2 supergraphs. It sits in front of your subgraphs and handles query planning, execution, and response composition.
This skill generates version-correct configuration. Router v1 and v2 have incompatible config schemas in several critical sections (CORS, JWT auth, connectors). Always determine the target version before generating any config.
Ask the user before generating any config:
Which Apollo Router version are you targeting?
[1] Router v2.x (recommended — current LTS, required for Connectors)
[2] Router v1.x (legacy — end-of-support announced, security patches only)
[3] Not sure — help me decide
If the user picks [3], display:
Quick guide:
• Pick v2 if: you're starting fresh, using Apollo Connectors for REST APIs,
or want backpressure-based overload protection.
• Pick v1 if: you have an existing deployment and haven't migrated yet.
Note: Apollo ended active support for v1.x. The v2.10 LTS (Dec 2025)
is the current baseline. Migration is strongly recommended.
Tip: If you have an existing router.yaml, you can auto-migrate it:
router config upgrade router.yaml
Store the selection as ROUTER_VERSION=v1|v2 to gate all subsequent template generation.
Ask: Production or Development?
Load the appropriate base template from:
templates/{version}/production.yamltemplates/{version}/development.yamlAsk which features to include:
connectors, early v2 preview key was preview_connectors)For each selected feature, collect required values.
templates/{version}/sections/ for auth, cors, headers, limits, telemetry, and traffic-shaping.templates/v2/sections/connectors.yaml as the source.templates/{version}/production.yaml or templates/{version}/development.yaml) or from references.ROUTER_VERSION=v2."*" for production)issuer, v2 uses plural issuers arrayconnectors.sources.<subgraph>.<source>)$config values for connector runtime configurationpreview_connectors to connectorsPresent the tuning guidance:
Operation depth limit controls how deeply nested a query can be.
Router default: 100 (permissive — allows very deep queries)
Recommended starting point: 50
Lower values (15–25) are more secure but will reject legitimate queries
in schemas with deep entity relationships or nested fragments.
Higher values (75–100) are safer for compatibility but offer less
protection against depth-based abuse.
Tip: Run your router in warn_only mode first to see what depths your
real traffic actually uses, then tighten:
limits:
warn_only: true
What max_depth would you like? [default: 50]
The same principle applies to max_height, max_aliases, and max_root_fields.
http://otel-collector:4317)9090)0.1 = 10%)templates/{version}/Run the post-generation checklist:
router: (client-facing), not only all: (subgraph)issuers (v2) not issuer (v1), or vice versarouter config validate <file> if Router binary is availableAfter generating or editing any router.yaml, you MUST:
validation/checklist.md and report pass/fail for each checklist item.router config validate <path-to-router.yaml> if Router CLI is available.After answering any Apollo Router request (config generation, edits, validation, or general Router guidance), decide whether the user already has runnable prerequisites:
APOLLO_KEY + APOLLO_GRAPH_REF, orsupergraph.graphql plus reachable subgraphsIf prerequisites are already present, do not add extra handoff text.
If prerequisites are missing or unknown, end with a concise Next steps handoff (1-3 lines max) that is skill-first and command-free:
rover skill to compose or fetch the supergraph schema.apollo-router once the supergraph is ready to validate and run with the generated config.apollo-server, graphql-schema, and graphql-operations skills to scaffold and test.Do not include raw shell commands in this handoff unless the user explicitly asks for commands.
apollo-router skill to generate or refine router.yaml for your environment.APOLLO_KEY and APOLLO_GRAPH_REF (no local supergraph composition required).graphql-schema + apollo-server to define/run subgraphs, then use graphql-operations for smoke tests, then use the rover skill to compose or fetch supergraph.graphql.apollo-router skill to validate readiness (validation/checklist.md) and walk through runtime startup inputs.Default endpoint remains http://localhost:4000 when using standard Router listen defaults.
If the user asks for executable shell commands, provide them on request. Otherwise keep Quick Start guidance skill-oriented.
| Mode | Command | Use Case |
|---|---|---|
| Local schema | router --supergraph ./schema.graphql | Development, CI/CD |
| GraphOS managed | APOLLO_KEY=... APOLLO_GRAPH_REF=my-graph@prod router | Production with auto-updates |
| Development | router --dev --supergraph ./schema.graphql | Local development |
| Hot reload | router --hot-reload --supergraph ./schema.graphql | Schema changes without restart |
| Variable | Description |
|---|---|
APOLLO_KEY | API key for GraphOS |
APOLLO_GRAPH_REF | Graph reference (graph-id@variant) |
APOLLO_ROUTER_CONFIG_PATH | Path to router.yaml |
APOLLO_ROUTER_SUPERGRAPH_PATH | Path to supergraph schema |
APOLLO_ROUTER_LOG | Log level (off, error, warn, info, debug, trace) |
APOLLO_ROUTER_LISTEN_ADDRESS | Override listen address |
router [OPTIONS]
Options:
-s, --supergraph <PATH> Path to supergraph schema file
-c, --config <PATH> Path to router.yaml configuration
--dev Enable development mode
--hot-reload Watch for schema changes
--log <LEVEL> Log level (default: info)
--listen <ADDRESS> Override listen address
-V, --version Print version
-h, --help Print help
--dev mode for local development (enables introspection and sandbox)--hot-reload for local development with file-based schemasAPOLLO_KEY in logs or version control${env.VAR}) for all secrets and sensitive configallow_any_origin or wildcard CORS in productionrouter config upgrade router.yaml for v1 → v2 migration instead of regenerating from scratchvalidation/checklist.md after every router config generation or editrouter config validate <file> when Router CLI is availablemax_depth: 50 as the default starting point, not 15 (too aggressive) or 100 (too permissive)warn_only: true for initial limits rollout to observe real traffic before enforcing