1 Overview

Everything in Module 1 assumed you were typing prompts into a chat box. GitHub Copilot moves the model into your editor, where your code becomes the prompt: it reads the file you're editing, your open tabs, and your comments, then suggests code inline as you type — plus a chat assistant that can explain, test, refactor, and document with your workspace as context.

For .NET developers, Copilot is where prompting skill pays off most often, because you use it hundreds of times a day. The developers who get spectacular results from it are doing the same things you learned in Module 1 — supplying context, writing clear intent, reviewing everything — just expressed through editor-native mechanics: names, comments, open files, and chat.

This tutorial covers the daily craft: writing C# with completions, generating NUnit unit tests, refactoring and quality improvement, documentation generation, building service classes, and using Copilot Chat effectively. The next tutorial goes deeper into advanced usage.

2 Learning Objectives

After completing this tutorial, you will be able to:

• Explain how Copilot builds context from your editor and steer it deliberately.
• Write C# with completions efficiently: intent comments, descriptive names, and rhythm of accept/reject.
• Generate NUnit test suites with Copilot and review them with tutorial 5's honesty discipline.
• Drive behavior-preserving refactorings and quality improvements through Copilot Chat.
• Generate XML documentation comments and higher-level docs from your code.
• Scaffold service classes that fit your codebase's dependency injection and conventions.
• Use Copilot Chat's slash commands, selections, and inline chat where each fits best.
• Apply the unchanged review bar: Copilot suggestions are drafts, not decisions.

3 Prerequisites

• A GitHub account with Copilot access (individual, business, or trial) and Visual Studio 2022 or VS Code with the Copilot extensions installed.
• Module 1's prompting fundamentals — especially context supply (tutorial 4) and generated-test review (tutorial 5).
• Comfortable C#: classes, interfaces, async/await, and a working .NET project to practice in.

4 How Copilot Thinks: Context Is Everything

GitHub Copilot — the archetypal AI pair programmer — has two faces. Code completion offers ghost text at your cursor: each inline suggestion is a gray preview you accept with Tab or ignore by typing on, ranging from finishing a line to writing a whole method. Copilot Chat is a conversation panel (plus inline chat at your cursor) for multi-step work: explain this, test this, refactor this, with your code attached as context. Completions keep you in flow; chat handles anything needing instructions or discussion.

Both faces run on the same fuel: context. Copilot does not magically know your repository — for completions it primarily sees the current file and your other open editor tabs; for chat, your selection, the file, and whatever workspace context you explicitly reference. This single fact explains most quality variance between users. The developer with the relevant interface open in a tab, descriptive names, and a clear intent comment gets eerily accurate suggestions; the developer in an empty file with vague names gets tutorial-grade filler.

Hold on to the Module 1 mapping: intent comments are instructions; open tabs are grounding and few-shot examples; descriptive names are context; chat questions are full prompts; and every suggestion is a draft entering Ask → Review → Improve. Copilot is prompt engineering with the prompt assembled from your workspace.

5 Writing C# Code with Copilot

Daily completion craft comes down to three steering inputs and one rhythm. Steering input one: names. `ProcessData(object input)` invites junk; `CalculateLoyaltyDiscount(Order order, CustomerTier tier)` practically writes its own body, because descriptive names collapse the space of plausible completions. Write the signature you actually want before pausing for the suggestion.

Steering input two: the intent comment. A one-line comment above the cursor describing what comes next is a mini-prompt: '// validate the request, returning all failures rather than stopping at the first' produces materially different (and better) code than no comment. For anything non-obvious, state edge cases in the comment — '// treat null and empty as no discount' — exactly like output constraints in Module 1. Delete or compress scaffolding comments after acceptance; keep the ones that still document intent.

Steering input three: open tabs. Implementing `IInvoiceExporter`? Open the interface in a tab. Writing your fourth repository? Keep the best existing one open as an exemplar — Copilot imitates its structure, naming, and error handling with startling fidelity. This is the editor-native version of tutorial 4's context pack: contracts plus exemplar, supplied by tab management instead of pasting.

// Parse a quantity string: range 1-999, whitespace tolerated,
// null/empty/non-numeric throws ArgumentException,
// out of range throws ArgumentOutOfRangeException.
public static int ParseQuantity(string input)
{
    // <- pausing here, Copilot proposes a body honoring the comment's rules.
    //    The comment IS the prompt: instruction + constraints in one place.
}

