Observability
Skill byerlikaya/claude-starter-kit/claude-starter/skills/observability
Enterprise engineering workflow for Claude Code — not just prompts. AI agents that plan, build, audit, and ship with security gates, privacy checks, and approval-controlled commits. Safely adopt it into new or existing repositories.
npx -y skills add byerlikaya/claude-starter-kit --skill observabilityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Stack-agnostic observability: structured logs, correlation ids, metrics and traces; no PII or secrets in logs. Makes a production issue traceable to why it happened. Trigger phrases: "observability", "structured logging", "structured log", "add a trace", "add a metric", "correlation id", "add logging"
SKILL.md
3.1 KB, as published. Nobody here has run it
Observability
Goal: to be able to answer "what happened, where, why" during a production incident by looking at the logs. It is stack-agnostic; when you need a framework-specific library/format, do a web search.
Three signals
- Log — event record (structured/JSON, leveled).
- Metric — numeric time series (request count, latency, error rate, resource usage).
- Trace — a request's journey across services (spans + correlation id).
Checklist
- Logs are structured (JSON/key-value), not string interpolation
- Every log line carries a correlation id (request/trace id)
- Levels are correct: the DEBUG/INFO/WARN/ERROR distinction is meaningful
- No PII/secret is logged (password, token, card, national/ID number, email body)
- Error logs carry context (input summary, user/resource id — not PII); the stack trace does not leak to the user
- Critical business metric + infrastructure metric are emitted (where applicable)
- The correlation id is propagated across service-to-service calls (header/propagation)
How
- Structured logger — set up/use one whose output is machine-readable (JSON). Search for the library the framework recommends.
- Correlation id: generate it at the entry point (HTTP middleware / message consumer) or take it from the incoming
X-Request-Id/trace header; put it in the log context; propagate it to downstream calls. - Level discipline: INFO = business event, WARN = expected-but-noteworthy, ERROR = needs intervention. DEBUG is off/sampled in production.
- Context fields:
event,correlation_id,user_id(not PII, an opaque id),duration_ms,outcome. Do not embed them in free text. - Metrics: at minimum RED (Rate, Errors, Duration) or USE; plus business-critical counters. Search for the framework's metrics library.
- Trace (in a distributed system): start/end spans, bind the correlation id to the trace id.
PII / secret leakage (critical)
Never to the log: password, token, API key, card number, national/ID number, full email/phone body, raw request body.
- Mask:
user@***, card**** 1234, tokensk-p…789. - When needed, log an opaque id (hash/uuid), not the raw value.
- This axis overlaps with
security-scan(sensitive data in logs) andprivacy-compliance(KVKK/GDPR) — if personal data is involved, trigger those too.
Invariant rules
- Structured > free text — greppable, parseable.
- Correlation id on every line — without it, a distributed error is untraceable.
- No PII/secret is logged — mask it or use an opaque id.
- Do not make noise — every line must answer a question; do not add meaningless spam logs.
- Match the existing format — if the repo has a logger, follow its pattern; do not impose a new one.