Check Backend Configuration

Check the Backend Configuration

The user configures their observability CLI themselves; agents never run interactive auth (OAuth device codes and SSO browser logins stall subagents — observed). What this skill does instead: resolve the configured stack, show which instance the runs will hit, prove the CLI is connected, and guide the user when it is not.

1. Resolve the stack

odd_config_get names the configured stack (local — the default —, grafana, azure-monitor, cloudwatch, datadog, dynatrace, splunk). When the mission or the instructions name a different one, they win — whether the switch persists is the caller's call: odd-observe persists it with odd_config_set so the next run starts from it; odd-verify states the divergence and does not persist (the stored report is the contract it replays). local routes straight to the local stack — steps 2-4 are replaced by the Local specificity section below.

2. Resolve the CLI and read its configuration

Open the stack's reference in the observability-cli-guides skill — it names the CLI (gcx, Pup, dtctl, az, aws, splunk) and the commands that display its current configuration/context.

Prove the binary exists before reading anything: run the reference's ## CLI binary Detect command as written, in a shell without set -u (splunk's Detect references $SPLUNK_HOME, usually unset). A non-zero exit means the binary is absent — an installation problem, never a configuration one: say "the ` CLI is not installed" (naming the reference's binary, never "CLI not configured"), route to the update-backend-configuration` skill's guided install offer, and resume here once the user has installed; if they decline, stop with the same clear error — the mission cannot query this backend until the binary exists. Everything below — display, probe, guidance — assumes a binary that runs.

Then open this skill's own reference for the stack (references/.md) — it says exactly what to display for that backend and where each value comes from, including the persisted stack_config values from odd_config_get. Show that configuration to the user as-is, no confirmation needed — it is informative: which instance, tenant, or site the queries are about to hit is exactly what a user wants to see before a run, and what catches a wrong-target mistake before it costs a mission. Every display ends with the reference's change-request phrasing example, so the user knows how to ask for a change.

3. Prove the connection

Run the reference's cheapest probe (whoami, list datasources, or the equivalent). Any successful response = connected — evidence over impressions. Failure = stop with a clear error naming the backend and what is missing ("CLI not configured for — see its observability-cli-guides reference") — never attempt to authenticate on the user's behalf, and never invent, echo, or store credentials.

4. Guide what is missing

Point the user at the exact setup steps in the backend's reference, ask for the inputs the mission needs (instance URL, tenant, workspace, where the credentials come from — by name, never values), and re-run the probe once the user says the setup is done. The probe's success is the exit criterion, not the user's assurance. One check before guiding remote auth: on grafana with no remote gcx context configured, offer the alternative first — if the user meant the local stack, the fix is odd_config_set {"stack": "local"}, not an authentication.

Local specificity

stack: local is the local stack: apply the setup-local-stack skill (isolated gcx context, datasource UIDs, ports from the global configuration) — that skill owns the local method, this one only routes to it, and it is fully self-serve: no user authentication to guide, so a missing gcx setup on a fresh machine is NOT a "CLI not configured" error. The connection proof is then gcx config check against the isolated local context. The display shape is [references/local.md](references/local.md) — Grafana URL and both OTLP endpoints resolved from odd_config_get, never hardcoded — while setup-local-stack keeps owning the method. grafana always means a remote Grafana — the gcx context says which instance.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: using-system
• Source: using-system/oddyssey
• License: MIT
• Homepage: https://github.com/using-system/oddyssey#readme

Install and usage instructions live in the source repository linked above.