You've been using GitHub Copilot for a while. It's great out of the box, but you keep catching yourself repeating the same context. "We use Vitest, not Jest.", "Always use server actions, not API routes.", "Run migrations with this specific command."

GitHub Copilot now has three primitives that let you codify this kind of knowledge: Instructions, Prompts, and Skills. They overlap just enough to be confusing, but once you see how each one works, the choice becomes obvious.

Let's break them down.

Instructions: The Always-On Rules

instructions.md are Markdown files that passively shape Copilot's behavior. Think of them as the coding standards document your team actually reads - because the AI reads it for them.

Where they live:

• .github/copilot-instructions.md - project-wide rules, loaded on every interaction
• .github/instructions/*.instructions.md - file-specific or task-specific rules, loaded on-demand

When to use instructions

Use instructions when the guidance applies broadly and should always be in play without anyone explicitly asking for it.

Example 1: Project-wide standards

.github/copilot-instructions.md:

# Project Guidelines

## Code Style
- Use functional components with hooks, never class components
- Prefer named exports over default exports
- Use `pnpm`, not `npm` or `yarn`

## Architecture
- API routes live in `src/app/api/`
- All database access goes through the repository pattern in `src/lib/db/`
- Never import server-only modules in client components

## Testing
- Run tests with `pnpm test`
- Use Vitest, not Jest
- Co-locate test files next to source: `Button.test.tsx` beside `Button.tsx`

This file is loaded into every Copilot interaction. When you ask it to write a test, it'll reach for Vitest. When it scaffolds a component, it'll use a named export. No reminders needed.

Example 2: File-specific rules loaded automatically

.github/instructions/react-components.instructions.md:

---
description: "Standards for React components"
applyTo: "src/components/**/*.tsx"
---

# React Component Standards

- Use the `cn()` utility from `@/lib/utils` for conditional classes
- Props types go above the component, named `{ComponentName}Props`
- Use `forwardRef` for any component that wraps a native element

The applyTo glob means this loads automatically whenever Copilot is working on files in src/components/. You never invoke it — it just shows up when relevant.

Example 3: On-demand task instructions

.github/instructions/database-migrations.instructions.md:

---
description: "Use when writing database migrations, schema changes, or data transformations"
---

# Migration Guidelines

- Always create reversible migrations with explicit `up` and `down`
- Never drop a column in the same release as the code removal
- Add indexes concurrently: `CREATE INDEX CONCURRENTLY`
- Test rollback locally before pushing

No applyTo here. Instead, the description tells Copilot when this instruction is relevant. When you ask Copilot to help with a migration, it reads the description, recognizes the match, and pulls in the instructions automatically.

Key Takeaway

Instructions are passive.

They shape behavior without you thinking about them. The best instructions are ones your team writes once and then forgets exist — because Copilot just does the right thing.

Prompts: The Reusable Tasks

What they are: Template files for specific, repeatable tasks you trigger on-demand. They're like saved chat messages with superpowers — you can pin them to specific models, restrict their tools, and parameterize inputs.

Where they live:

