GitHub Copilot flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Accept inline suggestion

Press Tab to insert the current ghost-text completion at the cursor. The accepted text becomes ordinary editable code, so you own its correctness, security, and licensing.

Cycle next suggestion

When several completions are available, use the next-suggestion shortcut (Alt+] on Windows/Linux, Option+] on macOS) to preview alternatives before accepting or rejecting with Esc.

Copilot Chat context references

Chat participants and variables such as @workspace, @terminal, @vscode, #file, and #selection attach specific context to a prompt, controlling which files or selections the model can reason over.

Slash commands in chat

Predefined prompt intents like /explain, /fix, /tests, /doc, and /new expand into structured requests, saving you from writing the same framing instructions repeatedly.

Copilot Edits mode

An agent-style mode that proposes coordinated changes across multiple files as a reviewable diff. You accept or discard per file instead of approving single-line completions.

Copilot code review

A pull request feature that posts review comments generated by Copilot. Comments are advisory suggestions; they do not approve, block, or merge the pull request on their own.

Pull request summaries

Copilot can draft a PR description from the diff. The author must verify the summary, because it may omit behavioral changes or misdescribe intent.

Copilot CLI assistance

Terminal surfaces let you request shell commands and explanations. Generated commands can be destructive, so inspect flags and paths before executing them.

Client-server architecture

The IDE extension gathers local context, sends a prompt over HTTPS to GitHub's service and a hosted model, and streams completions back for display in the editor.

Context window limits

Prompts and surrounding code are truncated to fit a token budget. Files far from the cursor or selection usually contribute nothing to an inline completion.

Completion versus chat models

Inline suggestions use latency-optimized models with short context, while chat requests can use larger models with longer context and tool-like context references.

Code referencing

A feature that matches suggestions against an index of public code and can show the matching repository and license, helping you assess provenance before accepting.

Training data policy

Business and Enterprise plans do not use member code to train models. Individual plans expose a setting governing whether snippets may be used for product improvement.

Server-side exclusion enforcement

Content exclusions are applied by the service, not the client, so excluded repositories and paths are not sent as context and cannot produce suggestions.

Copilot metrics

Administrative reporting on seats, active users, acceptance rates, and feature adoption. Metrics describe usage patterns and do not expose full prompt contents.

Network requirements

Editors reach GitHub hosts and the model service over HTTPS. Firewalls and proxies must allow these endpoints or completions and chat fail silently or with errors.

Prompt specificity rule

State language, framework, version, input and output shapes, and constraints. Every ambiguity left in the request becomes variance in the returned suggestion.

Selection as context

Selecting the target region and opening related files before prompting gives the strongest signal, because selection and nearby code dominate the assembled context.

Few-shot anchoring

Including one or two short examples of the desired signature, style, or output format in the prompt constrains the model to imitate that pattern.

Comment-driven development

Write a precise comment or docstring describing intended behavior, then trigger completion. The comment acts as an executable specification for the generated body.

Negative constraints

Explicit prohibitions such as no new dependencies, no network calls, or keep the public API unchanged shrink the output space and reduce unwanted refactors.

Task decomposition

Split large requests into signature, body, then tests. Each small prompt fits the context budget and is easier to verify than one monolithic request.

Refine rather than regenerate

When output is wrong, edit the prompt or attach the missing file instead of re-rolling the same request, since identical context tends to yield similar results.

Plan before code

Ask chat for an approach or diff outline first. Reviewing the plan catches reasoning errors before they are written into multiple files.

High-yield productivity tasks

Boilerplate scaffolding, test generation, docstrings, regex construction, and language translation give the largest time savings because they are pattern-heavy and easy to verify.

Generated test verification

Tests produced from a selection often mirror the implementation's existing bugs. Check each assertion against intended behavior rather than trusting a green run.

Stack trace diagnosis

Paste the full error message and relevant frames into chat with /fix or /explain. Complete traces produce far better diagnoses than a single exception line.

Multi-file refactoring

Copilot Edits handles renames, signature changes, and repeated pattern replacements across files, provided you review the diff and run the build afterward.

Impact measurement

Use adoption and acceptance metrics alongside delivery data. High acceptance rates do not by themselves demonstrate improved code quality or reduced defects.

Content exclusion rules

Organization or enterprise settings that list repositories and path patterns whose files are never sent as context, covering both completions and chat features.

Policy hierarchy

Enterprise settings constrain organizations, organization settings apply to members, and user preferences operate inside that envelope. A lower level cannot loosen a higher restriction.

Public code matching block

An organization policy that disallows suggestions matching public code. Matching completions are suppressed rather than shown with a reference.