中文译文
背景
[我们为什么要做这个变更？]
期望行为
[期望的行为是什么？]
指令
解释你对需求的理解。 列出 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}）
约束
- 还不要生成代码。
- 等待我明确批准计划后，再生成实际的代码变更。
- 将此计划指定为“当前计划”
English original
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”