observability
Skill4 starsChanged 29 days agoMITView on GitHub
Guide observability setup, metrics design, and alerting configuration. Use when: new service instrumentation, SLO definition, alert design, maturity assessment. Not for: setting numeric targets and Error Budget policy — use /slo; log format and levels — use /logging-guide. Keywords: observability, metrics, traces, golden signals, alerting, SLO.
87 other projects use a version of this.
Adopted by
Most recently taken up by
- juninmd/skillstheir own version, first seen Nov 8, 2026
- domengabrovsek/agent-configtheir own version, first seen Nov 8, 2026
- domengabrovsek/claudetheir own version, first seen Nov 8, 2026
- Ingvord/legendary-bassoontheir own version, first seen Nov 8, 2026
- sundaram2021/claude-code-observability-systemtheir own version, first seen Nov 8, 2026
- Mehul72/skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use gitops, background-jobs and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
kcns008Skillgitops
GitOps Agent (Flow) — manages ArgoCD applications, Helm charts, Kustomize overlays, deployment strategies (canary, blue-green, rolling), multi-cluster GitOps, and drift detection for Kubernetes and OpenShift clusters.
Also in 4 projects that use this
YepAPISkillbackground-jobs
Queue workers with BullMQ/Inngest/Trigger.dev, job retries, dead letter queues, concurrency.
Also in 4 projects that use this
Mushfiqur-Rahman-RobinSkillrag-systems
Best practices for building Retrieval-Augmented Generation systems — chunking, embedding, hybrid retrieval, reranking, indexing, caching, evaluation, observability — plus a catalog of RAG patterns and when each applies.
Also in 3 projects that use this
YepAPISkilldata-pipelines
ETL patterns, cron scheduling, queue-based processing, and batch jobs with Inngest/BullMQ.
Also in 4 projects that use this
wpankSkillcaching
Caching strategies, invalidation, eviction policies, HTTP caching, distributed caching, and anti-patterns. Use when designing cache layers, choosing eviction policies, debugging stale data, or optimizing read-heavy workloads.
Also in 5 projects that use this
MicrosoftSkilldata-modeling
Use when the app needs to store or read data — records, a database, entities, CRUD, lists, "save/remember X", or per-user data with row-level security. This app's data layer is Rayfin's: you declare entities as TypeScript classes with decorators in rayfin/data/, register them in the schema, and read/write them through the typed rayfin-client. Covers: defining an @entity, field decorators, registering it, per-entity access with @role, owner-only row-level security, and the client query/mutation API. Triggers: data, database, model, entity, schema, table, record, CRUD, create, read, update, delete, list, store, save, persist, per-user, row-level security, RLS, access control, ownership.
Also in 6 projects that use this
Other versions87 projects use a version of this.
Word for word · 1
- AsiaOstrich/universal-dev-standards★ 84100% same
Edited · 0
None found.
Wrote their own version · 86
- openai/plugins★ 7.8ksame name
- BuilderIO/agent-native★ 7.6ksame name
- brianlovin/briOS★ 2.3ksame name
- lablup/backend.ai★ 679same name
- DevelopersGlobal/ai-agent-skills★ 216same name
- kid-sid/claude-spellbook★ 190same name
- YougLin-dev/Aha-Loop★ 181same name
- proyecto26/system-design-skills★ 118same name
- TheBeardedBearSAS/claude-craft★ 108same name
- nitinjain999/platform-skills★ 71same name
76 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository55 other files it gives its agents.
- AGENTS.mdAGENTS.md
- ac-coverageSkill
- adrSkill
- ai-collaboration-standardsSkill
- ai-friendly-architectureSkill
- ai-instruction-standardsSkill
- api-designSkill
- atddSkill
- auditSkill
- bddSkill
- brainstormSkill
- changelogSkill
- checkinSkill
- ci-cdSkill
- code-reviewSkill
- commitSkill
- contract-testSkill
- databaseSkill
- deploySkill
- methodologySkill
- dev-workflowSkill
- docgenSkill
- documentation-guideSkill
- durableSkill
- e2eSkill
- error-code-guideSkill
- git-workflow-guideSkill
- incidentSkill
- journey-test-assistantSkill
- knowledge-graphSkill
- logging-guideSkill
- metricsSkill
- migrateSkill
- orchestrateSkill
- planSkill
- prSkill
- discoverSkill
- project-structure-guideSkill
- pushSkill
- refactorSkill
- releaseSkill
- requirementSkill
- retrospectiveSkill
- reverseSkill
- runbookSkill
- securitySkill
- scanSkill
- skill-builderSkill
- sloSkill
- spec-deriveSkill
- sddSkill
- sweepSkill
- tddSkill
- coverageSkill
- testing-guideSkill
The file
We split this skill into the rules it gives an agent
1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.
0
Common
Most of the 70 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 103
Before deploying a service to production:
“Common” is measured: kept by at least 6 in 10 of the 70 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Observability Assistant | 可觀測性助手
Language: English | 繁體中文
Version: 1.0.0 Last Updated: 2026-06-19 Applicability: Claude Code Skills
Core Standard: This skill implements Observability Standards. For the authoritative methodology (full Metrics/Traces detail, sampling, OTel integration), refer to the core standard.
Guide observability implementation across the three pillars: Logs, Metrics, and Traces.
引導三支柱可觀測性實作:Logs、Metrics、Traces。
Capabilities | 功能
| Capability | Description | 說明 |
| Instrumentation Check | Pre-launch observability checklist | 上線前可觀測性檢查表 |
| Maturity Assessment | L0-L4 maturity self-evaluation | L0-L4 成熟度自評 |
| Metric Design | Help design metrics (type, naming, labels) | 協助設計 Metrics |
| Alert Design | Design SLO-based alerts with noise reduction | 設計 SLO-based 告警 |
| Golden Signals | Verify 4 golden signals coverage | 驗證四大黃金信號覆蓋 |
Usage | 使用方式
/observability # Show observability guide
/observability --checklist # Run instrumentation checklist
/observability --maturity # Maturity assessment (L0-L4)
/observability --alerting # Alert design guide
/observability "payment-service" # Guide for specific serviceThree Pillars Framework | 三支柱框架
Each pillar gives a different lens; their power is in correlation.
| Pillar | What It Captures | When to Use | Granularity |
| Logs | Discrete events with context | Debugging, audit trails, error details | High (per-event) |
| Metrics | Numerical measurements over time | Dashboards, alerting, capacity planning | Low (aggregated) |
| Traces | Request flow across services | Latency analysis, dependency mapping | Medium (per-request) |
Correlation fields: trace_id links Logs ↔ Traces ↔ Metrics (via Exemplars);
service.name filters all three pillars. Workflow: metric anomaly → exemplar →
trace → trace_id in logs.
Golden Signals | 四大黃金信號
Based on Google SRE. Every service SHOULD monitor all four before production.
| Signal | Measure | Example Metric | Alert (SLO-based) |
| Latency | P50/P95/P99 via Histogram, split success/error | http.server.request.duration.seconds | P99 > X ms for 5 min |
| Traffic | Requests/sec, by route/method | http.server.request.total (rate) | drop > 50% or spike > 200% |
| Errors | errors / total requests | ...request.total{status=~"5.."} ÷ total | error rate > X% for 5 min |
| Saturation | CPU/mem/pool/disk utilization | system.cpu.utilization (Gauge) | resource > 80% for 10 min |
Metric Types | Metric 型別
| Type | Behavior | Use When |
| Counter | Only goes up (resets on restart) | request count, error count, bytes sent |
| Gauge | Point-in-time, up/down | queue depth, active connections, memory |
| Histogram | Distribution across buckets | request duration, response size |
| Summary | Client-computed percentiles | legacy, no server-side aggregation |
Naming: <domain>.<entity>.<action>.<unit> in snake_case (e.g.
db.client.query.duration.seconds). Label cardinality: keep labels under
~1000 unique values — never use user_id / request_id / raw url / ip as
labels; record those in Logs or Traces instead.
Maturity Model (L0–L4) | 成熟度模型
| Level | Name | Characteristics | Upgrade Action |
| L0 | No Observability | only stdout/stderr; debug via SSH + tail -f | structured logging; centralize collection |
| L1 | Basic Logging | structured JSON logs, centralized, searchable | add business metrics; first dashboard |
| L2 | Metrics-Driven | Logs + Metrics, dashboards, threshold alerts | enable tracing; SLO-based alerting |
| L3 | Full Observability | three pillars + correlation + SLO alerts + Golden Signals | anomaly detection; auto-remediation |
| L4 | Intelligent | AIOps anomaly detection, predictive alerts, auto-remediation | maintain, optimize, share learnings |
Self-check: find logs for one request across services (L1+) → dashboards of error rate & latency (L2+) → trace request ingress→DB→back (L3+) → auto-detect anomalies before users report (L4).
Instrumentation Checklist | 上線前檢查表
Before deploying a service to production:
- Structured logging — JSON with
trace_idcorrelation - HTTP/gRPC entry metrics — request count, duration histogram, error rate per endpoint
- Business operation metrics — key events tracked (orders, payments)
- Distributed tracing — span propagation, sampling rate, W3C Trace Context headers
- Health checks — liveness (running?) and readiness (can serve?) probes
- Golden Signals dashboard — Latency, Traffic, Errors, Saturation visualized
- Alert rules — at minimum SLO burn-rate alerts
- Log retention — policies set per log level
- Sensitive data excluded — no passwords, tokens, or PII in logs/traces
Next Steps Guidance | 下一步引導
可觀測性引導完成。建議下一步:
- 執行
/slo定義 SLI/SLO/Error Budget ⭐ 推薦- 執行
/incident設定事故回應流程- 執行
/checkin提交變更
Reference | 參考
- Detailed guide: guide.md — the three pillars (logs, metrics, traces) in depth. Read it when setting up monitoring, choosing metric types, implementing tracing, or assessing maturity.
- Core standard: observability-standards.md
- Core standard: alerting-standards.md
- Core standard: slo-standards.md
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

