← ClaudeAtlas

graphqllisted

GraphQL schema design standards and resolver conventions. Use when writing or reviewing any GraphQL schema, resolver, or operation — naming, nullability, types, input objects, mutations, queries, and operation structure.
ndisisnd/cook · ★ 1 · API & Backend · score 65
Install: claude install-skill ndisisnd/cook
# GraphQL Standards > Source: [GraphQL Best Practices](https://graphql.org/learn/best-practices/) · [Apollo Naming Conventions](https://www.apollographql.com/docs/graphos/schema-design/guides/naming-conventions) · [GraphQL Schema Design](https://graphql.org/learn/schema-design/) ## Priority: P0 — Schema Correctness ### Nullability The GraphQL spec makes every field nullable by default. A wrong `!` is not just inaccurate — when a non-null field resolver returns `null`, GraphQL propagates the null **upward** through the response tree, wiping out the nearest nullable parent. One bad guarantee can null out an entire object from the client's response ([graphql.org](https://graphql.org/learn/schema-design/#nullability)). - Mark a field non-null (`!`) only when the server can **guarantee** it will never be null — not just "usually non-null". - Mutation payload root fields (`user`, `order`) must be nullable — the mutation may fail and return errors instead of data. - List elements and the list itself have separate nullability: `[User!]!` means a non-null list of non-null users. - `ID!` is always non-null — if you have an ID, it exists. ```graphql # Correct — list is non-null, elements are non-null users: [User!]! # Wrong — two levels of null to handle; null element in a list is almost never valid users: [User] ``` ### Scalars & Custom Types - Use built-in scalars: `String`, `Int`, `Float`, `Boolean`, `ID`. - Add custom scalars for domain types: `DateTime`, `Date`, `URL`, `Em