bubbles-observability-adapter

Authors and wires telemetry adapters implementing a four-verb contract for Bubbles observability planes.

1|Updated Mar 17, 2026
One-click install
npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-observability-adapter-pkirsanov
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: bubbles-observability-adapter
Source: https://github.com/pkirsanov/bubbles/tree/main/skills/bubbles-observability-adapter
Command: npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-observability-adapter-pkirsanov

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams running the Bubbles agent orchestration framework need a uniform, swappable way to fetch live production telemetry (alerts, SLO burn, error rate, deploy impact) from their own monitoring stack, and a method to mine validate-plane traces for hidden defects during live-category tests. ## Core Features & Use Cases - Uniform 4-verb adapter contract: Every adapter under bubbles/adapters/observability/ implements fetch-alerts, fetch-slo-burn, fetch-error-rate, and fetch-deploy-impact with defined JSON output shapes and exit-code semantics, verified by observability-adapter-lint.sh. - Two-plane wiring: Declarative (plane, signal) → {adapter, profile} resolution in traceContracts.observability.endpoints splits the ephemeral validate test stack from read-only prod operate-plane consumers (bubbles.stabilize, bubbles.upkeep, bubbles.train). - Trace-driven defect discovery: During integration/e2e/stress/load tests against a wired stack, mine telemetry for error spans, latency outliers, fan-out/N+1 patterns, and missing spans, then file findings through bubbles.bug. - Use Case: You run Grafana Cloud Prometheus and want Bubbles ops agents to read live SLO burn and alerts; author a prometheus.sh-style adapter, wire it in .github/bubbles-project.yaml, and incident diagnosis plus promote/rollback gating light up immediately. ## Quick Start Ask the agent to author a new observability adapter for your telemetry stack following the four-verb contract and wire it into the validate and operate planes of your project's traceContracts configuration.

Frequently Asked Questions about bubbles-observability-adapter

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

FAQPage Schema
How do I write a custom observability adapter for Bubbles?▼

Create an executable bash script at `bubbles/adapters/observability/<name>.sh` implementing all four verbs (fetch-alerts, fetch-slo-burn, fetch-error-rate, fetch-deploy-impact) in a case statement, plus a `-h`/`--help` usage block. Run `observability-adapter-lint.sh` to verify the contract.

How do I wire a telemetry adapter into the Bubbles validate and operate planes?▼

Edit `.github/bubbles-project.yaml` under `traceContracts.observability.endpoints`, mapping each signal to an adapter name and profile per plane. The resolver script maps `(plane, signal)` to `{adapter, profile}` at runtime; profiles select environment bindings, not separate adapter files.

Can an observability adapter provide default URLs or tokens?▼

No. Adapters must refuse to run when required environment variables are unset, exiting 1 with an explicit error. The framework-wide NO DEFAULTS policy requires operators to set env vars explicitly per environment.

What happens when an observability adapter fails or is unreachable?▼

Adapter exit 1 is not a framework failure; it signals telemetry is unavailable and consumers must gracefully degrade and proceed without enrichment. Exit codes 2 and above are reserved for framework-level errors.

How do I find hidden defects using telemetry during integration or e2e tests?▼

Against a `posture: wired` validate-plane stack, mine traces for error spans, latency outliers breaching SLO targets, fan-out/N+1 patterns, and missing spans. File each finding through `bubbles.bug` with the captured trace as evidence; unfixed findings block completion.

When should tests not use the observability validate plane?▼

Defect mining applies only to live-category tests (integration, e2e-api, e2e-ui, stress, load) against a wired stack. Unit and ui-unit tests have no real stack to trace, and the operate/prod plane is read-only and off-limits to feature tests.