What this prompt does
This prompt configures a GitHub Copilot workspace agent so suggestion quality improves across an entire team. You set the [project_type], and the AI creates a .github/copilot-instructions.md file defining your [conventions], describing your [architecture_description] so generated code lands in the right layer, listing [preferred_libs] to always suggest and [blocked_libs] to never suggest, adding language-specific rules for each of your [languages], setting a [test_pattern] with a [mock_approach] for external dependencies, encoding [db_rules], and enforcing your [error_pattern]. It also documents how teammates should update the instructions as conventions change.
The structure works because encoding architecture and conventions once removes a great deal of repetitive correction from code review. When Copilot knows your [architecture_description] — say, clean architecture with domain, application, and infrastructure layers — it generates code in the correct layer instead of wherever happens to be convenient. The [preferred_libs] and [blocked_libs] lists steer it away from packages you have deliberately retired and toward your approved choices, so suggestions stop reintroducing dependencies you removed. The per-language rules keep a mixed-language repo coherent, and the [test_pattern] with a specific [mock_approach] makes generated tests consistent rather than each developer's Copilot inventing its own style. Documenting the update process inside the file is what keeps the whole thing current.
When to use it
- A team uses Copilot and you want consistent, on-convention suggestions across everyone
- You want generated code to land in the correct architectural layer automatically, without manual moving
- You keep correcting library choices and want
[preferred_libs]and[blocked_libs]enforced in suggestions - Your project spans multiple
[languages], each needing its own formatting and naming rules - You want generated tests to follow a
[test_pattern]with a consistent[mock_approach] - You need database and error-handling conventions encoded once so they stop drifting across the team
Example output
You get a .github/copilot-instructions.md file: project [conventions], an architecture section keyed to [architecture_description], preferred and blocked library lists, per-language rules for your [languages], testing instructions using [test_pattern] and [mock_approach], database rules from [db_rules], error-handling rules from [error_pattern], and guidance on how the team updates the file as conventions evolve.
Pro tips
- Describe
[architecture_description]concretely with named layers so Copilot places generated code correctly - Keep
[blocked_libs]explicit (for example, moment.js or axios) so the agent stops suggesting retired packages - Write per-language rules for each of your
[languages]; a mixed-language repo needs separate guidance per language - Make
[mock_approach]specific (interface mocks via dependency injection, no monkey-patching) so generated tests stay consistent - Document the update process inside the file itself so the conventions stay current as the team and stack evolve
- Version-control
copilot-instructions.mdand review changes to it like any other shared team standard