The rhythm: accept small, review always. Line-sized and block-sized acceptances stay reviewable in real time; whole-method acceptances get read before Tab, exactly as you'd review a colleague's paste. When a suggestion is close-but-wrong, accept then immediately correct — or reject and improve the steering (better name, sharper comment) rather than Tab-ing and hoping. Rejecting bad ghost text is one keystroke; debugging accepted bad ghost text is an afternoon.

6 Generating NUnit Tests and Documentation

Test generation is Copilot's most-loved workflow, and everything from tutorial 5 transfers. The chat route: select a method (or open its file) and use the /tests slash command — or better, a full chat instruction: 'Generate NUnit tests for ParseQuantity. Cases: happy paths, both sides of every boundary (0/1, 999/1000), null/empty/whitespace, non-numeric. [TestFixture], MethodName_Scenario_ExpectedResult names, Assert.That syntax, [TestCase] rows for boundaries.' The richer instruction is tutorial 5's context pack, typed into chat.

The completion route is quieter but powerful: open your test file beside the code under test, write the fixture shell and one exemplar test in your style, then write just the name of the next test — `Calculate_NegativeTotal_ThrowsArgumentOutOfRange` — and let ghost text supply the body. Because your exemplar and the code under test are both in context, the generated bodies match your conventions and the real API. The oracle discipline is unchanged: behavior expectations should come from a spec (your test names encode it), and every generated suite faces the honesty review — read the assertions, sabotage the code, demand red.

Documentation is the fastest win in the whole tool. Select a member and use /doc for XML documentation comments — or chat: 'Write /// docs for every public member: summary as purpose (not mechanism), params with meaning and units, returns, and each exception condition. Do not invent defaults or thread-safety claims.' The anti-invention clause survives from tutorial 5 because the failure mode survives: fluent docs stating behavior the code doesn't have. Fact-check every specific; then enjoy that documenting a class now takes minutes.

7 Refactoring, Quality, and Service Classes

Refactoring with Copilot runs through chat (or inline chat) on a selection, and tutorial 4's iron rule comes with it: say behavior-preserving, explicitly, every time. 'Refactor this method: extract the duplicated validation into a private helper. Behavior-preserving — identical outputs, exceptions, and side effects. Output only the changed code.' Small, named steps; tests green before and after; 'also fixed a bug I noticed' gets rejected and split into its own reviewed change. The /fix command handles the reverse case — diagnosing and correcting an actual defect — and its output gets the same scrutiny as any diagnosis from tutorial 3's debugging pattern.

For quality improvement, replace adjectives with criteria, exactly as in tutorial 4: 'Improve readability: guard clauses instead of nested ifs, max two nesting levels, intention-revealing names, no boolean parameters. Keep behavior identical.' Copilot Chat applies named criteria well; 'make this better' produces churn. A strong habit is the review prompt: select a method you just wrote (with or without Copilot) and ask 'Review this against [criteria]; list issues with line references before changing anything' — the model as first-pass reviewer, findings before edits.

Service classes are Copilot's natural scaffolding unit because your codebase already demonstrates the pattern. The workflow: open the interface to implement plus one exemplar service in tabs; write an intent comment block naming the service's responsibility and dependencies; write the class declaration and constructor signature; then let completions drive member by member, or ask chat to scaffold the skeleton first (tutorial 4's skeleton-first discipline, editor edition). With constructor injection visible in your exemplar, Copilot wires dependency injection idiomatically — including the registration line when you ask for it.

// OrderArchiveService: moves closed orders older than a retention window
// to cold storage. Dependencies: IOrderRepository, IColdStorageClient,
// TimeProvider. Async throughout, CancellationToken on public methods,
// no exceptions swallowed. Follow the structure of CustomerExportService.
public sealed class OrderArchiveService : IOrderArchiveService
{
    // <- with the interface and CustomerExportService open in tabs,
    //    completions now propose constructor, fields, and members
    //    matching your codebase's conventions.
}

8 Using Copilot Chat Effectively

Chat is where Module 1 skills transfer most directly — a chat message is just a prompt with your workspace attached. Effectiveness comes from three mechanics: scope (what code the question is about — a selection beats a file, a file beats vague reference), instruction quality (full anatomy: what to do, constraints, output form), and the right entry point for the job:

Chat's underrated superpower is explanation-first work on legacy code: /explain on a selection, verify against the source, then modify — the tutorial 3 pattern with zero copy-paste friction. Its equally underrated trap is scope creep: long chat sessions accumulate stale context just like any conversation (tutorial 6's pollution), so start fresh threads per task and re-select code rather than assuming the chat remembers your current state.

