Skip to main content
skill CX Codex

graphql-operations — Claude Code skill for GraphQL queries

A skill that keeps your agent writing GraphQL queries, mutations and fragments against the real schema. Useful when it starts inventing field names.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add apollographql/skills --skill graphql-operations -a claude-code
Open on GitHub

What graphql-operations does

The skill sets an order of work for GraphQL. Before writing an operation, the agent looks for the project schema: the schema entry in codegen.ts, graphql.config.* or apollo.config.*, then any *.graphql SDL files. Only fields, arguments and enum values the schema declares are allowed. The finished operation is saved next to the client's existing operations, and the server schema stays untouched unless you ask for a change.

Inside you get a reference for query, mutation and subscription structure, variable syntax, the @include and @skip directives, plus separate files: references/queries.md, references/mutations.md, references/fragments.md, references/variables.md and references/tooling.md. The ground rules are blunt: always name operations, pass dynamic values as variables, request only the fields you need, include id on cacheable types, colocate fragments with components. Tool access is limited to Bash(npm:*), Bash(npx:*), Read, Write, Edit, Glob and Grep.

It works with any GraphQL client — Apollo Client, urql, Relay and others. One catch: the field names shown in the guide are illustrations, not a set that fits your API. If the schema is missing from the repo and no config points to it, the agent stalls on the first field it tries, so check that part first.

What it helps with

  • write a query against the actual schema instead of guessing
  • move repeated field selections into fragments
  • trim unused fields from a heavy query
  • replace hardcoded values with variables
  • set up type generation and operation linting

Example prompts for the agent

  • Write a CreatePost mutation against our schema and save it next to the other operations
  • Split this query into fragments and put them in the component files
  • Review my operations for over-fetching and hardcoded values

How to install graphql-operations

1Skills CLI (Vercel)

npx skills add apollographql/skills --skill graphql-operations -a claude-code

2Manually: put the files in place

~/.claude/skills/graphql-operations/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/graphql-operations/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about graphql-operations

How do I install graphql-operations in Claude?

Run npx skills add apollographql/skills --skill graphql-operations -a claude-code. The skill lands in ~/.claude/skills/graphql-operations/SKILL.md.

What does graphql-operations do?

It guides the agent through writing queries, mutations and subscriptions: read the project schema first, then build the operation from its fields and arguments. It also covers fragment organization and type generation.

Which GraphQL clients does it work with?

Any of them — Apollo Client, urql, Relay and others. The skill leans on the schema and operation syntax rather than a specific library.

Source text

SKILL.md · MIT
---
name: graphql-operations
description: >
  Guide for writing GraphQL operations (queries, mutations, fragments) following best practices. Use this skill when:
  (1) writing GraphQL queries or mutations,
  (2) organizing operations with fragments,
  (3) optimizing data fetching patterns,
  (4) setting up type generation or linting,
  (5) reviewing operations for efficiency.
license: MIT
compatibility: Any GraphQL client (Apollo Client, urql, Relay, etc.)
metadata:
  author: apollographql
  version: "1.0.1"
allowed-tools: Bash(npm:*) Bash(npx:*) Read Write Edit Glob Grep
---

# GraphQL Operations Guide

This guide covers best practices for writing GraphQL operations (queries, mutations, subscriptions) as a client developer. Well-written operations are efficient, type-safe, and maintainable.

## Start From the Schema

Write every operation against the project's schema, not against the examples in this guide.

1. Find the schema before you write anything. Check the `schema` entry in `codegen.ts`, `graphql.config.*`, or `apollo.config.*`, then look for `*.graphql` SDL files.
2. Use only the fields, arguments, and enum values that the schema defines. Field names in this guide, such as `updatedAt` or `orderBy: { field: CREATED_AT, direction: DESC }`, are illustrations.
3. Save the operation as a document next to the client's existing operations. Leave the server schema unchanged unless the user asks for a schema change.

## Operation Basics

