You ask a model why your team's deployment failed, describing the error message from memory and summarising what the pipeline does. The answer is plausible, generic, and does not match what actually went wrong. What should you change first?

The principle — When you describe material instead of providing it, the answer can only be as good as your description. Debugging is the case where that gap bites hardest, because the decisive detail is usually the one that looked unimportant.

Why the key is correct — Google's guidance is to include the instructions and information the model needs to solve a problem instead of assuming it has all of the required information, and its worked example makes the difference concrete: a generic router-troubleshooting answer becomes a correct one once the actual status table is pasted into the prompt. An error message recalled from memory has already been filtered through your assumption about what mattered. The raw text has not.

Why the others are wrong — Seniority and uptime are background rather than evidence. Asking for every possible cause widens a list built on the same missing information. And rewriting the description more carefully still substitutes your reading of the failure for the failure itself.

Remember this — Paste the artefact, not your account of it.

Sources — Google, Prompt design strategies.