observability-readiness

스타8

포크0

업데이트2026년 7월 9일 11:09

Verify that a deployment is observable before promotion. Use when DevOps must check logs, metrics, traces, dashboards, alerts, health endpoints, synthetic probes, SLO/error-budget signals, correlation IDs, runbook links, and incident triage evidence without exposing credentials or sensitive telemetry.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

evolplus

evolplus/talos

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Observability Readiness

When to use

Use this skill before staging/production deployment, before enabling traffic, and during release readiness for features whose failure needs operational detection.

Inputs and outputs

Inputs: architecture/instrumentation contract, service list, health endpoints, expected logs/metrics/traces, dashboards/alerts, target environment, and incident runbook references.
Outputs: observability readiness verdict, missing telemetry findings, dashboard/alert references, smoke probe evidence, and deploy-report observability fields.

Procedure

Map critical signals. For each deployed service, identify health endpoint, readiness/liveness signal, key logs, metrics, traces, and business/user-impact indicators.
Check deploy-time telemetry. Verify the new version emits startup logs, request logs, errors, latency, saturation/resource metrics, background job signals, and dependency health.
Verify correlation. Confirm request IDs/correlation IDs connect frontend, backend, workers, and external calls where applicable.
Confirm dashboards and alerts. Record dashboard names/links and alert names/status. Use names or URLs only; do not include tokens or private query credentials.
Define smoke/synthetic probes. List post-deploy probes for user flows, API health, queues, scheduled jobs, and external integrations.
Check runbook path. Ensure a human can move from alert to runbook to rollback/mitigation path.
Emit verdict. ready, ready-with-gaps, or blocked.

Hard rules

Never promote a high-risk deployment with no health signal, no alert, and no rollback trigger.
Never expose sensitive logs, PII, auth headers, trace baggage, API keys, or dashboard tokens.
Never treat "container running" as observability readiness.
Never invent SLOs or alert thresholds; record missing contracts as follow-up work.
Never mark observability ready when incident responders cannot identify service/version/environment from telemetry.

References

../release-readiness/SKILL.md - release gate that consumes this verdict.
../rollback-readiness/SKILL.md - rollback trigger thresholds.
../../agents/_templates/devops.md - deploy-report expectations.

이 저장소의 다른 Skills

같은 저장소

be-framework-coding-standard

evolplus/talos

Standardized backend implementation guidance for BE Dev using the SRS-declared Backend-Track and Backend-Framework. Use when coding, refactoring, or reviewing backend web APIs, BFFs, microservices, workers, jobs, or service integrations in TypeScript with Express, TypeScript with NestJS, Python with FastAPI, Java with Spring Boot, .NET Core C#, Pure Golang, Java Core, Golang with Gin, Golang with Fiber, Golang with Echo, or Golang with Kratos; BE Dev reads docs/SRS.md Backend-Track and Backend-Framework plus §3.4.5 Source Layout, then selects the matching reference so routing, layering, contracts, validation, observability, errors, transactions, and tests match the chosen stack.

2026-07-308

local-deployment

evolplus/talos

How DevOps composes the local Docker environment for QA and operator trials, including port probing, secret-safe env discovery, test-only runtime-reset endpoint verification for direct-DB fixtures, QA deploy-report fields, and human trial URLs without editing project Compose files.

2026-07-308

playwright-author

evolplus/talos

Concrete how-to for QA-Author writing Playwright specs from markdown TCs — project layout, full-state resets for direct-DB fixtures and caches, parallel-worker isolation, contract-aware URL assertions, network mocking, retries, traces, and visual diffs. Consult after `ui-test-execution` when the target surface is web AND the project uses Playwright.

2026-07-308

qa-execution-runner

evolplus/talos

QA-Exec run contract for executing authored test cases against the deployed build. Use when QA-Exec is dispatched for a task in-test to gather by-us/by-task test cases, check executable specs and instrumentation coverage, invoke the proper runner, execute UI tiers, validate visual specs, route failures, and write docs/qa-reports/<task-id>.md plus artifacts.

2026-07-308

sdlc-loop

evolplus/talos

Codex-native orchestration entrypoint for Evo Talos. Use when the user asks for /sdlc-loop, sdlc-loop, start project, continue the SDLC loop, run the governed workflow, or auto-dispatch eligible SDLC work until the next gate. Acts as the Codex equivalent of the Claude slash command.

2026-07-308

ui-test-execution

evolplus/talos

Framework-agnostic principles for executing UI tests against the running build — TC-to-spec mapping, selectors, full-state fixture reset across DB/cache/worker state, shared-resource parallelism, determinism, and visual diffs. Consult when QA-Author writes executable specs or QA-Exec invokes a runner against a deployed build.

2026-07-308

name	observability-readiness
description	Verify that a deployment is observable before promotion. Use when DevOps must check logs, metrics, traces, dashboards, alerts, health endpoints, synthetic probes, SLO/error-budget signals, correlation IDs, runbook links, and incident triage evidence without exposing credentials or sensitive telemetry.
agents	["devops"]
sdlc_phase	deploy
owner	Platform Eng
status	active

Observability Readiness

When to use

Use this skill before staging/production deployment, before enabling traffic, and during release readiness for features whose failure needs operational detection.

Inputs and outputs

Inputs: architecture/instrumentation contract, service list, health endpoints, expected logs/metrics/traces, dashboards/alerts, target environment, and incident runbook references.
Outputs: observability readiness verdict, missing telemetry findings, dashboard/alert references, smoke probe evidence, and deploy-report observability fields.

Procedure

Map critical signals. For each deployed service, identify health endpoint, readiness/liveness signal, key logs, metrics, traces, and business/user-impact indicators.
Check deploy-time telemetry. Verify the new version emits startup logs, request logs, errors, latency, saturation/resource metrics, background job signals, and dependency health.
Verify correlation. Confirm request IDs/correlation IDs connect frontend, backend, workers, and external calls where applicable.
Confirm dashboards and alerts. Record dashboard names/links and alert names/status. Use names or URLs only; do not include tokens or private query credentials.
Define smoke/synthetic probes. List post-deploy probes for user flows, API health, queues, scheduled jobs, and external integrations.
Check runbook path. Ensure a human can move from alert to runbook to rollback/mitigation path.
Emit verdict. ready, ready-with-gaps, or blocked.

Hard rules

Never promote a high-risk deployment with no health signal, no alert, and no rollback trigger.
Never expose sensitive logs, PII, auth headers, trace baggage, API keys, or dashboard tokens.
Never treat "container running" as observability readiness.
Never invent SLOs or alert thresholds; record missing contracts as follow-up work.
Never mark observability ready when incident responders cannot identify service/version/environment from telemetry.

References

../release-readiness/SKILL.md - release gate that consumes this verdict.
../rollback-readiness/SKILL.md - rollback trigger thresholds.
../../agents/_templates/devops.md - deploy-report expectations.