Observability designer

Skill willianbs/skills/observability-designer

AI Engineering Operating System

Install

npx -y skills add willianbs/skills --skill observability-designer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Designs SLIs/SLOs, structured logs, traces, and alert quality for a feature or service. Use when shipping new paths or fixing noisy/missing alerts. Emits OBS_PLAN. Never recommends alert spam or metrics without a user/journey signal.

SKILL.md

2.8 KB, 603 tokens by cl100k_base, as published. Nobody here has run it

Purpose

Make the system operable: what to measure, log, trace, and alert on—with owners and noise control.

When to Use / When NOT to Use

Use when: new services/features; after incidents; alert fatigue; missing dashboards; before deploy of HighRisk paths.

Do not use when: pure algorithm-local changes with no runtime surface; writing the full Grafana JSON unless asked.

Preconditions

Feature/service scope and rough user journey. Prefer CONTEXT_PACK + SLOs if they exist.

Inputs / Outputs

Inputs: scope, IMPACT_REPORT/INCIDENT_LOG optional, existing metrics/alerts if known.

Outputs: OBS_PLAN

Upstream / Downstream

Upstream: delivery-planner, incident-commander, performance-auditor, engineering-os.

Downstream: feature-implementer, test-strategy-designer, quality-gate (deploy), postmortem-writer.

Core Principles

SLIs from user journeys, not vanity counters.
Alerts need: signal, threshold, ownership, runbook link, severity.
Prefer fewer high-quality alerts over many noisy ones.
Structured logs with correlation IDs; no secrets/PII in log bodies.
Traces on boundaries (entry, datastore, external calls).
RED/USE as defaults; adapt to stack.
Every alert answers “what do I do at 3am?”.

Process

Journeys / golden signals for the scope.
SLIs + SLO targets (or explicit “no SLO yet”).
Metrics list — name, type, labels (cardinality-safe).
Logging plan — events, fields, redaction.
Tracing plan — spans, attributes.
Alerts — condition, sev, routing, runbook outline; explicitly suppress noisy candidates.
Dashboard minimum viable views.
Decision.

Evidence Requirements

Tie SLIs to real endpoints/jobs. Cite existing metric names when present.

Stop Conditions / Failure Modes

Condition	Action
Alert with no action/runbook	Revise — do not ship that alert
High cardinality label proposal	Block that label

Severity + Confidence

Missing observability on SEV-1 path → High for deploy-gate conditions.

Output Contract

## OBS_PLAN
Journeys/SLIs/SLOs: ...
Metrics: ...
Logs: ...
Traces: ...
Alerts: ...
Dashboards: ...
Decision: Proceed | ProceedWithConditions | Revise | Block

Handoffs

feature-implementer, quality-gate, incident-commander, performance-auditor.

Never

Never log secrets or raw PII.
Never page on symptoms without ownership.
Never require 50 metrics for a tiny feature.