GitHub Copilot is an AI coding assistant that can suggest code, explain existing logic, support refactoring, help investigate defects and generate tests. Use it as a collaborator: give it clear context, review every change and keep people accountable for the final result.
On this practical guide
Where GitHub Copilot helps
Write
Generate boilerplate, functions, scripts, tests and documentation from a clear description.
Understand
Explain unfamiliar code, data flow, regular expressions, errors and dependencies.
Improve
Suggest refactors, remove duplication and make code easier to read or maintain.
Debug
Analyse an error, propose likely causes and suggest focused checks or fixes.
Test
Draft test cases, unit tests, API checks and Playwright scenarios, including negative paths.
Review
Summarise a change and highlight risks, missing validation or possible edge cases.
Keep expectations realistic: Copilot can produce incomplete, insecure or incorrect output. A confident answer is not proof that the answer is correct.
Ways to work with Copilot
| Experience | Good for | How to use it |
|---|---|---|
| Inline suggestions | Small completions and repetitive code. | Start writing code or a precise comment, then accept, edit or reject the suggestion. |
| Inline chat | A focused change in the current file or selection. | Select the relevant code and ask for one clear transformation or explanation. |
| Chat | Questions, planning, debugging and codebase exploration. | Provide the goal, context, constraints and expected output. |
| Edit mode | Controlled changes across selected files. | Choose the working set, describe the change and review the resulting diff. |
| Agent mode | Multi-step tasks that may inspect files, run tools and iterate. | Set boundaries, monitor actions and validate the final result. |
| GitHub experiences | Repository questions, pull requests, issues and code review. | Use only the repository context needed for the task. |
Names and availability can differ by editor, plan and organisation policy. Check the current GitHub documentation before depending on a specific feature.
Write better prompts
A useful prompt explains the task like a short engineering ticket.
Goal: Add Playwright coverage for the password reset form.
Context:
- Tests use TypeScript and Page Object Models.
- Existing fixtures are in tests/fixtures.ts.
- Prefer role and label locators.
Requirements:
- Cover a registered email and an invalid email format.
- Assert the visible message and the API response.
- Do not use fixed waits.
Output:
- Show the proposed test file.
- Explain assumptions and any missing information.
Prompt checklist
- State the goal and desired result.
- Point to relevant files, code or errors.
- Describe project conventions and constraints.
- Give representative examples when format matters.
- Ask for assumptions, risks and alternatives.
- Break large requests into reviewable steps.
- Continue the conversation to correct or refine the result.
A practical QA workflow
- Understand the change. Ask Copilot to summarise the relevant code, interfaces and affected flows.
- Identify risks. Request positive, negative, boundary, permission, accessibility and failure scenarios.
- Choose coverage. Decide what belongs at unit, API, integration or UI level.
- Draft tests. Provide the framework, local conventions and acceptance criteria.
- Inspect the diff. Check selectors, data, assertions, cleanup and unintended file changes.
- Run quality checks. Execute formatting, linting, type checks and the relevant test suite.
- Challenge the result. Add cases Copilot missed and confirm the test can fail for the right reason.
- Use normal review. Commit and review AI-assisted changes through the same pull request and CI process as human-written code.
Useful QA prompts
Explain this feature from a tester's perspective. List its inputs,
outputs, state changes, dependencies and main risks.
Create a decision table for these acceptance criteria. Highlight
missing or conflicting rules before writing test cases.
Review this Playwright test for weak locators, fixed waits, shared
state, missing assertions and reasons it may become flaky.
Given this failed CI log and the related test, separate likely product
defects from test or environment problems. Suggest the next three checks.
Review AI-generated code
- Read every line. Never approve a change only because tests pass.
- Confirm the code matches the requirement and project conventions.
- Check authentication, authorisation, input validation and error handling.
- Look for exposed secrets, personal data or unsafe logging.
- Verify dependencies, licences and copied-looking code before adoption.
- Test edge cases and failure paths, not only the generated happy path.
- Run static analysis, security scanning and dependency checks where available.
- Keep the change small enough for a person to review properly.
Responsible use principles
| Principle | Practical behaviour |
|---|---|
| Fairness | Test representative users and data. Look for different outcomes between comparable groups. |
| Reliability and safety | Validate output under normal, boundary and failure conditions. Add human approval for high-impact actions. |
| Privacy and security | Do not place secrets, credentials, personal data or restricted code in prompts unless policy explicitly allows it. |
| Inclusiveness | Consider accessibility, language, location, device and connectivity needs. |
| Transparency | Record important assumptions and make AI-assisted work reviewable through normal diffs and evidence. |
| Accountability | The person and team accepting the output remain responsible for its quality and impact. |
Before using Copilot at work: follow your organisation's rules for source code, customer data, intellectual property, approved models, extensions and external tools.
Configure useful project context
Good repository instructions reduce repeated explanations. GitHub supports repository-wide instructions in .github/copilot-instructions.md. Keep them short, specific and maintained with the codebase.
# Repository guidance
- Use TypeScript with strict mode.
- Follow the existing folder and naming conventions.
- Prefer accessible Playwright locators: role, label and test ID.
- Never add fixed sleeps to automated tests.
- Reuse fixtures and test-data builders before creating new ones.
- Run formatting, linting, type checks and affected tests.
- Do not modify generated files or commit secrets.
- Explain assumptions when requirements are incomplete.
Teams can also use path-specific instruction files for specialised areas. Keep local editor settings, organisation policies and content exclusions aligned with the repository's security needs.
MCP and external tools
Model Context Protocol (MCP) lets Copilot connect to approved tools and data sources. The GitHub MCP Server can provide repository context and actions for areas such as issues, pull requests and code. Other MCP servers may expose test management, browsers, documentation or internal services.
- Use trusted servers from known publishers.
- Review the tools and permissions a server receives.
- Grant the minimum access needed for the task.
- Prefer read-only access until write actions are necessary.
- Review tool calls before allowing sensitive or destructive operations.
- Never place tokens directly in source files or committed configuration.
- Follow organisation policies and approved-server lists.
MCP expands impact: a wrong chat answer is one risk. A wrong answer with permission to change issues, code or environments is a larger risk. Keep access narrow and retain human control.
Troubleshooting checklist
- Confirm the correct GitHub account has Copilot access.
- Check whether an organisation policy disables the feature or file type.
- Update the editor and Copilot extensions, then reload the editor.
- Sign out and sign in again when authentication appears stale.
- Check the GitHub status page for an active service incident.
- Test a small file or clean workspace to isolate project-specific problems.
- Check proxy, VPN, firewall and certificate settings.
- Review Copilot logs without sharing secrets or personal data.
- For MCP problems, confirm the server is running, authorised and allowed by policy.
Quick adoption checklist
- Start with low-risk, easy-to-review tasks.
- Agree what data and repositories Copilot may access.
- Add concise repository instructions.
- Keep human review and CI checks mandatory.
- Measure useful outcomes such as review time, escaped defects and rework.
- Collect examples of effective prompts and common failures.
- Review permissions, policies and instructions regularly.
Useful links
- GitHub Copilot documentation ↗ — current features, setup and administration.
- Customising Copilot responses ↗ — repository and path-specific instructions.
- Set up the GitHub MCP Server ↗ — current configuration guidance.
- Troubleshoot common Copilot issues ↗ — authentication, extensions and connectivity.
- Responsible use of GitHub Copilot ↗ — limitations and recommended safeguards.
- Current Copilot plans ↗ — compare availability and limits.