GitHub Explains How Beginners Can Teach Copilot Their Codebase: 4 Mechanisms

GitHub has released a tutorial for beginners on the Copilot app. The topic is narrow but practical: how to tell an AI assistant what your project consists of and which rules the team follows. The guide covers four mechanisms: custom instructions, skills, custom agents and MCP servers, including Playwright.

The announcement is short, so what follows describes the general logic of these tools based on GitHub's current documentation. Specific file names and menu items in the app itself may differ.

The problem the guide addresses

Any AI assistant knows the programming language by default, but it does not know your project. It has no idea that your tests run through pnpm, that styles live in a separate layer, or that direct database calls from controllers are forbidden. As a result, it suggests plausible code that fails review. Fixing this by hand in the chat every time is slow, and the knowledge does not accumulate.

GitHub's approach is to move context out of the developer's head and into the repository. Rules and descriptions sit next to the code, are versioned in git, and work the same way for everyone who opens the project.

Four levers for configuration

The guide builds up the setup from simple to complex.

• Instructions. A text file in the repository, usually in Markdown. It describes the stack, build and test commands, code style and prohibitions. This is the minimal layer, and the one to create first.
• Skills. Packages of knowledge and workflows for a specific task, such as preparing a release or writing a migration. They load when a task requires them and do not bloat the context all the time.
• Custom agents. Separate profiles with their own role, set of tools and rules: a reviewer, a test author, a technical writer. For routine work, you don't have to rewrite the prompt every time.
• MCP servers. The Model Context Protocol connects external tools to Copilot. The example in the guide is Playwright. With it, the agent can open a page in a browser, walk through a user scenario and check the result instead of guessing from the code.

Why this matters right now

AI coding tools are moving from autocomplete to agents that change files and run commands on their own. The more autonomy an agent has, the more a lack of context costs: a mistake in one line turns into a faulty commit touching twenty files. Configuring through the repository is cheaper than cleaning up after the fact.

The approach has a downside, too. Instructions go stale just like documentation. If the team switches linters but the rules file stays the same, the agent will confidently follow the old rules. In addition, an MCP server with access to a browser or external systems widens the attack surface, and its permissions should be restricted as carefully as those for CI.

Where to start in practice

1. Write a short instructions file: the stack, install, build and test commands, and three to five hard rules. The agent uses long texts less effectively than short, precise ones. 2. Test the result on a real, small task, such as fixing a bug. If Copilot keeps making the same mistake, add that rule to the file. 3. Turn recurring processes, such as review or test writing, into separate agents or skills. 4. Connect MCP servers one at a time. Start with Playwright for UI checks and immediately define which domains and actions it can access. 5. Include the instructions file in code review. The rules should change together with the code.

The takeaway for a beginner is simple: in one evening you can get an assistant that knows your commands and conventions. The guide's whole value is that it shows the order of steps, not isolated features.