编码前的变更计划

### 上下文
{{context}}

### 期望行为
{{desired_behavior}}

### 指令
解释你对需求的理解。  
列出你希望我验证的 5 个假设。  
制定一个实现 ${desired_behavior} 的计划。

### 符号与操作
➕ Add ：表示创建一个新文件  
✏️ Edit ：表示编辑一个已有文件  
❌ Delete ：表示删除一个已有文件  

### 需修改的文件
* 文件列表应列出你请求添加、修改或删除的文件  
* 使用 ${symbol_and_action} 来表示对应操作  
* 在文件名前显示 ${symbol_and_action}  
* 符号与操作必须始终一起显示  
  ** 例如，显示为 “➕ Add : GameModePuzzle.tsx”  
  ** 不要显示为 “➕ GameModePuzzle.tsx”  
* 仅显示文件名  
  ** 例如，显示 “➕ Add : GameModePuzzle.tsx”  
* 不要显示文件路径  
  ** 例如，不要显示 “➕ Add : components/game/GameModePuzzle.tsx”  

### 计划
* 将计划名称标识为标题  
* 标题必须加粗  
* 不要在计划名称前加上“Name :”  
* 将你的计划以编号列表形式呈现  
* 每个步骤的标题必须加粗  
* 聚焦用户在应用中的功能行为  
* 始终使用简单英文，而非技术术语  
* 严格避免写出函数签名（例如，myFunction(arg: type): void）  
* 计划步骤中不得包含具体代码语法、函数签名或变量类型  
* 提及文件名时，使用加粗文本  

**计划之后提供**  
* 置信度（0 到 100%）  
* 风险评估（对现有功能造成破坏的可能性）  
* 受影响的文件（参见 ${files_to_be_modified}）  

### 约束
* 暂时不要生成代码  
* 在我明确批准该计划之前，不要生成实际的代码更改  
* 将此计划指定为“当前计划”

### Context
{{context}}

### Desired Behavior
{{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”