Cursor Rules for Angular Projects

Cursor rules for an Angular project tell the assistant how your application is organized, which Angular version and patterns are in use, how state and data flow through components, and which commands to run for tests and builds. Angular has changed significantly across major versions — from classic NgModules to standalone components, from RxJS-only to Signals — and many real projects span more than one era. Without rules, the assistant uses whatever Angular pattern it has seen most often, which may not match your project. fenbs helps teams keep the decisions behind those conventions in one shared place, so every assistant session starts from the same approved setup.

The templates below are starting points. Replace module names, service paths, and CLI commands with your actual project values. Test each rule on a representative file before adding it to version control.

Application structure

Angular projects that use NgModules need a rule about which modules exist and which features belong in each. Standalone component projects have a different structure. Either way, naming the top-level folders and their purpose prevents the assistant from adding a feature in the wrong place.

This project uses standalone components (Angular 17+). Do not introduce NgModules.

Structure:
- src/app/features/: feature components and their routes
- src/app/shared/: reusable components, directives, pipes
- src/app/core/: services that are provided at root (HTTP, auth, etc.)

Each feature folder contains its component, its routes, and its own services
if they are feature-specific.
Do not add services to src/app/core/ without confirming they should be singleton.

Change detection and rendering rules

Change detection strategy affects performance and how components respond to updates. A project that has decided to use OnPush throughout needs a rule stating that, so new components are not added with default change detection. Similarly, a project using Angular Signals has different conventions from one using RxJS BehaviorSubject for local state.

Change detection:
- Use ChangeDetectionStrategy.OnPush for all new components
- For local state: use Signals (signal(), computed(), effect())
- Do not introduce new BehaviorSubject or ReplaySubject for component-local state
  (existing uses are fine to leave)
- For async data from services: use toSignal() or the async pipe

Services and dependency injection

Angular's dependency injection system has several ways to provide a service: at root, at component level, or in a specific module or environment. A rule about which pattern to use prevents the assistant from accidentally creating multiple instances of a service that should be a singleton, or making a feature service available application-wide when it should be scoped.

Services:
- Global services: @Injectable({ providedIn: 'root' })
- Feature-scoped services: provide in the route config with providers: []
  Do not use a separate module for feature-scoped services
- HTTP calls go through the HttpClient service, not fetch()
- Do not use the Http class (removed in Angular 5)

Reactive patterns and RxJS

Even in a Signals-first project, RxJS is still used for HTTP responses, router events, and complex async sequences. A rule about which operators are approved and how to handle subscriptions prevents common memory leak patterns and keeps the codebase consistent.

RxJS:
- Always unsubscribe: use takeUntilDestroyed() in components and directives
- Do not use the subscribe() method without an unsubscription strategy
- Prefer declarative pipelines over imperative subscribe with side effects
- Do not use .pipe(tap()) for primary logic; use it for side effects only
- Prefer higher-order mapping operators (switchMap, mergeMap) over nested subscribes

Testing and build commands

Angular projects typically use Karma and Jasmine for unit tests, though newer projects may use Jest. UI testing may use Playwright or Cypress. A rule naming your actual test setup prevents the assistant from writing tests with the wrong framework syntax or using the wrong test runner command.

Tests:
- Unit tests: Jest (not Karma). Run: npx jest or ng test
- Component tests: use TestBed.configureTestingModule with standalone: true imports
- E2E tests: Playwright in e2e/ directory

Build:
- Development: ng serve
- Production build: ng build --configuration=production
- Type check: npx tsc --noEmit

How to do this with fenbs

1. Create a free account and add a project for your Angular application.
2. Add a skill or prompt for each rule area: structure, change detection, services, RxJS patterns, and test setup. Keep each focused and specific to your project version.
3. Record decisions that explain why your conventions are what they are: why the project moved from NgModules to standalone components, why OnPush is required, which Angular version is the current target.
4. When someone proposes adopting Signals for a part of the app that still uses RxJS state, record the open decision in fenbs and wait for sign-off before updating the rule files.
5. Connect your AI tools from Integrations so they read the current rules before starting work on the project.

Rules that often need updating after Angular upgrades

Angular releases major versions frequently, and each one deprecates or removes patterns from earlier versions. After upgrading, review your rules against the Angular migration guide and update anything that references removed APIs, deprecated decorators, or changed module patterns. A rule that says "use NgModule" in a standalone component project actively misleads every assistant that reads it.

The cursor rules deprecated article explains how to identify and migrate outdated rule file formats. The same approach applies to Angular-specific instructions that referenced patterns from older versions.

Angular's release schedule brings breaking changes and deprecations with every major version. Rules written for Angular 14 or 15 may reference APIs that have since changed. The Angular migration guide and the ng update command identify which changes affect your project. Review rule files after each major Angular upgrade and remove or update any instruction that references a deprecated module, decorator, or lifecycle hook.

The Angular CLI generates scaffolding with defaults that may differ from your project's conventions. If the team always adjusts CLI-generated files — removing the default inline template, splitting a component into separate files, or adding a barrel export — put that adjustment as an explicit note in the rule. Otherwise the assistant may treat CLI output as the final form and skip the adjustment.

If the project is part of an Nx or Angular Workspaces monorepo, the structure rule should name the libraries and applications in the workspace and the intended boundaries between them. A rule scoped to the whole workspace will reach every library. Use separate rule files scoped to each library or application so that library-specific conventions do not appear when the assistant is working on a different part of the monorepo.