CoreWise Academy

Prompting & Context · Layer II / Practitioner

Sharpen the prompt or brainstorm first

Two ways to start an AI task: deepen a rough prompt when you know the goal, or brainstorm first when the goal or the tradeoffs are still open. A quick test for which one you are in.

Nº 024 · Vol. I·5 min read· Updated July 2026

Read firstBrief the model like a brilliant new hire (Assumes you know how to write a briefed prompt (explicit instructions, examples, XML tags, output format) before deciding when to bother.)
“sharpen the ask, or settle the goal first”

You have a rough idea and a blank prompt box. You could type the idea and hit go, and you will get a median answer, because a vague prompt asks the model to guess what you meant. There are two better moves, and they solve different problems. When you know what you want and typed it lazily, deepen the prompt. When you do not yet know what you want, because the goal is fuzzy or two directions both look reasonable, stop and brainstorm before any prompt. Pick the wrong move and you lose the afternoon: brainstorming a settled task is ceremony, and sharpening a prompt whose goal is unsettled buys a precise answer to the wrong question.

01Sharpen when the goal is clear

A prompt like “review this file” leaves the model guessing at the scope, the output, and whether you even want edits. You know all three. You just did not type them. Deepening the prompt is the act of writing them down before you send.

Anthropic’s prompting best practices name the levers that matter most here. Be clear and direct, and if you want work that goes beyond the basics, ask for it rather than hoping the model infers it. Give the reason behind an instruction, because the model generalizes from the why. Use an explicit action verb: “can you suggest some changes” gets you suggestions, while “change this function” gets you edits. Put any long input at the top and your question at the bottom, which tested up to 30 percent better on complex inputs. End by asking the model to check its answer against the bar you set. The full craft of a briefed prompt lives in Brief the model like a brilliant new hire; both vendors land on the same lean-out advice in Claude and OpenAI, one prompting playbook.

This is what the /enhance-prompt skill does in one step: it turns a rough line into a prompt a cold session can act on. The same meta-prompt works in any tool. Paste your rough request under it:

Rewrite the request below into a prompt a fresh agent can act on with no other context.
- State the real goal and the success signal.
- Name the exact files or inputs, with paths.
- Use an explicit action verb: "change" or "implement" for edits, "propose" or "list" for advice.
- State the output shape you want: a file, a table, a ranked list.
- If the work touches anything costly to undo, split it into a propose step and an apply step.
- End with a self-check against the success signal.
Ask me one question only if a missing answer would change the result.

Request: <paste your rough request>

Two minutes of this beats ten minutes of re-prompting a model that keeps guessing.

02Brainstorm when the goal is open

No amount of prompt polish helps when you cannot yet say what a good answer looks like. Three signals put you here: the goal is ambiguous, two or more approaches differ in ways that matter, or the change is expensive to undo, like a schema, a public API, or user-facing copy.

The move is to resolve the decisions that materially affect the build first, then prompt. Match the depth to the uncertainty. A settled request skips discovery and goes straight to work. One open choice needs a quick alignment: name the choice, recommend a direction, and continue. A new workflow or a cross-cutting change earns a full pass over goals, constraints, and the approaches worth comparing.

This is what the brainstorming skill front-loads, and it is where the token cost of guessing wrong shows up. A precise deep run against the wrong goal spends real budget, the kind Stop hitting your token limit teaches you to protect. Settling the goal for the price of a short conversation is the cheaper trade.

03Which one am I in

The fork comes down to two questions. Can you name the success signal and the shape of the output you want? If yes, you are underspecified, so sharpen. Is there more than one materially different direction, or is the work costly to reverse? If yes, the goal is unsettled, so brainstorm.

The two moves chain on anything large. Brainstorm to settle the goal and the slices the work breaks into, then sharpen one prompt per slice and run them. A rough request is a prompt to ask which move you are in, not a failing you correct by typing faster. Both moves also travel as installed skills, the pattern behind Expertise you can install: the judgment about how much to settle before you start is exactly the kind of method worth packaging once and reusing.

“A precise answer to the wrong question still costs you the afternoon.”

Further reading

FAQ

You typed "review the auth module" and got vague suggestions you did not want. Sharpen or brainstorm, and what specifically do you add?

Sharpen. You knew the goal, a review, and only underspecified it. Add the pieces the model was left to guess: the file paths, an explicit action verb (audit and list findings, do not edit), the output shape (a severity-tagged list), and a self-check against a stated bar. Anthropic's best practices are blunt here: an explicit verb decides whether you get suggestions or edits, and naming the output format steers the result. The goal was clear, so no brainstorming was needed.

Two dashboard designs both look reasonable and you cannot say which serves the user better. Why does deepening the prompt not help?

Deepening makes the model execute a known goal precisely, and your goal is still open. A sharper prompt would get you a clean build of whichever design you happened to name, which you may then throw away. This is the brainstorm case: settle the decision that changes the build, which design and why, then sharpen a prompt for the winner. Sharpening first buys a fast, precise answer to a question you had not settled.

How do the two moves chain on a large project, and what tells you to stop brainstorming?

Brainstorm to settle the goal, the tradeoffs, and the slices the work breaks into, then sharpen one prompt per slice and run them. You stop brainstorming when the open decisions no longer change implementation, which is the moment you can name the success signal and the output shape. Past that point more discussion is ceremony, and the lighter sharpen move takes over. Match the depth of the front-loading to the uncertainty and the cost of being wrong.

Sources

Original work by the editor, no video source.