Direct answer
High-quality prompts are not stacks of modifiers, but clear scope, constraints, evidence, and stopping conditions.
What this guide helps you solve
Help developers build reusable Claude Code prompting and planning practices.
Five components of an executable prompt
Effective prompts describe the goal, relevant scope, non-negotiable constraints, expected deliverables, and verification method. Claude can explore implementation details, but it cannot infer business boundaries the team never states.
File paths, complete error messages, existing implementation examples, and test commands are more valuable than asking the model to "think hard." When the scope is uncertain, request read-only exploration first and narrow it gradually.
- Goal: A user-observable result.
- Scope: The directory, file, or module to inspect first.
- Constraints: dependencies, compatibility, prohibited modifications.
- Deliverables: Code, tests, documentation, or analysis reports.
- Verification: Tests, builds, lint checks, screenshots, or reproduction steps.
Fix the login failure after session expiry in src/auth. Read the existing token refresh implementation first.
Do not add dependencies or change the database schema. Add a failing test, then fix the root cause.
Run the auth tests and typecheck, and finish with the evidence and remaining risks.
Work in four phases: Explore, Plan, Implement, and Verify
Plan mode lets Claude read and analyze without editing. It suits cross-file changes, architectural tradeoffs, and unfamiliar areas of the codebase. Explore the current state, produce a reviewable plan, then exit Plan mode before implementing it.
The plan should identify specific files, data flows, migration or compatibility risks, tests, and explicit exclusions. Planning reduces rework when the goal is clear but the implementation still has meaningful choices.
- 01ExploreLimit the search area and locate the actual implementation, tests, and historical constraints.
- 02PlanList file-level changes, risks, and verification commands for approval.
- 03ImplementEdit according to the confirmed plan and pause when new facts are encountered.
- 04VerifyRun machine-readable checks and review the final diff.
Stay in Plan mode. Identify the files required for OAuth login, trace the session data flow,
list the required tests, and state what is out of scope. Do not write code yet.Do not plan small tasks merely for the sake of process
Plan mode consumes context and time. Spelling fixes, a targeted log statement, or a clearly defined mechanical change can be requested and verified directly.
Use a simple test: if you can describe the expected diff accurately in one sentence, formal planning is usually unnecessary. If you do not know which modules are involved, explore first.
Give Claude an acceptance check it can run
Test exit codes, builds, lint results, fixed inputs and outputs, and browser screenshots can all create a verification feedback loop. Without those signals, Claude can only stop when an implementation "looks right."
Ask for the actual commands and key results instead of a bare claim that work was "verified." For critical changes, use a fresh subagent to review the requirements and diff independently.
When implementation is complete, run `pnpm test auth` and `pnpm typecheck`. If either fails, inspect the error and fix it
until the checks pass or a decision is required. Report each command, its result, and anything not verified.Correct mistakes early and reset a polluted context
Press Esc as soon as Claude heads in the wrong direction, then identify the incorrect assumptions and add specific constraints. Do not wait for it to produce many irrelevant changes before rejecting the approach.
If two consecutive corrections fail to fix the same problem, use /clear to start with a clean context and include the newly discovered constraints in the first prompt. Keep unrelated tasks in separate sessions so old logs and failure paths do not distort current decisions.
/clear
/compact Keep only confirmed interface constraints, changed files, and validation commandsProvide high-value context directly
Referencing a file with @, pasting the complete error, attaching a screenshot, or providing the official API URL is more precise than paraphrasing. For large inputs, let Claude read data on demand instead of loading every log into the main context at once.
When business decisions are required, ask Claude to interview you first and turn the answers into a self-contained specification. Implement that specification in a new session so the execution phase starts with clean context.
I need a bulk import feature. Ask me about the data format, error policy, idempotency, authorization, performance, and UX.
Do not ask questions the code already answers. After confirming the boundaries, write the complete specification to SPEC.md without implementing it.Official sources and verification scope
This guide is based on public official documentation. Commands and configuration may change between client versions, so verify the linked sources before use.
View documentation scope