opencode and Angular: A Practical Coding Agent Guide

opencode is a terminal coding agent that works well in Angular projects when the project instructions are explicit. This guide shows how to set up AGENTS.md, prompt for Angular tasks, verify changes with Angular CLI, and avoid common template, DI, and RxJS mistakes. For a broader introduction, see How to use opencode: a step-by-step guide.

Why opencode handles Angular well

opencode suits Angular work because it operates from the project root, reads AGENTS.md, and can run Angular CLI commands directly. It handles TypeScript, templates, and Angular idioms well enough to modify components, services, routes, and specs in place. The agent works best when you document the exact commands and conventions; then it consistently generates code that matches the project rather than generic Angular examples. For example, you can ask it to run npx ng test and parse failures, or to update a standalone component import and rebuild. This makes it a practical assistant for everyday Angular tasks like adding typed forms, refactoring to signals, or adding lazy-loaded routes. If you are new to the tool, the opencode page has a quick orientation.

Configure AGENTS.md for your Angular project

opencode looks for AGENTS.md in the project root. Put Angular-specific commands and rules there so every session follows the same conventions. A minimal but effective AGENTS.md for a modern Angular codebase looks like:

# AGENTS.md

## Commands
- Install: npm ci
- Dev server: npx ng serve
- Build: npx ng build
- Test: npx ng test --watch=false --browsers=ChromeHeadless
- Lint: npx ng lint
- Format check: npx prettier --check "src/**/*.{ts,html,scss}"

## Structure
- `src/app/features` holds feature areas, each with standalone components and routes
- `src/app/shared` holds reusable components, directives, and pipes
- `src/app/core` holds singleton services, guards, and interceptors

## Angular rules
- Use standalone components; do not create NgModules unless the change truly needs one
- Prefer `inject()` over constructor injection
- Use signals for component state; use RxJS for asynchronous service streams
- Type reactive forms with `FormGroup<T>` or `FormControl<T>`
- Avoid `any`; use Angular’s typed APIs

Update the commands to match the package manager and test runner your project uses, but keep the file short enough that opencode reads it on every run. If your project uses Jest instead of Jasmine, replace the test command with npx jest. For heavy state management or custom DI, add a note about module boundaries and provider lifetimes.

A working loop: small changes, tests, and diff review

Treat each opencode task as a small change request, not a large rewrite. Start with a clear prompt, let the agent inspect the relevant files, propose or implement a focused change, then run the Angular-specific verification commands and read the diff before moving on.

Example prompts:

• “Add a standalone UserProfileComponent under src/app/features/user/; use signals for the form values and inject UserService with inject().”
• “Refactor DashboardComponent to replace the selected filter BehaviorSubject with a signal, keeping the same async data loading.”
• “Generate a typed reactive form for the checkout flow and update the existing Jasmine spec to cover validation and submission.”
• “Diagnose why npx ng test fails for OrderService specs; fix the TestBed configuration and make all tests pass.”
• “Add a route guard to protect /admin, lazy-load the admin feature, and update the router config to use standalone routes.”

After each change, have opencode run the relevant test or build command and show the output alongside git diff. This keeps failures close to the change and prevents compounding template or injection mistakes.

Angular tasks opencode handles well, and the pitfalls to watch

opencode handles repetitive Angular work well: generating components, services, typed forms, updating templates, adding specs, refactoring to signals, converting constructor injection to inject(). It can also update route configs and adjust Angular CLI workspace files. The agent tends to be more reliable when a task is scoped to one component or service at a time; broad refactors across many files need more review.

Some Angular work benefits from explicit contracts: when migrating to signals, ask opencode to convert one component at a time, update its template bindings, and run the relevant spec before moving to the next. For typed forms, provide the model interface and validation rules, and require the spec to assert the submit handler.

However, watch these Angular-specific pitfalls:

• Missing imports or standalone component registration: it may forget to import a standalone child component or ReactiveFormsModule in the importing component.
• NgModule leftovers: when converting to standalone, it might leave a declaration in an old module or duplicate a provider.
• RxJS memory leaks: it may subscribe in a component without AsyncPipe or takeUntilDestroyed, causing leaks.
• Change detection with OnPush: it might mutate signal-based state or observable data incorrectly, leading to stale views.
• TestBed configuration: generated specs may not call compileComponents() or provide the right mocks for injected services.
• Template type errors: it can produce HTML that type-checks poorly against component properties, especially with strict templates.

Review the diff around template files, injection tokens, and route configurations with extra care; these are where Angular-specific errors usually hide.

Verifying Angular changes with the CLI

Use these commands as the verification gate after each opencode change:

Require the agent to update spec files for any behavior change and run the full suite before you accept the diff. For failures, ask it to read the exact test output, locate the failing line, and propose a minimal fix rather than regenerating entire files. If the agent proposes a fix, require it to run the same failing command again and show green output, not just state that it fixed the issue.

Running parallel agents on an Angular project with AgentVera

When one Angular change is not enough, AgentVera lets you run several opencode instances side by side. The most useful parts for Angular are separate git worktrees per agent, automatic code review with file:line findings, checkpoints that can be undone, and token budgets. Worktrees keep feature, service, and component work from overwriting each other; code review catches template or DI mistakes before they reach your branch; checkpoints make large refactors such as signals or RxJS conversions reversible; token budgets stop a single agent from spending an entire budget on one migration. See best tools to run AI coding agents in parallel for more setup context.

Wrapping up Angular work with opencode

opencode becomes effective on Angular when you treat AGENTS.md as executable project context, prompt for small changes, and verify with Angular CLI before accepting diffs. Use the testing table as a gate, watch the pitfalls in templates and injection, and scale with worktrees when parallel work is needed.