Developers are increasingly turning to generative AI for code creation, and its role is rapidly shifting from mere assistance to a core part of the development process—whether for building quick demos or scaffolding full application modules.

Angular v20.2 introduces a new CLI command that generates a dedicated configuration file tailored for AI models. This file captures project-specific rules, which guide the AI to adopt best practices, stick to existing coding conventions, and deliver new features that align with your project’s architecture.

Now, let’s see how to trigger this file’s creation and review the guidelines it brings.

🤖 Generating the AI Configuration Files

As of Angular CLI v20.2, the initial project setup includes a prompt asking whether an AI configuration file should be added:

ng new app
Enter fullscreen mode Exit fullscreen mode

After that, the setup process will ask you to specify at least one AI tool you want to enable.

? Which AI tools do you want to configure with Angular best practices? 
  See: https://angular.dev/ai/develop-with-ai

❯ ◉ None  
  ◯ Claude                 [ https://docs.anthropic.com/en/docs/claude-code/memory ]  
  ◯ Cursor                 [ https://docs.cursor.com/en/context/rules ]  
  ◯ Gemini                 [ https://ai.google.dev/gemini-api/docs ]  
  ◯ GitHub Copilot         [ https://code.visualstudio.com/docs/copilot/copilot-customization#_custom-instructions ]  
  ◯ JetBrains AI Assistant [ https://www.jetbrains.com/help/junie/customize-guidelines.html ]  
  ◯ Windsurf               [ https://docs.windsurf.com/windsurf/cascade/memories#rules ]
Enter fullscreen mode Exit fullscreen mode

For every tool you choose, the Angular CLI creates its own configuration file and stores it at a dedicated location:

  • Gemini → .gemini/GEMINI.md
  • Copilot → .github/copilot-instructions.md
  • Claude → .claude/CLAUDE.md
  • Cursor → .cursor/rules/cursor.mdc
  • JetBrains → .junie/guidelines.md
  • Windsurf → .windsurf/rules/guidelines.md

When you already have a particular AI tool in mind, the interactive prompt can be bypassed entirely—just provide it as a flag:

ng new app --ai-config=gemini
ng new app --ai-config=copilot
ng new app --ai-config=claude
ng new app --ai-config=cursor
ng new app --ai-config=jetbrains
ng new app --ai-config=windsurf
Enter fullscreen mode Exit fullscreen mode

Should you choose to bypass this step, there is still an alternative route: the configuration can be introduced into an already-existing project at any point afterward via any of these commands:

# Start the prompt to choose which AI tool(s) to configure
ng generate ai-config

# Generate the AI configuration for a specific tool (Gemini in this example)
ng generate ai-config --tool=gemini
Enter fullscreen mode Exit fullscreen mode

🔍 Let’s Analyze the Configuration File

Regardless of the AI tool you pick, the structure of the generated files stays consistent.

Note: the Cursor file also includes some metadata, nothing to worry about

AI context for code generation

The file opens with a context block that sets the stage for the AI:

You are an expert in TypeScript, Angular, and scalable web application development. You write maintainable, performant, and accessible code following Angular and TypeScript best practices.

This initial guidance steers the AI toward scaffolding and recommendations that respect the conventions and best practices specific to your Angular setup.

Sections and rules

After the opening, the file splits into sections, each packing additional context and rules tailored to distinct development concerns:

  • TypeScript Best Practices
  • Angular Best Practices
  • Components
  • State Management
  • Templates
  • Services

Below is the complete configuration file, covering every section and rule:

## TypeScript Best Practices

- Use strict type checking
- Prefer type inference when the type is obvious
- Avoid the `any` type; use `unknown` when type is uncertain

## Angular Best Practices

- Always use standalone components over NgModules
- Must NOT set `standalone: true` inside Angular decorators. It's the default.
- Use signals for state management
- Implement lazy loading for feature routes
- Do NOT use the `@HostBinding` and `@HostListener` decorators. Put host bindings inside the `host` object of the `@Component` or `@Directive` decorator instead
- Use `NgOptimizedImage` for all static images.
  - `NgOptimizedImage` does not work for inline base64 images.

## Components

- Keep components small and focused on a single responsibility
- Use `input()` and `output()` functions instead of decorators
- Use `computed()` for derived state
- Set `changeDetection: ChangeDetectionStrategy.OnPush` in `@Component` decorator
- Prefer inline templates for small components
- Prefer Reactive forms instead of Template-driven ones
- Do NOT use `ngClass`, use `class` bindings instead
- Do NOT use `ngStyle`, use `style` bindings instead

## State Management

- Use signals for local component state
- Use `computed()` for derived state
- Keep state transformations pure and predictable
- Do NOT use `mutate` on signals, use `update` or `set` instead

## Templates

- Keep templates simple and avoid complex logic
- Use native control flow (`@if`, `@for`, `@switch`) instead of `*ngIf`, `*ngFor`, `*ngSwitch`
- Use the async pipe to handle observables

## Services

- Design services around a single responsibility
- Use the `providedIn: 'root'` option for singleton services
- Use the `inject()` function instead of constructor injection
Enter fullscreen mode Exit fullscreen mode

Each section here sticks to non-opinionated guidance and is almost entirely about favoring the newer Angular APIs over their predecessors.

Take the new Angular Control Flow directives (@if, @for, @switch) — they should replace *ngIf, *ngFor, and *ngSwitch. Likewise, Signals along with the input()/output() APIs are preferred over their older counterparts.

Add your own rules

Should you wish, the configuration is fully open to extension — add your own naming conventions, ordering preferences, or any coding standards that align with your team’s workflow.

Options include slotting extra rules into the existing sections or building brand-new sections from scratch as needed.

For example, here’s what a dedicated NgRx section might resemble:

## NgRx Best Practices

- Use feature-specific state slices rather than a single global state object.
- Always define action types using a `[Feature] Event` convention (e.g., `[Auth] Login Success`).
- Group effects logically per feature and keep side-effects outside of components.
- Avoid deeply nested state structures; normalize data when possible.
Enter fullscreen mode Exit fullscreen mode

Treat this file as if it were source code, though it reads like prose. Keeping it neat, well-structured, and maintainable is no easy feat and demands the same attention you'd give any other codebase.

🎉 Thanks for Reading! Until Next Time! 🚀

Enjoyed this? I’m eager to hear what you think—send a comment, hit like, or follow along for more. Much appreciated! 👏

Pass it along to teammates, peers, or anyone into Angular.
Let’s connect on LinkedIn! 👋😁