model planning template risk: low

App Change Implementation Plan Drafter

The prompt instructs the model to explain comprehension of requirements, list 5 hypotheses for validation, create a bold-titled numbered plan in plain English focused on user behav…

PROMPT

### Context
[Why are we doing the change?]

### Desired Behavior
[What is the desired behavior ?]

### Instruction
Explain your comprehension of the requirements.
List 5 hypotheses you would like me to validate.
Create a plan to implement the ${desired_behavior}

### Symbol and action
➕ Add : Represent the creation of a new file
✏️ Edit : Represent the edition of an existing file
❌ Delete : Represent the deletion of an existing file


### Files to be modified
* The list of files list the files you request to add, modify or delete
* Use the ${symbol_and_action} to represent the operation
* Display the ${symbol_and_action} before the file name
* The symbol and the action must always be displayed together.
** For exemple you display “➕ Add : GameModePuzzle.tsx”
** You do NOT display “➕ GameModePuzzle.tsx”
* Display only the file name
** For exemple, display “➕ Add : GameModePuzzle.tsx”
* DO NOT display the path of the file.
** For example, do not display “➕ Add : components/game/GameModePuzzle.tsx”


### Plan
* Identify the name of the plan as a title.
* The title must be in bold.
* Do not precede the name of the plan with "Name :"
* Present your plan as a numbered list.
* Each step title must be in bold.
* Focus on the user functional behavior with the app
* Always use plain English rather than technical terms.
* Strictly avoid writing out function signatures (e.g., myFunction(arg: type): void).
* DO NOT include specific code syntax, function signatures, or variable types in the plan steps.
* When mentioning file names, use bold text.

**After the plan, provide**
* Confidence level (0 to 100%).
* Risk assessment (likelihood of breaking existing features).
* Impacted files (See ${files_to_be_modified})


### Constraints
* DO NOT GENERATE CODE YET.
* Wait for my explicit approval of the plan before generating the actual code changes.
* Designate this plan as the “Current plan”

INPUTS

desired_behavior REQUIRED: Placeholder for the desired behavior description used in plan creation
symbol_and_action: Reference to symbols like ➕ Add for file operations
files_to_be_modified: Reference to section for listing files to add/edit/delete

REQUIRED CONTEXT

Context (why the change)
Desired Behavior (what is desired)

ROLES & RULES

Explain your comprehension of the requirements.
List 5 hypotheses you would like me to validate.
Create a plan to implement the ${desired_behavior}
Use ➕ Add, ✏️ Edit, ❌ Delete to represent operations.
Display the ${symbol_and_action} before the file name.
The symbol and the action must always be displayed together.
Display only the file name.
DO NOT display the path of the file.
Identify the name of the plan as a bold title.
Do not precede the name of the plan with "Name :".
Present your plan as a numbered list.
Each step title must be in bold.
Focus on the user functional behavior with the app.
Always use plain English rather than technical terms.
Strictly avoid writing out function signatures.
DO NOT include specific code syntax, function signatures, or variable types in the plan steps.
DO NOT GENERATE CODE YET.
Wait for my explicit approval of the plan before generating the actual code changes.
Designate this plan as the “Current plan"

EXPECTED OUTPUT

Format

markdown

Schema

markdown_sections · Comprehension of requirements, 5 hypotheses, Files to be modified, Plan title, Plan steps, Confidence level, Risk assessment, Impacted files

Constraints

DO NOT GENERATE CODE YET
use ➕ Add :, ✏️ Edit :, ❌ Delete : format for files
bold plan title without 'Name :'
numbered list with bold step titles
plain English focused on user behavior
no technical terms or code syntax
confidence level 0-100%
risk assessment
impacted files list
designate as 'Current plan'

SUCCESS CRITERIA

Accurately explain comprehension of requirements.
List exactly 5 hypotheses for validation.
Create a detailed implementation plan.
Strictly follow file modification symbols and format.
Present plan in bold titled numbered list focusing on user behavior.
Provide confidence, risk, and impacted files after plan.

FAILURE MODES

Generating code before approval.
Including file paths.
Using technical terms or code syntax in plan.
Incorrect symbol-action format.
Not bolding titles or steps.
Listing wrong number of hypotheses.
Omitting confidence, risk, or impacted files.

CAVEATS

Dependencies

Requires Context section.
Requires Desired Behavior section.
Depends on ${desired_behavior} placeholder.
Depends on ${symbol_and_action} and ${files_to_be_modified} variables.

Missing context

Knowledge of current codebase and files to propose modifications.
Full example of expected output structure.

Ambiguities

Inconsistent placeholder syntax: uses [ ] for Context/Desired Behavior but ${ } elsewhere.
Unclear what specific type of 'hypotheses' to list (e.g., about requirements, code, or implementation).
Unclear exact placement of 'Files to be modified' section relative to other parts.
Unclear where to 'Designate this plan as the “Current plan”' (e.g., in title or end).
In Plan's 'Impacted files', unclear how to format (repeat symbols or just list names).

QUALITY

OVERALL: 0.80
CLARITY: 0.75
SPECIFICITY: 0.85
REUSABILITY: 0.80
COMPLETENESS: 0.80

IMPROVEMENT SUGGESTIONS

Standardize all placeholders to one style, e.g., {{context}} and {{desired_behavior}}.
Clarify hypotheses: 'List 5 assumptions about the requirements or existing code that need user validation.'
Specify output order: e.g., 1. Comprehension, 2. Hypotheses, 3. Files to be modified, 4. Plan.
Add 'Label the plan section as **Current plan**' for clarity.
Provide a complete example response after the instructions.

USAGE

Copy the prompt above and paste it into your AI of choice — Claude, ChatGPT, Gemini, or anywhere else you're working. Replace any placeholder sections with your own context, then ask for the output.