backend-configuration

Verify and switch the configured observability backend CLI before dispatching missions.

9|2|Updated Aug 16, 2026
One-click install
npx skills add https://github.com/using-system/oddyssey --skill backend-configuration-using-system
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: backend-configuration
Source: https://github.com/using-system/oddyssey/tree/main/.apm/skills/backend-configuration
Command: npx skills add https://github.com/using-system/oddyssey --skill backend-configuration-using-system

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Before an observability mission runs, someone must confirm which backend stack is configured, prove its CLI is installed and connected, and persist any backend switch or targeting values correctly — doing this ad hoc leads to failed missions and wrong-target queries. ## Core Features & Use Cases - Connection preflight (Check): Resolves the configured stack via odd_config_get, displays the effective backend configuration, runs the reference-defined connection proof, and emits a preflight handoff block for the mission. - Backend switching (Switch): Validates the target stack, checks CLI binary presence with a guided install offer, persists the switch and per-environment stack_config values via odd_config_set, then verifies with a connection proof. - Machine snapshot script: scripts/preflight.py gathers CLI versions, running containers, git state, and .odd/ store contents in one call, printing the handoff's Machine line. - Use Case: Before running an observe mission, ask the agent to confirm the configured Grafana or CloudWatch backend — it shows the target instance, proves the CLI is authenticated, and hands the mission a ready preflight block. ## Quick Start Ask the agent to check the configured observability backend and prove its CLI is connected before starting the mission.

Frequently Asked Questions about backend-configuration

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I switch the configured observability backend?

Ask to switch backends by name; the skill maps your phrasing to a known stack, checks the target CLI binary is installed, persists the switch with odd_config_set, writes any required stack_config values, then verifies with a connection proof.

How do I verify my observability CLI is connected before a mission?

The Check flow resolves the configured stack, displays the effective backend configuration, and runs the reference's cheapest connection probe such as whoami or listing datasources. A successful response ends in a preflight handoff block the mission reuses.

What happens if the backend CLI is not installed?

The skill reports the binary as missing, shows the reference's install steps, and offers a guided install — it never installs silently. If you decline, the switch can still persist but missions will fail at the CLI until the binary exists.

Can it store credentials or API keys in stack_config?

No. stack_config holds only flat scalar targeting values like URLs, regions, workspace names, and GUIDs. Credentials stay in the CLI's own auth store and are referenced by name only; the skill never stores, echoes, or authenticates with secrets.

Does it support custom observability stacks?

Yes. Custom stacks live in .odd/observability-stacks/<name>/guide.md in the repository. The switch validates the guide against the reference contract with check_stack_reference.py before persisting its declaration, and linked guides are fetched to a scratch directory.