TechnicalCollectible prompt
Make your AI tool explain its plan before it edits
Before you change any code, I want your plan. The task: {{page_or_feature}}. The project is built with {{tech_stack}}.
Step 1. Read first. Open the files involved and tell me what you found: which files, components and data this touches, how it works today, and anything already in the project that does part of the job.
Step 2. The plan, in plain language I can check without reading code:
- What you'll change, file by file, and roughly how big each change is
- What you won't touch, and anything shared that other pages depend on
- New packages, database changes, environment variables or settings, if any, and why existing ones won't do
- How the result will look and behave, including loading, empty and error states
- Risks: what could break, and how we'd notice
- How you'll check it: the tests you'll run or add, and what I should click to verify
- Your confidence, and what you're assuming
Step 3. Questions: up to three, only where the answer changes the plan.
Then stop and wait. Don't edit files until I reply "go". If I change the plan, restate the final version in three lines before starting. While working, if something differs from the plan, such as a file that isn't what you expected, stop and tell me instead of improvising. When you finish, compare what you did against the plan, point by point, and list anything you changed that wasn't in it.
Technicalnvoka.com/library/nvoka-make-your-ai-tool-explain-its-plan-before-editingScan to open
Technical
Make your AI tool explain its plan before it edits
The AI reads the code, says what it will change and why, then waits for your go-ahead.
Curated by Nvoka
CursorClaude CodeLovableWindsurf
Make it yours
Fill in the blanks and change any word. Only your copy changes, never the card.
Fill in the blanks
0 of 2 filledYour prompt
Before you change any code, I want your plan. The task: {{page_or_feature}}. The project is built with {{tech_stack}}.
Step 1. Read first. Open the files involved and tell me what you found: which files, components and data this touches, how it works today, and anything already in the project that does part of the job.
Step 2. The plan, in plain language I can check without reading code:
- What you'll change, file by file, and roughly how big each change is
- What you won't touch, and anything shared that other pages depend on
- New packages, database changes, environment variables or settings, if any, and why existing ones won't do
- How the result will look and behave, including loading, empty and error states
- Risks: what could break, and how we'd notice
- How you'll check it: the tests you'll run or add, and what I should click to verify
- Your confidence, and what you're assuming
Step 3. Questions: up to three, only where the answer changes the plan.
Then stop and wait. Don't edit files until I reply "go". If I change the plan, restate the final version in three lines before starting. While working, if something differs from the plan, such as a file that isn't what you expected, stop and tell me instead of improvising. When you finish, compare what you did against the plan, point by point, and list anything you changed that wasn't in it.