GraphQL prompts are strongest when the agent can see the schema, a real operation and the resolver path together. A query can be valid and still return too much data, trigger repeated database work or expose another person's record. These prompts help review that full path while keeping schema design, performance investigation and authorization testing as separate jobs with their own evidence.
Supply a narrow slice of the graph
Include relevant types, a named operation, sanitized variables and a representative response. Show both data and errors if the response contains them. Explain the caller's purpose and which fields it actually displays. A complete schema dump can bury the relationships needed for one task, so begin with the reachable types and add more only when the agent identifies a dependency.
The GraphQL query guide explains fields, arguments, variables and fragments. Those are useful structural inputs, but they do not define your application's authorization policy or performance budget. Supply those requirements explicitly rather than asking the model to infer them from type names.
Review an operation against a user need
Ask which selected fields contribute to the intended screen or workflow. The answer should preserve fields required for pagination and correct state handling. When fragments are shared, include their consumers before removing selections. A locally smaller operation can break a shared caller if the review ignores the wider use.
Review {{operation}} and {{fragments}} against {{screen_requirements}}.
Use {{schema_slice}} to verify fields, arguments and variable types.
Explain each requested field's purpose. Suggest a focused operation change
that preserves pagination and error handling. List schema ambiguities
instead of inventing fields. Validate with our existing GraphQL tooling.
Investigate resolver work with measurements
A nested query is not automatically inefficient. It becomes a problem when resolving its fields causes repeated or expensive work under the relevant workload. Ask for an instrumented baseline, then compare a proposed batching or caching change. Include access boundaries in the cache design so one user's result cannot be reused for another user's request.
Investigate resolver work for {{named_operation}}.
Read {{resolver_paths}} and use {{query_trace}} with {{fixture_size}}.
Count backend calls and identify repeated lookup keys. Propose batching
or request-scoped reuse only where evidence supports it. Compare results,
call count and failure behavior before and after. Preserve authorization
for each resolved object and do not share private results across users.
Test authorization and partial response behavior
A top-level check may not cover every path to a nested object. Provide the ownership rule and ask the agent to reach the same record through different relationships. Also describe what the client should do when some fields fail. A response containing an error needs an application decision about what remains usable.
Build a GraphQL test plan for {{ownership_rule}} and {{operation}}.
Use users A and B and try direct and nested paths to the same object.
Cover missing identity, another user's object and {{resolver_failure}}.
For each case, specify expected data, errors and client-visible behavior.
Implement only the cases supported by our existing test environment and
report unverified assumptions separately.
Plan schema evolution around actual consumers
Before removing a field, gather known operations and the evidence used to identify them. Ask for a migration sequence, a deprecation message and a check that indicates when removal is safe. Do not equate an empty local search with proof that external consumers no longer use a field.
Save the approved GraphQL prompt in Kipt with variables for operation, schema slice and resolver evidence. For HTTP interface descriptions and schema compatibility outside GraphQL, continue with the OpenAPI prompts.