Team Setup and Repository Conventions

Consistency in AI-assisted development is a configuration problem. When ten developers on a team each run Copilot CLI with different mental models of what it should and should not do, you get ten different behaviors — some of them expensive to clean up. The fix is a shared, version-controlled configuration that makes the right defaults automatic.

This is not about constraining what developers can do with Copilot CLI. It is about making it unnecessary for each developer to rediscover the same conventions by trial and error. The repo configuration does the heavy lifting.

What to set up in the repo

The required file is .github/copilot-instructions.md. Everything else is optional but useful. The instructions file is the only artifact that directly affects Copilot CLI's behavior — the other files are for human understanding. Do not let the presence of optional files cause you to underprioritize the required one.

What the instructions file should cover for a team

When writing the instructions file as a team artifact rather than a personal one, prioritize:

The test command. This is the most important single line in the file. Every developer should get the same test runner invoked after edits. If your project uses pnpm test --watch=false rather than bare npm test, write that exactly.

The coding conventions that generate the most review comments. What does your team argue about in code review? Default exports vs named exports? Async patterns? Error handling conventions? Whatever produces the most review comments is what Copilot CLI needs to know to avoid generating those same comments in AI-assisted work.

The forbidden actions. Specifically: what commands should never run without human confirmation? git push, npm publish, database migrations, infrastructure changes. These belong in the deny list.

File system conventions. Where do new files go? What naming patterns does the project use? Where are tests relative to source files? Copilot CLI infers some of this from exploring the codebase, but explicit instructions reduce guessing.

Here is an example instructions file written for team use rather than personal use:

# Context
Node.js 20 REST API. TypeScript strict mode. Prisma ORM with PostgreSQL.
CI runs on GitHub Actions. Production deployments via Vercel (never trigger manually).

# Conventions
- Test command: `pnpm test --run` (vitest, not Jest)
- Named exports only — no default exports anywhere in src/
- No `any` type; narrow with `unknown` and type guards
- New services go in src/services/, new routes in src/routes/
- Every new function must have a JSDoc comment

# Tools — Team Policy
Allow: file read, glob, grep, shell (test and lint only)
Deny: git push, git push --force, npm publish, pnpm publish, prisma migrate deploy

# Code Review Guidance for Copilot CLI PRs
All PRs from /delegate or /fleet must be reviewed before merge.
Treat them as external contributor PRs — read the full diff.

That file is 20 lines. It covers everything Copilot CLI gets wrong in the first session on a new codebase.

Security posture for teams

When individuals use Copilot CLI, security misconfigurations affect one developer. When Copilot CLI is team-wide, security misconfigurations affect every PR, every session, and every deployment pipeline that a delegated agent might touch.

The two highest-severity rules in the checklist require special emphasis for teams:

No secrets in the instructions file. The instructions file is checked into version control. It gets cloned to every developer's machine, included in forks, and sometimes made public. An API key in .github/copilot-instructions.md is not a secret — it is a public secret waiting to be scraped. Use environment variables for anything sensitive. Reference the env var name in the instructions file if needed: "use the API key from STRIPE_SECRET_KEY env var."

Review every PR from /delegate. Teams with CI automation sometimes add auto-merge rules for green CI. Do not apply auto-merge to PRs from /delegate agents. They need human eyes. The agent ran tests in its own isolated context; the test suite is a necessary but not sufficient condition for merging autonomous AI work.

Maintaining the instructions file over time

An instructions file written once and never updated becomes a liability. As the codebase evolves — new frameworks, new conventions, deprecated patterns — the instructions file needs to stay current.

Add a standing item to your team's sprint review or monthly engineering meeting: "Is the copilot-instructions.md still accurate?" If someone changed the test runner from Jest to vitest and did not update the instructions file, every session on that repo will invoke the wrong test command until someone notices.

Lesson Drill

1. Write or update .github/copilot-instructions.md for a real project your team uses. Include the test command, three explicit coding conventions, and at least two denied tools.
2. Share the instructions file with a teammate. Ask them to identify any conventions the file misses or any rules that seem incorrect.
3. Run a Copilot CLI session on a team member's machine using the shared instructions file. Does Copilot CLI behave consistently with how it behaves in your own sessions?

Bottom Line

Consistent team use of Copilot CLI is a configuration problem, not a training problem. The repo's .github/copilot-instructions.md is the primary control surface — keep it short, specific, reviewed, and current. Build a review norm that treats Copilot CLI PRs like external contributor PRs: read the diff, do not auto-merge. Keep secrets out of instruction files entirely. The security checklist is not optional — it is the baseline every team using Copilot CLI needs to have explicit answers to.

You now have the full Copilot CLI workflow: install and session management, custom instructions, plan mode, session state, tool control, delegation, and team setup. The completion project puts it all together in one real task from end to end.