@harness-engineering/cli 1.23.1 → 1.24.0

package/dist/agents/skills/claude-code/angular-schematics/SKILL.md

@@ -0,0 +1,184 @@
+# Angular Schematics
+
+> Use ng generate, configure angular.json defaults, and author custom schematics for consistent code generation across a team
+
+## When to Use
+
+- Scaffolding components, services, pipes, guards, and other Angular artifacts with the CLI
+- Configuring `angular.json` to set project-wide defaults (standalone, OnPush, flat file structure)
+- Applying Angular migration schematics to upgrade between major versions
+- Authoring custom schematics to enforce team conventions in code generation
+- Using third-party schematics from libraries (Angular Material, NgRx, Spectator)
+
+## Instructions
+
+1. Use `ng generate component <name>` (shorthand: `ng g c <name>`) to scaffold components. Add flags for common options: `--standalone`, `--change-detection OnPush`, `--skip-tests`, `--flat`.
+2. Set schematic defaults in `angular.json` under `projects.<name>.schematics` so flags are applied automatically without typing them every time.
+3. Use `ng generate @angular/core:standalone` to migrate an NgModule-based project to standalone components. Run the migration in three phases (convert, remove modules, switch bootstrap).
+4. Use `ng update` to update Angular and its dependencies with automatic migration schematics. Always run `ng update @angular/core @angular/cli` together.
+5. Use `ng generate environments` to scaffold environment files in Angular 15+.
+6. For library schematics, install the library first (`ng add @angular/material`), which runs its own `ng-add` schematic for automatic setup.
+7. Author custom schematics as TypeScript functions using the `@angular-devkit/schematics` package. A schematic receives a `Tree` (virtual file system) and `SchematicContext` and returns a `Rule`.
+
+```bash
+# Common generation commands
+ng generate component features/products/product-list --standalone --change-detection OnPush
+ng generate service core/services/auth
+ng generate guard core/guards/auth --functional
+ng generate pipe shared/pipes/truncate --standalone
+ng generate directive shared/directives/highlight --standalone
+ng generate resolver features/products/product --functional
+ng generate interceptor core/interceptors/auth --functional
+
+# Generate with alias shortcuts
+ng g c features/dashboard --standalone
+ng g s services/cart
+ng g p shared/pipes/format-bytes --standalone --flat
+```
+
+```json
+// angular.json — set schematic defaults for the project
+{
+  "projects": {
+    "my-app": {
+      "schematics": {
+        "@schematics/angular:component": {
+          "standalone": true,
+          "changeDetection": "OnPush",
+          "style": "scss",
+          "flat": false
+        },
+        "@schematics/angular:directive": {
+          "standalone": true
+        },
+        "@schematics/angular:pipe": {
+          "standalone": true
+        },
+        "@schematics/angular:guard": {
+          "functional": true
+        },
+        "@schematics/angular:interceptor": {
+          "functional": true
+        }
+      }
+    }
+  }
+}
+```
+
+```bash
+# Angular version upgrade
+ng update @angular/core@17 @angular/cli@17
+
+# Migrate to standalone
+ng generate @angular/core:standalone
+# Phase 1: Convert components/directives/pipes to standalone
+# Phase 2: Remove unnecessary NgModules
+# Phase 3: Switch to bootstrapApplication
+
+# Apply NgRx schematics
+ng generate @ngrx/schematics:store AppState --root --module app.module.ts
+ng generate @ngrx/schematics:feature products --module features/products/products.module.ts
+```
+
+```typescript
+// Custom schematic — basic structure
+// schematics/my-feature/index.ts
+import {
+  Rule,
+  SchematicContext,
+  Tree,
+  url,
+  apply,
+  template,
+  move,
+  mergeWith,
+} from '@angular-devkit/schematics';
+import { strings } from '@angular-devkit/core';
+
+export function myFeature(options: { name: string; path: string }): Rule {
+  return (tree: Tree, context: SchematicContext) => {
+    const templateSource = apply(
+      url('./files'), // template files directory
+      [
+        template({
+          ...strings, // dasherize, classify, camelize, etc.
+          ...options,
+          name: options.name,
+        }),
+        move(options.path),
+      ]
+    );
+
+    return mergeWith(templateSource)(tree, context);
+  };
+}
+```
+
+## Details
+
+**`angular.json` structure overview:**
+
+```
+angular.json
+└── projects
+    └── <project-name>
+        ├── architect
+        │   ├── build       — build config (outputPath, assets, fileReplacements)
+        │   ├── serve       — dev server config (port, proxy, open)
+        │   ├── test        — test runner config (karma/jest)
+        │   └── lint        — eslint config
+        └── schematics      — default options for ng generate
+```
+
+**`fileReplacements` for environments:**
+
+```json
+"configurations": {
+  "production": {
+    "fileReplacements": [
+      { "replace": "src/environments/environment.ts", "with": "src/environments/environment.prod.ts" }
+    ]
+  }
+}
+```
+
+**Proxy configuration for dev server:** Create `proxy.conf.json` and reference it in `angular.json` under `serve.options.proxyConfig`:
+
+```json
+{ "/api": { "target": "http://localhost:3000", "secure": false, "changeOrigin": true } }
+```
+
+**Custom schematic templates:** Files in the `files/` directory use EJS-style template syntax for file name and content interpolation:
+
+```
+files/
+  __name@dasherize__.component.ts.template
+  __name@dasherize__.component.html.template
+```
+
+`<% classify(name) %>` in the file content becomes `MyFeature`. The `strings` helper from `@angular-devkit/core` provides `camelize`, `classify`, `dasherize`, `underscore`, and `capitalize`.
+
+**`ng add` schematics:** Third-party packages run setup logic on install (`ng add @angular/material`). They can modify `angular.json`, `package.json`, and source files automatically. Review the schematic's changes in git diff before committing.
+
+**Migration schematics:** Angular major version migrations run as schematics that automatically update APIs, rename symbols, and transform code patterns. Running `ng update` without `--force` performs a dry-run first, showing what would change.
+
+## Source
+
+https://angular.dev/tools/cli/schematics
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/claude-code/angular-schematics/skill.yaml

