Copilot passed every check - still not cleared for takeoff

Three posts into this series, I ran into a question I couldn't actually answer in one breath: is this repo Copilot ready? Not whether the custom instructions file exists. Not whether MCP is configured. Just ready, the way you'd ask about a plane before a long flight. Every time, I caught myself doing the same thing: reopening the 1.1 post to check the precedence table, reopening 1.2 for the MCP governance grid, reopening 1.3 for the Hooks versus Skills distinction, then trying to hold all three open in my head at once.

That's not a process. That's a pilot doing three separate walkarounds on three separate days and hoping nothing changed in between.

So here's what I actually built: one panel. Every gauge from the last three posts, wired into a single instrument cluster, plus the parts of the panel that are still reading amber because nobody's resolved them yet. You can pass every individual check in this series and still not be cleared for takeoff, because cleared for takeoff means someone looked at the whole panel at once, not each gauge in isolation. This post is that look.

(Yes, the pun in Copilot is doing a lot of work in this metaphor. I didn't pick the name; GitHub did. I'm just the one flying the thing.)

The Panel Legend

Before you check any individual gauge, here's the legend: what each one tells you and where it came from. Each row comes straight from the "reach for X when" framing in the source post or posts cited beside it.

Primary Flight Display: Custom Instructions

The primary flight display is the first thing any pilot glances at, and on a Copilot repo that's your custom instructions setup, repo-wide and path-specific both. Here's the full preflight check for it, straight out of 1.1:

• Set up .github/copilot-instructions.md at the repository root. It's the most broadly consumed mechanism in 1.1, and usually the first thing worth configuring in a new repository.
• Writing it by hand? Treat GitHub's own five content categories as a starting checklist, not five mandatory boxes: project summary, build and test commands (flag the mandatory ones), project layout, environment setup, CI/CD.
• For guidance that should only apply to certain files, add .github/instructions/**/*.instructions.md with a required applyTo glob (or comma-separated patterns). Add excludeAgent on top of that if one specific consumer, code review or Copilot cloud agent, should be exempt. It's not a way to hide something from IDE Chat in general, just from one named consumer.
• Repo-wide and path-specific compose additively when both apply to the same file. Neither one overrides the other; Copilot hears both.
• Check 1.1's surface-support matrix before assuming coverage. VS Code code review has no path-specific support at all. Eclipse code review has neither repo-wide nor path-specific.
• If personal or organization instructions, or AGENTS.md, are also in play: GitHub.com ranks them; personal beats repository (where path-specific beats repo-wide beats AGENTS.md) beats organization, though everyone's still heard regardless of rank. Copilot CLI just combines everything with no ranking at all. Different rooms, different rules. Don't carry one's assumptions into the other.
• Inline completions, the ghost-text autocomplete, are confirmed to not read custom instructions on VS Code specifically, per VS Code's own documentation. JetBrains, Xcode, Visual Studio, and Eclipse: vendor documentation wasn't checked in this project's research, so it's unconfirmed, not a no.

Comms Panel: MCP

MCP is the radio panel: how the repo talks to systems outside the cockpit walls. One qualifier worth stating exactly, because it's easy to blur: MCP complements custom instructions; it doesn't replace them. That line is my own synthesis of the functional distinction GitHub's Customization Cheat Sheet draws between the two, not a sentence lifted directly from GitHub's docs. Worth knowing which is which before you quote either one as gospel.

• Three genuinely distinct configuration surfaces exist, not one inheriting fully from another: client-side (your own IDE or CLI, personal or repo-shareable), GitHub.com's repository JSON settings, and the GitHub Copilot desktop app's own settings.
• For repository-level JSON, the tools field is required, not optional.
• If a repo-configured server needs a credential, that's an Agents secret or variable prefixed COPILOT_MCP_, specifically that, not a generic GitHub Actions secret, and only when the server actually needs one.
• Governance is four separate mechanisms, not one setting: the org or enterprise "MCP servers in Copilot" policy (a blanket on or off switch), the MCP registry allow list (discoverability), repository JSON's tools field (per server restriction), and a custom agent's own tools: list (per agent restriction).
• The registry allow list does not reach Copilot cloud agent or Copilot code review.
• The separate "MCP servers in Copilot" policy does apply to code review. The repository's MCP configuration and its code review MCP toggle stay two distinct controls; don't fold them into the allow list exclusion above.
• The agent firewall does not cover MCP traffic at all. Don't lean on it as an MCP control. It was never watching that door.

Autopilot and Crew Panel: Delegation and Automation

Everything under 1.3 lives here: Custom Agents, Subagents, Agent Skills, Hooks, and Prompt Files, the crew that runs the parts of the flight you're not hand flying yourself.

