Reviewing AI-Generated Code: Copilot Code Review and Custom Instructions

1. Copilot Code Review: Capability, Architecture, and Activation

You already know GitHub Copilot as an interaction partner — completions, chat, edit mode, Agent mode. Copilot code review is a different kind of surface: an automated reviewer that reads a pull request the way a human teammate would and leaves comments on it.

What code review does

At its core, Copilot code review does three things on a pull request: it suggests fixes, it generates a PR summary, and it comments directly on the changed code. That description has held up since it was first documented, and it is still the right mental model for what the feature is for, even though how it produces that output has changed.

The architectural update — an evolution, not a contradiction

As of 2026-03-05, Copilot code review runs on an agentic, tool-calling architecture, generally available for Copilot Pro, Pro+, Business, and Enterprise plans. Nothing about the earlier description is wrong — code review still suggests fixes, still summarizes, still comments inline. What changed is the engine underneath: the reviewer now reasons using tool calls. Current documentation separately establishes that code review reads repository customization files and supports MCP server and agent-skills integration (covered in Section 2). Treat the 2026-03-05 change as a documented upgrade to the same feature, not a different product.

Comment: always non-blocking, never approval

This is the single fact to carry through the rest of this chapter: Copilot code review always leaves a review of type Comment. It never blocks a merge, and it never counts as a formal approval. If your repository requires an approving review before merge, Copilot code review's comments do not satisfy that requirement — a human still has to approve. You'll rely on this fact directly in Section 4 and Activity 4, when you decide whether the pull request from Chapter 3 is ready to merge.

Copilot code review also has two effort levels you choose deliberately:

• Lite — the default; fast and targeted.
• Balanced — deeper analysis using higher-reasoning models.

Check your plan's eligibility first

Copilot code review's availability is plan-dependent, not a given on every Copilot plan — and the check that matters is against the Copilot plan your account is actually on, your live plan, not an assumption based on your team or organization. Whichever way that check lands, this chapter doesn't strand you: a documented Path B manual-review fallback exists for every later activity that depends on code review actually running, so the chapter is completable either way. Activity 1 carries the actual eligibility check and the two-path routing that follows from it.

Using code review without an individual license

Organization members can use Copilot code review without holding an individual Copilot license, but only when an enterprise admin or organization owner has enabled that path. This matters for team adoption: a reviewer doesn't necessarily need their own seat, but someone with admin or owner rights has to turn the capability on first. This chapter does not cover the rest of organization or enterprise Copilot administration — treat this as the one licensing fact you need to plan a team rollout.

Activating it on the reference project

