Verified against Claude Code · 2026-08-05
Force a written, approved plan before Claude Code touches a multi-file feature
A plan-first prompt that blocks any file edit until Claude Code has written out the affected files, sequence, and risk points — mirroring Claude Code's own Plan Mode discipline so multi-file features get reviewed as a plan, not discovered as a half-finished diff.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are planning a multi-file feature. Do not create, edit, or delete any file, and do not run any command that changes repo state, until the plan below is written out in full and I have explicitly approved it. You may read files and search the codebase freely while planning. FEATURE Add a saved-searches feature: users can save their current filter combination on the /reports page with a name, and reload it later from a dropdown. DEFINITION OF DONE A saved search persists across sessions, appears in the dropdown ordered by most recently used, and reloading one restores every filter exactly. CONSTRAINTS Reuse the existing FilterState type in lib/reports/filters.ts rather than creating a parallel shape; no new database table if the existing user_preferences JSON column can hold it. WRITE THE PLAN IN THIS FORMAT 1. Understanding — restate the feature in your own words in two or three sentences, including anything ambiguous in the request that you are choosing to resolve one way, and how. 2. Files touched — every file you expect to create or modify, grouped by whether it is new or existing, with a one-line reason for each. 3. Sequence — the order you will make changes in and why that order, for example the shared type before the two components that import it. If any step could be done in parallel with another, say so. 4. Interfaces and contracts — every function signature, API shape, database column, or exported type that this feature adds or changes, written out before you write the implementation. 5. Risk points — the two or three places most likely to break something outside this feature's obvious scope, and what you will check to confirm they did not. 6. What you are explicitly not doing — anything adjacent that a reasonable person might expect but that is out of scope for this pass. End the plan with the exact sentence: Waiting for approval before making any changes. Do not proceed past that point under any circumstance, including if you believe the plan is obviously correct.
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Claude Code's own Plan Mode — toggled with Shift+Tab twice — puts the agent into a read-only research state where it can use Read, Grep, and Glob but is mechanically blocked from Edit, Write, and most Bash calls until you approve the plan it proposes; this prompt reproduces that same blocking discipline as a portable instruction, which matters because plan mode is a manual toggle you can forget to hit, and because the same discipline is valuable in tools without a dedicated read-only mode. Naming files touched and sequence as required plan sections forces the model to commit to a full change surface before writing the first line, which is exactly where multi-file features go wrong in agentic coding — an assistant that starts with the component it finds most obvious can build two files against an interface it invents on the fly, then discover on file three that the shape needs to change, redoing work a five-minute plan would have caught. The interfaces and contracts step exists because that is the actual coordination point between files: if two files agree on a function signature only by accident of matching code as it's written, rather than by a stated contract, a later edit to either file can silently break the other. The hard stop at waiting for approval, with no exception carved out even for a plan the model is confident about, is the same behavioral lever CLAUDE.md constraint blocks use elsewhere — an agentic assistant will otherwise reasonably interpret an approved-sounding plan as its own authorization to proceed.
What you get back
1. Understanding: Add a way for a user to save their current filter combination on /reports under a name and reload it later. Ambiguous point: the request doesn't say whether saved searches are per-user or shared team-wide — resolving this as per-user only, since the existing user_preferences column is scoped to a single user. 2. Files touched: New — none required, reusing user_preferences. Existing — lib/reports/filters.ts (add SavedSearch type), components/reports/FilterBar.tsx (add Save button and dropdown), lib/api/user-preferences.ts (add read/write helpers for the saved_searches key). 3. Sequence: SavedSearch type first, then the user-preferences helpers (depend on the type), then FilterBar UI last (depends on both). 4. Interfaces: SavedSearch = { id: string; name: string; filters: FilterState; savedAt: string }. saveSearch(userId, search): Promise<void>. listSavedSearches(userId): Promise<SavedSearch[]>. 5. Risk points: user_preferences is currently unbounded JSON — need to confirm there's a size cap before appending indefinitely. 6. Not doing: no sharing or team visibility, no editing a saved search's filters after creation, only save and delete. Waiting for approval before making any changes.
Verified against
Claude Code Sonnet 4.6 · 2026-08-05
Cursor 2.1 · 2026-08-04
Changelog
- 2026-08-05 — Initial publish, verified against Claude Code (Sonnet 4.6) and Cursor 2.1.
Building this for real?
This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
