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.