Activity 1 walks you through activating code review on the reference project repository — enabling it, locating and choosing an effort level following current GitHub documentation, and confirming the review that comes back is classified as Comment, never Approve or Request changes — and asks you to record which effort level you chose and why, plus who on your team could use the no-license path. If code review is not available to you (recorded on Chapter 4's Path B), Activity 1 instead walks you through recording that.

2. What Code Review Reads: The Current Customization-Mechanism Inventory

Copilot code review doesn't operate on a blank slate. It reads a set of reusable customization files from your repository, and the current architecture (Section 1) can also draw on a couple of additional integrations. This section is an inventory — what currently exists and where it's documented — not a composition tutorial; Section 3 covers how to write good instruction content.

The files code review reads

Per GitHub's own code review documentation, Copilot code review reads three kinds of files for custom guidance: a repository-wide .github/copilot-instructions.md, an AGENTS.md, and path-specific files matching .github/instructions/**/*.instructions.md. A later, 2026-07-29 changelog adds that code review's current architecture also supports MCP server integration and agent-skills configuration, both now generally available.

The fuller current mechanism inventory

A fuller and more precise inventory of currently-durable reusable customization mechanisms adds detail this chapter treats as the primary source:

• Repository-wide instructions — .github/copilot-instructions.md, applied automatically across most IDEs.
• Path-specific instructions — .github/instructions/NAME.instructions.md files, scoped with an applyTo glob in frontmatter (e.g. applyTo: "**/*.ts"), plus an optional excludeAgent frontmatter key. In-editor application of this mechanism — both applyTo targeting and the excludeAgent key — is currently supported only in VS Code and Visual Studio, not JetBrains, Xcode, or Eclipse. That limit is about which IDEs apply the file to your in-editor Copilot interactions, not about whether the file has any effect at all: Copilot code review reads the committed path-specific instructions file on GitHub regardless of which IDE you use.
• AGENTS.md — a project-context file, distinct in purpose from copilot-instructions.md (Activity 2 asks you to work out that distinction for the reference project).
• Reusable prompt templates — .github/prompts/*.prompt.md files, manually invoked rather than automatically applied, and still in public preview.

Custom chat modes: a real mechanism, split documentation

Custom chat modes (.github/chatmodes/*.chatmode.md) are a real, current, first-party mechanism — but you won't find their syntax on docs.github.com; that absence is directly confirmed. Their authoritative documentation is reported to live on the Visual Studio Code docs site instead, since custom chat modes are described as a VS Code Copilot Chat feature rather than a cross-product GitHub Copilot mechanism the way repository instructions are — but docs.github.com does not confirm that specific VS Code location, so treat it as a starting point to search from, not a confirmed destination. If you go looking for chat-mode frontmatter syntax, start on the VS Code docs site rather than docs.github.com, and confirm what you find there before relying on it.

Named but not covered here

Two things belong on this inventory but are out of scope for this chapter:

• MCP server integration — code review's current architecture can use MCP servers as an input, but configuring an MCP server is Chapter 5's job. This section names it as an existing integration only.
• Agent-skills configuration — likewise named as a current input, not configured here.

This section also does not attempt the four context-supply mechanisms as a category (MCP, Copilot Spaces, repository indexing, content exclusion) — that framing belongs to Chapter 6. What you're building here is narrower: the specific customization files Copilot code review itself reads.

Activity 2 has you locate or create the repository-wide and path-specific files on the reference project, and write a short note recording where each mechanism in this inventory is documented.

3. Composing Review-Scoped Custom Instructions

Knowing the files exist (Section 2) doesn't tell you what to write inside them. GitHub has published composition guidance for exactly one of these files — the Copilot code review instructions — and this section teaches it, with its scope limit stated every time.

GitHub's documented composition guidance

GitHub's tutorial "Using custom instructions to unlock the power of Copilot code review" is the most detailed first-party guidance available on writing instruction content. Applied as a checklist:

• Be clear, concise, and specific. Vague guidance produces vague review comments.
• Prefer short, imperative bullet points over narrative prose. "Flag any function over 50 lines without a comment explaining why" works better than a paragraph making the same point.
• Keep the file under roughly 1,000 lines. Shorter files are more likely to be fully processed.
• Start small and iterate. Begin with 10-20 instructions covering your team's most common concerns, test them against real pull requests, and add instructions incrementally based on what the review does or doesn't catch.

Two caveats travel with this guidance every time it's stated: Copilot may not follow every instruction perfectly on every run, and very long instruction files risk having some instructions overlooked.

Where this guidance stops applying

This is a scope limit, not a footnote: the composition guidance above is documented specifically for Copilot code review instructions, per the tutorial's own framing. GitHub has not published an equally detailed composition page for repository, path-specific, or personal instructions generally. Do not present "be concise, use imperative bullets, stay under ~1,000 lines, start with 10-20 and iterate" as documented GitHub policy for those other instruction types. If it's pedagogically useful to suggest this guidance is reasonably transferable to other instruction files, that suggestion must be explicitly labeled as author inference — a reasonable teaching guess, not a documented rule — until the human project owner decides whether to generalize it. This chapter does not make that generalization decision; it only respects the boundary.

A separate, unrelated technique exists elsewhere

GitHub also publishes a general-purpose Copilot Chat prompt-composition technique — a different claim, resting on general prompt-engineering documentation rather than this code-review-scoped tutorial. That technique is owned by Chapter 6 and is not taught here. The two should never be treated as the same guidance: one is scoped to code review instruction files (this section); the other is general chat prompting technique (Chapter 6).

Activity 3 has you draft a review-scoped instructions file using this checklist, run it against a real pull request, and revise it based on what comes back — plus write your own explicit scope note distinguishing this guidance from a general instruction-writing rule.

4. Closing the Loop: Reviewing the Pull Request from Chapter 3

Everything in this chapter so far has been setup: code review is active (Section 1) — or, if code review is not available to you (recorded on Chapter 4's Path B), its Path B manual-review fallback is ready — you know what it reads (Section 2), and you've written and iterated a review-scoped instructions file (Section 3). This section is where you apply all three to a real artifact — the open, unmerged pull request the Chapter 3 workflow produced — and validate it before merge. No new product facts are introduced here; this is synthesis of what Section 1 through Section 3 already established.

What "closing the loop" means

Chapter 3's workflow delegated a bounded task and left you with an open pull request — whichever valid provenance path that chapter's workflow took to produce it. That PR has been sitting unreviewed since. With code review configured (or your manual-review fallback ready), an effort level chosen where applicable, and a tuned instructions file active, you now have the tools to actually validate it rather than merge on trust.

The review still doesn't decide for you

Re-anchor here on Section 1's central fact: whatever Copilot code review says about this pull request, it comes back as a Comment review. It cannot block the merge, and it does not count as approval. The decision to merge stays a human decision, gated by your repository's actual required checks and by human review — the code review comments (or, on the Path B manual-review fallback, your manual review observations) are input to that decision, not a substitute for it. Treat every comment or observation on the Chapter 3 pull request as something to triage — address it, defer it with a reason, or reject it with a reason — rather than as a checklist that must be cleared before you're allowed to merge.

What you're producing

By the end of Activity 4, the Chapter 3 pull request will have every review observation triaged with a recorded decision — whether from Copilot code review or from your own manual review pass on the Path B manual-review fallback — and you'll have written a short merge-readiness note that correctly attributes the actual merge gate to human review and required checks rather than to the non-blocking review itself. Activity 4 also has you decide and record what happens to the pull request next — merged or deliberately left open. That closes the reference project's review step with a known, recorded state, leaving the project ready for Chapter 5 to attach MCP tooling to the same codebase.

Activity 1: Configure Copilot Code Review on the Reference Project

Goal: Enable and configure the review surface the rest of this chapter's activities depend on, directly on the reference project repository — or, if code review is not available to you (recorded on Chapter 4's Path B), record that so Activity 3 and Activity 4's fallback path applies.

Check eligibility and choose your path:

1. Confirm eligibility first: check the Copilot plan your account is actually on — your live plan — against code review's documented GA list (Pro, Pro+, Business, Enterprise), current as of the dated 2026-03-05 architecture announcement. This course's evidence does not establish code review's status on any other plan. If you're on Free, Student, or Max, check your live Copilot settings directly rather than assuming either way.
2. If code review isn't exposed to you, switching to Pro, Pro+, Business, or Enterprise for this chapter's exercises is optional, not required — and it's a real billing change with real cost, not a routine settings toggle, so weigh that before deciding either way. If code review is exposed to you (whether already, or after a switch you chose to make), follow Path A: Code Review Enabled below. If you can't switch, or you can switch but choose not to, follow Path B: Code Review Not Available to You below instead.

Path A: Code Review Enabled

Steps:

1. Enable Copilot code review on the reference project repository, following current GitHub documentation.
2. Locate the effort-level setting and choose between Lite (default, fast/targeted) and Balanced (deeper, higher-reasoning models) before you trigger your first review. Write down which you picked and why.
3. Trigger Copilot code review on the existing open, unmerged pull request produced by the Chapter 3 workflow. Confirm the review Copilot leaves is classified as Comment, never Approve or Request changes — check this directly on the Copilot review itself in the PR's conversation or reviews view; that it never appears among the PR's required/blocking checks is a supporting observation, not the primary check.
4. Work out who on your team could use code review without holding an individual Copilot license, and what an enterprise admin or organization owner has to enable for that to work. Remember: this is an admin/org-owner precondition, not a personal setting anyone can flip for themselves.

Expected outputs:

• A recorded eligibility check confirming code review is available on your plan, including any plan switch you made after checking — a recorded switch here replaces your Chapter 2 Activity 3 live-plan record for the rest of the course.
• The reference project repository with Copilot code review enabled and an effort level selected.
• A short written note recording the review's non-blocking Comment status and the no-individual-license reviewer path.

Hints:

• Search current GitHub documentation to find the effort-level setting rather than assuming where it lives or at what level it applies — choose it before you trigger your first review.
• Confirm the Comment status directly on the Copilot review in the pull request's conversation or reviews view; its absence from the PR's required/blocking checks is a supporting observation, not the primary check.
• The no-license path requires enterprise-admin or organization-owner enablement, not a personal setting.

Checkpoint:

• Your note confirms code review is actually available on your plan and documents any plan switch you made.
• The pull request shows a Copilot review classified as Comment, confirmed by opening the review itself in the PR — its absence from required/blocking checks is a supporting observation, not the primary check.
• Your note states which effort level is active and the reason for that choice — not an unexamined default.
• Your note correctly names the admin/org-owner enablement precondition for license-free usage, not "anyone can use it."

Path B: Code Review Not Available to You

Steps:

1. Record plainly, in writing, why you're proceeding on Path B: name your plan, and state either that a switch to Pro, Pro+, Business, or Enterprise wasn't possible (for example, no admin rights or no purchasing authority) or that it was possible but you chose not to make it — either reason is a legitimate basis for this path.
2. Work out who on your team could use code review without holding an individual Copilot license, and what an enterprise admin or organization owner has to enable for that to work — even though you can't configure code review yourself right now. Remember: this is an admin/org-owner precondition, not a personal setting anyone can flip for themselves.
3. Note that Activity 3 and Activity 4 both provide a Path B manual-review fallback you'll use in place of live code review output.

Expected outputs:

• A plainly recorded reason for proceeding on Path B: your plan, and whether a switch wasn't possible or was possible but declined.
• A short written note recording the no-individual-license reviewer path.

Hints:

• The no-license path requires enterprise-admin or organization-owner enablement, not a personal setting.
• Recording the reason clearly is the required output here — there's no partial configuration to attempt, and choosing not to switch is as valid a reason as not being able to.

Checkpoint:

• Your note plainly records why you're proceeding on Path B and states that you're proceeding on it.
• Your note correctly names the admin/org-owner enablement precondition for license-free usage, not "anyone can use it."

Activity 2: Inventory and Add Reusable Customization Files

Goal: Identify — and where applicable, create — the current reusable customization files Copilot code review reads, and correctly locate their documentation.

Steps:

1. Locate or create .github/copilot-instructions.md in the reference project.
2. Create one path-specific instructions file under .github/instructions/, with a real applyTo glob scoped by filename or sub-path — not by a bare file extension and not by directory. Chapter 1 requires at least two source files spanning two concerns precisely so this file has something to scope to; an extension-only glob (e.g. **/*.py, **/*.go, **/*.ts) matches every file of that language, including both of your source files, and would cover the same ground as your repository-wide file. Pick a pattern — the file's own name, or a sub-path segment unique to it — that matches one of your two source files and excludes the other. Commit this file under .github/instructions/ regardless of which IDE you're using: Copilot code review reads it on GitHub whatever IDE produced it. If you're on VS Code or Visual Studio, also confirm the frontmatter is valid and the file is recognized in-editor. If you're on JetBrains, Xcode, Eclipse, or any other IDE, additionally record, in writing, that your IDE does not apply this file to your in-editor Copilot interactions — that's an in-editor limitation, not a reason to skip committing the file.
3. Decide whether the reference project should also have an AGENTS.md, and write down how its purpose differs from copilot-instructions.md.
4. Without creating one, note that .github/prompts/*.prompt.md reusable prompt templates exist as a public-preview mechanism.
5. Without configuring one, note that custom chat modes (.github/chatmodes/*.chatmode.md) exist, that docs.github.com doesn't cover their syntax, and that their documentation is reported to live on the VS Code docs site — treat that as your starting search point, not a confirmed destination, since docs.github.com does not confirm that location.
6. Without configuring either, note that code review's current architecture also supports MCP server integration and agent-skills configuration as inputs — full MCP configuration is covered in Chapter 5.

Expected outputs:

• .github/copilot-instructions.md, present and committed.
• A path-specific .instructions.md file, committed under .github/instructions/ regardless of IDE, with a working applyTo glob scoped by filename or sub-path that matches one of your two source files and excludes the other. If you're outside VS Code or Visual Studio, also a written record that your IDE does not apply this file in-editor.
• A short inventory note listing every mechanism covered above and correctly locating each one's documentation.

Hints:

• In-editor application of the path-specific instructions mechanism — both applyTo targeting and the optional excludeAgent frontmatter key — is currently supported only in VS Code and Visual Studio, not JetBrains, Xcode, or Eclipse. That's a limit on which IDEs apply the file to your in-editor Copilot interactions, not a reason to skip committing it — Copilot code review reads the committed file on GitHub regardless of your IDE.
• applyTo globs use standard glob syntax; scope by filename or sub-path rather than a bare extension like **/*.ts — an extension-only glob matches every same-language file in your project, including both of your two source files, so pick a pattern that matches one and excludes the other.
• Start on the VS Code docs site, not docs.github.com, for custom chat mode syntax — but confirm what you find there, since docs.github.com does not confirm that specific location.

