/phoenix-graphql

name: phoenix-graphql
description: >
  Write efficient GraphQL queries against the Phoenix API. Load this skill in two cases:
  (1) before composing any non-trivial GraphQL query yourself for data analysis (via
  the `phoenix-gql` bash command) — it contains schema entrypoints and patterns
  that eliminate the need for introspection; (2) when the user asks for help writing
  GraphQL queries for their own scripts, tools, or integrations against Phoenix —
  it covers the endpoint, authentication, and client examples.
summary: Answer data questions with efficient GraphQL queries, or get working GraphQL for your own scripts and integrations against the Phoenix API.

Two modes

• **Internal data analysis** — you are querying Phoenix yourself to answer a question. Apply the schema facts, efficiency rules, and patterns below directly.
• **Helping the user integrate** — the user wants GraphQL queries for their own code or tools. Use the same schema facts and patterns, plus the "External API usage" section for endpoint, auth, and client examples. Queries you hand to the user should use variables and include pagination handling.

Entrypoints

Top-level `Query` entrypoints get you to a starting entity; per-entity schema details live in the reference files listed under "Schema map" below.

• `node(id: ID!)` — global lookup for **any** entity by its Relay global id; resolve with an inline fragment, e.g. `node(id: $id) { ... on Dataset { name } }`. This is the primary way to fetch datasets, prompts, experiments, sessions, and annotations, which have **no** by-name/by-id helpers.
• `projects(...)`, `datasets(...)`, `prompts(...)`, `evaluators(...)` → Relay connections, each with `filter`/`sort` inputs to find an entity when you only have a name.
• By-X helpers (the only ones that exist): `getProjectByName(name: String!)`, `getProjectSessionById(sessionId: String!)`, `getDatasetExampleByExternalId(datasetId: GlobalID!, externalId: String!)`, `getSpanByOtelId(spanId: String!)`, `getTraceByOtelId(traceId: String!)`. There is **no** `getDatasetByName`, `getPromptByName`, or `getExperimentById` — use `node(id:)` or a connection `filter` instead.
• `viewer` → the authenticated `User`; `projectCount`, `datasetCount`, `promptCount` — cheap counts.
• `compareExperiments(baseExperimentId: GlobalID!, compareExperimentIds: [GlobalID!]!, first, after, filterCondition)` → experiment comparison.

Schema map

Per-entity field references and examples are split into reference files. Load **only** the one(s) you need with `load_skill_reference`, after loading this skill:

• [Projects, spans, and traces](references/project-spans-traces.md): Project aggregates and `spans`; Span and Trace fields. The starting point for most trace analysis.
• [Sessions](references/sessions.md): ProjectSession multi-turn session metrics, token/cost, and session traces.
• [Datasets](references/datasets.md): Dataset and DatasetExample examples, versions, splits, and labels.
• [Experiments](references/experiments.md): Experiment and ExperimentRun runs, aggregate metrics, and comparison.
• [Prompts](references/prompts.md): Prompt and PromptVersion versions, templates, and tags.
• [Annotations](references/annotations.md): Span, trace, session, and experiment-run annotation fields; how to read them; and the mutations that write notes, labels, and annotation configs.
• [Filter expressions](references/filter-expressions.md): The span, trace, and session filter languages (`filterCondition`, `traceFilterCondition`, `sessionFilterCondition`), including vocabulary, operators, root-span scoping, and compiled examples. Load it before writing any condition beyond the one-liners below.

Conventions

These apply to every entity:

• **Pagination** is Relay-style: `first`/`after` args; responses have `edges { node { ... } }` and `pageInfo { hasNextPage endCursor }`. Cursors are opaque strings. Some connections (e.g. `Project.spans`, `Experiment.runs`, `ProjectSession.traces`) are forward-only.
• **IDs**: the `id` field on any node is a Relay global ID (base64 of `TypeName:rowId`) — use it with `node(id:)`. OpenTelemetry hex IDs come from `Span.spanId` and `Trace.traceId` — use those for OTel lookups. Note a `Span` has **no** `traceId` field; read it via the nested `trace { traceId }`. Never mix global IDs with OTel IDs.
• **`TimeRange`** input: `{ start: DateTime, end: DateTime }` — ISO 8601 strings; `end` is exclusive; both optional.
• **`SpanSort`** input: `{ col: SpanColumn, dir: SortDir }`, e.g. `{ col: startTime, dir: desc }`. Useful `SpanColumn` values: `startTime`, `latencyMs`, `tokenCountTotal`, `cumulativeTokenCountTotal`, `tokenCostTotal`.
• **Filter conditions** (`filterCondition`, `traceFilterCondition`, `sessionFilterCondition`) are Python boolean expressions, one language each for spans, traces, and sessions, e.g. `span_kind == 'LLM'`, `status_code == 'ERROR'`, `'timeout' in output.value`, `annotations['Hallucination'].label == 'hallucinated'`. There is no `traces` connection: list traces with the clause `parent_span is None` (root spans, orphans included), or `parent_id is None` for spans with no parent id. Unknown span filter names compile as attribute paths and match nothing, so read `references/filter-expressions.md` before writing a condition.

Efficiency rules

• **Do not run full schema introspection.** Read the relevant `Schema map` resource instead; it covers the fields and arguments for that entity. Only when a resource does not cover a field you need, introspect a single type: `{ __type(name: "Project") { fields { name args { name type { name kind } } } } }`.
• **Batch independent lookups with aliases** in one query instead of multiple round trips, e.g. `p50: latencyMsQuantile(probability: 0.5) p99: latencyMsQuantile(probability: 0.99)`.
• Select only the fields you need; keep page sizes small (10–50) and paginate only when necessary.
• Pass values via query variables, never string interpolation. A document m