oma-observability
Intent-based observability + traceability router across layers, boundaries, and signals. Routes to vendor-specific skills via category taxonomy; owns transport tuning, meta-observability, incident forensics. Use for observability, traceability, telemetry, APM, RUM, metrics, logs, traces, profiles, SLO, incident forensics, tracing architecture work.
npx skills add first-fluke/oh-my-agent --skill oma-observability --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Routes observability tasks (setup, migrate, investigate, alert, trace, tune, route) across MELT+ signals, layers, boundaries, and vendor categories. It designates vendor-category targets, tunes transport, assesses meta-observability, and handles incident forensics. It supports observability-as-code, dashboards, and SLO guidance via a structured route to vendor skills or internal resources.
How it works
- Classifies the intent into one of: setup, migrate, investigate, alert, trace, tune, route.
- Identifies layers, boundaries, signals, and vendor category.
- Loads the relevant resource guides and then, per the intent, routes to vendor-category guidance or a generic cross-vendor reference (e.g., OTel semconv, vendor docs).
- Produces setup/migration/tuning/forensics guidance or config changes, and may adjust transport, meta-observability, privacy, and retention considerations.
- Verifies pipeline health and governance factors (clock skew, cardinality, retention, privacy, audit) before finalizing.
- If a vendor-owned skill fully covers the task, delegates rather than duplicating documentation.
- Outputs an explicit routed recommendation and, when applicable, a target for delegation.
When to use it
- Setting up an observability pipeline (OTel SDK + Collector + vendor backend)
- Designing traceability across service and domain boundaries
- Tuning transport layer (UDP/MTU, OTLP gRPC vs HTTP, Collector topology)
- Running incident forensics (6-dimension localization)
- Selecting a vendor category or implementing observability-as-code (Grafana Jsonnet dashboards, PrometheusRule CRD, OpenSLO YAML, SLO burn-rate alerts)
- Meta-observability tasks (pipeline self-health, clock skew detection, cardinality guardrails, retention)
- Migrating off deprecated tools (e.g., Fluentd migration guidance)
What it can touch
- References to OTel/CNCF/W3C standards and vendor categories via resources
- May read/write observability configs, dashboards, alerts, and docs; generally delegates vendor-specific implementation
- Requires live status checks for CNCF/vendor status when relevant
Caveats
- Delegates to vendor-owned skills when fully covered; does not duplicate vendor documentation
- Requires current live status checks for CNCF/vendor references
- Fluentd is deprecated guidance; suggests Fluent Bit or OTel Collector for new/migration work
# Observability Agent - Intent-based Router ## Scheduling ### Goal Route, design, tune, and review observability work across MELT+P signals, layers, boundaries, vendor categories, transport choices, meta-observability, and incident forensics. ### Intent signature - User asks for observability, telemetry, OTel, metrics, logs, traces, profiles, SLOs, RUM, APM, incident forensics, trace propagation, transport tuning, or observability-as-code. - User needs vendor/category routing or observability architecture instead of a single vendor's already-covered setup. ### When to use - Setting up an observability pipeline (OTel SDK + Collector + vendor backend) - Designing traceability across service and domain boundaries (W3C propagators, baggage, multi-tenant, multi-cloud) - Tuning transport layer (UDP/MTU, OTLP gRPC vs HTTP, Collector DaemonSet vs sidecar topology) - Running incident forensics (6-dimension localization: code / service / layer / host / region / infra) - Selecting a vendor category (OSS full-stack vs commercial SaaS vs high-cardinality specialist vs profiling specialist) - Implementing observability-as-code (Grafana Jsonnet dashboards, PrometheusRule CRD, OpenSLO YAML, SLO bu
- Scheduling
- Goal
- Intent signature
- When to use
- When NOT to use
- Expected inputs
- Expected outputs
- Dependencies
- Control-flow features
- Structural Flow
- Entry
- Scenes
- Transitions
- Failure and recovery
What does the oma-observability skill do?
Intent-based observability + traceability router across layers, boundaries, and signals. Routes to vendor-specific skills via category taxonomy; owns transport tuning, meta-observability, incident forensics. Use for observability, traceability, telemetry, APM, RUM, metrics, logs, traces, profiles, SLO, incident forensics, tracing architecture work.
How do I install it?
Run `npx skills add first-fluke/oh-my-agent --skill oma-observability --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From first-fluke/oh-my-agent, a repository with 1,204 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.