• Start from the legend above, not habit. Pick the mechanism the need actually calls for instead of reaching for whichever one you already know.
• For a custom agent that also defines MCP servers, tools: and mcp-servers are two different knobs. tools: filters everything that agent can touch, built-in tools and MCP-sourced ones alike. mcp-servers is the agent's own extra server definitions. Configuring one is not configuring the other.
• Automatic custom agent selection exists on two surfaces, and they work differently: Copilot CLI infers which agent fits, plus gives you three manual overrides, and Copilot cloud agent runs its own separate automatic path. Set disable-model-invocation: true on any cloud-agent-facing agent that should only ever be picked by hand.
• On the cloud agent, the repository hook file form, .github/hooks/*.json, is the only Hooks configuration present by default in that sandbox. No user-level hook files, settings.json, config.json, or installed plugins ship with it.
• Confirm Hooks are supported in VS Code, currently in preview, per its own vendor documentation.
• Agent Skills are confirmed in Visual Studio 2026 version 18.5 or later. The dedicated skills management panel specifically needs Visual Studio 2026 Insiders version 18.6 or later; the feature itself doesn't wait for Insiders, only that one panel does.
• Skills versus Prompt Files is an axis, not a coin flip. Reach for a Skill when a multistep workflow should load its bundled assets automatically, no one deciding case by case. Reach for a Prompt File for one focused task, run repeatedly with different inputs, always invoked by hand.

(If you've ever set up a Skill and quietly called it basically a Hook, this whole panel would like you to sit back down.)

The Board With Amber Lights

Not every gauge on this panel reads green. Twelve of them, consolidated from Chapters 1.1 through 1.3, still read amber: known, tracked, not resolved. I want to be completely explicit about what appearing on this list means, because a list has a way of feeling settled even when half the point of this one is the opposite. Appearing here means verify this yourself. It does not mean solved.

Six lights carried from 1.1, unresolved:

• Inline completions are confirmed not to read custom instructions on VS Code specifically. For JetBrains, Xcode, Visual Studio, and Eclipse, vendor documentation wasn't checked in this project's research.
• JetBrains Chat and Xcode Chat's path-specific instruction support is disputed between two current official GitHub docs pages.
• JetBrains' personal versus repository instruction precedence has no official source describing how the two interact.
• How Copilot resolves an actual conflict between personal, repository, and organization instructions is undocumented. GitHub's guidance stops at keep them consistent, not here's what wins.
• GitHub.com Chat's path-specific instruction support is undocumented, not confirmed absent.
• Visual Studio cloud agent's repo-wide and path-specific instruction support are both undocumented.

Two lights carried from 1.2, unresolved:

• Whether an organization- or enterprise-wide per-tool policy exists, beyond repository JSON's own tools field and each agent's own tools: list, wasn't found in the official sources reviewed for Chapter 1.2. Not found there isn't the same claim as doesn't exist.
• The official sources reviewed for Chapter 1.2 don't document the GitHub Copilot desktop app's own tools, resources, prompts, and remote OAuth boundaries to the same depth as the IDE versus cloud agent and code review contrast.

Four lights carried from 1.3, unresolved:

• Recursive-subagent behavior is documented for Copilot CLI and opt-in VS Code. JetBrains, Xcode, Eclipse, and Visual Studio weren't checked for recursion in 1.3's research, so their behavior stays unconfirmed either way. That doesn't override what 1.3 says about which surfaces support Subagents at all, and it's not license to assume Subagent support where 1.3 already rules it out.
• Prompt Files' Xcode support is disputed between two current official sources. One marks it preview; the other's supported-IDE list omits Xcode entirely.
• Whether a cloud-agent-installed plugin's Hooks actually execute the way they do under Copilot CLI is genuinely open, not settled in either direction.
• The GitHub Copilot desktop app's exact plugin-mediated Hooks execution details aren't spelled out. GitHub.com and Copilot CLI, by contrast, have direct support.

The Card Clipped to the Yoke

Last thing: a card you actually keep within reach midflight, not buried three posts back. Where every mechanism above is actually configured, one line each. Two things deliberately left off this card: personal and organization instructions, and the cross-tool AGENTS.md variants (CLAUDE.md, GEMINI.md, .claude/CLAUDE.md). Those are precedence and consumption questions, not location lookups, and they're already covered in the Primary Flight Display checklist above. MCP alone gets four rows here, not one, because where is MCP configured genuinely has four different answers depending which surface you mean.

Preflight Complete

• Bookmark the card above, not the whole post. That's the part you'll actually reopen next month.
• Treat the amber lights as a to-do list for your own environment, not a bug report against Copilot. None of those questions is fully settled yet, which is different from something being broken.
• Next time someone asks "is this repo Copilot ready," hand them the panel instead of a guess.

Here's what actually surprised me building this: the amber lights bothered me less than I expected going in. A checklist that quietly rounds every uncertain item up to confirmed is worse than useless; it's actively misleading, because you find out it was never resolved on the one day it actually mattered, instead of on a slow afternoon reading a blog post. I'd rather fly with twelve gauges that honestly read "verify this yourself" than one that confidently lies to me.

Four posts into this series, Copilot's instrument panel is genuinely getting comprehensive. It's just not finished, and pretending otherwise would be the least honest thing I could put in a post that calls itself a readiness checklist. Preflight's done and you're mostly cleared. The rest of the panel is yours.