@@ -0,0 +1,44 @@
+name: angular-schematics
+version: '1.0.0'
+description: Use ng generate, custom schematics, and angular.json workspace config for scaffolding and configuration
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - angular.json
+  - '**/*.component.ts'
+  - '**/*.component.html'
+  - '**/*.service.ts'
+  - '**/*.module.ts'
+related_skills:
+  - angular-standalone-components
+  - angular-component-pattern
+  - angular-service-di
+  - angular-testing-patterns
+stack_signals:
+  - angular
+  - typescript
+  - rxjs
+keywords:
+  - schematics
+  - ng-generate
+  - angular-json
+  - workspace
+  - custom-schematic
+  - code-generation
+  - migration
+metadata:
+  author: angular.dev
+  upstream: 'angular.dev/tools/cli/schematics'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/angular-service-di/SKILL.md

@@ -0,0 +1,108 @@
+# Angular Service & Dependency Injection
+
+> Design Angular services with the right provider scope, injection tokens, and hierarchical injector strategy
+
+## When to Use
+
+- Creating a shared service (data fetching, state, utilities) and deciding on its scope
+- Replacing a module-level provider with `providedIn: 'root'` or a standalone provider
+- Using `InjectionToken` to inject non-class values (config objects, feature flags, URLs)
+- Injecting services into other services without circular dependencies
+- Providing mock implementations in tests
+
+## Instructions
+
+1. Decorate every service with `@Injectable`. Use `providedIn: 'root'` as the default — it makes the service a singleton and tree-shakeable without needing to list it in a module.
+2. Use `providedIn: 'root'` for app-wide singletons. Use component-level `providers: [MyService]` only when you need a fresh instance per component subtree.
+3. Create `InjectionToken<T>` for any non-class dependency: API base URLs, feature flags, environment config, or factory functions.
+4. Use the `inject()` function (Angular 14+) instead of constructor injection when writing standalone functions, guards, or effects. It reads more cleanly and is required outside class constructors.
+5. Avoid circular dependencies by extracting shared state into a lower-level service that neither service imports.
+6. Prefer `DestroyRef` injection over implementing `OnDestroy` in services — it keeps cleanup co-located with subscription setup.
+
+```typescript
+// environment config token
+export const API_BASE_URL = new InjectionToken<string>('API_BASE_URL', {
+  providedIn: 'root',
+  factory: () => 'https://api.example.com',
+});
+
+@Injectable({ providedIn: 'root' })
+export class ProductService {
+  private readonly http = inject(HttpClient);
+  private readonly baseUrl = inject(API_BASE_URL);
+  private readonly destroyRef = inject(DestroyRef);
+
+  getProducts(): Observable<Product[]> {
+    return this.http.get<Product[]>(`${this.baseUrl}/products`);
+  }
+}
+
+// Override in tests or feature modules
+providers: [{ provide: API_BASE_URL, useValue: 'https://staging.example.com' }];
+```
+
+```typescript
+// Component-scoped service — new instance per component tree
+@Component({
+  selector: 'app-wizard',
+  providers: [WizardStateService], // fresh instance, destroyed with component
+  template: `...`,
+})
+export class WizardComponent {}
+```
+
+## Details
+
+**Injector hierarchy:** Angular maintains a tree of injectors that mirrors the component tree. When a token is requested, Angular walks up the tree until it finds a provider. Root injector covers the entire app. Module injectors cover lazy-loaded modules. Component injectors cover a component and its descendants. This hierarchy is the mechanism behind scoped singletons.
+
+**`providedIn: 'root'` vs module providers:** Module providers were the Angular 2–12 idiom. They work but require importing the module to get the service. `providedIn: 'root'` eliminates that coupling and enables tree-shaking — unused services are removed from the bundle automatically.
+
+**`inject()` function:** Available in any injection context (constructor, field initializer, factory function, guard, resolver). It cannot be called in a method body called outside the injection context. Use it freely in class field initializers and `@Component` function callbacks.
+
+**Multi-providers:** Use `multi: true` with a token to collect multiple implementations under one token. Angular's `HTTP_INTERCEPTORS` and `APP_INITIALIZER` tokens use this pattern.
+
+```typescript
+export const VALIDATORS = new InjectionToken<Validator[]>('VALIDATORS');
+providers: [
+  { provide: VALIDATORS, useClass: EmailValidator, multi: true },
+  { provide: VALIDATORS, useClass: PhoneValidator, multi: true },
+];
+// inject(VALIDATORS) → [EmailValidator, PhoneValidator]
+```
+
+**Service isolation for testing:** Provide a mock in `TestBed.configureTestingModule`:
+
+```typescript
+TestBed.configureTestingModule({
+  providers: [{ provide: ProductService, useValue: mockProductService }],
+});
+```
+
+**Tree-shakeable tokens:** Pair `InjectionToken` with a `factory` to make the default value tree-shakeable:
+
+```typescript
+export const FEATURE_FLAGS = new InjectionToken<FeatureFlags>('FEATURE_FLAGS', {
+  providedIn: 'root',
+  factory: () => ({ darkMode: false, betaSearch: false }),
+});
+```
+
+## Source
+
+https://angular.dev/guide/di
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/claude-code/angular-service-di/skill.yaml

