agentleFS
NikoxkxNikoxkx/Agent-Skills/skills/web-development/graphql-schema-designer/SKILL.md

graphql-schema-designer

Skill1 starsChanged 5 months agoApache-2.0View on GitHub

Designs GraphQL schemas with types, queries, mutations, subscriptions, and resolvers. Use when building or refactoring a GraphQL API.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 6 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always think about what the client actually needs (avoid over-fetching by design).

    line 43
  2. Distinctive:

    Create DataLoader per type.

    line 47
  3. Very specific:

    Use in resolvers: loader.load(id).

    line 48
  4. Very specific:

    Prefer cursor-based (Relay connection spec or simple after + first).

    line 51
  5. Very specific:

    Use union error types (e.g., CreatePostResult = Post | ValidationError | Unauthorized).

    line 61
  6. Very specific:

    Use graphql-ws or Apollo subscriptions.

    line 65
  7. Distinctive:

    Circular references: Use lazy loading or interfaces.

    line 81
  8. Distinctive:

    Rate limiting & complexity: Use graphql-query-complexity or persisted queries.

    line 83
  9. Distinctive:

    Run example queries and mutations — they return expected shapes.

    line 89
  10. Distinctive:

    Test pagination cursors with real data.

    line 91

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Overview

Designs complete, production-ready GraphQL schemas including type definitions (scalar, object, input, enum, interface, union), queries, mutations, subscriptions, resolver patterns, solutions to the N+1 problem (DataLoader), pagination (cursor-based), error handling via union types or extensions, and guidance on schema-first vs code-first, stitching vs federation.

When to Use This Skill

  • Building a new GraphQL API or refactoring an existing one.
  • User describes data model or operations ("users can query their orders with line items and status history").
  • Choosing between REST and GraphQL or improving an existing GraphQL schema.

Prerequisites

  • GraphQL server (Apollo Server, Yoga, Pothos, Nexus, or codegen-based).
  • Database or data sources the resolvers will call.
  • For advanced: DataLoader, Redis for caching, understanding of federation.

Steps

  1. Schema-first vs code-first decision:
    • Schema-first: SDL + resolvers (good for collaboration with frontend).
    • Code-first: TypeScript classes/decorators or builder (better DX, type safety).
  2. Core type system:
    • Scalars (ID, String, Int, Float, Boolean, custom DateTime, JSON).
    • Enums for status fields.
    • Input types for mutations.
    • Interfaces and unions for polymorphism.
  3. Query design:
    • Root queries should be specific (not generic "node" unless using Relay).
    • Always think about what the client actually needs (avoid over-fetching by design).
  4. N+1 problem & DataLoader:
    • Identify batchable loads (e.g., user for each post).
    • Create DataLoader per type.
    • Use in resolvers: loader.load(id).
  5. Pagination:
    • Prefer cursor-based (Relay connection spec or simple after + first).
    • Provide edges + pageInfo or a simpler items + hasMore.
    • Offset pagination only for admin/internal use cases.
  6. Mutations & input validation:
    • One mutation per action.
    • Return the mutated entity or a payload type.
    • Use input objects.
  7. Error handling:
    • Use union error types (e.g., CreatePostResult = Post | ValidationError | Unauthorized).
    • Or GraphQL errors with extensions.
  8. Subscriptions (real-time):
    • Use graphql-ws or Apollo subscriptions.
    • Pub/sub backend (Redis, in-memory for dev).
  9. Output:
    • Complete SDL or code-first schema.
    • Resolver map or class.
    • DataLoader setup example.
    • Pagination helper.
    • Example queries/mutations in the response.

Examples

Full schema for a blog + comments + users (with DataLoader, cursor pagination, and union error types) is provided, along with resolver skeleton and subscription example.

Edge Cases & Error Handling

  • Circular references: Use lazy loading or interfaces.
  • Authorization: Perform auth checks inside resolvers or with middleware/directives.
  • Rate limiting & complexity: Use graphql-query-complexity or persisted queries.
  • Schema evolution: Deprecate fields instead of removing; use versioning or federation for major changes.

Verification

  1. Load the schema in GraphQL Playground / Apollo Studio / Insomnia.
  2. Run example queries and mutations — they return expected shapes.
  3. Enable DataLoader batching and confirm single DB query for lists.
  4. Test pagination cursors with real data.
  5. Subscriptions fire on mutation.
  6. Success: Schema is expressive, performant (no N+1), type-safe on both sides, and easy to evolve.

References

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.