observability-core

Vendor-neutral incident discipline for while production is broken.

v0.1.0Source ↗#incident#observability#triage#postmortem

At a glance

Ships
3 skills
Install with
dev-standards
Needs
  • A filled-in capability table: where errors, metrics, deploys and incidents live in your environment
Runs in
Claude Code, or anywhere skills load

Install

  1. 01Add the marketplace (once)

    /plugin marketplace add https://catylai.com/marketplace.json
  2. 02Install observability-core

    /plugin install observability-core@catylai

Three skills. incident-declaration carries the declare-at-confirmation mandate, severity by customer impact, incident roles, communication cadence, and a scope-reset checkpoint after two failed mitigations. blast-radius measures how many users, requests, tenants and regions are affected — and why that number, not the stack trace, sets severity. production-triage is the triage loop: aggregate by error signature, merge and dedupe, rank by blast radius and novelty, and propose tracked work items behind an approval gate.

Everything is written against capabilities rather than products: an error aggregator, a metrics store, a deploy log, an incident record. There is no requirement for any particular observability vendor, which is what lets the procedures survive a change of one. Before first use in a new environment, fill in the capability table in the plugin's SKILL.md — where errors aggregate, where metrics live, where the deploy log is, where an incident gets declared.

It covers the live phase only and hands off at resolution. Postmortems belong to ops-workflows. Concrete queries belong in a vendor adapter layered on top — see gcp-observability for Google Cloud.