create-observability

Define logs, metrics, traces, and alerts for feature production health.

5|Updated Jul 25, 2025
One-click install
npx skills add https://github.com/tomzx/agents --skill create-observability
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: create-observability
Source: https://github.com/tomzx/agents/tree/main/skills/create-observability
Command: npx skills add https://github.com/tomzx/agents --skill create-observability

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Observability planning ensures production health is visible from day one by specifying what to monitor and how to measure it.

Core Features & Use Cases

  • Define critical logs, metrics, traces, and alerts for a feature before implementation.
  • Align instrumentation with business goals by mapping service health to actual user outcomes.
  • Use Case: When starting a new feature, generate an observability plan that can be implemented in .sdlc/features/FEAT-NNNN-<slug>/observability.md.

Quick Start

Create an observability plan for a feature by outlining the logging categories, metrics, traces, health checks, and alerting rules in the target observability document.

Frequently Asked Questions about create-observability

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

FAQPage Schema
How do I plan observability for a new feature before implementation?

Observability planning involves specifying what to monitor and how to measure it by defining logging categories, metrics, traces, health checks, and alerting rules. You generate this plan into a .sdlc/features/FEAT-*/observability.md document before implementation begins.

What is the best way to define alerts and metrics for a software feature?

The best way to define alerts and metrics is to align instrumentation with business goals by mapping service health to actual user outcomes. You identify distributed traces, health checks, and logging categories before the feature is implemented.

When do I need to specify distributed tracing and logging categories?

You need to specify distributed tracing and logging categories when starting a new feature across the software development lifecycle. Specifying these observability artifacts before implementation ensures production health is visible from day one.

Can I generate an observability plan for any new feature in my SDLC?

Yes, you can generate an observability plan for any new feature in your software development lifecycle. The process applies to new features and outputs a complete .sdlc/features/FEAT-*/observability.md document for downstream implementation.

What should I include in an observability plan to ensure reliable operation?

An observability plan should include critical logs, service metrics, distributed traces, health checks, and alerting rules. Outlining these instrumentation elements ensures production health is visible and measurable for reliable operation.