DEV Community

Abhishek Pandit
Abhishek Pandit

Posted on

Your Copilot Has No Memory. Here's How I Fixed That in 5 Minutes.

#ai #github #githubcopilot #productivity

Imagine you hire a brilliant contractor.

Sharp, fast, knows every technology. You spend the first morning briefing them: "We do test-driven development here. Security is non-negotiable. PRs stay under 300 lines. We parameterize every database query — no exceptions."

They nod. They get it. The day goes brilliantly.

Next morning they show up with no memory of any of it.

You brief them again. They get it again. Day goes great.

This repeats. Every. Single. Day.

That is GitHub Copilot without configuration.

The Problem Nobody Talks About

Copilot is genuinely impressive. But it's stateless. Every session starts from zero. It doesn't know:

  • Your testing philosophy (TDD? integration-first? mocks or no mocks?)
  • Your security rules (parameterized queries, no secrets in code, validate at the boundary)
  • Your review standards (what makes a PR approvable vs. blocked)
  • Which specialist mindset you need right now (reviewer? tester? security auditor?)

So you either re-prompt it every session — which nobody actually does — or you accept generic output that fits nobody's codebase in particular.

There's a better way.

The Fix: Give Copilot an Employee Handbook

GitHub Copilot has a feature most people don't know exists: if you put a file at .github/copilot-instructions.md in your repo, Copilot reads it automatically — every session, forever.

No prompting. No setup ritual. It just knows your rules.

And there's more. Put specialist personas in .github/agents/ and you can summon them in Copilot Chat with a single @ mention. One message and Copilot becomes a staff engineer doing a 5-axis code review. Another message and it's a QA engineer writing tests using the Prove-It pattern. Another and it's a security auditor running STRIDE analysis against your auth flow.

I built a template that sets all of this up for you. Here's how it works.

What You're Getting 

.github/
  copilot-instructions.md   ← Copilot reads this every session. Your rules, automatically.
  agents/
    code-reviewer.md        ← Staff engineer. 5-axis review before every merge.
    test-engineer.md        ← QA engineer. TDD, coverage gaps, bug reproduction tests.
    security-auditor.md     ← Security engineer. OWASP Top 10. STRIDE. Real vulnerabilities only.
Enter fullscreen mode Exit fullscreen mode

Three specialists on speed dial. Zero configuration after the first setup.

5-Minute Setup

What you need first

  • GitHub account
  • VS Code
  • GitHub Copilot subscription (Individual, Business, or Enterprise)
  • GitHub Copilot extension installed in VS Code
  • GitHub Copilot Chat extension installed in VS Code

That's it. No CLI tools. No config files to write manually.

Step 1 — Create your repo from the template

Go to 👉 github.com/panditAbhis/copilot-workflow

Click the green "Use this template" button → "Create a new repository".

Name your repo, set visibility, click Create repository.

Your new repo now has the .github/ folder with everything pre-configured. Copilot picks it up automatically — no further action needed.

Step 2 — Verify it's working

Open your new repo in VS Code. Open Copilot Chat (Ctrl+Alt+I on Windows/Linux, Cmd+Alt+I on Mac).

Ask:

What are the coding standards for this project?
Enter fullscreen mode Exit fullscreen mode

Copilot should describe your testing pyramid, review standards, and security rules — without you typing a single instruction. If it does, you're done with setup.

Doesn't work? Open VS Code settings and confirm github.copilot.chat.codeGeneration.useInstructionFiles is set to true. It's the default, but worth checking.

Step 3 — Meet your three specialists

Open Copilot Chat and try these:

The Code Reviewer:

@code-reviewer Review the changes in src/auth/login.ts
Enter fullscreen mode Exit fullscreen mode

You get a structured report: Critical issues (blocks merge), Important issues (should fix), Suggestions (optional). Labeled so you know exactly what's required.

The Test Engineer:

@test-engineer I have a bug — users can log in with an expired token. Write a failing test that proves this bug exists before I fix it.
Enter fullscreen mode Exit fullscreen mode

This is the Prove-It Pattern: write a test that fails with the current broken code, then fix the code until the test passes. The test is your proof the bug existed and is now gone.

The Security Auditor:

@security-auditor Audit my file upload handler. I want OWASP Top 10 coverage and a STRIDE threat analysis.
Enter fullscreen mode Exit fullscreen mode

Findings are classified by severity (Critical/High/Medium/Low) with proof-of-concept exploitation and specific remediation code — not vague "consider validating input" advice.

What the Coding Standards Actually Cover

The copilot-instructions.md bakes in three areas of discipline. Here's the short version:

Testing

Copilot knows the test pyramid: 80% unit tests (pure logic, no database, milliseconds each), 15% integration tests (real database, localhost only), 5% E2E tests (critical user paths only).

It knows to test what code does, not how it does it internally. Tests that verify method call sequences break when you refactor — even if behavior is unchanged. State-based assertions survive refactoring.

Code Quality

PRs under ~100 lines are ideal. Over 1000 lines, it'll tell you to split. Refactoring PRs and feature PRs stay separate — always. No dead code, no "I'll clean this up later" shims. Abstractions don't get written until the third time you need them.

Security

Every external input is hostile until validated. Database queries are parameterized — no concatenating user input into SQL, ever. Secrets stay in .env, never in code. LLM output (yes, even Copilot's output) is treated as untrusted input — it never goes directly into eval, SQL, or HTML.

The Analogy That Clicked for Me

Think of this setup like a kitchen.

Vanilla Copilot is like a chef who shows up not knowing your restaurant's cuisine, your signature dishes, your allergen rules, or your prep standards. You explain everything every service.

This template is the kitchen bible — laminated, on the wall, permanent. The chef reads it once at the start of each shift. You never explain the basics again.

The three agents are your sous-chefs: a quality inspector who tastes every dish before it leaves the kitchen, a prep specialist who sets up the station correctly before service, and a health inspector who checks that nothing is going to make someone sick.

You're still the head chef. You make the calls. They make you faster and safer.

What's Next in This Series

This is part 1. Here's what's coming:

Part What you'll learn
1 — this one Setup: instructions file + three agent personas
2 Deep dive: using @code-reviewer before every PR
3 Deep dive: TDD with @test-engineer and the Prove-It pattern
4 Deep dive: threat modeling with @security-auditor
5 Building agentic workflows — the /ship command that fans out all three in parallel

Get the Template

👉 github.com/panditAbhis/copilot-workflow

Click Use this template. Five minutes. Done.

If this helped, follow for the rest of the series — and drop a ⭐ on the repo so others can find it.

Coding standards in this template are derived from Addy Osmani's agent-skills, Google's Software Engineering practices, and OWASP guidelines.

Series navigation

Part Title
1 Your Copilot Has No Memory. Here's How I Fixed That in 5 Minutes.
2 Stop Merging Blind: How I Use @code-reviewer Before Every PR
3 Never Fix a Bug Without Proof: The @test-engineer Prove-It Pattern
4 Think Like an Attacker: How I Use @security-auditor Before Every Production Deploy
5 One Command to Rule Them All: The /ship Chatmode
6 Stop Building the Wrong Thing: @spec-writer and @planner
7 A Day in the Life: Complete Session Walkthrough

Top comments (0)