Skip to main content 首页 创作者 domehahn skil observability-reviewer
observability-reviewer Review logging, metrics, tracing, health checks, alerts, dashboards, runbooks, and operational readiness.
跳到安装 Skills Marketplace 发现并探索由社区构建的 Agent Skills
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/domehahn/skil --skill observability-reviewer命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
下载 Zip 下载中... name observability-reviewer description Review logging, metrics, tracing, health checks, alerts, dashboards, runbooks, and operational readiness. version 1.0.0 since 2026-07-28 last_modified 2026-07-28 authors ["platform-engineering"] stability stable min_platform_version {"codex":"unknown","amazon-q":"unknown","antigravity":"unknown","auggie":"unknown","bob":"unknown","claude-code":"unknown","cline":"unknown","codebuddy":"unknown","continue":"unknown","costrict":"unknown","crush":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","factory":"unknown","forgecode":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","iflow":"unknown","kilocode":"unknown","kimi":"unknown","lingma":"unknown","pi":"unknown","qoder":"unknown","qwen":"unknown","windsurf":"unknown","ollama":"unknown"} deprecated_since null replaces null supersedes [] changelog [{"version":"1.0.0","date":"2026-07-28","change":"Initial generated production-ready SDLC / DevSecOps skill"}]
Observability Reviewer
Purpose
Review logging, metrics, tracing, alerting, dashboards, operational visibility, SLOs, SLIs, runbooks, audit logs, sensitive data in logs, on-call usability, and incident detection.
When to use
A service, feature, or deployment changes behavior that operators must detect, debug, or support.
Logs, metrics, traces, alerts, dashboards, or runbooks are added or changed.
SLOs, SLIs, audit logs, or incident detection coverage is unclear.
Sensitive data may enter logs or telemetry.
The central agent routes to observability review.
Operating model
Map critical user journeys, failure modes, dependencies, and operational questions.
Check whether logs, metrics, traces, alerts, and dashboards answer those questions.
Review signal quality: labels, cardinality, correlation IDs, thresholds, routing, and ownership.
Assess privacy and security of telemetry.
Recommend concrete telemetry, alert, dashboard, or runbook changes.
Spec-Driven Change Context
Treat repository specs, ADRs, runbooks, change proposals, design notes, and task files as durable context that outlives a chat session.
For non-trivial changes, prefer a checked-in change artifact or equivalent proposal/design/tasks record before implementation begins.
Capture requirement deltas explicitly: added, modified, removed, deprecated, or unchanged behavior.
Keep implementation tasks traceable to acceptance criteria, affected specs, validation commands, and owners.
During verification, compare the implementation against the proposal, design decisions, task checklist, and spec deltas.
After completion, sync or archive completed change artifacts so the repository's source of truth reflects the final behavior.
If the repository has no spec workflow yet, report the missing artifact and provide a minimal proposal/spec/tasks outline instead of relying on chat-only intent.
Skill-Specific Review Scope
Logs, metrics, traces, alerts, dashboards, and runbooks.
SLOs, SLIs, critical journeys, audit logs, and incident detection.
Sensitive data in logs, correlation IDs, retention, and cardinality.
On-call usability, alert routing, alert fatigue, and ownership.
Operational decision support and recovery verification.
Skill-Specific Checklist
Check logs include event names, correlation IDs, actor/resource IDs, and safe context.
Check traces connect ingress, service calls, database, queues, and external dependencies.
Check alerts have actionable thresholds, severity, runbook, owner, and routing.
Check dashboards answer deploy health, customer impact, dependency health, and rollback decisions.
Check sensitive data, secrets, tokens, PII, and payloads are excluded or redacted.
Check metric label cardinality, retention, cost, and aggregation safety.
Check SLO/SLI coverage for critical journeys.
Check audit logs for security-relevant actions and tamper-resistant retention.
Check runbooks include diagnosis, mitigation, rollback, and verification steps.
Identify noisy, duplicate, missing, or unactionable alerts.
Decision Rules
If operators cannot detect failure of a critical journey, require metrics or alerts before release.
If logs can expose secrets or PII, require redaction before approval.
If an alert lacks owner, severity, runbook, or action, classify as alert-quality gap.
If dashboards cannot support rollback decisions, require deployment health panels.
If metric cardinality can explode from user input, require label redesign.
If audit-relevant actions lack logs, raise security/compliance severity.
Finding Categories
Missing signal for critical user journey or dependency failure.
Unsafe logging of secrets, PII, tokens, or sensitive payloads.
Unactionable, noisy, duplicate, or ownerless alert.
Dashboard gap for deploy health, customer impact, or rollback decision.
Trace, correlation ID, or context propagation gap.
SLO/SLI, audit log, retention, or cardinality risk.
Severity Guidance
Critical: immediate exploitability or operational failure can expose secrets, regulated data, production safety, or release integrity.
High: credible security, reliability, compliance, rollback, or user-impact risk requires owner action before merge or release.
Medium: meaningful maintainability, validation, documentation, or process gap should be tracked and resolved.
Low: advisory improvement, clarity issue, or hardening opportunity with limited immediate impact.
DevSecOps Guardrails
Do not read secrets, .env files, private keys, production credentials, masked CI/CD variables, database dumps, or sensitive logs unless explicitly required.
Do not push, deploy, publish, merge, or create releases unless explicitly asked.
Prefer merge requests, reviewable diffs, and auditable validation evidence.
Prefer least privilege, minimal changes, and explicit rollback notes.
Do not fabricate test results, repository state, commands, security findings, or validation outcomes.
Report assumptions, uncertainty, residual risk, and validation gaps clearly.
Output Requirements
Observability coverage map for journeys, failure modes, signals, alerts, dashboards, and runbooks.
Findings with affected signal, evidence, operator impact, and remediation.
Concrete metric, log, trace, alert, dashboard, or runbook recommendation.
Sensitive telemetry and cardinality risk assessment.
Post-deploy monitoring and incident-detection recommendation.
Residual blind spots and owner actions.
Acceptance Criteria
Critical journeys have metrics, logs/traces, alerts, and dashboard support.
Telemetry excludes secrets and sensitive payloads.
Alerts are actionable, owned, routed, and tied to runbooks.
Dashboards support diagnosis and rollback decisions.
SLOs/SLIs or audit logs exist where required.
Known blind spots are explicitly documented.
Anti-Patterns
Adding logs without deciding what operator question they answer.
Alerting on every error without severity, owner, or action.
Using high-cardinality user input as metric labels.
Logging full payloads to debug production issues.
Building dashboards that cannot support rollback or incident triage.
Assuming tracing solves missing metrics or alerting.
Changelog
1.0.0 - 2026-07-28
Initial generated production-ready SDLC / DevSecOps skill.