• .github/prompts/*.prompt.md — workspace-scoped
• ~/.config/github-copilot/prompts/*.prompt.md — personal, follows you across projects

When to use prompts

Use prompts when you have a single, focused task you do repeatedly and want consistent output every time.

Example 1: Generating tests from code

.github/prompts/generate-tests.prompt.md:

---
description: "Generate test cases for the selected code"
agent: "agent"
---

Generate comprehensive test cases for the provided code:

- Include happy path, edge cases, and error scenarios
- Follow existing test patterns in this codebase
- Use descriptive test names that read like specifications
- Mock external dependencies, never hit real APIs

Now type /generate-tests in chat, and you get consistent, well-structured tests every time. No re-explaining your preferences.

Example 2: Writing a changelog entry

.github/prompts/changelog.prompt.md:

---
description: "Draft a changelog entry from recent git commits"
agent: "agent"
tools: [terminal]
---

Review the git log since the last tag and draft a changelog entry.

Format:
## [version] - YYYY-MM-DD
### Added
### Changed
### Fixed

Group by type. Use past tense. Link PR numbers. Keep entries to one line.

Example 3: PR description generator

.github/prompts/pr-description.prompt.md:

---
description: "Generate a PR description from the current branch diff"
agent: "agent"
tools: [terminal]
---

Generate a pull request description based on the current branch's diff against main.

Include:
1. **Summary** — what changed and why (2-3 sentences)
2. **Changes** — bullet list of notable changes
3. **Testing** — how this was tested
4. **Screenshots** — placeholder if UI changed

Use the conventional commits in the log to understand intent.

Key Takeaway

Prompts are active.

You invoke them deliberately when you want to run a specific task. They're your saved workflows — small, focused, and reusable. If you're reaching for the same chat prompt more than twice, it should be a prompt file.

Skills: The Multi-Step Workflows

What they are: Folders containing instructions, scripts, templates, and reference docs that Copilot loads on-demand for complex, multi-step tasks. Skills are the heavy machinery — they bundle everything the agent needs to execute a sophisticated workflow.

Where they live:

• .github/skills/<skill-name>/SKILL.md — workspace-scoped
• ~/.copilot/skills/<skill-name>/SKILL.md — personal

When to use skills

Use skills when you need a multi-step workflow with bundled assets — scripts to run, templates to fill, reference docs to consult. If a prompt is a recipe card, a skill is the entire cookbook chapter with ingredients included.

Example 1: A deployment verification skill

.github/skills/verify-deployment/
├── SKILL.md
├── scripts/
│   └── smoke-test.sh
└── references/
    └── endpoints.md

SKILL.md:

---
name: verify-deployment
description: 'Verify a deployment is healthy. Use when deploying, after deploy, smoke test, health check.'
---

# Deployment Verification

## Procedure
1. Ask which environment (staging/production)
2. Run the [smoke test script](./scripts/smoke-test.sh) against the environment
3. Check each endpoint listed in [endpoints reference](./references/endpoints.md)
4. Report results as a table: endpoint, status, response time
5. Flag any endpoint returning non-200 or responding > 2s

This bundles the smoke test script and endpoint list with the instructions. The agent doesn't need to search for them or ask you where they are.

Example 2: A component scaffolding skill

.github/skills/new-component/
├── SKILL.md
└── assets/
    ├── component.tsx.template
    ├── component.test.tsx.template
    └── component.stories.tsx.template

SKILL.md:

---
name: new-component
description: 'Scaffold a new React component with tests and stories. Use when creating components, new UI element, add component.'
---

# New Component

## Procedure
1. Ask for the component name and directory
2. Create from [component template](./assets/component.tsx.template)
3. Create test from [test template](./assets/component.test.tsx.template)
4. Create story from [stories template](./assets/component.stories.tsx.template)
5. Add barrel export to the directory's `index.ts`

Key Takeaway

Skills are orchestrations.

They package complex workflows with their dependencies. The bar for creating a skill is higher — you need a folder structure, and the task needs to be complex enough to justify it. But for workflows you run regularly, they're transformative.

Decisions, Decisions, Decisions

The examples above should help

You've seen all three, but you're probably still wondering which option best fits your usecase.

Don't overthink it — ask yourself these questions:

Remember:

• Instructions = "Always do this" (passive)
• Prompts = "Do this now" (active, simple)
• Skills = "Do this now, and here's everything you need" (active, complex)

Getting Started

Don't try to build all three at once.

1. Start with copilot-instructions.md — write down the things you keep correcting Copilot on. "Use Vitest.", "We use pnpm.", "Components go here." This takes five minutes and pays off immediately.

2. Notice your repeated prompts — if you've typed "write tests for this using our patterns" more than twice, make it a .prompt.md file.

3. Graduate to skills when you feel the friction — when a prompt isn't enough because you need to reference a script or template, that's your signal to create a skill folder.

The goal isn't to configure Copilot perfectly on day one. It's to gradually encode your team's knowledge so the AI gets smarter about your codebase over time.