### Query Structure

```graphql
query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    email
  }
}
```

### Mutation Structure

```graphql
mutation CreatePost($input: CreatePostInput!) {
  createPost(input: $input) {
    id
    title
    createdAt
  }
}
```

### Subscription Structure

```graphql
subscription OnMessageReceived($channelId: ID!) {
  messageReceived(channelId: $channelId) {
    id
    content
    sender {
      id
      name
    }
  }
}
```

## Quick Reference

### Operation Naming

| Pattern      | Example                                     |
| ------------ | ------------------------------------------- |
| Query        | `GetUser`, `ListPosts`, `SearchProducts`    |
| Mutation     | `CreateUser`, `UpdatePost`, `DeleteComment` |
| Subscription | `OnMessageReceived`, `OnUserStatusChanged`  |

### Variable Syntax

```graphql
# Required variable
query GetUser($id: ID!) { ... }

# Optional variable with default
query ListPosts($first: Int = 20) { ... }

# Multiple variables
query SearchPosts($query: String!, $status: PostStatus, $first: Int = 10) { ... }
```

### Fragment Syntax

```graphql
# Define fragment
fragment UserBasicInfo on User {
  id
  name
  avatarUrl
}

# Use fragment
query GetUser($id: ID!) {
  user(id: $id) {
    ...UserBasicInfo
    email
  }
}
```

### Directives

```graphql
query GetUser($id: ID!, $includeEmail: Boolean!) {
  user(id: $id) {
    id
    name
    email @include(if: $includeEmail)
  }
}

query GetPosts($skipDrafts: Boolean!) {
  posts {
    id
    title
    draft @skip(if: $skipDrafts)
  }
}
```

## Key Principles

### 1. Request Only What You Need

```graphql
# Good: Specific fields
query GetUserName($id: ID!) {
  user(id: $id) {
    id
    name
  }
}

# Avoid: Over-fetching
query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    email
    bio
    posts {
      id
      title
      content
      comments {
        id
      }
    }
    followers {
      id
      name
    }
    # ... many unused fields
  }
}
```

### 2. Name All Operations

```graphql
# Good: Named operation
query GetUserPosts($userId: ID!) {
  user(id: $userId) {
    posts {
      id
      title
    }
  }
}

# Avoid: Anonymous operation
query {
  user(id: "123") {
    posts {
      id
      title
    }
  }
}
```

### 3. Use Variables, Not Inline Values

```graphql
# Good: Variables
query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
  }
}

# Avoid: Hardcoded values
query {
  user(id: "123") {
    id
    name
  }
}
```

### 4. Colocate Fragments with Components

```tsx
// UserAvatar.tsx
export const USER_AVATAR_FRAGMENT = gql`
  fragment UserAvatar on User {
    id
    name
    avatarUrl
  }
`;

function UserAvatar({ user }) {
  return <img src={user.avatarUrl} alt={user.name} />;
}
```

## Reference Files

Detailed documentation for specific topics:

- [Queries](references/queries.md) - Query patterns and optimization
- [Mutations](references/mutations.md) - Mutation patterns and error handling
- [Fragments](references/fragments.md) - Fragment organization and reuse
- [Variables](references/variables.md) - Variable usage and types
- [Tooling](references/tooling.md) - Code generation and linting

## Ground Rules

- ALWAYS read the project's schema first, and use only the fields, arguments, and enum values it defines
- ALWAYS name your operations (no anonymous queries/mutations)
- ALWAYS use variables for dynamic values
- ALWAYS request only the fields you need
- ALWAYS include `id` field for cacheable types
- NEVER hardcode values in operations
- NEVER duplicate field selections across files
- PREFER fragments for reusable field selections
- PREFER colocating fragments with components
- USE descriptive operation names that reflect purpose
- USE `@include`/`@skip` for conditional fields

© apollographql · MIT · apollographql/skills

Similar skills

Everything for Backend and APIs →

From the same set11

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor