GraphQL Response Shaping Prompt Template

This prompt is designed for GraphQL gateway and backend-for-frontend (BFF) teams who need to transform raw service data into a JSON payload that strictly conforms to a requested GraphQL query shape. The core job-to-be-done is field-level response shaping: given a raw data object and a GraphQL query string, the model must return a JSON response containing only the fields requested in the query, respecting nested selections, aliases, and field renames. The ideal user is an engineering lead or backend developer building a product feature where a lightweight, AI-driven shaping layer sits between upstream services and a GraphQL response, often as a fallback or augmentation to a traditional resolver.

Use this prompt when you control the raw data input and need a flexible, schema-aware transformation that would be tedious to hard-code for rapidly changing queries. It is appropriate for prototyping GraphQL facades, normalizing responses from third-party APIs that don't natively support GraphQL, or building internal tools where strict resolver logic is overkill. Do not use this prompt when you need guaranteed, bit-exact response shaping at high throughput; a compiled resolver or a deterministic JSON transformation library is the correct tool for that. This prompt is also unsuitable for queries with deeply nested fragments, complex @skip/@include directives, or field-level authorization logic, as the model's probabilistic nature introduces risk of field leakage or omission.

Before using this prompt, you must have the raw data payload and the exact GraphQL query string available at runtime. The prompt assumes the raw data is a superset of the requested fields; it does not fetch missing data. The primary failure mode is field inclusion error, where the model either includes unrequested fields (over-fetching) or omits requested fields (under-fetching). A secondary risk is alias mishandling, where a field requested with an alias is returned under its original name. To mitigate these risks, you must pair this prompt with a post-generation validation step that parses the GraphQL query, extracts the expected response shape, and diffs it against the model's output. For any production use case involving user data, implement a human review or automated approval gate before the shaped response is returned to the client.

This template is designed to be copied directly into your prompt management system, API call, or evaluation harness. It instructs the model to generate a JSON payload that conforms precisely to a provided GraphQL query shape, including only the fields requested, respecting aliases, and handling nested selections. The square-bracket placeholders represent the dynamic inputs your application must supply at runtime. Do not leave them unresolved in production.

textCopy
You are a GraphQL response shaping engine. Your task is to generate a JSON response body that exactly matches the field selection in the provided GraphQL query.

[INPUT]

[GRAPHQL_QUERY]

[OUTPUT_SCHEMA]

[CONSTRAINTS]
- Include ONLY the fields explicitly requested in the GraphQL query. Do not add extra fields.
- If a field has an alias in the query, use the alias as the key in the JSON response.
- For nested object selections, produce nested JSON objects containing only the requested sub-fields.
- If the query includes fragments, resolve them inline and apply the same field inclusion rules.
- If a requested field is not available in [INPUT], omit the key entirely unless [NULL_HANDLING] specifies otherwise.
- Do not include __typename unless explicitly requested in the query.
- Output ONLY the valid JSON object. No markdown fences, no explanatory text.

[NULL_HANDLING]

[EXAMPLES]

Query:
query { user { id name email } }

Input Data:
{ "user": { "id": 1, "name": "Alice", "email": "alice@example.com", "role": "admin" } }

Output:
{ "user": { "id": 1, "name": "Alice", "email": "alice@example.com" } }

Query with alias:
query { customer: user { id fullName: name } }

Input Data:
{ "user": { "id": 1, "name": "Alice", "email": "alice@example.com" } }

Output:
{ "customer": { "id": 1, "fullName": "Alice" } }

Now generate the response for [GRAPHQL_QUERY] using [INPUT].

To adapt this template, replace each placeholder with the actual data your application manages. [INPUT] should contain the full data object from your resolver or data source. [GRAPHQL_QUERY] is the raw query string. [OUTPUT_SCHEMA] can optionally contain a JSON Schema for post-generation validation. [NULL_HANDLING] should specify whether null fields are included (e.g., "field": null) or omitted entirely. The [EXAMPLES] block provides few-shot demonstrations; extend it with edge cases from your own schema, such as array fields, inline fragments, or union types. After generating the response, always validate it against the expected shape using a JSON Schema validator or a field-inclusion checker before returning it to the client.

This prompt is designed to sit inside a GraphQL gateway or a backend-for-frontend (BFF) layer where the model receives a user's natural-language request and the parsed GraphQL query shape, then returns a JSON payload that matches the requested field selections exactly. The implementation harness must ensure that the model never sees the raw user input without the accompanying query shape, and that the output is validated against the expected selection set before it reaches the client.

Wire the prompt into a request pipeline with three stages: pre-processing, inference, and post-validation. In pre-processing, parse the incoming GraphQL query to extract the requested field names, nested selections, and any aliases. Inject these into the [QUERY_SHAPE] placeholder as a structured description—do not pass the raw GraphQL SDL string unless the model has been explicitly fine-tuned to interpret it. For inference, use a model with strong JSON-mode or structured-output support (e.g., GPT-4o with response_format: { type: 'json_object' } or Claude with a prefill { token). Set temperature to 0 or near-zero to reduce field hallucination. Log the full assembled prompt, the raw model response, and the parsed JSON payload for every request. If the model returns malformed JSON, retry once with a repair prompt that includes the parse error message and the original [QUERY_SHAPE]; if the second attempt fails, fall back to a static error response and alert the operations channel.

Post-validation is the critical safety net. Before returning the payload to the client, validate that every key in the model's output exists in the requested selection set and that no extra fields have been introduced. For nested selections, recurse through the output object and the query shape in parallel. If the query uses aliases, confirm the output keys match the alias names, not the underlying field names. Run an eval check that measures field precision (no extra fields), field recall (all requested fields present for non-null data), and alias fidelity (alias keys match exactly). For high-risk domains where incorrect field exposure could leak data, route outputs that fail validation to a human review queue before any client response is sent. This harness turns the prompt from a one-shot generation into a reliable, auditable component of your API surface.