Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
vasilyu1983 avatar

Qa Observability

  • 145 installs
  • 73 repo stars
  • Updated July 13, 2026
  • vasilyu1983/ai-agents-public

Helps with ai & agent building tasks.

About

qa-observability is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted development.

  • qa-observability
  • AI & Agent Building
  • AI-coding skill

Qa Observability by the numbers

  • 145 all-time installs (skills.sh)
  • +2 installs in the week ending Jul 27, 2026 (Skillselion tracking)
  • Ranked #3,405 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/vasilyu1983/ai-agents-public --skill qa-observability

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs145
repo stars73
Last updatedJuly 13, 2026
Repositoryvasilyu1983/ai-agents-public

What it does

Helps with ai & agent building tasks.

Files

SKILL.mdMarkdownGitHub ↗

QA Observability and Performance Engineering

Use telemetry (logs, metrics, traces, profiles) as a QA signal and a debugging substrate.

Core references (see data/sources.json): OpenTelemetry, W3C Trace Context, and SLO practices (Google SRE).

Quick Start (Default)

If key context is missing, ask for: critical user journeys, service/dependency inventory, environments (local/staging/prod), current telemetry stack, and current SLO/SLA commitments (if any).

1. Establish the minimum bar: correlation IDs + structured logs + traces + golden metrics (latency, traffic, errors, saturation). 2. Verify propagation: confirm traceparent (and your request ID) flow across boundaries end-to-end. 3. Make failures diagnosable: every test failure captures a trace link (or trace ID) plus the correlated logs. 4. Define SLIs/SLOs and error budget policy; wire burn-rate alerts (prefer multi-window burn rates). 5. Produce artifacts: a readiness checklist plus an SLO definition and alert rules (use assets/checklists/template-observability-readiness-checklist.md and assets/monitoring/slo/*).

Default QA stance

  • Treat telemetry as part of acceptance criteria (especially for integration/E2E tests).
  • Require correlation: request_id + trace_id (traceparent) across boundaries.
  • Prefer SLO-based release gating and burn-rate alerting over raw infra thresholds.
  • Budget overhead: sampling, cardinality, retention, and cost are quality constraints.
  • Redact PII/secrets by default (logs and attributes).

Core workflows

1. Establish the minimum bar (logs + metrics + traces + correlation). 2. Instrument with OpenTelemetry (auto-instrument first, then add manual spans for key paths). 3. Verify context propagation across service boundaries (traceparent in/out). 4. Define SLIs/SLOs and error budget policy; wire burn-rate alerts. 5. Make failures diagnosable: capture a trace link + key logs on every test failure. 6. Profile and load test only after telemetry is reliable; validate against baselines.

Quick reference

TaskRecommended defaultNotes
TracingOpenTelemetry + Jaeger/TempoPrefer OTLP exporters via Collector when possible
MetricsPrometheus + GrafanaUse histograms for latency; watch cardinality
LoggingStructured JSON + correlation IDsNever log secrets/PII; redact aggressively
Reliability gatesSLOs + error budgets + burn-rate alertsGate releases on sustained burn/regressions
PerformanceProfiling + load tests + budgetsAdd continuous profiling for intermittent issues
Zero-code visibilityeBPF (OpenTelemetry zero-code) + continuous profiling (Parca/Pyroscope)Use when code changes are not feasible

Navigation

Open these guides when needed:

If the user needs...ReadAlso use
A minimal, production-ready baselinereferences/core-observability-patterns.mdassets/checklists/template-observability-readiness-checklist.md
Node/Python instrumentation setupreferences/opentelemetry-best-practices.mdassets/opentelemetry/nodejs/opentelemetry-nodejs-setup.md, assets/opentelemetry/python/opentelemetry-python-setup.md
Working trace propagation across servicesreferences/distributed-tracing-patterns.mdassets/checklists/template-observability-readiness-checklist.md
SLOs, burn-rate alerts, and release gatesreferences/slo-design-guide.mdassets/monitoring/slo/slo-definition.yaml, assets/monitoring/slo/prometheus-alert-rules.yaml
Profiling/load testing with evidencereferences/performance-profiling-guide.mdassets/load-testing/load-testing-k6.js, assets/load-testing/template-load-test-artillery.yaml
A maturity model and roadmapreferences/observability-maturity-model.mdassets/checklists/template-observability-readiness-checklist.md
What to avoid and how to fix itreferences/anti-patterns-best-practices.mdassets/checklists/template-observability-readiness-checklist.md
Alert design and fatigue reductionreferences/alerting-strategies.mdassets/monitoring/slo/prometheus-alert-rules.yaml
Dashboard hierarchy and layoutreferences/dashboard-design-patterns.mdassets/monitoring/grafana/template-grafana-dashboard-observability.json
Structured logging and cost controlreferences/log-aggregation-patterns.mdassets/observability/template-logging-setup.md

Implementation guides (deep dives):

  • references/core-observability-patterns.md
  • references/opentelemetry-best-practices.md
  • references/distributed-tracing-patterns.md
  • references/slo-design-guide.md
  • references/performance-profiling-guide.md
  • references/observability-maturity-model.md
  • references/anti-patterns-best-practices.md
  • references/alerting-strategies.md
  • references/dashboard-design-patterns.md
  • references/log-aggregation-patterns.md

Templates (copy/paste):

  • assets/checklists/template-observability-readiness-checklist.md
  • assets/opentelemetry/nodejs/opentelemetry-nodejs-setup.md
  • assets/opentelemetry/python/opentelemetry-python-setup.md
  • assets/monitoring/slo/slo-definition.yaml
  • assets/monitoring/slo/prometheus-alert-rules.yaml
  • assets/monitoring/grafana/grafana-dashboard-slo.json
  • assets/monitoring/grafana/template-grafana-dashboard-observability.json
  • assets/load-testing/load-testing-k6.js
  • assets/load-testing/template-load-test-artillery.yaml
  • assets/performance/frontend/template-lighthouse-ci.json
  • assets/performance/backend/template-nodejs-profiling-config.js

Curated sources:

  • data/sources.json

Scope boundaries (handoffs)

  • Pure infrastructure monitoring (Kubernetes, Docker, CI/CD): ../ops-devops-platform/SKILL.md
  • Database query optimization (SQL tuning, indexing): ../data-sql-optimization/SKILL.md
  • Application-level debugging (stack traces, breakpoints): ../qa-debugging/SKILL.md
  • Test strategy design (coverage, test pyramids): ../qa-testing-strategy/SKILL.md
  • Resilience patterns (retries, circuit breakers): ../qa-resilience/SKILL.md
  • Architecture decisions (microservices, event-driven): ../software-architecture-design/SKILL.md

Tool selection notes (2026)

  • Default to OpenTelemetry + OTLP + Collector where possible.
  • Prefer burn-rate alerting against SLOs over alerting on raw infra metrics.
  • Treat sampling, cardinality, and retention as part of quality (not an afterthought).
  • When asked to pick vendors/tools, start from data/sources.json and validate time-sensitive claims with current docs/releases if the environment allows it.

Fact-Checking

  • Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.
  • Prefer primary sources; report source links and dates for volatile information.
  • If web access is unavailable, state the limitation and mark guidance as unverified.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.