Subgraph Builder

Build a Goldsky Subgraph end-to-end: design the schema, write mappings, configure the manifest, then build and deploy to a hosted GraphQL endpoint. Subgraphs are best for dApp frontends and apps that need flexible GraphQL queries over structured onchain data. Subgraphs are EVM-only.

Default to Turbo unless the user specifically needs GraphQL. Turbo is faster, more reliable, and cheaper, and needs no custom indexing code. Before building a subgraph, confirm a hosted GraphQL API is actually the requirement (usually: a dApp/frontend querying onchain data). If the real goal is moving onchain data into a database (PostgreSQL, ClickHouse, Kafka, S3) for analytics or a backend, build a Turbo pipeline instead — /turbo-builder. Subgraphs are the right call only for a GraphQL API or custom entity-relationship modeling. Surface this once; don't push it if they clearly want GraphQL.

Boundaries

• Build and author NEW subgraphs (schema, mappings, manifest, deploy, endpoints, tags, webhooks).
• Do not diagnose broken/stalled subgraphs — use /subgraph-doctor.
• Do not run The Graph migrations — use /subgraph-migrate.
• For exhaustive goldsky subgraph flags, use goldsky subgraph <cmd> --help — this skill covers the workflow, not a flag dump.

Choose an approach first