opencode is a coding agent you start by running opencode in your Vue.js project folder. It reads AGENTS.md for project-specific instructions and can create, modify, and test components, stores, and composables using the same Vite, Vitest, and Vue Test Utils commands you already use. A clear AGENTS.md and a review loop make it a practical part of daily Vue.js work.
Why opencode fits Vue.js development
Vue 3’s single-file components (SFCs) give opencode a clean target: each component bundles template, script, and scoped style in one file, so changes are localized and easy to review. Composition API logic with ref, computed, and watch is explicit enough for the agent to reason about and modify without guessing framework conventions. Pinia stores are small modules that map directly to files, which reduces cross-file context loss. Vite’s fast dev server and Vitest’s quick test runs give the agent rapid feedback after each edit. This means you can assign a full feature slice—component plus store plus test—and still keep the diff reviewable.
Preparing your Vue.js project for opencode
opencode looks for an AGENTS.md file in the project root. For Vue.js work, that file should be short and prescriptive: package manager, commands, folder structure, and rules that prevent common Vue mistakes. Here is a realistic example:
# AGENTS.md
Use pnpm. Run all commands from the repo root.
Commands:
- dev: pnpm dev
- build: pnpm build
- test: pnpm test -- --run
- lint: pnpm lint
- typecheck: pnpm typecheck
Folder conventions:
- src/components for reusable components
- src/views for route-level components
- src/composables for shared Composition API logic
- src/stores for Pinia stores
- src/router for vue-router configuration
- Tests live next to the component as ComponentName.spec.ts
Vue.js rules:
- Use <script setup lang="ts"> and Composition API only. No Options API.
- Always type props with defineProps<{...}>() and emits with defineEmits<{...}>().
- Use ref for primitives, reactive only for objects that need deep reactivity; prefer computed over manual watchers.
- Pinia stores use setup-style stores with ref, computed, and functions.
- Do not mutate props directly. Emit events for child-to-parent communication.
- Do not use document or window directly; if needed, write a composable and test it.
- After any change, run pnpm lint, pnpm typecheck, and pnpm test -- --run. Fix all failures before finishing.This file removes ambiguity about how Vue components should be written. For a broader introduction to opencode workflows, see How to use opencode: a step-by-step guide. Keep AGENTS.md updated when your conventions change; the agent treats it as a source of truth.
A working loop with example prompts
Work in small, testable steps. Start with a clear prompt that names the files and expected behavior. After the agent finishes, review the diff, run the test suite yourself if anything looks off, and commit working changes before moving on. Use git diff after each turn; if the change spans more than two or three files, ask for a split. This keeps the agent from compounding mistakes across components.
Typical prompts that work well:
- Add a
useDebouncecomposable insrc/composables/useDebounce.tsand use it inSearchInput.vueto debounce user input by 300 ms. Add a Vitest test with fake timers that verifies the debounced value. - Refactor
UserList.vueto pull user data from the Pinia storeuseUserStoreinstead of local reactive state. Keep the existing props and emitted events unchanged and update the component test. - Create a new
Pagination.vuecomponent undersrc/components/with propscurrentPageandtotalPages, emitpage-changewith the selected page number, and write a spec that mounts the component and checks both the emit and disabled states. - Fix the failing test in
ProductCard.spec.tswithout changing the component’s public API. Explain the root cause, then add a regression test for the reported behavior. - Run
pnpm typecheckand fix all TypeScript errors insrc/components, keeping the code style consistent with the rest of the project.
After each prompt, ask for a summary of what changed and which tests were run. That makes the review faster.
What opencode does well and where to watch it
opencode handles many Vue.js tasks well: creating new SFCs with typed props and emits, moving logic into composables, wiring components to Pinia stores, adding or updating Vitest specs, and fixing TypeScript errors. It is usually good at following existing patterns when AGENTS.md points to them.
But watch closely in these areas:
| Area | Common mistake | How to verify |
|---|---|---|
| Reactivity | Using a plain object instead of ref or reactive, or mutating a ref without .value | Run tests and read the diff for lost reactivity |
| Async updates | Forgetting await nextTick() before asserting DOM changes after a reactive update | Check tests for flakiness or false passes |
| Props vs emits | Mutating a prop directly or wrapping props in local state unnecessarily | Review SFC diffs for direct props.xxx = assignments |
| Pinia | Calling store actions outside a component without setup, or using an options store when the project uses setup stores | Inspect store files and test with createTestingPinia when needed |
| Component boundaries | Creating a huge component instead of extracting a composable or child component | Enforce the folder conventions from AGENTS.md |
When the agent gets one of these wrong, point to the exact line in the diff and ask for a targeted fix. That usually trains the next turn.
Testing Vue.js changes with opencode
Vitest and Vue Test Utils are the fastest way to catch Vue-specific issues. Instruct the agent to run pnpm test -- --run after every change and to add tests for new behavior. Do not accept a task as done if the agent only ran the specific test file; the full suite must pass.
Use mount from Vue Test Utils to render a component in isolation, createTestingPinia from @pinia/testing to provide a fake store, and vi.useFakeTimers() for debounce or async composable tests. Ask the agent to prefer focused assertions like expect(wrapper.emitted('page-change')).toEqual([[2]]) instead of broad snapshot checks. Type checking with pnpm typecheck and linting with pnpm lint should run in the same verification step. If a test feels weak or the agent removed an assertion to make it pass, reject the diff and ask for a regression test that would fail against the original code.
Running opencode with other agents in AgentVera
For larger Vue.js codebases, AgentVera can run opencode alongside other agents in real terminal panels. Each agent can work in its own git worktree, so a Pinia store refactor and a component migration never overwrite each other’s files. Automatic code review catches Vue-specific mistakes such as missing await nextTick() or direct prop mutation, with findings linked to file:line. Checkpoints let you undo a turn that broke reactivity or a test suite and replay the session step by step. These controls matter when several agents touch stores, components, and tests at the same time. See Best tools to run AI coding agents in parallel (2026) for details.
Wrapping up: opencode as a Vue.js pair programmer
Use opencode on Vue.js projects by making conventions explicit in AGENTS.md, working in small test-driven steps, and reviewing every diff against Vue’s reactivity and component rules. With Vitest as the safety net and a disciplined review loop, opencode becomes a reliable pair programmer for Composition API, Pinia, and single-file component work.