Gemini CLI for Angular: A Practical Developer Guide

When you run gemini in an Angular project, it can read your existing code, run Angular CLI commands, edit components and services, and verify its work with tests and build. The key is giving it an Angular-specific GEMINI.md and working in small, verified steps. For the command itself, see Gemini CLI; for a broader setup walkthrough, see How to use Gemini CLI: a step-by-step guide.

What Gemini CLI does well in an Angular project

Angular is highly structured: standalone components, services with dependency injection, templates, signals, RxJS, and a CLI that enforces conventions. Gemini CLI operates in the same terminal, so it can run ng generate, ng test, ng build, and ng lint just like a developer. Because Angular code tends to have clear file boundaries and typed inputs/outputs, a coding agent can reason about the component tree and services without guessing. The main value is not generating a whole app from scratch, but handling repetitive, well-specified changes such as converting a component to signals, adding tests around existing behavior, or refactoring a service while keeping the public API stable.

Give the agent Angular-specific instructions in GEMINI.md

Start by creating a GEMINI.md file in the project root. This is the agent’s project context: it tells the CLI which commands to run and which Angular conventions to respect. Keep it short enough that the agent actually follows it, but specific enough to prevent bad changes. A practical GEMINI.md for a standalone Angular project may look like this:

# GEMINI.md

## Commands
- Install dependencies: npm ci
- Run unit tests once: npx ng test --watch=false --browsers=ChromeHeadless
- Run lint: npx ng lint
- Build for production: npx ng build
- Check strict TypeScript: npx tsc --noEmit -p tsconfig.app.json

## Angular conventions
- Use standalone components, directives, and pipes. Do not create NgModules.
- Services are provided in `root` unless the user says otherwise.
- Use `inject()` instead of constructor injection.
- Prefer Angular signals for component-local state and derived state.
- Use RxJS only for async event streams; never expose raw `Subject` publicly without a reason.
- Keep components dumb: business logic belongs in services.
- File names are kebab-case: `product-card.component.ts`, `cart.service.ts`.
- Do not add dependencies without asking first.
- Preserve existing test files and update them when the API changes.
- Run `npm ci` only when package-lock.json has changed; otherwise use existing node_modules.

Keep GEMINI.md under roughly one hundred lines and include only commands you actually run. If your Angular project uses Nx or a monorepo, adjust the commands to target the correct app. The agent will follow these instructions more reliably when they are specific, executable, and match your real workflow. After that, start the agent with gemini in the project folder. When you ask for a change, it will read GEMINI.md and then inspect the relevant Angular files. If the project uses Jest instead of Jasmine, replace the test command with npx jest or the script from package.json.

Plan, make a small change, run the tests, review the diff

The most reliable process is plan, small step, run tests, review diff. Do not ask for a broad refactor in one turn. Instead, break the work into changes that touch one component or service at a time, and ask the agent to run the Angular test command after each step.

Example prompts for typical Angular work:

• “Generate a standalone ProductCardComponent with inputs product and selected, an output addToCart, and internal signal state for quantity. Add a unit test that verifies the output emits the product and quantity.”
• “Refactor AuthService to use inject() instead of constructor parameters and expose the current user as a signal. Update all components that used the old observable to still compile and pass tests.”
• “Convert the users page template from *ngIf and *ngFor to the new @if and @for control flow. Run the unit tests afterward.”
• “Find all RxJS subscriptions in src/app that are not cleaned up. Replace manual subscriptions with async pipe or takeUntilDestroyed() where possible, and run the test suite.”
• “Add a functional route guard admin.guard.ts that checks an AuthService signal and redirects to /login if not authenticated. Include tests using TestBed.”

For a more detailed loop with a coding agent, see AI pair programming: how to work with a coding agent. After each prompt, review git diff before moving on. The agent can run tests, but you should still look at what changed, especially in template files and Angular configuration.

What Gemini CLI handles well and where you must verify closely

A table helps map common work to prompts and risks:

More broadly, Gemini CLI handles repetitive Angular tasks well: generated components, services with providedIn: 'root', signal conversions, route guards, and updating TestBed imports. The places to watch closely are Angular-specific and often subtle:

• Change detection: if code mutates objects inside signals or arrays, Angular may not detect changes. Review any converted state for mutable updates.
• Dependency injection: the agent may add a service to providers in a component when it should be root-provided, or vice versa. Check providedIn and constructor usage.
• Template type checking: Angular strict templates can fail on small type mismatches. The agent may disable strict checks just to make a change pass. Do not allow edits to angularCompilerOptions without explicit request.
• Test setup: Jasmine and Jest differ. The agent may change test runner configuration instead of fixing tests. Keep test config changes in diff review.
• RxJS cleanup: Angular projects often use async pipe or takeUntilDestroyed. A refactor can introduce memory leaks by subscribing in ngOnInit without cleanup.

Test and verify every Angular change before you accept it

Make verification non-negotiable. After every change, ask the agent to run the unit tests for the affected area and then the full build. For a typical Angular CLI project, that means:

• npx ng test --watch=false --browsers=ChromeHeadless
• npx ng build
• npx ng lint

If the project uses Jest, use the package script from package.json. If the project has end-to-end tests, run them only for changes that affect routing or integration flows. Do not accept “tests pass” without seeing the command output. Ask the agent to show the relevant output, then run git diff --stat and git diff yourself. Pay attention to changes in src/app, because Angular templates and TS files are the highest-risk areas. Before committing, run npx tsc --noEmit -p tsconfig.app.json to catch type errors that ng test may not surface.

Run several agents on one Angular project with AgentVera

For larger Angular codebases, you can run multiple Gemini CLI sessions side by side in AgentVera, each in its own real terminal panel and git worktree, so one agent can refactor services while another updates components without overwriting files. When an agent finishes a turn, a second model reviews the diff and links findings to file and line, which is useful for catching broken Angular template bindings or DI mistakes. Checkpoints let you undo an entire turn and replay it step by step, and token budgets stop an agent once it hits a cap while keeping the conversation. See AI agent orchestration for coding: 5 patterns and tools.

Bottom line

Gemini CLI can be a productive pair programmer on an Angular codebase if you treat it like a junior developer with strong tooling: give it a clear GEMINI.md, ask for small changes, require tests and a build after every step, and review the diff for Angular-specific issues. The agent is most useful when the project already has conventions and test coverage; then it can reduce the time spent on repetitive components, services, signal conversions, and template refactors.