GitHub Copilot workflow for TypeScript pair programming

Short answer
Use Copilot as an interactive pair partner during driver/navigator sessions, enforce “test-first + security-first” rules, and gate merges with strict CI (type-check, lint, tests, vulnerability scans). Below are practical rules, CI checks, prompt snippets, and a checklist you can adopt this week.

Recommendation (one-sentence)
Adopt a test-first pairing workflow where the navigator crafts focused Copilot prompts/comments, the driver accepts/edits suggestions, and every Copilot-generated change is accompanied by tests and automated security/static checks before merge.

Decision criteria (choose what matters most for you)
- Highest output quality: require strict TypeScript (noImplicitAny, strict), unit tests, coverage >= 80%, and mutation testing.
- Fast iteration: shorter prompts, inline suggestions, staged PRs, but keep manual review required.
- Low security risk: add Snyk/Dependabot + Semgrep + policy that blocks Copilot suggestions using unsafe APIs.

Team rules (apply during pair sessions)
- Roles: driver types; navigator crafts prompts & reviews Copilot output before accepting. Swap every 20–30 minutes.
- Prompt provenance: add a single-line comment above Copilot-suggested blocks: // Copilot-assisted: prompt-id XYZ
- Never accept code without unit tests or an explicit security justification.
- Ban patterns: no use of eval(), new Function(), hard-coded secrets, or suppressing TypeScript errors with // @ts-ignore without reviewer sign-off.

CI checks to enforce
- Type-check: tsc --noEmit with project tsconfig strict options enabled.
- Lint: ESLint with recommended TypeScript rules + custom rules banning any/ts-ignore and enforcing JSDoc on public APIs.
- Unit tests: jest/ vitest with coverage threshold (e.g., 80% overall; per-package min if monorepo).
- Static security: Semgrep rules for common JS/TS pitfalls (XSS, injection, insecure deserialization).
- Dependency vuln scan: Dependabot + Snyk or npm audit in CI; fail on high/critical.
- Optional: mutation testing (Stryker) on critical modules monthly.
- Branch protection: require passing CI + 1 peer review (2 for public or critical repos).

Prompt snippets (use as comments in VSCode or in Copilot Chat)
- Implement function (driver types signature):
// Task: implement `mergeUserProfiles(a,b)`
// Constraints: preserve immutability; reject if duplicate id; O(n) expected; no any; include JSDoc and tests.
// Tests: write unit tests for mergeUserProfiles covering empty, conflicts, and duplicates.
// Security: ensure no prototype pollution.
- Test-first (navigator asks Copilot to create tests):
/* Create unit tests for function X: input shapes, edge cases, expected throws. Use Jest and mock network calls. */
- Security-aware (force safe APIs):
// Use only safe JSON parsing; do not call eval or Function. If external input used, validate shape with zod/schema.

Best-for / Avoid-if
- Best for: teams wanting faster iteration, consistent scaffolding, and higher DRY on repetitive code.
- Avoid if: you can't enforce CI/PR rules, have heavy regulatory compliance needs, or lack reviewers comfortable auditing AI output.

Practical checklist (before merge)
- [ ] tsc passes
- [ ] ESLint passes
- [ ] Unit tests + coverage pass
- [ ] Semgrep/Snyk/Dependabot scans show no critical issues
- [ ] PR includes short note: “Copilot used: yes” + prompt snippet or file pointer
- [ ] At least one reviewer verified no insecure patterns

Notes on cost/skill/team-size
- Security scans like Snyk may require paid tiers for advanced policies (budget-dependent).
- Junior-heavy teams should require stricter pairing and more review time; experienced teams can loosen cadence.

If you want, I can convert those Semgrep rules and example ESLint rules into a starter repo config and a couple of concrete Copilot comment templates for VSCode.

Compare GitHub Copilot and Cursor