Describe the work; gate the risk
What good prompting looks like
The pattern of prompting that holds up over time is unglamorous. Describe the task in the way a competent collaborator would describe it to another competent collaborator: the goal, the audience, the constraints, the criteria for a good result, the examples that anchor what good means. Almost everything called prompt engineering is a variation of this. There is no syntactic trick that beats specificity. The honest signal that a prompt is good is that, written out, it reads like a brief — clear enough that someone unfamiliar with the work could have written what was asked.
Prompt the prompt
When the task is unfamiliar or the brief is hard to write, the most useful move is to ask the assistant to write the prompt for you. Describe what you are trying to do, ask for the prompt that would best elicit a good result, then run that prompt rather than the original sketch. This is not laziness; it is using the assistant's familiarity with prompting against the task. A common refinement is to ask for the prompt and then ask why each instruction is in it, which usually exposes one or two requirements the user had not articulated.
Permissions as a deliberate default
Most agentic tools can take actions on the host system: read files, write files, install packages, run commands, delete things. The default is usually to ask before doing any of these, which is safe but slow. The opposite default — skipping every check — is fast but the worst choice in almost any working setting. The defensible middle position is to pre-approve a short list of low-risk actions, including reading files, running tests, starting a development server, and committing to version control, while keeping the higher-risk actions gated. The list itself is worth treating as a small document; written down, it can be shared and audited.
What to gate, no matter how convenient
A small number of actions are worth keeping behind explicit approval even when the workflow would benefit from speed. Installing new packages from external sources, because the supply chain is the most common route in for malicious code. Deleting files or folders, because the cost of a wrong call is asymmetric. Sending data to external services that were not part of the original brief, because data leaves an organisation in many small steps rather than one big one. The rule is not motivated by paranoia. It is that the upside of fast convenience on these specific operations is small and the downside is recoverable only with effort.
Of the prompts you typed last week, which one produced the best result? Without re-reading it, can you say what made it work?