Repository Instructions Clarify Prompt Files' Roles

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.

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 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.

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.