observability-baseline — скилл для Claude Code
Добавляет в новый сервис перехват ошибок в Sentry, структурные логи с request_id и эндпоинты /healthz и /readyz. Пригодится, когда проект только собирается и первый сбой в проде не должен остаться незамеченным.
npx skills add avelikiy/great_cto --skill observability-baseline -a claude-codeЧто делает observability-baseline
Скилл применяют на этапе генерации приложения. Он закладывает три вещи сразу: инициализацию Sentry (DSN берётся из переменной SENTRY_DSN, в код не вписывается), логгер, который пишет JSON с request_id для каждого запроса, и пару эндпоинтов — GET /healthz для проверки живости процесса и GET /readyz для проверки доступности зависимостей вроде базы и кэша. Диагностика уходит в stderr, чтобы не смешиваться с выводом для пользователя.
Дальше это надо подключить к остальным агентам, иначе код просто лежит в репозитории. app-scaffolder встраивает instrumentation.ts, логгер и эндпоинты в сгенерированное приложение и добавляет SENTRY_DSN в .env.example. infra-provisioner прописывает переменную в продовом окружении и наводит health-пробу платформы на /readyz. l3-support читает Sentry и логи с request_id при разборе инцидента, а devops роняет деплой, если после выката /readyz не отдаёт 200.
Скилл не подходит для чистой библиотеки, CLI без запущенного сервиса и статического сайта без бэкенда — там нечего пробовать и логировать. Результат фиксируют в docs/infra/PROVISION-{slug}.md: проект Sentry и эндпоинты. Готово не тогда, когда три части есть в коде, а когда они подключены к продовому окружению.
Какие задачи решает
- поймать первую ошибку в проде, а не узнать о ней от пользователей
- связать все записи лога одного запроса по request_id
- отдать балансировщику эндпоинт для проверки живости сервиса
- проверить доступность базы и кэша до приёма трафика
- завалить деплой, если сервис после выката не отвечает
Примеры запросов агенту
- Собери новый сервис и сразу встрой в него Sentry, JSON-логи с request_id и эндпоинты /healthz и /readyz
- Пропиши SENTRY_DSN в продовом окружении и наведи health-пробу платформы на /readyz
- Проверь, что после деплоя /readyz отдаёт 200, иначе останови выкат
Как установить observability-baseline
1Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill observability-baseline -a claude-code2Вручную: положить файлы
~/.claude/skills/observability-baseline/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/observability-baseline/
1Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill observability-baseline -a codex2Вручную: положить файлы
.agents/skills/observability-baseline/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill observability-baseline -a cursor2Вручную: положить файлы
.cursor/skills/observability-baseline/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install avelikiy/great_cto observability-baseline2Вручную: положить файлы
.github/skills/observability-baseline/SKILL.md1Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill observability-baseline -a gemini-cli2Командой платформы
gemini skills install https://github.com/avelikiy/great_cto --path skills/observability-baselineВручную: положить файлы
.devin/skills/observability-baseline/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill observability-baseline -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов
Вопросы о observability-baseline
Как установить observability-baseline в Claude Code?
Выполните npx skills add avelikiy/great_cto --skill observability-baseline -a claude-code. Файл скилла окажется по пути ~/.claude/skills/observability-baseline/SKILL.md.
Что делает observability-baseline?
На этапе генерации приложения закладывает перехват ошибок в Sentry, структурные логи с request_id и эндпоинты /healthz и /readyz. Без этого первый сбой в проде остаётся невидимым.
Для каких проектов скилл не подходит?
Для чистой библиотеки, CLI без запущенного сервиса и статического сайта без бэкенда. Там нет работающего сервиса, который можно проверять и логировать.
Исходный текст
SKILL.md · MIT
---
name: observability-baseline
description: Scaffold-time observability so a shipped product is not blind in prod from day one — error capture (Sentry), request-id structured logging, and /healthz + /readyz endpoints. stack-baseline pins Sentry but nothing wires it; this is the wiring. Loaded by app-scaffolder (bake into the scaffold), infra-provisioner (prod env + probes), and consumed by l3-support (traces) and devops (deploy gate).
when_to_use: |
Apply when:
- app-scaffolder is generating a new product (any archetype that runs as a service)
- infra-provisioner is setting prod env vars + health probes
- l3-support needs traces/logs to triage an incident
Do NOT apply to:
- pure library / cli archetypes with no running service
- static marketing sites with no backend
effort: medium
allowed-tools: Read, Write, Edit, Grep, Glob
paths:
- "src/**"
- "app/**"
- "docs/infra/**"
---
# observability-baseline
stack-baseline names Sentry and wires it nowhere — so every shipped product's first
prod incident is invisible, and l3-support triages blind. This skill makes three
things exist at scaffold time. Defaults baked in; no founder question.
## 1. Error capture (Sentry)
- `instrumentation.ts` (Next.js) / SDK init at process start; DSN from `SENTRY_DSN`
env (never hardcoded).
- CI uploads source maps on release so stack traces are readable (release = git sha).
- Capture unhandled rejections + a global error boundary on the client.
## 2. Request-id structured logging
- A logger that emits **JSON** (not `console.log` prose) with a per-request
`request_id` (generate at the edge, propagate via header/async-local-storage).
- Levels: error / warn / info / debug — diagnostics go to **stderr**, never mixed
into user-facing stdout. (Same discipline as the CLI logging gap, DEEPEN d94.)
- One log line per request with: request_id, method, path, status, latency_ms.
## 3. Health endpoints
- `GET /healthz` — liveness (process up). `GET /readyz` — readiness (deps reachable:
db, cache). Cheap, unauthenticated, no PII.
- These are what infra-provisioner probes and what a load balancer checks.
## Wiring (a skill is shelfware unless a consumer loads it)
| Consumer | What it does with this skill |
|----------|------------------------------|
| **app-scaffolder** | bakes `instrumentation.ts` + the JSON logger + `/healthz`+`/readyz` into the generated app; adds `SENTRY_DSN` to `.env.example` |
| **infra-provisioner** | sets `SENTRY_DSN` in the prod env list; points the platform health probe at `/readyz`; records the Sentry project in PROVISION |
| **l3-support** | first triage step reads Sentry + the request-id logs (a trace now exists to read) |
| **devops** | deploy gate fails if `/readyz` doesn't return 200 post-deploy |
## Output
A scaffolded app where the first prod error is captured, every request is traceable
by id, and the platform can health-check it. Record the Sentry project + endpoints
in `docs/infra/PROVISION-{slug}.md`. Done = the three pieces exist AND are wired
into the prod env, not just present in code.
© avelikiy · MIT · avelikiy/great_cto