add-datasource
Use for the implementation workflow that adds gcx CLI support for a datasource type not registered in internal/datasources/providers — query client, command…
Sets up and instruments a developer's own LLM app or agent to send generations and agentic workflow to Grafana Agent Observability (the Agent Observability SDKs) — greenfield setup, fixing broken instrumentation, or filling gaps in existing instrumentation. Uses gcx for the
$ npx -y skills add grafana/gcx --skill agento11y-instrument --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/agento11y-instrumentContext preview
The summary Claude sees to decide when to auto-load this skill.
Sets up and instruments a developer's own LLM app or agent to send generations and agentic workflow to Grafana Agent Observability (the Agent Observability SDKs) — greenfield setup, fixing broken instrumentation, or filling gaps in existing instrumentation. Uses gcx for the
name: agento11y-instrument description: > Sets up and instruments a developer's own LLM app or agent to send generations and agentic workflow to Grafana Agent Observability (the Agent Observability SDKs) — greenfield setup, fixing broken instrumentation, or filling gaps in existing instrumentation. Uses gcx for the parts a static prompt can't do: `gcx login` / `gcx cloud stacks` to find the stack, and `gcx agento11y agents|conversations|generations` to VERIFY that data actually lands — so it iterates (instrument → run → verify → fix) until generations arrive, not blindly. Reads the app's code, detects language/framework, classifies instrumentation state (none / partial / broken), then runs a fixed gap checklist whose #1 item is the silent failure no other prompt catches: the SDK emits OTel spans/metrics but never creates a TracerProvider/MeterProvider, so without them all metrics go to a no-op and are lost. Also checks agent_version (required for per-version Performance charts), set_result completeness, SYNC vs STREAM, parent_generation_ids DAG links, and workflow-step coverage. Recommends changes citing file:line and, only with explicit confirmation, applies minimal diffs that don't change app behavior. Pulls SDK reference from agento11y's llms.txt rather than restating it, and hands off to `agento11y-test-starter` once data flows. It does NOT write test suites or set up tenant evaluations, rules, or guards — offline test suites are `agento11y-test-starter`, tenant eval rules + guards are `agento11y-prod-setup`; does NOT install coding-agent telemetry plugins (that is llms.txt "Path A"); does NOT mint or store credentials or invent endpoints. Trigger on phrases like "instrument my app", "send my agent's traces to Grafana", "set up AI observability for my app", "my generations aren't showing up", "why is Performance empty", "add Agent Observability to my code", "fix my instrumentation". allowed-tools: Bash, Read, Grep, Glob, Edit, Write, WebFetch
Help a developer wire **their own** LLM app or agent to Grafana Agent Observability, from zero or from a broken/partial state, and **keep going until data actually lands in the stack**. The value this skill adds over the static instrumentation prompt is two things a prompt can't do:
1. A mechanical **gap checklist** run against the real code — headed by the one failure that is completely silent (missing OTel providers → every metric lost, no error). 2. A **verification loop** through `gcx`: after each change, run the app and check the `gcx agento11y` agents / conversations / generations commands to confirm generations arrived. Diagnose the next gap from what's missing, not from guesswork.
The SDK reference (env vars, provider snippets, field lists, framework adapters, workflow steps) lives in agento11y's `llms.txt` "Path B". Fetch it rather than restating it here; this file holds the flow and the decision logic. A minimal fallback lives in [references/instrumentation.md](references/instrumentation.md) for when the fetch is unavailable.
`https://raw.githubusercontent.com/grafana/agento11y/main/llms.txt` (Path B). Only inline decision logic here. If the fetch fails, fall back to [references/instrumentation.md](references/instrumentation.md).
`AGENTO11Y_PROTOCOL`, `AGENTO11Y_AUTH_MODE`, `AGENTO11Y_AUTH_TENANT_ID`, `AGENTO11Y_AUTH_TOKEN`, `OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_EXPORTER_OTLP_HEADERS`) or ask the developer. Never fabricate a URL or mint a token.
verification loop (Step 5) confirms data landing against the Cloud tenant. Never fabricate the endpoint or token — read them from the environment or ask.
this **even if sibling apps or existing `.env` files in the repo use `SIGIL_*`** — matching a stale local convention perpetuates it. If the app already reads `SIGIL_*`, add the `AGENTO11Y_*` names (the SDK still honors both) and note the old ones are deprecated. Do not "match the siblings."
developer says yes (Step 5). Read-only gcx verification and re-running the app happen freely inside the loop; editing files does not.
prompt rewrites, no dependency upgrades beyond the SDK/adapter packages actually needed.
"just to run the verify loop."** Instrument whatever model the app already uses. This is absolute: changing the model is out of scope for instrumentation, full stop. If a run fails because a provider API key is missing, the only allowed responses are: (a) ask the developer to provide the key for the model the app *already* uses, or (b) skip the live run and report the wiring as verified-by-construction, telling the developer to run it themselves. Do **not** offer to switch the provider, do **not** ask "which provider should I use?", and do **not** add a new provider dependency (e.g. `langchain-anthropic`) to make the run succeed. If the developer separately says they *want* a different model, that is an app change they own — tell them to make it and re-invoke this skill; do not fold it into the instrumentation diff. Swapping the model silently changes what the app does and what gets observed, which defeats the point. **The provider API key (`ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, …) is the app's own concern, not the instrumentation's** — it aut
Grafana — in your terminal and your agentic coding environment. gcx works with Grafana Cloud, Enterprise, and OSS (Grafana 12+). See the compatibility matrix for details. Query production. Investigate alerts. Let the Assistant root-cause issues.
Repo: grafana/gcx
Use for the implementation workflow that adds gcx CLI support for a datasource type not registered in internal/datasources/providers — query client, command…
Use for the implementation workflow once a capability is already classified as a Grafana Cloud product provider (SLO, OnCall, Synthetic Monitoring, k6, ML,…
Regenerate the gcx marketing bento-box slide (slide.html) with verified commands from the current codebase. Builds a fresh binary and reflects against the…
Guides a contributor and their coding agent through adding or extending a capability in the grafana/gcx codebase: deciding whether a new command is needed and…
Reference for porting a Grafana Cloud product from the legacy grafana-cloud-cli into a gcx provider — adapter, schema/example registration, CRUD redirect…