Microsoft's .NET Blog clarified in a September 2025 post (surfaced again in recent developer discussion) how GitHub Copilot's two customization layers differ: repository-wide copilot-instructions.md files apply automatically to every request, while *.prompt.md files are reusable, task-specific templates invoked on demand, such as a code-review checklist. Microsoft's VS Code documentation confirms the same split and adds a third layer, agent skills, for bundled multi-step workflows. For developers and ML practitioners wiring Copilot into CI/CD and code-review pipelines, treating persistent conventions and one-off task prompts as separate artifacts reduces duplicated boilerplate and makes prompt-driven automation easier to version and audit.
Distinguishing repository instructions from prompt files is a small but practical governance pattern that helps teams maintain stable, auditable Copilot behavior while keeping task-level workflows modular. Treating project conventions and one-off task prompts as separate artifacts reduces repeated boilerplate, simplifies updates to coding standards, and makes prompt-driven automation easier to test and version.
What happened
According to the Microsoft .NET Blog, instruction files, often named copilot-instructions.md, "define the rules, coding standards, or guidelines Copilot should follow" and are placed in the .github folder. The same post notes teams can also add file- or scenario-specific instruction files (for example title.instructions.md) that apply only to certain requests. Microsoft's Visual Studio Code documentation describes the same distinction: instructions apply automatically to every request, while prompt files are saved, reusable prompts invoked explicitly as a slash command, such as /scaffold-component or /prep-pr. VS Code's documentation adds a third customization layer, agent skills, for bundling multi-step, repeatable workflows with scripts and examples.
Technical context
From an engineering perspective, this separation maps to two different concerns: persistent policy or configuration versus executable prompt templates. Repository instructions act as global context that should remain stable across conversations; prompt files encapsulate the variable, task-level prompt an engineer runs for a specific action. That separation mirrors common software patterns that isolate configuration from behavior.
For practitioners
For developers and ML practitioners embedding Copilot into CI/CD and code-review workflows, keeping repository-level instructions and task-specific prompt files as separate artifacts improves repeatability and reduces drift in automated suggestions. Naming and placement conventions, such as .github/copilot-instructions.md versus .github/prompts/*.prompt.md, determine how predictably these files load and how easy the resulting automation is to version and audit.
What to watch
Watch for how teams adopt these naming and placement conventions, and whether CI or code-review tooling begins to reference prompt files directly rather than pasting instructions inline. Adoption patterns will determine how easy it becomes to version, test, and audit prompt-driven automation across repositories.
Key Points #
- 1Repository instructions load automatically and set persistent, repository-wide Copilot coding standards.
- 2Prompt files are reusable, task-specific templates invoked on demand, such as a code-review checklist.
- 3Separating the two artifact types reduces duplicated boilerplate and improves auditability of Copilot automation.
Scoring Rationale #
A practical, product-level clarification for developers and ML practitioners using Copilot for automated code review and CI/CD workflows. Useful governance guidance but incremental, not a model or platform breakthrough; corroborated by two independent Microsoft sources (.NET Blog and official VS Code docs).
Sources #
Public references used for this report. Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.