This card is for the moment you hand over one ambitious task and expect a finished result back, not for a single-line request. It covers the two controls that decide how such a run goes, effort and simultaneity, and then assembles the whole brief into one block you can paste. For the per-habit lines, keep the sibling cheat-sheet next to it; none of this is tied to one release, and it holds on any modern reasoning model, with Claude as my reference point.
Set the effort dial before you send
For the levels themselves, and the kind of work each one suits, read the host article; this card covers the part it leaves to you, which is how to pick between them.
Treat the choice as a short experiment rather than a preference. Start at high. Rerun the same representative task at medium and compare the output you would actually use. If quality holds, drop to low. Go to very high only when the extra reasoning produces a better usable result, not merely a longer one: very high is an exception you should be able to justify, never a default.
Two caveats are worth building into the habit. Low effort is less likely to reach for search or retrieval tools and more likely to answer from memory, so raise it on any turn where current research or careful retrieval decides whether the answer is right. And very high can spend extra thinking tokens ahead of a long written deliverable without improving the writing that comes out.
The real point is that nobody else's preferred setting transfers to your work. Keep one representative task you can rerun on demand: your own repeatable example beats a recommendation you read somewhere.
Weak: "Use the strongest setting, it's the best one."
Paste this:
Use the lowest effort level that reliably produces the quality I need for [task]. Raise it for difficult reasoning, or when the answer depends on current research or careful retrieval. Lower it for routine execution. Tell me which level you settled on and why.
What can actually run at the same time
Two different moves hide behind the word "parallel", and they carry different costs.
- Parallel tool use — independent searches, file reads and checks fired together instead of one per turn.
- Delegation — a substantial independent workstream handed to a focused agent while the lead keeps coordinating the whole result.
The mental model is an assembly line. One process does not need one worker performing every step in order; independent pieces go out separately, get done at the same time, and come back to a lead that assembles them.
What you gain from that shape:
- Independent work finishes together instead of queueing behind whatever went first.
- Each agent carries a narrower responsibility, so it stays on its own piece.
- Several investigations can run at once, which widens what you cover.
- The lead's context stays clean, because it never has to hold every intermediate detail.
Now the half people skip. Do not parallelize a step that depends on an earlier result: running it early only means running it on the wrong input. Do not delegate what two tool calls would finish, because the handoff costs more than the task. Do not split work that needs constantly shared context, because you will pay for the same context twice and still get seams. And do not create so many agents that coordinating them costs more than the simultaneity saves.
One rule survives all of this: delegation does not transfer responsibility. The lead still owns the combined result and has to verify it before it reaches you, because four parts that each look finished can still contradict each other where they meet.
Weak: "Spin up a bunch of agents and get this done fast."
Paste this:
Identify which parts of [task] are independent. Run independent tool calls at the same time, and delegate a substantial independent workstream when the handoff is worth it. Keep dependent steps sequential. You stay responsible for the combined result: reconcile the parts and verify them together before you call this done.
The brief in one piece
Here is the card assembled. Paste it at the start of an ambitious task, swap the brackets for your own words, and cut any line the task genuinely does not need. The finish-line and verification clauses are deliberately one sentence each: writing a definition of done is taught in the article on briefing an agent to work unsupervised, verification in the sibling cheat-sheet, and this block only carries both along.
Goal. Here is what I need and why it matters: [goal and context]. Definition of done. The work is complete when: [observable success criteria]. Completion. Do this end to end, make routine reversible decisions yourself, and stop only for a destructive action, a material change of scope, or something only I can give you. Effort. Use the lowest effort level that reliably produces this quality; raise it for difficult reasoning and lower it for routine execution. Verification. Check every material result before calling this complete, fix what fails, and state plainly whatever stayed unverified. Execution. Run independent operations at the same time and delegate substantial independent workstreams, keep dependent steps sequential, and stay responsible for reconciling the combined result.
Before you send it
- Is the final outcome unambiguous, or could two readers act on it differently?
- Does the model know why the work matters and who receives it?
- Are the success criteria observable, rather than a matter of taste?
- Does the effort level match this task's real difficulty instead of your default?
- Is there a verification method someone else could repeat?
- Which parts are independent, and which have to stay sequential?
- Does the lead stay responsible for reconciling and verifying the combined result?