What this prompt does
This prompt produces a layered GitHub Copilot custom-instructions setup so AI suggestions align with company standards at three distinct levels. It is parameterized on [org_type] and asks for organization-level rules enforcing [compliance_rules], repository-level rules for your [repo_type] repos, and personal-level rules for [developer_role] developers. Because Copilot reads these instructions as context for every suggestion, the rules effectively ride along with each completion instead of being checked only later.
The structure works because governance is naturally layered, not monolithic. Organization-level instructions carry security and data-handling requirements across every repository; repository-level instructions encode project architecture, naming, and file-structure rules specific to each repo type; and personal-level instructions capture an individual developer's style and habits. On top of that, the prompt writes instructions that stop Copilot from suggesting [forbidden_patterns] such as hardcoded secrets or SQL string concatenation, adds framework-specific guidance for [frameworks_used] so generated code is idiomatic, enforces [test_conventions] on generated tests, and includes a quarterly review checklist. The deliverable is the actual Markdown content for each level. Blocking the patterns that violate policy at the instruction level beats catching them later in an audit.
When to use it
- You are rolling Copilot out across a team and want suggestions to respect your standards from the start.
- You need compliance and security rules to ride along with every suggestion, not be caught later in audit.
- You have multiple repo types that each need different architecture and naming guidance.
- You want to discourage specific dangerous patterns at the instruction level.
- Your test suites should follow consistent conventions even when AI-generated.
- You want a repeatable process to review and update the instructions over time.
Example output
Expect ready-to-commit Markdown for each layer. You get an organization-level instruction file with your compliance rules and approved libraries, repo-level files encoding architecture and naming for each [repo_type], personal-level guidance per [developer_role], explicit prohibitions on the [forbidden_patterns] you listed, framework-specific sections for [frameworks_used], test instructions reflecting [test_conventions], and a quarterly review checklist. Each block is meant to be dropped into the appropriate Copilot custom-instructions location, so the setup is genuinely deployable rather than theoretical.
Pro tips
- Make
[compliance_rules]specific and verifiable, such as PCI-DSS for payment code, so Copilot has concrete constraints rather than vague guidance. - List real anti-patterns in
[forbidden_patterns]like hardcoded secrets or SQL string concatenation; discouraging them at the instruction level beats audit-time cleanup. - Keep repo-level rules genuinely repo-specific in
[repo_type]; duplicating org-level rules just adds noise that dilutes the important parts. - Name your actual stack in
[frameworks_used]so the idiomatic guidance matches what you ship rather than a generic default. - Treat instructions as living documents and use the quarterly checklist, because standards and forbidden patterns drift over time.
- Remember instructions guide Copilot rather than enforce it, so pair them with linting and review for the rules that truly must hold.
