Individual skill

observability-hardening

Audit or improve observability for named production questions, incidents, or opaque operations using privacy-safe telemetry. Use only when the user explicitly asks for an observability or instrumentation pass, telemetry design, dashboards or alerts, or when inability to explain production behavior is the primary problem. Do not trigger for ordinary debugging, adding one log line, generic production readiness, product analytics alone, or implementation work that merely benefits from diagnostics.

observability-hardening/SKILL.md

Read pinned source

Source commit 1acf58f08cca24b764a4352a6c30fed1f7fb9fb6

What was checked

Matches the observed repository HEAD: Yes
Scanner rules are current: No
Repository scan complete: No
Skill scan complete: Yes
Observed behavior: Not checked yet
Last checked: Nov 7, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings): 197
Repository last updated: Nov 9, 2026
License: MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

design Derived category
operations Derived category
data Derived category
security Derived category
testing Derived category

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files

SKILL.mdcore · 3,722 bytes
agents/openai.yamlasset · 314 bytes
references/checklist.mddoc · 1,755 bytes

Read excerpt


# Observability Hardening

Use this skill when the product works but failures are opaque. The output should make production behavior explainable without leaking private data.

## Counterweight: questions before telemetry

- Start with the operator or user question that cannot currently be answered. Add no signal without a named consumer and decision.
- Inspect provider-native logs, metrics, traces, request IDs, and dashboards before building parallel telemetry.
- Choose the cheapest sufficient signal. Do not add logs, metrics, traces, dashboards, alerts, analytics, and user-visible state as a bundle.
- Instrument ownership boundaries and material state transitions, not every function or phase.
- Prefer a saved query or clearer existing event over a new pipeline, schema, SDK, collector, or dashboard.
- Budget cardinality, volume, retention, latency, privacy, and on-call noise. More telemetry can make diagnosis worse.
- Add an alert only when someone owns a concrete response. Add user-visible progress only when users must wait or act.
- Do not turn a local debugging gap into a repository-wide observability program or product analytics redesign.