GitHub Copilot CLI brings GitHub’s coding agent into the terminal: run copilot in a Vue.js project and it can read the codebase, change SFCs, update Pinia stores, and run Vitest. With the right project instructions it handles Vue-specific work reliably. This guide shows the setup, a working loop, common tasks, and testing practices.
A practical setup for a Vue project
GitHub Copilot CLI is a good fit for Vue.js because the work is mostly local and file-based: components, composables, stores, and tests all live in a normal Vite project. The agent can run the same commands a developer runs, so feedback from pnpm test:unit and pnpm build is immediate. It reads single-file components as whole files, which matters because a change to a prop, emit, or computed property usually touches only the <script setup> block. It also understands Composition API patterns, Pinia store modules, and Vitest’s Vue Test Utils conventions. For terminal-native scaffolding, refactoring, and test repair, GitHub Copilot CLI is the reference.
Start by adding project instructions. GitHub Copilot CLI reads .github/copilot-instructions.md, then AGENTS.md if the first is missing. Keep the file short and Vue-specific; do not replace the README. The goal is to prevent the agent from guessing commands, folder layout, or testing setup. A realistic file looks like this:
# Project instructions for copilot
Package manager: pnpm
Commands:
- install: pnpm install
- dev: pnpm dev
- build: pnpm build
- test: pnpm test:unit
- lint: pnpm lint
Conventions:
- Vue 3 + Vite + TypeScript + Pinia + Vitest + Vue Test Utils.
- Single-file components use <script setup lang="ts">, <template>, and scoped styles.
- Components live in src/components, pages/views in src/views, composables in src/composables, Pinia stores in src/stores.
- Use PascalCase for component files and kebab-case in templates.
- Prefer Composition API; avoid Options API in new code.
- Keep components small; extract logic into composables when a component exceeds ~150 lines.
- Each component gets a co-located .spec.ts that mounts with Vue Test Utils, wraps in a Pinia testing instance, and uses flushPromises for async updates.
- When you change a component's props or emits, update its tests in the same turn.
If you are new to the agent itself, the step-by-step guide at How to use GitHub Copilot CLI: a step-by-step guide covers installation and authentication. After adding the instructions, run copilot in the project folder and ask it to summarize the file layout as a first sanity check.
A repeatable plan-and-test workflow
For Vue work, a strict loop prevents the agent from turning a small refactor into a sprawling rewrite. Use this sequence:
- Ask for a plan first. Have the agent list the files it will touch and the commands it will run.
- Let it implement one small change or one component at a time.
- Run the verification commands yourself or ask the agent to run them:
pnpm test:unit,pnpm lint,pnpm build. - Review
git diffbefore accepting; treat the agent’s explanation as a hint, not proof. - If a test fails, give the agent the exact failure output and ask it to fix only that test or the smallest component change.
Example prompts that fit this loop:
- Add a
useCartcomposable in src/composables that uses a Pinia cart store, persists the cart to localStorage, and returns reactive totals. Include a Vitest test for add, remove, and persistence. - Refactor
UserProfile.vueto use typeddefinePropsanddefineEmits, extract the profile form intoProfileForm.vue, and keep all existing tests passing. - Update the project to use the
@alias forsrcin Vite and TypeScript, then rewrite the existing imports in three components and run tests and build. - The
OrderSummary.spec.tstest fails after I changed the Pinia store to async. Read the failure, update the component or test, and run only that test file. - Add form validation to
CheckoutForm.vuewith inline error messages,aria-invalid, and a disabled submit button. Add tests that cover empty fields and successful submit.
Where Copilot CLI excels and where it stumbles
GitHub Copilot CLI handles these Vue.js tasks well when scoped tightly: converting Options API components to Composition API, adding or updating Pinia stores, writing composables with tests, fixing TypeScript errors in templates, wiring Vue Router lazy routes, and updating Vitest tests after prop changes. The table shows a few high-value tasks, a prompt shape, and where to watch.
| Task | Good prompt | Watch closely |
|---|---|---|
| Add a Pinia store | Create src/stores/notifications.ts with state, getters, actions; add a component that uses it. | It may read or write store state directly without actions; enforce encapsulation. |
| Refactor an SFC | Convert ProductCard.vue to <script setup> with typed props/emits, keep template unchanged. | It may change template formatting or remove scoped from styles; diff the template separately. |
| Fix a failing test | Run pnpm test:unit — ProductCard.spec.ts, then fix the test if the component behavior is correct. | It may edit the component to make the test pass instead of correcting a bad assertion. |
| Extract a composable | Move the search/filter logic from CatalogView.vue into useCatalogFilters.ts, with tests. | Reactivity is subtle: avoid destructuring returned refs; ensure .value usage is consistent. |
Pitfalls specific to Vue.js: losing reactivity when destructuring props or Pinia store getters; using ref when reactive object shape changes would be clearer; missing nextTick after DOM updates in tests; forgetting to mount with a fresh Pinia instance in tests; and changing scoped style names or template bindings when only script logic was requested. Keep tasks small and review the diff per component.
Testing Vue components with Vitest
Testing is the most reliable feedback signal. Ask the agent to write or update Vitest tests with Vue Test Utils before changing component behavior. A useful prompt is: ‘Write a failing test for the new email validation in LoginForm.vue, then implement the validation so the test passes.’ Always run pnpm test:unit after each turn. For async components, tell the agent to use flushPromises and await nextTick(); for Pinia, use createTestingPinia or a real store with a fresh state before each test.
CLI-only checks cannot catch visual regressions in scoped styles or complex slot layouts. If you want the agent to verify rendered output, pair the CLI with browser automation; AI agent browser testing: let the agent check your app explains how to let the agent check the app in a browser. At minimum, run pnpm build and pnpm lint after test changes to catch TypeScript template errors and style issues.
Coordinating multiple agents with AgentVera
AgentVera runs GitHub Copilot CLI alongside other coding agents’ real command-line tools in a single desktop window, each in its own terminal panel. For a Vue.js project, the most useful parts are parallel worktrees, so one agent can refactor a Pinia store while another works on a component without overwriting files; automatic code review that links findings to file:line; and checkpoints that let you undo any turn and replay step by step. This is especially valuable when several agents handle independent SFCs or stores concurrently, because review catches reactivity and test regressions before you merge.
Final notes
Treat GitHub Copilot CLI as a fast, test-driven pair programmer for Vue.js, not a replacement for design decisions. Keep instructions concrete, work in small steps, and use Vitest as the contract. When one agent is not enough, parallel worktrees and review in AgentVera help scale the same workflow across components and stores.