@@ -0,0 +1,45 @@
+name: angular-service-di
+version: '1.0.0'
+description: Design Angular services with dependency injection, providers, and injection tokens
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - angular.json
+  - '**/*.component.ts'
+  - '**/*.component.html'
+  - '**/*.service.ts'
+  - '**/*.module.ts'
+related_skills:
+  - angular-component-pattern
+  - angular-state-management
+  - angular-http-interceptors
+  - angular-testing-patterns
+  - ts-strict-types
+stack_signals:
+  - angular
+  - typescript
+  - rxjs
+keywords:
+  - dependency-injection
+  - service
+  - injectable
+  - provider
+  - injection-token
+  - hierarchical-injector
+  - providedIn
+metadata:
+  author: angular.dev
+  upstream: 'angular.dev/guide/di'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/angular-signals-pattern/SKILL.md

@@ -0,0 +1,116 @@
+# Angular Signals Pattern
+
+> Manage reactive state with Angular Signals — signal(), computed(), effect(), and toSignal() — for fine-grained, zone-free reactivity
+
+## When to Use
+
+- Building new components in Angular 17+ that need reactive local state
+- Replacing `BehaviorSubject` + `async` pipe patterns with simpler signal-based state
+- Deriving display values from multiple state pieces without manual subscription management
+- Bridging RxJS observables into signal-based components via `toSignal()`
+- Preparing for zoneless change detection (Angular 18+)
+
+## Instructions
+
+1. Create mutable state with `signal<T>(initialValue)`. The returned `WritableSignal<T>` exposes `.set()`, `.update()`, and `.mutate()` (arrays/objects).
+2. Derive values with `computed(() => ...)`. Computed signals are lazy and memoized — they only recompute when their dependencies change. Never compute inside a template expression; use `computed()` instead.
+3. Run side effects with `effect(() => ...)`. Effects re-run automatically when any signal they read changes. Clean up resources by returning a cleanup function or using the `onCleanup` callback.
+4. Convert an RxJS `Observable` to a signal with `toSignal(obs$, { initialValue: ... })`. This subscribes for you and unsubscribes on destroy. Provide `initialValue` to avoid the `undefined` initial state.
+5. Convert a signal to an Observable with `toObservable(sig)` when you need to compose it with RxJS operators.
+6. Prefer signal inputs (`input()`) over `@Input()` for new components — they integrate with the reactivity graph natively.
+7. Do not call `.set()` or `.update()` inside a `computed()` — computed signals must be pure.
+8. Wrap mutable signal state in a service when it needs to be shared across components.
+
+```typescript
+import { Component, signal, computed, effect, inject } from '@angular/core';
+import { toSignal } from '@angular/core/rxjs-interop';
+import { ProductService } from './product.service';
+
+@Component({
+  selector: 'app-cart',
+  template: `
+    <p>Items: {{ itemCount() }}</p>
+    <p>Total: {{ formattedTotal() }}</p>
+    <button (click)="addItem(selectedProduct())">Add</button>
+  `,
+})
+export class CartComponent {
+  private productService = inject(ProductService);
+
+  // Convert observable to signal — auto-unsubscribed on destroy
+  selectedProduct = toSignal(this.productService.selected$, {
+    initialValue: null,
+  });
+
+  items = signal<CartItem[]>([]);
+
+  itemCount = computed(() => this.items().length);
+
+  total = computed(() => this.items().reduce((sum, item) => sum + item.price * item.qty, 0));
+
+  formattedTotal = computed(() =>
+    new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).format(this.total())
+  );
+
+  constructor() {
+    // Side effect: persist cart to localStorage whenever items change
+    effect(() => {
+      localStorage.setItem('cart', JSON.stringify(this.items()));
+    });
+  }
+
+  addItem(product: Product | null): void {
+    if (!product) return;
+    this.items.update((items) => [...items, { ...product, qty: 1 }]);
+  }
+}
+```
+
+## Details
+
+**Signal vs BehaviorSubject:** A `BehaviorSubject` requires `.subscribe()`, `.next()`, and `.unsubscribe()` (or `takeUntil`). A `WritableSignal` has no subscription overhead and integrates with Angular's change detection graph directly. Signals also compose with `computed()` without the `combineLatest` ceremony required by observables.
+
+**Lazy computation:** `computed()` is lazy and cached. If no consumer reads the computed signal, it never runs. If the dependencies haven't changed since last read, the cached value is returned without re-running the function. This makes computed signals safe to use in templates even for expensive derivations.
+
+**Effect cleanup:** Effects that set up subscriptions, timers, or DOM listeners should clean up on re-run:
+
+```typescript
+effect((onCleanup) => {
+  const id = setInterval(() => this.tick.update((t) => t + 1), 1000);
+  onCleanup(() => clearInterval(id));
+});
+```
+
+**`toSignal` guarantees:** `toSignal()` must be called in an injection context (constructor or field initializer). It auto-subscribes and auto-unsubscribes using `DestroyRef`. The `initialValue` option avoids the `T | undefined` type widening; `requireSync: true` can be used when the observable is known to emit synchronously (e.g., `BehaviorSubject`).
+
+**Mutation helpers:** For arrays and objects, use `.update()` to apply a pure transform:
+
+```typescript
+this.items.update((list) => list.filter((i) => i.id !== removedId));
+```
+
+Avoid mutating in place then calling `.set(this.items())` — signal equality checks use reference equality, so this won't trigger updates.
+
+**Zoneless change detection:** Angular 18+ supports `provideExperimentalZonelessChangeDetection()`. With signals, components no longer need Zone.js to trigger change detection — signal writes schedule DOM updates directly. Adopting signals now future-proofs components for zoneless.
+
+**When to keep RxJS:** Signals are not a replacement for RxJS when you need time-based operators (`debounceTime`, `throttleTime`), combination operators (`combineLatest`, `forkJoin`), or error handling (`catchError`, `retry`). Bridge with `toSignal()` / `toObservable()` at the boundary.
+
+## Source
+
+https://angular.dev/guide/signals
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/claude-code/angular-signals-pattern/skill.yaml

