observability-design

Generate structured instrumentation, SLO, and alerting design documents.

1|Updated Jul 31, 2023
One-click install
npx skills add https://github.com/austintheriot/dotfiles --skill observability-design-austintheriot
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: observability-design
Source: https://github.com/austintheriot/dotfiles/tree/main/.claude/skills/observability-design
Command: npx skills add https://github.com/austintheriot/dotfiles --skill observability-design-austintheriot

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Observability design turns vague instrumentation ideas into a concrete telemetry plan that can measure user-visible reliability, performance, and SLOs with the right tradeoffs.

Core Features & Use Cases

  • Brainstorm instrumentation plans: define spans, metrics, logs, error semantics, sampling, and propagation for a new service, feature, or API.
  • Critique proposed plans: review SLOs, alerting thresholds, cardinality, and trace/log correlation from an OpenTelemetry + SRE + Honeycomb-aware lens.
  • Produce a shareable design doc: output an actionable instrumentation/SLO/alerting plan (without writing code) including cost and open questions.

Quick Start

Tell the skill whether you are designing instrumentation from scratch or reviewing a proposed plan, and describe the service, user impact, scale, and telemetry backend.

Frequently Asked Questions about observability-design

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

FAQPage Schema
How do I design OpenTelemetry instrumentation for a new service?▼

Design OpenTelemetry instrumentation by defining spans, metrics, logs, error semantics, and sampling for a new service. This skill produces a structured telemetry design doc covering REST/gRPC/GraphQL flows, async processing, and collector strategy without writing code.

What is the best way to critique an existing SLO and alerting plan?▼

Critique an existing SLO and alerting plan by reviewing thresholds, cardinality, and trace/log correlation from an SRE and Honeycomb-aware lens. The skill identifies gaps, risks, and cost tradeoffs in your current telemetry design.

How do I prevent high cardinality when planning telemetry for a backend API?▼

Prevent high cardinality in telemetry by applying collector and sampling strategy decisions during the design phase. This skill helps you evaluate cardinality risks and tradeoffs for REST/gRPC/GraphQL request flows before implementation.

Can I use this to plan observability for async background processing?▼

Yes, you can plan observability for async background processing. The skill applies telemetry design to async flows, defining appropriate spans, error semantics, and propagation to measure user-visible reliability.

Does the telemetry design output include actual instrumentation code?▼

No, the telemetry design output does not include instrumentation code. It produces an actionable design doc detailing SLOs, alerting thresholds, and open questions, deliberately avoiding code implementation.