What it does

Forces the agent to confirm which environment a bug report came from — production, staging, preview, or local — before proposing a diagnosis. Many “it works on my machine” debugging dead-ends start with the agent assuming the error came from the same environment it can run code in.

When to use it

When triaging error reports from users, Sentry, or oncall logs
In any project with multiple deployment environments
When pasting an error message into the agent without context
After watching the agent confidently propose a fix that turned out to be irrelevant to where the bug actually occurred

How it works

Add to your CLAUDE.md:

## Debugging — Verify Environment First

Before diagnosing a runtime error, ask or confirm:

1. Where did this report come from? (prod / staging / preview / local)
2. What was the user/system doing when it occurred?
3. What environment variables, feature flags, or org/tenant context was active?
4. Can you reproduce it in the environment matching the report?

Do not assume the environment based on the error shape alone. Re-read sources
and verify against the actual environment before concluding. Avoid reporting
findings from stale terminal output.

Example

Without this skill:

User: “Login is broken — getting JWT expired.” Agent: “I’ll fix the JWT refresh logic in apps/web/src/auth.ts.” (Agent rewrites refresh logic. Pushes a PR. The bug was actually a misconfigured JWT_SECRET rotation in staging — local dev was fine the whole time.)

With this skill:

User: “Login is broken — getting JWT expired.” Agent: “Where is this happening — production, staging, or local? And do you have the request ID or timestamp?” User: “Staging, started ~30 min ago.” Agent: “Got it. I’ll check staging env vars and recent deploys before touching code.”

Why it matters

LLM agents are eager to propose fixes — especially fixes that involve writing code, which is what they’re rewarded for. But many production incidents are environmental (a rotated secret, a stale flag, a database connection limit) and have nothing to do with code. The fastest way to ship a wrong fix is to skip the question “where did this happen?”

This skill costs you one clarifying question. It saves hours of misdirected debugging and rolled-back PRs.