Asking well

Two things decide the result

Most of what separates a good session from a frustrating one comes down to two habits. Say precisely what you want, and give Claude a way to tell whether it got there. Everything else in prompting is detail around those two.

The reason is the same loop from the agent lessons. Claude acts, reads the result, and decides again. A vague request gives it nothing to aim at. A request with a check gives every step something to be corrected against.

Be specific

The guide's advice is plain: specific prompts save a round of corrections. Name the file, describe the symptom, and say what fixed looks like.

Compare two requests:

The second costs thirty more seconds to write and usually saves a whole turn.

Give context by pointing, not describing. Use @path to include a file, and paste screenshots with Ctrl+V, which gives you an [Image #N] chip to refer to by number. Pipe in logs directly: cat error.log | claude -p "what's going on here".

Give it a way to verify

This is the most valuable habit. Give Claude a pass/fail check it can run itself: a test file, a build exit code, a linter, a fixture diff, or a screenshot to compare against.

Then ask for evidence, not a claim: the command that was run and its output. "Tests pass" is a sentence. The command and its printed result are a fact.

For things that tests and typechecks miss, /verify builds, runs and looks at the app. /code-review uses a fresh subagent that never saw your conversation, so it does not share the author's blind spots.

When you do not know the spec

If you cannot describe the change yet, do not guess. Use the interview pattern: ask Claude to interview you until it could write a spec, let it write SPEC.md, then build in a fresh session. The questions force the vague parts into words before any code exists.