plan-before-changes

name	plan-before-changes
description	Use when the user requests any modifications, additions, deletions, or changes to code, configuration, or files. The agent must first create a detailed plan, present it to the user for review, and wait for explicit approval before executing any changes. | 当用户提出任何修改、增加、删除或改动代码、配置、文件的需求时，使用此技能。执行变更前，必须先制定详细计划，提交用户审阅，并等待明确同意。

Plan Before Changes

Overview

This skill ensures that any change – whether a code edit, file addition/deletion, or configuration update – is reviewed and explicitly approved by the user before execution. It prevents unintended or premature modifications, keeps the user in control, and forces the agent to think through the full impact of a change before acting.

Core Process

Follow these steps for every change request:

1. Parse the request – Identify all intended changes:

   • Which files will be modified, added, or deleted?
   • What exact lines, content, or operations will change?
   • Are there any commands to run (e.g., tests, builds, migrations)?

2. Create a detailed plan – Write the plan in a clear, structured format that includes:

   • Files affected – list each file path and the operation (modify/add/delete)
   • Specific changes per file – use before/after snippets or unified diffs where possible
   • Commands to execute – exactly what commands will be run (e.g., git add ..., rm ..., npm run test)
   • Expected outcomes – what should happen after the changes (e.g., tests pass, feature works)
   • Risks or side effects – any potential issues (e.g., breaking API compatibility, data loss)

3. Present the plan to the user – Use a clear heading or code block. Example:

   ## Change Plan
   - Modify `src/config.js`: change line 12 from `port=3000` to `port=4000`
   - Delete `legacy/deprecated.py`
   - Run `make migrate` after changes
   Please review and reply with **approve** to proceed.
   

4. Request explicit approval – Wait for a message that contains an unambiguous approval word (e.g., "approve", "proceed", "yes", "looks good", "ok to execute"). Do not assume generic statements like "ok" or "sure" are approval unless they clearly refer to the plan.

5. Execute only after approval – Perform each action exactly as described in the plan. If any deviation becomes necessary, go back to step 2 (update plan and re-request approval).

6. Handle modifications to the plan – If the user asks for changes to the plan, update the plan accordingly and go back to step 4. Do not merge the new request into execution without a fresh approval.

Common Rationalizations

Rationalization	Counter‑argument
"The change is trivial (e.g., a one‑character fix)."	The skill applies to all changes regardless of size. A single character can break production. The plan step costs seconds and prevents mistakes.
"The user already described what they want, so a separate plan is redundant."	A verbal description is not a structured plan. The plan forces the agent to verify scope, identify missing files, and surface assumptions before execution.
"I can show the plan and execute immediately because the user is waiting."	The user explicitly asked for review before execution. Skipping the wait violates the request and erodes trust.
"The user said 'go ahead' generically earlier in the conversation."	Approval must refer to the current plan. Old approvals do not apply to new or changed plans.
"I already know the exact commands, so planning is just busywork."	The plan is not for the agent – it's for the user to review. Writing it down makes hidden assumptions visible.

Red Flags

Recognise these behavioural patterns that indicate the skill is being violated:

• The agent makes any change (file write, delete, command execution) without first presenting a plan.
• The agent presents a plan but does not wait for a reply before acting.
• The agent updates a plan based on user feedback but does not re‑request approval.
• The agent executes additional changes that were not listed in the approved plan.
• The agent assumes approval from partial statements (e.g., "looks" without "good", "ok" when context is ambiguous).
• The agent proposes a plan that is too vague (e.g., "I'll update the authentication code" without file names or line numbers).

Verification

Before considering this skill "followed" for a given change, confirm:

• ☐ A plan was written and presented to the user.
• ☐ The plan includes file paths, operations, and (for modifications) exact changes or diffs.
• ☐ The agent explicitly asked for approval with a clear request (e.g., "reply with 'approve'").
• ☐ The user replied with an explicit approval message that refers to the plan (captured in conversation log).
• ☐ Every executed action matches the approved plan exactly – no extra changes, no omitted steps.
• ☐ If any deviation occurred, a new plan was created and approved before proceeding.