Developers like automation. GitHub Copilot Agent writes code, runs tests, edits files.
This speed hides a risk. The agent starts changing code before you see a plan.
You need a brake. A short sentence in your prompt gives you control.
The core idea
Describe the changes you want.
Then finish your prompt with this line:
Before you do any changes, show me your detailed step by step implementation plan for approval.
You ask the agent for a plan first. No edits yet. Only a clear list of steps.
Afterwards you review the plan. You confirm, refine, or reject.
Why this helps
A plan first pattern improves the flow.
You gain:
- Clear intent before edits touch your code
- Easier review, since you see a list of steps, not a block of diff
- Lower risk of half-finished refactors
The agent shifts from "fire and forget" to "propose, then act".
You stay in charge of scope and direction.
A small example
Prompt:
I want to extract logging concerns from this C# class into a separate service.
Steps:
1. Identify all logging calls.
2. Introduce an IAppLogger interface.
3. Inject IAppLogger into the constructor.
4. Replace direct logging calls with the new abstraction.
Before you do any changes, show me your detailed step by step implementation plan for approval.
A good plan from the agent might look like this:
Step 1: Scan the class and list all logging calls, grouped by log level.
Step 2: Propose the IAppLogger interface signature which covers the current usage.
Step 3: Add the new interface and a concrete implementation in a Logging folder.
Step 4: Update the target class constructor to accept IAppLogger through dependency injection.
Step 5: Replace direct logging calls with calls to IAppLogger.
Step 6: Update the composition root to register the concrete logger.
Step 7: Propose unit test updates for the new abstraction.
You read the plan. You notice missing points or risks.
For example:
- No mention of structured logging
- No mention of log context
- No mention of cross cutting concerns in other classes
You respond:
Good start.
Extend the plan with:
- Structured logging support
- Log context (correlation id, user id)
- Follow up steps for other classes using logging in this project
Then show me the updated plan. Do not change any code yet.
Only when the plan looks solid you ask the agent to apply the plan.
Prompt variants
You tune the line for different work modes.
For safety and review:
Before you do any changes, show me your detailed step by step implementation plan for approval. Wait for my confirmation before you start.
For pair programming:
Before you do any changes, propose a detailed step by step implementation plan. Ask me questions if anything in my request is unclear.
For larger refactors:
Before you do any changes, outline a detailed step by step implementation plan with milestones. Mark risky steps explicitly.
Notice the common structure.
You ask for:
- A detailed plan
- Steps in order
- A pause before edits
- Space for questions
Tips for daily use
A few habits help you get value from this pattern.
- Keep your change request short and focused
- Ask for numbered steps
- Ask for risk highlights for bigger changes
- Ask for test impact in the plan
- Store your favorite prompt variant in a snippet or note
- Use the same pattern across your team, so prompts stay consistent
When this pattern shines
This simple line in your prompt works best when:
- You refactor legacy code
- You touch shared libraries
- You change public APIs
- You work in a codebase you do not know well
- You review plans with teammates in chat or pull requests
In all those cases you gain a shared view of the work before any edit happens.
You see scope. You see risk. You see test impact.
Then you decide how far the agent should go.
You guide the agent. Not the other way around.
Top comments (0)