当 GitHub Copilot 了解其所处理代码库的具体规则时，其表现会更好，而不是仅依赖通用指令。GitHub 说明，其中很大一部分上下文可以存储在代码仓库内，使 Copilot 能够自动识别组件的组织方式、所使用的命令，以及命名和测试标准。
通用指令和路径特定指令
配置工作从创建 .github/copilot-instructions.md 文件开始，用于放置适用于整个代码仓库的规则，例如首选的架构、命名约定，以及测试和验证要求。
GitHub 还支持在 .github/instructions 中创建与特定路径相关联的指令文件。这些文件使用 applyTo 字段来确定指令适用的文件或情形。这样，便可以结合通用指导原则与更加专业化的规则，而不必将同一种风格强加给所有文件类型。
将重复性流程转化为技能
通用指令并不适合所有流程。例如，运行质量检查、准备发布版本或诊断工作流失败等操作都需要可重复的步骤。为此，GitHub 建议使用代理技能，即可以包含指令、脚本和其他资源的文件夹。
可以将项目专用技能放在 .github/skills 中，并为每项技能设置一个文件夹。名为 quality-checks 的文件夹可以包含 SKILL.md 文件，其中规定何时使用该技能、用于测试和验证代码风格的命令、每条命令检查的内容，以及如何处理常见故障情况。
何时需要自定义代理？
有些任务不止涉及一个流程，而是跨越多个文件和工具。GitHub 以可访问性审查为例，这类审查可能需要检查组件、模板、样式和交互。在这些情况下，可以在 .github/agents 中创建自定义代理，并确定其目标、指令、工具以及与项目相关的上下文。
当某类工作反复出现，并且能够从专业角色或特定视角中获益时，这种选项便很合适，尤其是在任务需要处理多个文件和上下文来源的情况下。
通过 MCP 服务器扩展 Copilot 的能力
指令、技能和代理帮助 Copilot 理解如何在项目内部工作，而 Model Context Protocol (MCP) 服务器则将其连接到代码仓库之外的工具、数据源和服务。文档服务器可以提供框架指导，而 Playwright 等服务器则可以通过浏览器打开应用并与之交互。
配置 Playwright 后，可以通过 MCP 服务器请求手动测试功能。这样，验证便不再局限于自动化测试是否成功；Copilot 还能够检查更改后的界面行为，并在浏览器中与其交互。
实际会发生什么变化？
其主要好处是将重复性知识从对话转移到代码仓库内可供审查的文件中。指令规定标准，技能记录流程，代理专注于复杂任务，而 MCP 服务器则增加了使用外部工具的能力。GitHub 建议逐步开始：选择一条需要反复解释的规则，将其放入 .github/copilot-instructions.md，然后观察 Copilot 如何应用这条规则。
文章还提到了 Awesome Copilot 代码仓库，其中包含可供共享的现成指令、技能和代理。不过，在采用这些资源之前，仍有必要根据项目的工具和标准对其进行调整。