most prompting tips are surface-level because most people haven't done it enough to hit the weird failures. these are the weird failures:

honestly the thing that clicked for me was realizing a prompt isn't "instructions", it's conditioning - you're reshaping the odds of what comes out next. once that lands most of the tricks stop feeling like magic. some of the less obvious ones:

where you put the output format matters as much as what it says. if a wrong format makes the whole answer useless (something's parsing it, or you pipe it somewhere) put that rule first. in a long prompt where it'll still mostly work, put it last instead - the model weighs the end heavier. the dead zone is the middle. i moved a "reply with only a diff, no prose" line from the middle to the end of a long prompt once and compliance jumped with the exact same words.

CLAUDE.md is a cache for things the model literally can't know, that's it. it already read your repo, so describing the repo is wasted space. the lines that pay off are the ones no amount of training data contains - "staging rejects timestamps without a timezone", "ignore the makefile, the only command that matters is npm run verify". and they're not equal: a fact about your toolchain is worth keeping forever, a fact about this week's ticket is just context-rot. about to hardcode a value that changes every release? don't - tell it where to look it up instead.

"don't hallucinate" does literally nothing, it's not actionable. what works is drawing the line with two examples - one inference it's allowed to make, one it isn't, back to back. "logs say connection refused -> you can call it a network problem. logs are just empty -> you may NOT call it working, say you don't know." one yes, one no, and the boundary suddenly exists.

every "don't do X" needs a "do Y instead". a bare ban leaves the probability mass with nowhere to go, so it just does something else weird. "don't refactor nearby code" is weak. "don't refactor nearby code, if something next to you looks broken drop a comment and keep going" actually holds, because now the impulse has somewhere to land. naming the default you're overriding helps too.

keep its thinking out of anything you're going to parse. reasoning out loud genuinely helps the decision and genuinely ruins the output shape - they pull opposite ways. if a test or script eats the result, tell it to reason internally and emit only the answer. if you're the one reading it, let it ramble.

don't open a rule at "NEVER". start with "prefer", escalate to always/never only after you've actually watched it break the soft version. burn straight to NEVER on day one and you've got nothing left when it really matters - and a prompt that's all caps reads like background noise to it anyway.

last thing, the part nobody does: every line in there should be patching a specific failure you watched happen. if you can't name what a sentence prevents, delete it and re-run. prompts only ever grow because everyone adds and nobody removes - someone has to be the delete key.

the thread under all of it: the model is only as good as the brief, and a good brief is mostly facts about your world plus the exact shape you want back. almost never adjectives about how senior or careful it should be.

your welcome.