Start with the action, not the error
The same error message can mean different things. Cannot find module during local development, in CI, and after deploy are three different stories. So the first context line should answer “what was I doing?”, not only “what error did I get?”
Useful examples:
- ran
npm testafter updating a dependency; - opened a page after deploy to staging;
- executed a database migration;
- built a Docker image locally;
- clicked a UI button after changing an API response.
That gives AI a frame for the problem and prevents it from explaining everything at once.
Add environment and the recent change
An error almost always has a version context. For frontend, that may mean Node.js, npm or pnpm, framework, and browser. For backend, runtime, framework, database, OS, and container image. For CI, runner image, workflow step, secrets, cache, and branch.
Also say what changed recently. Even if the change feels unrelated. A new env var, upgraded package, different base image, or small refactor often gives a better clue than the stack trace alone.
Do not paste unsafe details
A relevant stack trace is useful. Secrets are not. Before sharing a snippet with AI, replace:
- tokens with
REDACTED_TOKEN; - private URLs with
https://private.example/...; - emails or user ids with neutral examples;
- production credentials with their shape but not the value.
AI does not need the real token to explain an authorization error. It needs the error type, where it appeared, and what changed.
Ask for an explanation before a fix
If you ask “fix this”, AI may jump straight to a broad refactor. It is better to first ask for a short explanation, the 2-3 most likely causes, and the first local check.
A good answer should say not only what to do, but why that cause fits your context. If the explanation is not tied to versions, command, or recent change, it is not yet diagnosis.
In short
AI is bad at reading minds, but good with well-collected context. One error line makes it guess. Action, environment, recent change, and expected behavior turn the request into a small debugging brief.
Do not ask “what is this?” Ask: “explain what this means in this context, and what I should check first.”
Quick checklist
- Include the action that triggered the error, not only the error line.
- Add runtime, framework, and package manager versions.
- Say what changed before the error appeared.
- Redact tokens, private URLs, and personal data.
- Ask AI to rank likely causes before writing a fix.
- Verify the answer locally with a small command or test.
Explain an error message without guessing
Help me explain this error and identify the most likely cause without guessing. Context: - What I was doing: [command, UI action, test run, deploy, build] - Expected behavior: [what should have happened] - Actual behavior: [what happened] - Full error text or relevant stack trace: [paste snippet] - Environment: [OS, runtime, framework, versions, package manager] - What changed recently: [new dependency, config, env var, migration, refactor] - What I already tried: [commands, rollback, cache clear, other] - What must stay hidden: [secrets, tokens, private URLs - replaced with REDACTED] Explain: 1. What this error means in plain language. 2. The 2-3 most likely causes in this specific context. 3. Which causes are unlikely and why. 4. Which local checks or commands to run first. 5. The smallest fix or next step to try without a large refactor. Output format: - Short explanation - Most likely causes - What to check first - Minimal next step - What information is still missing