9 Setup and the Surrounding Toolchain

• Visual Studio 2022: Copilot ships integrated in current versions — sign in with your GitHub account; completions and chat appear natively in the IDE.
• VS Code: install the GitHub Copilot and Copilot Chat extensions; same sign-in, same two faces.
• Plans: individual, business, and enterprise tiers differ in policy controls (telemetry, suggestion filtering, model options) — teams should review business-tier settings deliberately.
• The deterministic gate is unchanged: compiler, Roslyn analyzers, .editorconfig, tests, and CI judge every accepted suggestion exactly as they judge typed code (tutorial 4's enforcement truth).
• Keyboard essentials worth learning day one: accept (Tab), dismiss (Esc), cycle alternative suggestions, and the inline-chat shortcut — check your IDE's current keybindings, as they evolve.
• Public-code filtering and IP settings exist at the organization level — know your team's policy before you rely on defaults.

One habit upgrades everything else: treat tab management as context management. Before a work session, open the interfaces and exemplar classes the task involves; close noise files. You are literally assembling Copilot's prompt — the developers who do this consciously stop being surprised by suggestion quality.

10 The Daily Copilot Catalog

The catalog's common thread: Copilot compresses the typing, never the judgment. Each row pairs a generation mechanism with the Module 1 discipline that makes it safe — and the pairs are not optional garnish; they are why some teams report large quality-neutral speedups while others report speed with a defect tax.

11 Code Examples in C#

A realistic completion session: the test-file pattern from section 6. You write the shell and one exemplar; Copilot writes the rest from names.

[TestFixture]
public class ParseQuantityTests
{
    // Exemplar test - handwritten, sets the style:
    [Test]
    public void Parse_ValidNumber_ReturnsValue()
    {
        int result = QuantityParser.ParseQuantity("42");
        Assert.That(result, Is.EqualTo(42));
    }

    // Now write ONLY the next test's name and pause:
    [Test]
    public void Parse_ValueBelowMinimum_ThrowsArgumentOutOfRange()
    {
        // <- ghost text proposes the body: correct exception type,
        //    boundary value "0", Assert.Throws pattern matching your exemplar.
    }

    // Boundary table? Write the attribute rows and pause after the signature:
    [TestCase("1", 1)]
    [TestCase("999", 999)]
    public void Parse_BoundaryValues_ReturnsParsed(string input, int expected)
    {
        // <- body follows from the rows + exemplar.
    }
}

And the chat-side instruction that produces a compliant service skeleton — note it is tutorial 4's scaffolding template, typed where the workspace supplies the contracts:

/*  Paste into Copilot Chat with IOrderArchiveService and
    CustomerExportService open in editor tabs:

    Scaffold OrderArchiveService implementing IOrderArchiveService.
    Skeleton ONLY: fields, constructor (constructor injection),
    method stubs with XML docs and TODO comments - no logic yet.
    Conventions: async suffix, CancellationToken on public methods,
    match the structure of CustomerExportService.
    Then wait - I will review before we fill any method.       */

12 Step-by-Step: A Service Class, End to End, with Copilot

One complete feature — an EmailDigestService that summarizes a user's weekly activity — built with every mechanism in this tutorial. Replay it in your own project.

1. Stage the context: open IEmailDigestService (the interface), your cleanest existing service (exemplar), and the entities it touches. Close unrelated tabs. This is prompt assembly.
2. Skeleton via chat: the section-11 instruction — skeleton only, constructor injection, conventions named, 'wait for my review'. Review the skeleton: naming, dependencies, cancellation. Fix with one follow-up.
3. Fill member by member with completions: intent comment above each method stating rules and edge cases, then let ghost text propose; accept block by block, reviewing each. Close-but-wrong suggestions get corrected immediately, not Tab-ed past.
4. Quality pass via chat: select the completed class — 'Review against: guard clauses, max 2 nesting levels, no swallowed exceptions, intention-revealing names. List issues with line references first.' Apply the fixes you agree with.
5. Tests: new test file, exemplar test handwritten, then names-only generation for the case list you designed (boundaries, empty activity, null user). Run them — investigate failures in both directions.
6. Honesty check: sabotage the digest date-range logic; demand red; restore. The suite has earned its green (tutorial 5, unchanged).
7. Documentation: /doc on the public surface with the anti-invention clause; fact-check the specifics; commit code, tests, and docs together.
8. Retrospective (30 seconds): which steering worked, which suggestions misfired, and one library entry if a chat instruction proved reusable (tutorial 7's capture habit).

13 Limitations and Caveats

• Suggestions inherit every Module 1 failure mode: hallucinated APIs (the compiler catches the loud ones; review catches the wrong-overload quiet ones), stale idioms from training-data lag, and confident wrong logic. The review bar does not move because the code appeared in your editor.
• Context limits are real: Copilot sees your open editor surface, not your whole repository or your architecture docs. Suggestions touching systems it can't see (your auth flow, your conventions in unopened files) are pattern guesses.
• Quality varies with codebase circumstance: strong conventions and exemplars → strong suggestions; chaotic legacy → chaotic suggestions. Copilot amplifies what it sees.
• Autocomplete-acceptance drift is the tool-specific risk: hundreds of small Tab decisions a day erode review vigilance. Counter it structurally — small acceptances, tests, analyzers, and PR review unchanged.
• Chat sessions accumulate stale context like any conversation — fresh thread per task, re-select code explicitly.
• Organizational policies (telemetry, public-code filtering, IP settings) vary by plan — know yours before relying on defaults, especially for proprietary code.
• Understanding debt applies doubly: accepting code you couldn't have written is borrowing (tutorial 7) — use /explain on anything you accept but don't fully own.

14 Best Practices and Common Mistakes

The habits of high-quality Copilot use:

• Manage tabs as context: interfaces and exemplars open, noise closed — before you start typing.
• Steer with names and intent comments; state edge cases where you'd state output constraints.
• Accept small and review always; reject-and-resteer beats accept-and-debug.
• Say behavior-preserving on every refactor; keep tests green across each step.
• Give tests the full instruction (cases + conventions) and the honesty review after.
• Use /explain before modifying anything unfamiliar — and on anything you accepted but couldn't have written.
• Fresh chat thread per task; select exactly the code your question concerns.
• Let the deterministic gate (compiler, analyzers, tests, CI) judge everything — unchanged.

The mistakes that turn a multiplier into a liability:

• Tab-ing through block after block unread — speed now, defect tax later.
• Working with vague names and no comments, then blaming the suggestions.
• Asking chat to 'make it better' instead of naming criteria.
• Accepting refactors that 'also fixed' something — unreviewed behavior change.
• Trusting generated tests because they're green, skipping assertions-and-sabotage.
• Treating /doc output as fact without checking stated defaults and exceptions.
• One eternal chat thread carrying stale context across unrelated tasks.
• Letting Copilot code merge on a lighter review than human code — the bar is the point (tutorial 4, always).

20 Summary & Key Takeaways

• Copilot is Module 1 in your editor: your workspace is the prompt — names are context, comments are instructions, tabs are grounding and few-shot examples.
• Two faces, two skills: steer completions with names/intent comments/tab management; steer chat with precise selections and full-anatomy instructions.
• Accept small, review always; reject-and-resteer beats accept-and-debug; /explain anything you accept but couldn't have written.
• Tests via chat instructions or the names-only pattern — with tutorial 5's honesty review unchanged: assertions, sabotage, earned green.
• Refactors say behavior-preserving explicitly, move in small named steps, and prove themselves with tests green before and after.
• Service classes: contracts and exemplar in tabs, intent comment block, skeleton-first, member-by-member fills.
• /doc makes documentation minutes-cheap; the anti-invention clause and fact-checking keep it honest.
• The deal: Copilot compresses typing, never judgment — the review bar, the deterministic gate, and the privacy rules do not move.

You now have the daily Copilot craft. The next tutorial goes further: advanced steering, workspace-scale features, custom instructions, and the workflows that separate power users from everyone else.

21 Next Steps

Continue with the next tutorial in the path: Advanced GitHub Copilot Usage — custom instructions, workspace context features, multi-file workflows, and the advanced patterns that compound the basics you just learned.

• Practice: run the section 12 walkthrough on a small service in your own codebase — staging tabs deliberately at every step.
• Practice: for one day, write an intent comment before every non-trivial method and note the suggestion quality difference.
• Practice: generate one NUnit suite via the names-only pattern, then run the full honesty check on it.
• Practice: /explain three pieces of code you accepted this week; if any explanation surprises you, that was understanding debt.
• Reading: the official GitHub Copilot documentation for your IDE — features and keybindings current as of today, which this tutorial deliberately doesn't freeze.