@@ -0,0 +1,44 @@
+name: angular-signals-pattern
+version: '1.0.0'
+description: Manage reactive state with Angular Signals — signal(), computed(), effect(), and toSignal()
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - angular.json
+  - '**/*.component.ts'
+  - '**/*.component.html'
+  - '**/*.service.ts'
+  - '**/*.module.ts'
+related_skills:
+  - angular-component-pattern
+  - angular-rxjs-patterns
+  - angular-performance-patterns
+  - angular-state-management
+stack_signals:
+  - angular
+  - typescript
+  - rxjs
+keywords:
+  - signals
+  - computed
+  - effect
+  - toSignal
+  - reactive
+  - signal-input
+  - WritableSignal
+metadata:
+  author: angular.dev
+  upstream: 'angular.dev/guide/signals'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/angular-standalone-components/SKILL.md

@@ -0,0 +1,130 @@
+# Angular Standalone Components
+
+> Build module-free Angular apps with standalone: true, bootstrapApplication, and lazy-loaded standalone routes
+
+## When to Use
+
+- Starting a new Angular 17+ application (standalone is the default and recommended approach)
+- Migrating from NgModule-based apps to reduce boilerplate and improve tree-shaking
+- Adding lazy-loaded feature routes without creating a dedicated NgModule
+- Publishing a reusable component library that consumers can import without module ceremony
+
+## Instructions
+
+1. Set `standalone: true` in the `@Component`, `@Directive`, or `@Pipe` decorator. Standalone components declare their own dependencies in the `imports` array instead of through a module.
+2. List every dependency the template uses in the `imports` array: other standalone components, directives, pipes, and Angular built-ins like `NgIf`, `NgFor`, `AsyncPipe`, `RouterLink`, `ReactiveFormsModule`.
+3. Bootstrap the app with `bootstrapApplication(AppComponent, appConfig)` in `main.ts`. Move all providers (`provideRouter`, `provideHttpClient`, `provideAnimations`) into the `appConfig` object.
+4. Configure routing with `provideRouter(routes)`. Use `loadComponent` for lazy-loaded standalone components and `loadChildren` for lazy feature route arrays.
+5. Import `CommonModule` only as a last resort when migrating. Prefer importing individual directives (`NgIf`, `NgFor`, `AsyncPipe`) for better tree-shaking.
+6. Share providers across a lazy route group by using the `providers` array on a route object — this creates a scoped injector for that route subtree.
+7. Run `ng generate component --standalone` (or set `standalone: true` as the default in `angular.json` schematics) to generate standalone components by default.
+
+```typescript
+// main.ts
+import { bootstrapApplication } from '@angular/platform-browser';
+import { provideRouter } from '@angular/router';
+import { provideHttpClient, withInterceptors } from '@angular/common/http';
+import { provideAnimations } from '@angular/platform-browser/animations';
+import { AppComponent } from './app/app.component';
+import { routes } from './app/app.routes';
+import { authInterceptor } from './app/auth.interceptor';
+
+bootstrapApplication(AppComponent, {
+  providers: [
+    provideRouter(routes),
+    provideHttpClient(withInterceptors([authInterceptor])),
+    provideAnimations(),
+  ],
+});
+```
+
+```typescript
+// app.routes.ts
+import { Routes } from '@angular/router';
+
+export const routes: Routes = [
+  { path: '', redirectTo: '/home', pathMatch: 'full' },
+  {
+    path: 'home',
+    loadComponent: () => import('./home/home.component').then((m) => m.HomeComponent),
+  },
+  {
+    path: 'admin',
+    loadChildren: () => import('./admin/admin.routes').then((m) => m.ADMIN_ROUTES),
+    // providers scoped to this route subtree
+    providers: [AdminStateService],
+  },
+];
+```
+
+```typescript
+// A standalone component
+import { Component } from '@angular/core';
+import { NgFor, AsyncPipe } from '@angular/common';
+import { RouterLink } from '@angular/router';
+import { ProductCardComponent } from '../product-card/product-card.component';
+
+@Component({
+  selector: 'app-product-list',
+  standalone: true,
+  imports: [NgFor, AsyncPipe, RouterLink, ProductCardComponent],
+  template: `
+    <app-product-card
+      *ngFor="let p of products$ | async"
+      [product]="p"
+      [routerLink]="['/product', p.id]"
+    />
+  `,
+})
+export class ProductListComponent { ... }
+```
+
+## Details
+
+**Why standalone over NgModules:** NgModules were a layer of indirection that required declaring, exporting, and importing components in multiple places. Standalone components are self-describing — the `imports` array is the entire dependency manifest. This makes the component portable, tree-shakeable, and easier to test (no `TestBed.configureTestingModule` module imports needed, just the component itself).
+
+**`provideRouter` features:** The functional router API supports feature flags as composable functions:
+
+```typescript
+provideRouter(
+  routes,
+  withDebugTracing(), // logs route events to console
+  withPreloading(PreloadAllModules),
+  withComponentInputBinding(), // binds route params to @Input()
+  withViewTransitions() // enables View Transitions API
+);
+```
+
+**`withComponentInputBinding`:** Enables binding route params, query params, and data directly to component inputs without injecting `ActivatedRoute`. The route param `id` maps to `@Input() id: string`.
+
+**Migrating from NgModules:** Use the Angular CLI migration: `ng generate @angular/core:standalone`. It runs in three passes: convert declarations to standalone, remove unnecessary NgModules, switch the bootstrap call.
+
+**Scoped providers on routes:** When a provider is listed in a route's `providers` array, it creates an Environment Injector scoped to that route. Services provided here are singletons within the lazy subtree but destroyed when the route is unloaded. This replaces the `forRoot()`/`forChild()` pattern from modules.
+
+**Testing standalone components:**
+
+```typescript
+await TestBed.configureTestingModule({
+  imports: [ProductListComponent], // import, not declare
+}).compileComponents();
+```
+
+## Source
+
+https://angular.dev/guide/components/importing
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.