Checkpoint:

• Both instruction files exist and are committed, and the path-specific file's frontmatter has a valid applyTo glob scoped by filename or sub-path, matching one of your two source files and excluding the other — not a bare extension and not a directory. This applies regardless of IDE. If you're outside VS Code or Visual Studio, you've also recorded in writing that your IDE doesn't apply the file in-editor.
• The inventory note correctly separates the docs.github.com-documented mechanisms from custom chat modes' reported-but-unverified VS Code documentation.
• MCP server integration and agent-skills configuration are named as existing inputs only, with no configuration attempted, and the note defers full MCP treatment to a later chapter.

Activity 3: Compose and Iterate Review-Scoped Custom Instructions

Goal: Apply GitHub's documented, code-review-scoped composition guidance to write and refine custom instructions against real review output — and state the guidance's scope limit explicitly, in writing.

Steps:

1. Write 10-20 short, imperative bullet instructions covering standards that are actually relevant to the reference project by extending .github/copilot-instructions.md, or by adding a path-specific .github/instructions/*.instructions.md file whose applyTo covers the pull request's changed files. Favor "Flag any function over 50 lines without a comment explaining why" over a narrative paragraph making the same point.
2. Keep the file under roughly 1,000 lines.
3. Run Copilot code review against the open, unmerged pull request the Chapter 3 workflow produced, with these instructions active — or, if code review is not available to you (recorded on Chapter 4's Path B), perform a manual review pass instead: read the PR's diff yourself against your instructions file and write down observations in the same shape a Copilot code review comment would take (file, line, which instruction it relates to). Either way, you need a set of review observations to react to next.
4. Read the resulting comments or observations. Revise at least two instructions based on what the review did or didn't catch — if a review misses something you expected, that's a signal to add or sharpen an instruction, not to abandon the file.
5. Write an explicit note stating that this composition guidance — clarity, imperative bullets, the ~1,000-line ceiling, the iterative 10-20-instruction starting set — is scoped to Copilot code review instructions specifically, and is not a general rule for all custom-instruction types.

Expected outputs:

• An extended .github/copilot-instructions.md file, or a path-specific .github/instructions/*.instructions.md file whose applyTo covers the pull request's changed files, with 10-20 imperative bullet instructions.
• A short revision log showing at least one iteration tied to a real review run — or, on the Path B manual-review fallback, tied to your manual review pass.
• An explicit scope note distinguishing this guidance from general instruction-writing policy.

Hints:

• Two caveats to carry forward: Copilot may not follow every instruction perfectly every time, and very long files risk some instructions being overlooked.

Checkpoint:

• The instructions file has 10-20 bullet-style, imperative instructions, stays under roughly 1,000 lines, and reads as imperative directives rather than narrative prose.
• The revision log shows a before/after instruction change tied to an observed review comment or manual-review observation (or its documented absence).
• The scope note restricts the guidance to code-review instructions and does not claim it as documented policy for repository/path/personal instructions generally.

Activity 4: Review and Validate the Chapter 3 Pull Request Before Merge

Goal: Close the Chapter 3 reference-project loop: apply the code review and scoped custom instructions configured across Activity 1 through Activity 3 — or their Path B manual-review fallback — to validate the open, unmerged pull request that workflow produced, before merge.

Steps:

1. Re-run or confirm Copilot code review on the Chapter 3 pull request, with your chosen effort level and your review-scoped custom instructions active — or, if code review is not available to you (recorded on Chapter 4's Path B), repeat the manual review pass from Activity 3 against the PR's current diff, using your iterated instructions file as the standard you're checking against.
2. Triage every review comment or manual-review observation: address it with a code change, explicitly defer it with a reason, or reject it with a reason. Not every comment needs a change — a documented reason to defer or reject is a legitimate outcome.
3. If the pull request touches files outside your path-specific instructions file's applyTo scope, check whether those files were covered by any instructions at all, and note the gap if not.
4. Write a short merge-readiness note that correctly treats the review's Comment status (or, on the fallback path, your own non-blocking manual observations): state plainly that human review and any required checks — not the review comments or observations themselves — are what gate the merge.
5. Decide what happens to the pull request next — merge it now that it's triaged, or deliberately leave it open — and record that decision, with your reasoning, in your reference-project notes. This is what Chapter 5 will inherit, so don't leave it ambiguous.

Expected outputs:

• Triaged Copilot code review comments (or, on the Path B manual-review fallback, triaged manual-review observations) on the Chapter 3 pull request, each with an addressed/deferred/rejected decision and a reason.
• A merge-readiness note distinguishing the non-blocking review from the actual merge decision.
• A recorded decision, with reasoning, on whether the pull request was merged or left open.

Hints:

• Not every comment needs a code change — a documented reason to defer or reject is a valid outcome.
• If the PR touches files outside the path-specific instructions file's applyTo scope, check whether those files were covered by any instructions at all.

Checkpoint:

• Every review comment or manual-review observation on the pull request has a recorded triage decision with a reason.
• The merge-readiness note attributes the actual merge gate to human review and required checks, not to the code review comments or manual observations, and does not treat Comment status as blocking or as formal approval.
• The reference-project notes state plainly whether the pull request was merged or left open, with a reason — not left ambiguous.

Reference Project Continuity — Chapter 4

Starting state: The reference project arrives from Chapter 3 with one loose end — an open, unmerged pull request produced by that chapter's workflow. The repository has no Copilot code review configuration yet, and no reusable custom-instruction files.

What this chapter adds, activity by activity:

• Activity 1 confirms code review's eligibility against the Copilot plan your account is actually on — your live plan — then turns on Copilot code review for the reference project and deliberately selects an effort level (Lite or Balanced). If code review is not available to you (recorded on Chapter 4's Path B), the activity instead records that, which routes Activity 3 and Activity 4 onto their manual-review fallback path. On the enabled path, Activity 1 triggers a review directly on the existing open, unmerged pull request the Chapter 3 workflow produced, not on a new PR the activity creates.
• Activity 2 adds the reference project's first reusable customization files: a repository-wide .github/copilot-instructions.md, plus a path-specific .github/instructions/*.instructions.md file — committed for every learner regardless of IDE, with a real applyTo glob scoped by filename or sub-path matching one of your two CH-001 source files and excluding the other, since Copilot code review reads the committed file on GitHub whatever IDE produced it; learners outside VS Code or Visual Studio additionally record, in writing, that their IDE doesn't apply the file to in-editor Copilot interactions — plus a written inventory of the other mechanisms (AGENTS.md, preview prompt templates, custom chat modes, MCP/agent-skills inputs) and where each is documented.
• Activity 3 produces the project's first tuned, review-scoped custom-instructions file — not written speculatively, but iterated at least once against real Copilot code review output on the Chapter 3 pull request, or, on the Path B manual-review fallback, against a manual review pass performed the same way.
• Activity 4 closes the loop Chapter 3 opened: the pull request that chapter produced is reviewed with this chapter's configured tools (or the manual-review fallback), every observation is triaged with a recorded decision, a merge-readiness note distinguishes the non-blocking Comment review from the actual, human-gated merge decision, and the learner decides and records what actually happens to the pull request next — merged, or deliberately left open, with a stated reason either way.

Ending state: The reference project now carries four things:

• Code review configuration:
  • Enabled path — Copilot code review enabled with a deliberately chosen effort level.
  • Path B — code review not available to you (recorded on Chapter 4's Path B), with a manual-review fallback used consistently in its place.
• Custom-instruction files — a committed repository-wide instructions file, plus a committed path-specific instructions file that Copilot code review reads regardless of IDE, plus documented awareness of AGENTS.md, preview prompt templates, and custom chat modes:
  • VS Code/Visual Studio — the path-specific instructions file also applies in-editor.
  • Any other IDE — the path-specific instructions file is committed and code-review-readable, with the in-editor limitation noted in writing.
• Review-scoped instructions file:
  • Enabled path — refined against real review output.
  • Path B — refined against its manual-review equivalent.
• The Chapter 3 pull request — triaged with merge-readiness documented, and its disposition determined and recorded as either merged or deliberately left open, with reasoning — a determinate outcome, not merely documented as merge-ready or not.

This closes the review step Chapter 3 left open and hands a codebase with working code-review configuration (or its recorded, triaged manual-review equivalent), custom instructions, and a known, recorded pull-request disposition forward to Chapter 5, which attaches MCP tooling to the same project, and to Chapter 6, which builds its context-assembly work on this chapter's customization foundation.

Sources

• The GitHub Copilot Handbook (book)
• https://github.blog/changelog/2026-03-05-copilot-code-review-now-runs-on-an-agentic-architecture/
• https://docs.github.com/copilot/using-github-copilot/code-review/using-copilot-code-review
• https://docs.github.com/en/copilot/how-tos/configure-custom-instructions-in-your-ide/add-repository-instructions-in-your-ide
• https://docs.github.com/en/copilot/tutorials/customize-code-review