Originally shared as an internal how-to document.
GitHub Copilot as a true pair programmer
I've spent a lot of time testing workflows, instructions and prompts. Some with more context, some with less. I've gotten some great results and some spectacular failures! Here's an overview of what I found works for nearly every scenario when using GitHub Copilot Agent mode as a pair implementation specialist.
📌 TL;DR
- Set up repo-level instructions & starter template
- Know your goal & break tasks into stories
- Explore options in Ask mode for planning
- Design a comprehensive, context-rich prompt
- Spell out rules, conventions & self-review steps
- Choose the right AI model for each task
- Require a self-review pass
- Supervise your AI pair—pause & redirect
- Review & refine changes like a seasoned engineer
- Provide feedback, reprompt & repeat
1. Set Up Repo-Level Instructions
Why it matters: Repo instructions give Copilot the context it needs before any new code exists. This is your baseline and everything from here on will depend on this.
🔁 If you missed it, check out my previous post All I’ve Learned About GitHub Copilot Instructions (So Far).
If you're starting a brand new project, use a starter template to scaffold basic structure and create a minimum set of instructions that includes:
Category | Description | Notes |
---|---|---|
Project Overview | What does this repo do? Why does it matter? | |
Testing Requirements | TDD strategy, code coverage %, test types, error handling, edge cases. | I never had a great opportunity to test Copilot's reaction to TDD. Add your experience below! |
Documentation | Javadoc, README, Swagger/OpenAPI specs. | ✨ If you want something a little more advanced, look into mermaid diagrams! |
Design & Security | Architecture constraints, naming conventions, auth rules. | |
Review Rules | Checklist for self-reviews and criteria for acceptance. | This step will save you a ton of time in the long run. |
2. Know Your Goal & Break It Down
✨ Side-project vibe-code?
🛠️ Production bug fix?
🌀 Somewhere in between?
Define your end goal, then split work into small, targeted stories that Copilot can handle one step at a time. If a task can be broken down further, do so - you’ll get better results. The smaller and more targeted you define the task, the better results you’ll get in the end.
💡 ProTip: Give Copilot access to your issue tracker via an MCP server. That's one less thing to copy/paste and you can add an update clause in your prompt to let Copilot handle the comments and even issue tracking status or labels directly.
3. Explore in Ask Mode
If you know exactly how, why, and where, then you can probably skip this step. Otherwise, before coding, do a little exploring with Copilot Ask mode. Prompt it with something like:
Given requirements in JIRA-123, analyze #codebase and propose 3 implementation options with pros/cons. Score each by simplicity & maintainability. Recommend one.
Iterate until uncertainties are surfaced and addressed. This is also the perfect time to validate your setup, including the story itself and custom instructions. Ask yourself, is the result what you expected it to be? If not, can you pinpoint which detail was unclear or too complex?
This is not only a great time to improve your custom instructions and story definition, but also explore alternative approaches. You might even think of something you wouldn't have otherwise.
⚠️ Be careful with overconfident models. Sometimes you will read an explanation presented with such a high degree of certainty that you’ll catch yourself agreeing with it regardless of whether it actually makes sense for your use case.
💡 ProTip: Ask mode is perfect for exploration. It prevents Copilot from making changes to the code before you’re ready and it saves a premium request.
4. Design a Comprehensive Prompt
Consider how you want to prompt Copilot to complete its task. For a high-impact production fix, you will probably want to keep a tight leash on the exact implementation. The more straightforward the prompt and instructions are, the less room Copilot has to veer off its intended path or hallucinate a better implementation than the one you had planned.
Your prompt should include:
- Specific
#file
or#selection
that is relevant to the task - Open any related or secondary files in the editor as additional context
- A numbered list of implementation steps, if you need better control or visibility along the way.
- Specify any important design patterns, security concerns, or future work planned (can also be separate
.github/instructions/specific-guidelines.instruction.md
files in the repo for ultimate reusability. - Identify any important config files (like
./eslint.config.js
or./vitest.config.js
) that Copilot must adhere to and put them in context with #file. - For complex tasks, add an extra step instructing Copilot to consider at least X alternative approaches before starting work. Assess whether the detailed implementation plan covers all edge cases and error scenarios appropriately. If not, then update accordingly before moving on.
It's always better to be more specific and more strict than to provide no guidance at all. If that means your prompt is closer to the size of a 3-page essay, then that's OK! Try it out and make changes later, if needed.
‼️ Example prompt:
Assess this #codebase in conjunction with the #file:README.md. Use #githubRepo tool to reference other codebases, as needed. Without making any changes to the existing code, generate a new PROJECT_DIAGRAM.md file that correctly illustrates a mermaid diagram for this repository. Adhere to the following guidelines: 1. The primary project diagram should be a very high-level and only include inputs, major functionality/business logic/outputs. If it links to a separate project, those should be well documented. 2. For each primary use case you can identify, generate a diagram for it that includes enough detail to document the process end to end, but leave out any irrelevant processing or "common sense" logic. 3. Every diagram should have its own section that includes the mermaid diagram itself, a brief description of its purpose, any external factors or links, troubleshooting steps for common failures, and suggested future improvements, if any exist, that would improve maintainability or eliminate potential bugs. 4. Ensure this new project_diagram is linked to from the primary #file:README.md
💡 ProTip: Mermaid diagrams are a great addition to any
README.md
and GitHub renders them without any help on your end. If you want the preview to display in VS Code, you'll need to install an extension. I use bierner.markdown-mermaid but there's a ton of them available.
5. Spell Out Rules & Guidelines
Reference your README.md
or .github/custom-instructions.md
file when defining strict guidelines, especially if a commit hook or linter is involved.
In your prompt, try adding something similar to:
Follow conventions in README.md: Javadoc, pass all tests, adhere to secure coding guidelines.
For narrow tasks, add file-specific context:
Implement within #MyComponent.tsx, preserve API interface.
🏹 One prompt → one premium request in Agent Mode. Maximize your premium usage by combining as much information and context into a single prompt as possible.
6. Choose the Right AI Model
The model you choose is probably the next biggest impact to the overall implementation and outcome. When in doubt, try the cheapest one first (aka smallest premium multiplier). If it doesn't work the first time, /clear
everything and then re-submit the prompt.
Task | Recommended Model | Alternate Model |
---|---|---|
New feature or complex logic | Claude Sonnet (any version) | Claude Opus |
Quick fix | o3/4-mini | Gemini 2.0 Flash |
Heavy analysis or debugging | o3/4 (regular) | Gemini 2.5 Pro |
Ideation or creative exploration | GPT-4.1 | GPT-4.5 |
📌 Refer to GitHub's model cheatsheet for more detailed info about picking the right model.
💡 ProTip: The VS Code Chat extension works like your terminal - just press the up arrow key to rotate through previous chats, even after you've cleared them. You can also use the history button at the top to return to a previously cleared chat.
7. Require a Self-Review Pass
Either in the overall initial prompt or in a custom-instructions file, instruct GitHub Copilot to complete a detailed self-review of all changes made according to a set guideline (security, optimization, maintainability, etc):
- Pass all tests & coverage checks - Meet lint & format requirements - Perform a detailed self-review with a focus on secure coding practices
💡 ProTip: You'll save on premium requests if you include the self-review requirements in the initial prompt. However, you'll get better results if you separate the review step from the implementation (be sure to
/clear
and consider changing the model, too!)
8. Supervise Your AI Pair
Always follow these basic guidelines whenever you're working with GitHub Copilot:
-
Never leave Copilot unattended (ask me how I know 🤣)
☝️ Asked and answered here.
When in doubt, pause the task
Clarify & redirect whenever needed
Resume only when context is clear
Communicate manual edits with Copilot (else they'll get overwritten)
💡 ProTip: It doesn't seem to cost anything extra to simply pause execution, assess, and then resume. However, if you end up sending a new prompt to redirect they will charge you the standard premium request fee (whenever I figure out what that really means, I'll let you know!)
9. Review Like a Human
Use VS Code’s diff view to accept/reset line-by-line. Keep changes by default and reset unwanted bits in Source Control - this helps prevent accidental resets.
Pick your battles. Don’t spend premium requests on minor formatting or nitpicks. Sometimes you have to accept that it's never going to be 100% perfect. Don't be afraid to jump in and take over when you need to.
🚨 Channel your inner code review boss, every single time. Whether AI helped out or not, you’re always on the hook for clean, accurate code. Double-check, polish, and take pride in your commits - it’s your name on the line, so make sure it’s something you’d want to sign off on!
10. Refine, Reprompt & Repeat
Treat every interaction with Copilot like you're teaching a junior dev. Use every available opportunity to improve your instructions, prompt, or clarify your goal:
- Ask clarifying questions
- Get alternate solutions
- Propose different approaches (then let Copilot pick)
- Prompt Copilot to challenge logic
- Flag missing tests/docs with inline or PR comments
💡 ProTip: Copilot is a powerful teammate, but it’s not a one-size-fits-all solution - especially when you’re dealing with brand-new repos, high-stakes production fires, or anything that needed to be done yesterday. Save yourself a headache: choose your AI battles wisely, and don’t try to make AI your Swiss Army knife for every situation. Sometimes, the fastest route is a good old-fashioned human touch.
💬 Your Turn:
What worked (or spectacularly failed)? Any surprises when pairing with GitHub Copilot?
Share your personal wins, no-repeat plans, and unique stories below!
🛡️ RAI Disclaimer
Everything I share here is my own perspective—created with the help of AI tools (GitHub Copilot, ChatGPT, and their friends), but always with a human in the loop. I do my best to catch accidental bias and fact-check, but if you ever spot something odd, let me know! AI isn’t perfect, and neither am I.
TL; DR: AI helped, but you can blame me for the chaos! 🫠
Top comments (0)