brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
backend-observabilityImplement correlated errors, traces, and structured logs with PII redaction. Use when "add logging", "instrument this", or wiring Sentry/Langfuse. Plan-only audit → plan-error-handling. Sentry triage → debug-sentry-monitor.
Independent GitHub snapshot · Automated classification · Original documentation governs
Degree of freedom: MIXED. What to wrap and alert on [HIGH freedom];
correlation ids, PII redaction, and the DoD [LOW freedom — run exactly].
Observe: checkout 500 in Sentry has no request_id; pino logs the cart id; no LLM (Langfuse unused). Interpret: cannot pivot error → logs; webhook still
console.logs. Classify: ALS request_id on logs +Sentry.setTag; convert console to pino; redactAuthorization. Verify: one id on the Sentry event and the log line;beforeSendstrips the header.
beforeSend, not per-call hopeconsole.log in prod; handled paths are not errorplan-error-handling; investigate a Sentry issue → debug-sentry-monitorThe build-time counterpart to your monitoring stack. The Sentry plugin installs the SDK;
debug-sentry-monitortriages after the fact;audit-langfuse-llmaudits LLM traces. This skill is about instrumenting correctly while you build so those tools have signal to work with — and so a 3am incident is debuggable.
Adding logging / tracing / metrics to new code, reviewing instrumentation, or fixing "we can't tell what happened in prod." Not for installing an SDK (use the Sentry/Langfuse plugins) or post-hoc triage (use the monitor/audit skills).
A prod incident is only debuggable if you can pivot error ↔ trace ↔ log ↔ user from any one of them. Make every layer share an id.
trace_id) at the entry point (HTTP middleware, edge function, job start). Put it in async context (AsyncLocalStorage / context var), not a parameter threaded everywhere.setTag("request_id", id) / setContext, and the Langfuse trace (trace.id or metadata). On an LLM error, attach the Langfuse trace URL to the Sentry event so you jump straight from the error to the prompt/response.Sentry.setUser, Langfuse userId/sessionId) — scrubbed (see redaction).level, msg, request_id, event, domain ids). One event per line. Use the platform logger (pino / structlog / slog), not bare console.log.error = needs a human; warn = degraded but handled; info = state transitions / business events; debug = dev-only, off in prod. Don't log error for handled flow.console.log shipped to prod — it's unsearchable, unleveled, and a PII leak risk. Remove or convert to a leveled structured log.beforeSend / data-scrubbing and Langfuse masking to strip PII from events/traces. Assume anything you put in a span/breadcrumb may be retained.http.server, db.query, llm.generate), add attributes (route, status, row count, model) — follow OTel semantic conventions, including the GenAI conventions for LLM spans (model, tokens in/out, cost, latency, temperature).trace_id into the surrounding request id and into Sentry on failure — so an LLM error in Sentry is one click from the full trace.userId / sessionId / release so audit-langfuse-llm can slice quality by cohort.sentry-create-alert / your channel.console.log shipped to prod.beforeSend + Langfuse masking.sentry-sdk-setup, sentry-setup-ai-monitoring, sentry-create-alert, sentry-otel-exporter-setup) — SDK + alert wiring.langfuse) + audit-langfuse-llm — LLM trace capture + quality audit.debug-sentry-monitor / debug-error — post-hoc triage of what this instrumentation surfaces.data-pipeline — per-run pipeline metrics use these same correlation + logging rules.workflow-spec-tdd — make "observable" part of the spec's "done when", not an afterthought.