@mrciphersmith/keryx 0.2.164 → 0.3.1

package/src/gdskills/bundled/stacks/angular/governance/scout.json

@@ -0,0 +1,32 @@
+[
+  {
+    "query": "Use when implementing a new Angular component, service, directive, or pipe -- standalone component structure, signal-based (signal()/computed()/effect()) state, inject()-based dependency injection, and typed Reactive Forms. Wires RxJS-to-signal interop (toSignal/takeUntilDestroyed) correctly and follows the project's own routing conventions. Not for Vue/React component implementation, not for writing unit specs for an Angular component (use angular-testing), and not for repairing an already-failing Angular compiler error (use angular-build-fix).",
+    "decision": "fork",
+    "topMatch": "angular/angular-code-review",
+    "recordedAt": "2026-09-25T06:33:13.884Z",
+    "skillName": "angular-implementation",
+    "justification": "Top match angular-code-review is this pack's own sibling sharing Angular/signal/inject() vocabulary, but is read-only review of already-written code, explicitly excluded here (this skill authors new components/services); trigger-accuracy eval confirms both route correctly on their own positive prompts. No existing catalog skill (react-implementation, vue-implementation, nestjs-implementation) covers Angular's own standalone-component/signal/inject() authoring surface."
+  },
+  {
+    "query": "Use when writing or fixing a TestBed spec for an Angular component, service, directive, pipe, or route guard -- configuring TestBed.configureTestingModule, driving a ComponentFixture (componentRef.setInput, detectChanges, whenStable), mocking HttpClient with HttpTestingController, testing a CanActivate/CanMatch guard function, and using fakeAsync/tick for deterministic async specs. Not for Vue/React component tests, not for a full user-flow check against a deployed, running instance, and not for implementing the component/service under test (use angular-implementation).",
+    "decision": "create",
+    "topMatch": "angular/angular-implementation",
+    "recordedAt": "2026-09-25T06:33:14.047Z",
+    "skillName": "angular-testing"
+  },
+  {
+    "query": "Use when reviewing an Angular component/service/directive diff for framework-specific correctness -- untracked RxJS subscriptions missing takeUntilDestroyed/async-pipe cleanup, OnPush components mutating input objects in place instead of replacing the reference, a dependency-injection call made outside a valid injector context, DomSanitizer bypassSecurityTrust* calls on user-influenced data, and NgModule/standalone mixing. Does not review generic JavaScript/TypeScript correctness the base stack reviewer already covers, does not review MobX store logic, and never edits code -- it reports findings only. Not for implementing or fixing the reviewed code (use angular-implementation or angular-build-fix).",
+    "decision": "create",
+    "topMatch": "angular/angular-implementation",
+    "recordedAt": "2026-09-25T06:33:14.214Z",
+    "skillName": "angular-code-review"
+  },
+  {
+    "query": "Use when resolving an `ng build` failure, an AOT/Ivy template type-checking error (a property that doesn't exist on the bound type, an @if/@for control-flow type mismatch), a missing NgModule declaration/import error, or a DI 'No provider for X' resolution error blocking an Angular build. Applies the smallest root-cause fix and never silences the compiler with strictTemplates: false, an `any` cast in a template context, or `@Injectable` removal. Not for a plain TypeScript compile failure outside any Angular template, and not for authoring a fresh component or injectable from scratch (use angular-implementation).",
+    "decision": "fork",
+    "topMatch": "nextjs-nuxt/nextjs-nuxt-build-fix",
+    "recordedAt": "2026-09-25T06:33:14.375Z",
+    "skillName": "angular-build-fix",
+    "justification": "Top match nextjs-nuxt-build-fix shares generic 'build fails' vocabulary but targets Next.js/Nuxt compile failures (Server/Client boundary, composable resolution), not Angular's AOT/Ivy template type-checking or NgModule/DI resolution errors this skill covers; the description explicitly excludes a plain TypeScript compile failure with no Angular template involved. No existing catalog skill covers ng build/AOT-specific fixes. Confirmed distinct by clean trigger-accuracy eval."
+  }
+]

package/src/gdskills/bundled/stacks/angular/pack.json

@@ -0,0 +1,55 @@
+{
+  "id": "angular",
+  "family": "framework",
+  "extends": "ts-js-node",
+  "modules": [
+    "angular-rules",
+    "angular-skills"
+  ],
+  "detectionMarkers": [
+    "angular"
+  ],
+  "provenance": {
+    "origin": "authored",
+    "sourceRef": "flow 318, Wave 4 batch 2"
+  },
+  "stability": "experimental",
+  "skills": {
+    "implement": [
+      "angular-implementation"
+    ],
+    "test": [
+      "angular-testing"
+    ],
+    "review": [
+      "angular-code-review"
+    ],
+    "build-fix": [
+      "angular-build-fix"
+    ],
+    "migrate": []
+  },
+  "agentProfile": {
+    "displayName": "Angular",
+    "auditFocus": [
+      "an RxJS subscription created in a component/directive with no takeUntilDestroyed, async pipe, or explicit ngOnDestroy teardown",
+      "a component still using ChangeDetectionStrategy.Default with heavy template bindings where OnPush plus signals would isolate re-renders",
+      "a service or dependency reached through constructor-parameter injection mixed inconsistently with inject() in the same file, or inject() called outside an injection context",
+      "a template still using *ngIf/*ngFor/*ngSwitch in a component whose codebase has otherwise migrated to @if/@for/@switch control flow",
+      "a NgModule-based component/directive/pipe added to a codebase where the rest of the app is standalone",
+      "state mutated directly on a class field instead of through a signal's set/update, or a computed signal with a side effect inside its computation"
+    ],
+    "buildCommands": [
+      "ng build (or the project's package.json build script wrapping the Angular CLI)",
+      "ng test (or the project's configured Karma/Jest runner) for unit tests",
+      "npx tsc --noEmit for standalone type-checking outside the Angular compiler",
+      "ng lint (or the project's configured eslint-angular script)"
+    ],
+    "fixGuardrails": [
+      "never add `standalone: false` or reintroduce an NgModule just to route around a compiler/DI error in an otherwise-standalone codebase",
+      "never disable Angular's strict template type checking (`strictTemplates`, `fullTemplateTypeCheck`) in tsconfig to silence a template type error",
+      "never swallow an RxJS subscription error with an empty `error: () => {}` handler to stop a console error from failing a build check",
+      "never delete or skip a failing TestBed spec to reach a green test run"
+    ]
+  }
+}

package/src/gdskills/bundled/stacks/angular/rules/coding-style.mdc

@@ -0,0 +1,82 @@
+---
+extends: common
+paths: ["**/*.ts", "**/*.html"]
+metadata:
+  origin: authored
+---
+
+# Angular coding style
+
+Narrows the stack-agnostic style rules to current Angular idiom (standalone
+components, signals, `inject()`). Applies to `*.ts` and component
+`*.html` templates; everything not Angular-specific still comes from the
+common rules this file `extends`.
+
+## Components and files
+
+- Components, directives, and pipes are standalone by default in current
+  Angular — do not set `standalone: false` or write a new `NgModule` to
+  register one unless the project itself is still NgModule-based
+  end-to-end.
+- One component (and its template/styles) per file, named after the
+  component class (`OrderSummary` in `order-summary.ts`, not a generic
+  `component.ts`). Match whatever file-suffix convention (`.component.ts`
+  vs. plain `.ts`) the project's own `angular.json`/existing files already
+  use rather than introducing a second one.
+- Keep a component's template under roughly 60-80 lines before extracting a
+  child component; a template doing significant `@if`/`@for` branching for
+  more than one concern is a sign the branches belong in separate
+  components.
+
+## Dependency injection
+
+- Prefer the `inject()` function over constructor-parameter injection for
+  new code (`private readonly router = inject(Router);`), since it composes
+  cleanly with field initializers and works outside constructors (guards,
+  resolvers, `provide*` factories). Do not mix `inject()` and
+  constructor-parameter injection for different dependencies in the same
+  class — pick one per class, and prefer `inject()` for new classes.
+- `inject()` only works inside an injection context (a constructor, a field
+  initializer, or a call wrapped in `runInInjectionContext`) — do not call
+  it inside a `setTimeout`, a plain async callback, or after the
+  constructor has returned.
+
+## Signals and state
+
+- Use `signal()` for local component/service state that changes over time,
+  `computed()` for values derived from other signals, and `input()`/
+  `model()` for component inputs — do not read/write a signal's backing
+  value directly; always go through `.set()`/`.update()`.
+- Keep a `computed()`'s computation pure (no side effects, no writes to
+  other signals inside it) — if a change needs to trigger a side effect,
+  use `effect()`, not a computed callback abused for its side effect.
+- Do not mirror a signal's value into a plain class field "for convenience"
+  in the template — read the signal directly (`value()`) so Angular's
+  fine-grained reactivity tracks the actual dependency.
+
+## Templates and control flow
+
+- Use the built-in control flow (`@if`, `@for` with a `track` expression,
+  `@switch`) in new templates, not `*ngIf`/`*ngFor`/`*ngSwitch` — unless the
+  surrounding component's own template still uses the structural-directive
+  form throughout, in which case match the existing file rather than
+  mixing both styles in one template.
+- Always give `@for` an explicit `track` expression (the item's own stable
+  id, not `$index`, unless the list has no natural identity) — an untracked
+  or index-tracked loop over data that reorders forces Angular to
+  re-render every row instead of just the ones that changed.
+
+## Naming and typing
+
+- `PascalCase` for component/directive/pipe/service classes, `camelCase`
+  for signals, fields, and methods — a signal's own name should read as the
+  value it holds (`user`, not `userSignal`), since calling it (`user()`)
+  already signals reactivity.
+- Type every `input()`/`output()`/`model()` explicitly
+  (`input<Order | null>(null)`) rather than relying on inference from a
+  loosely-typed default; an untyped input silently becomes `unknown`/`any`
+  at every call site.
+- Avoid `any` in component/service code; when the Angular CLI's generated
+  boilerplate produces a loosely-typed value (e.g. a form's raw value),
+  narrow it explicitly at the boundary instead of propagating `any`
+  through the class.

package/src/gdskills/bundled/stacks/angular/rules/patterns.mdc

@@ -0,0 +1,84 @@
+---
+extends: common
+paths: ["**/*.ts", "**/*.html"]
+metadata:
+  origin: authored
+---
+
+# Angular patterns
+
+Idiomatic component/service/change-detection design for current Angular,
+and the anti-patterns to avoid when narrowing the common architecture rules
+to this stack.
+
+## Change detection
+
+- Default new components to `ChangeDetectionStrategy.OnPush`. With
+  signal-based state this is nearly free: reading a signal in a template
+  registers it as a dependency and Angular schedules the check for you, so
+  `OnPush` plus signals rarely needs a manual `markForCheck()` at all.
+- If a component still receives data via `@Input()` mutation of a plain
+  object (not a signal) under `OnPush`, replace the mutation with a new
+  object reference (or migrate the input to a signal) — `OnPush` only
+  re-checks on a new reference/signal change, not a mutated property on the
+  same object.
+- Reach for `ChangeDetectorRef.markForCheck()` only when a value changes
+  outside Angular's own change-detection triggers (a third-party callback,
+  a native DOM event Angular didn't bind) and cannot reasonably be modeled
+  as a signal — not as a routine fix for "the view didn't update".
+
+## Dependency injection and service boundaries
+
+- Scope a service with `providedIn: 'root'` for app-wide singletons; scope
+  it in a route's providers (or a standalone component's `providers`) for
+  state that should reset per-feature/per-route instead of leaking across
+  the whole app's lifetime.
+- Keep a component's class focused on view state and event wiring; move
+  business logic, HTTP calls, and cross-component state into an injectable
+  service. A component `inject()`-ing `HttpClient` directly to build
+  request logic inline is a sign that logic belongs in a service instead.
+- Use Angular's `HttpClient` (with `provideHttpClient()` and interceptors
+  for cross-cutting concerns like auth headers) rather than a bare `fetch`
+  scattered through components — interceptors are the idiomatic place for
+  auth/error handling, not per-call boilerplate.
+
+## RxJS and signal interop
+
+- Prefer `toSignal()`/`toObservable()` (`@angular/core/rxjs-interop`) at
+  the boundary between RxJS streams (HTTP, router events, form
+  `valueChanges`) and signal-based component state, rather than manually
+  subscribing into a plain field.
+- When an `Observable` genuinely needs a manual `.subscribe()` inside a
+  component (rare once `async` pipe / `toSignal()` cover the common case),
+  pipe through `takeUntilDestroyed()` (call it in an injection context, or
+  pass an explicit `DestroyRef`) instead of hand-rolling a `Subject`+
+  `ngOnDestroy` teardown.
+- Do not fan a single source Observable out into multiple independent
+  `.subscribe()` calls that each re-trigger the source's side effects
+  (e.g. a re-fetching HTTP call); share it (`shareReplay`, or convert once
+  with `toSignal()`) so the side effect runs once per meaningful change.
+
+## Forms
+
+- Prefer Angular's typed Reactive Forms (`FormGroup<{...}>`,
+  `FormControl<T>`) over template-driven forms for anything beyond a
+  trivial single-field form — typed forms catch a renamed/removed control
+  at compile time instead of a silent runtime `undefined`.
+- Validate with Angular's built-in or custom `ValidatorFn`s registered on
+  the control, not ad-hoc validation logic scattered through submit-button
+  click handlers.
+
+## Anti-patterns
+
+- Do not reach into a child component's internals via `ViewChild` to call
+  a method or set a field when an `@Input()`/`input()`/signal binding, or
+  an `@Output()`/`output()` event, would express the same interaction
+  declaratively.
+- Do not perform DOM manipulation directly through `ElementRef.nativeElement`
+  in ordinary component code — use Angular's `Renderer2`, template
+  bindings, or a directive when direct DOM access is genuinely required
+  (a third-party widget, focus management); bypassing Angular's rendering
+  layer breaks server-side rendering and change-detection assumptions.
+- Do not put HTTP calls or other side effects inside a `computed()` — a
+  computed's callback can re-run any number of times and must stay pure;
+  side effects belong in `effect()` or an explicit event handler.

package/src/gdskills/bundled/stacks/angular/rules/security.mdc

@@ -0,0 +1,70 @@
+---
+extends: common
+paths: ["**/*.ts", "**/*.html"]
+metadata:
+  origin: authored
+---
+
+# Angular security
+
+Stack-specific risks on top of the common security rules, focused on where
+Angular's own sanitization can be bypassed and where DI/routing choices
+create an opening.
+
+## Template injection and sanitization bypass
+
+- Angular auto-sanitizes values bound into `innerHTML`, `href`,
+  style/URL/resource-URL contexts, and script/style properties — do not
+  reach for `DomSanitizer.bypassSecurityTrustHtml`/`bypassSecurityTrustUrl`/
+  `bypassSecurityTrustResourceUrl`/`bypassSecurityTrustScript` on
+  user-supplied or user-influenced content. Those calls tell Angular "trust
+  this value completely, skip sanitization" — reserve them for genuinely
+  static, developer-authored content (a hardcoded SVG, a known-safe
+  asset URL), never for a value that traces back to user input or an
+  external API response.
+- Prefer binding through the normal property/interpolation syntax
+  (`{{ value }}`, `[textContent]`) over `[innerHTML]` for user-controlled
+  text; if `[innerHTML]` is genuinely required for rich content, sanitize
+  server-side or via a vetted sanitizer library rather than trusting
+  Angular's default sanitizer alone for anything beyond simple formatting.
+- Never write directly to `ElementRef.nativeElement.innerHTML` — that
+  bypasses Angular's sanitizer entirely, unlike the `[innerHTML]` template
+  binding which still runs through it.
+
+## HTTP and CSRF
+
+- Send credentials/tokens via `HttpClient` interceptors (`HttpInterceptorFn`
+  or a class-based `HttpInterceptor`), not by hand-appending an
+  `Authorization` header at each call site — a missed call site is a
+  silent auth gap, not a build error.
+- When the backend uses cookie-based sessions, rely on Angular's built-in
+  `XSRF-TOKEN`/`X-XSRF-TOKEN` CSRF handling (`withXsrfConfiguration` /
+  the default cookie name) rather than disabling `withCredentials` or
+  rolling a custom CSRF header scheme, unless the backend's own CSRF
+  contract genuinely requires different header/cookie names — configure
+  those, don't drop the protection.
+
+## Routing and route guards
+
+- Gate any route that requires authentication/authorization with a route
+  guard (`CanActivateFn`/`CanMatchFn`) that actually checks server-verified
+  state (a token's validity, a role from the authenticated session) — never
+  a guard that only checks a client-side flag with no corresponding
+  server-side check on the API the route's data comes from.
+- Do not put secrets, API keys, or backend-only credentials into
+  environment files (`environment.ts`) that ship in the client bundle —
+  anything in `environment.*.ts` is public once built; only put
+  publicly-safe configuration (API base URLs, feature flags) there.
+
+## Dependency injection surface
+
+- Do not widen a service's provider scope to `providedIn: 'root'` just to
+  work around an injection error, when the service holds per-user or
+  per-session state — a root-scoped singleton is shared across the whole
+  app's lifetime (and across users in SSR), so session-scoped data leaking
+  into it is a cross-request data leak, not just a design smell.
+- Validate and narrow data crossing a trust boundary (route params, query
+  params, a form's raw value, a third-party postMessage payload) before
+  using it in a template binding or passing it to a service call — treat
+  router/query-string values as untrusted input, not as pre-validated
+  application state.

package/src/gdskills/bundled/stacks/angular/rules/testing.mdc

@@ -0,0 +1,73 @@
+---
+extends: common
+paths: ["**/*.ts", "**/*.html"]
+metadata:
+  origin: authored
+---
+
+# Angular testing
+
+Test layout, runner, and fixture conventions for Angular components,
+services, and directives — narrows the common testing rules to
+`TestBed`-based Angular idiom.
+
+## Layout and runner
+
+- Co-locate a unit test with its source (`order-summary.ts` /
+  `order-summary.spec.ts`), matching whatever the project's own existing
+  spec files already do; do not invent a parallel `__tests__/` tree in an
+  Angular CLI project that uses co-located `.spec.ts` files.
+- Run the project's configured runner (`ng test`, or a Jest/Vitest setup if
+  the project has migrated off Karma) rather than assuming Karma is
+  present — check `angular.json`'s `test` builder or the project's
+  `package.json` `test` script before invoking a specific runner by name.
+
+## Component tests
+
+- Configure the module under test with `TestBed.configureTestingModule`
+  (importing the standalone component directly in `imports`, since
+  standalone components are imported, not declared), then
+  `TestBed.createComponent` to get a `ComponentFixture`.
+- Set signal-based inputs through `fixture.componentRef.setInput('name',
+  value)`, not by assigning the component instance's field directly —
+  direct field assignment on a signal input does not go through Angular's
+  input-binding machinery and can silently not reflect in the template the
+  way a real caller's binding would.
+- After a change that affects the DOM (setting an input, clicking a
+  button, resolving a promise/observable the component depends on), call
+  `fixture.detectChanges()` (or `await fixture.whenStable()` for
+  async work) before asserting on the rendered DOM — an assertion made
+  before change detection runs reads stale markup.
+- Query the DOM through `fixture.debugElement.query(By.css(...))` /
+  `By.directive(...)`, or `fixture.nativeElement.querySelector(...)` for
+  plain DOM assertions — prefer a stable selector (a `data-testid`, a
+  semantic role/label) over a CSS class that styling changes could break.
+
+## Services, HTTP, and doubles
+
+- Test an injectable service through `TestBed.inject(MyService)` (or
+  direct instantiation for a service with no dependencies), not by
+  reaching into a component's private field to get at the service
+  instance.
+- Mock `HttpClient`-backed calls with `provideHttpClientTesting()` /
+  `HttpTestingController` (`expectOne`, `.flush(...)`) rather than a
+  hand-rolled fetch stub — it verifies the exact request was made and lets
+  the test control the exact response, and `httpTestingController.verify()`
+  at the end of each test catches an unexpected extra request.
+- Stub a genuinely external dependency (a third-party SDK, `window`/
+  browser APIs the test environment can't provide) at that boundary via
+  Angular's provider overrides (`TestBed.overrideProvider`) — do not mock
+  the component's own signals/services, which is what the test is supposed
+  to exercise.
+
+## Determinism
+
+- Prefer `fakeAsync`/`tick()` (or `waitForAsync`) over a real `setTimeout`
+  in a spec so a test doesn't depend on wall-clock timing; flush pending
+  timers/microtasks explicitly rather than adding an arbitrary `tick(1000)`
+  guess.
+- Reset any shared test state (a spy's call count, a `TestBed` module
+  configured with `teardown: { destroyAfterEach: true }`, which is
+  Angular's own default) between tests so one spec's setup cannot leak
+  into the next — do not disable that default teardown to "fix" a
+  cross-test leak instead of finding the actual shared state.

package/src/gdskills/bundled/stacks/angular/skills/angular-build-fix/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: angular-build-fix
+description: "Use when resolving an `ng build` failure, an AOT/Ivy template type-checking error (a property that doesn't exist on the bound type, an @if/@for control-flow type mismatch), a missing NgModule declaration/import error, or a NullInjectorError/'No provider for X' DI resolution error surfacing when the built app bootstraps. Applies the smallest root-cause fix and never silences the compiler with strictTemplates: false, an `any` cast in a template context, or `@Injectable` removal. Not for a plain TypeScript compile failure outside any Angular template, and not for authoring a fresh component or injectable from scratch (use angular-implementation)."
+triggers:
+  - "fix this ng build AOT template type error"
+  - "resolve this Angular No provider for X DI error"
+  - "fix this Angular NG8103/missing NgModule declaration error"
+  - "ng build reports a template type-checking failure"
+  - "fix this standalone Angular component import error"
+  - "Angular build fails after adding an @if block referencing a signal"
+metadata:
+  origin: authored
+  category: build-fix
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Angular build-fix (ng build / AOT / DI resolution)
+
+Resolve an `ng build` failure: an AOT/Ivy template type-checking error, a
+missing NgModule declaration/import, or a dependency-injection "No
+provider for X" resolution error. Applies the smallest change that fixes
+the actual root cause — never a change that only makes the compiler stop
+complaining. See `rules/coding-style.mdc` and `rules/patterns.mdc` for the
+typing/DI conventions a correct fix should restore.
+
+## Workflow
+
+### Step 1: Reproduce the failure
+
+```bash
+ng build
+```
+
+Run the project's own `package.json` build script if it wraps `ng build`
+with extra flags (configuration, budgets). Capture the exact error
+message, the file:line, and — for a template error — the template
+expression Angular is complaining about, not just the `.ts` file it's
+attributed to.
+
+### Step 2: Classify the failure
+
+- **Template type-checking error** (AOT/Ivy `strictTemplates`): a bound
+  property/method that doesn't exist on the component's type, an
+  `@if`/`@for` expression whose narrowed type doesn't match what the
+  template body assumes, or a mismatched event handler signature.
+- **Missing declaration/import error** (e.g. `NG8001`/`NG8103`-style
+  "is not a known element" or "can't bind to X since it isn't a known
+  property"): a component/directive/pipe used in a template but not
+  imported into the standalone component's `imports` array (or not
+  declared/exported by the right `NgModule` in an NgModule-based project).
+- **DI resolution error** ("No provider for X", `NullInjectorError`): a
+  service injected (via `inject()` or constructor) with no reachable
+  provider — missing `providedIn: 'root'`, missing from a component's/
+  route's `providers` array, or injected outside any injector context.
+- **Build-tool/config error**: a genuine `angular.json`/`tsconfig.json`
+  misconfiguration (a wrong path, a missing budget) rather than a code
+  issue.
+
+### Step 3: Find the root cause
+
+**Template type errors**: trace the bound expression back to the
+component class member it reads — the type Angular is checking against is
+the actual declared type of that signal/field/getter, not a guess. A
+template type error is usually telling the truth about a real mismatch
+between the template and the class.
+
+**Missing declaration/import**: check whether the component/directive/pipe
+is standalone (needs adding to the consuming component's `imports`) or
+NgModule-declared (needs adding to that module's `declarations`/`exports`,
+and the consuming module needs to import it) — the fix differs by which
+kind it is; check the component's own `@Component` decorator to tell.
+
+**DI resolution**: find where the service is (or should be) provided —
+check its own `@Injectable({ providedIn: ... })`, and any `providers`
+array on the component/route/module in the injection path. A "No provider
+for X" error means the injector tree that resolved this component/service
+has no matching provider anywhere above it, not that the class itself is
+broken.
+
+### Step 4: Apply the smallest correct fix
+
+- A template type error: fix the actual mismatch — correct the class
+  member's type, or correct the template expression reading it — not a
+  cast to `any` inside the template or a `$any()` template escape hatch
+  used to silence the checker.
+- A missing declaration/import: add the component/directive/pipe to the
+  correct `imports` (standalone) or `declarations`/`exports`
+  (NgModule) — not a blanket `CUSTOM_ELEMENTS_SCHEMA`/`NO_ERRORS_SCHEMA`
+  addition that suppresses unknown-element checking project-wide.
+- A DI resolution error: add the missing `providedIn`/`providers` entry at
+  the correct scope — not a workaround that constructs the service with
+  `new` instead of injecting it, which breaks DI's own singleton/testing
+  benefits.
+- A config error: fix the actual `angular.json`/`tsconfig.json` setting
+  that's wrong — call out explicitly in the report that a config file
+  changed and why.
+
+### Step 5: Verify and report
+
+Re-run `ng build` (the exact command from Step 1); confirm it now exits 0.
+Report the root cause and the fix, not just "build passes now".
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll wrap the template expression in `$any(...)` to stop the type error" | `$any()` disables type checking for that expression entirely — it hides the real mismatch instead of fixing the class member or the template expression reading it |
+| "I'll set `strictTemplates: false` in tsconfig, then this whole class of error goes away" | That silences template type checking project-wide for every component, not just the one with the error — a genuine project-wide policy change, not a fix for this build failure |
+| "I'll add `NO_ERRORS_SCHEMA` to fix this unknown-element error" | That tells Angular to stop validating unknown elements/attributes anywhere in that module, masking every future typo the same way, not just resolving this one missing import |
+| "No provider for X — I'll just `new X()` instead of injecting it" | That bypasses Angular's DI entirely (no testability via TestBed overrides, no respecting the service's actual provider scope); find and fix the missing provider instead |
+
+## Verification
+
+Do not report the fix done until all of the following hold:
+
+- The exact command that reproduced the failure in Step 1 (`ng build` or
+  the project's wrapping script) now exits 0.
+- No `$any()`, template `any` cast, `NO_ERRORS_SCHEMA`/
+  `CUSTOM_ELEMENTS_SCHEMA` addition, or `strictTemplates`/`fullTemplateTypeCheck`
+  downgrade was added to silence the error.
+- No dependency was constructed with `new` in place of a fixed DI
+  provider.
+- The report states the actual root cause, not just "build passes now".
+- `git status` shows changes confined to the files the root cause
+  required.

package/src/gdskills/bundled/stacks/angular/skills/angular-build-fix/evals.json

@@ -0,0 +1,72 @@
+{
+  "triggers": {
+    "positive": [
+      "My Angular template throws 'Property does not exist on type OrderDraft' the moment I run a production build — how do I get it compiling again?",
+      "My Angular app throws a NullInjectorError -- 'No provider for OrdersService' -- the instant it bootstraps after a clean build; what's the right way to resolve this DI resolution error?",
+      "Fix this Angular error: 'app-order-card' is not a known element",
+      "After wiring a signal into a brand-new @if block, `ng build` now reports a template type-checking error it didn't throw before -- what's the right way to fix this Angular build failure?",
+      "My standalone Angular component won't compile because I forgot to import CommonModule for @if — how do I track down and fix missing imports like this?",
+      "Angular build fails with a template type mismatch on this @for loop"
+    ],
+    "negative": [
+      "Fix this tsc type error in our Node.js backend with no Angular involved",
+      "Fix this Vue Vite build error about an unresolved SFC import",
+      "Implement a new Angular service that calls this REST API",
+      "Review this Angular component diff for OnPush mutation bugs",
+      "Fix this eslint no-floating-promises failure in our Express service",
+      "Write TestBed tests for this Angular component's HTTP calls"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "no-dollar-any-template-escape",
+      "prompt": "ng build fails with a template type error: Property 'total' does not exist on type 'OrderDraft' in the template expression `{{ order.total }}`. What's the right way to fix this?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer treats the template error as a genuine mismatch between the OrderDraft type and the template expression reading a total property from it, and fixes the type (or reads the correct property/derives the value) rather than silencing the checker with a $any() template escape hatch.",
+          "pass_criteria": [
+            "Names the concrete fix: adds a typed `total` property/accessor to OrderDraft, or changes the template to read/compute the correct existing property instead of a nonexistent `total`",
+            "Shows the corrected type declaration or corrected template expression, not just a statement that the type needs fixing"
+          ],
+          "fail_criteria": [
+            "Recommends wrapping the expression in `$any(order).total` (or any `$any()` usage) as the fix",
+            "Recommends disabling strictTemplates/fullTemplateTypeCheck in tsconfig instead of fixing the actual mismatch"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "The template is telling the truth: OrderDraft genuinely has no `total` property, so `{{ order.total }}` fails Angular's template type check. Trace where OrderDraft objects are built to see which case applies. If every OrderDraft is meant to carry a running total, add it to the type:\n\ninterface OrderDraft {\n  items: LineItem[];\n  total: number;\n}\n\nIf total is meant to be derived, change the template (or a computed() the template reads) instead of adding a stored field:\n\ntotal = computed(() => this.order().items.reduce((sum, item) => sum + item.price, 0));\n\n... and bind `{{ total() }}` in the template. Either way, don't reach for `$any(order).total` -- that disables type checking for the whole expression instead of fixing the real mismatch. After the fix, re-run `ng build` and confirm it exits 0 with no new `$any()` calls added.",
+        "known_wrong": "Quickest fix: change the template to `{{ $any(order).total }}`. That tells Angular's template checker to stop type-checking the expression, so the build passes immediately without needing to touch the OrderDraft interface or figure out where total should actually come from.",
+        "vague": "Fix the OrderDraft type so it actually has what the template expects, rather than working around the checker.",
+        "subtle_wrong": "Since OrderDraft doesn't have total, I added it as `total: any` on the interface so the template compiles regardless of whether it ends up as a number or something else later. This gets the build green without needing to pin down the exact type right now."
+      },
+      "anti_patterns": ["$any("]
+    },
+    {
+      "id": "fix-missing-provider-not-new",
+      "prompt": "The ng build itself succeeds, but the app throws at bootstrap: NullInjectorError: No provider for OrdersService!. What's the correct fix?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer fixes the actual dependency-injection configuration -- adding providedIn: 'root' on the service, or adding it to the relevant component's/route's providers array -- rather than working around the error by constructing the service directly with `new` instead of injecting it.",
+          "pass_criteria": [
+            "Identifies that the fix is to provide the service correctly, e.g. `@Injectable({ providedIn: 'root' })` on OrdersService, or adding it to the consuming component's/route's providers array",
+            "Explains that the error means no injector in the resolution path has a provider for OrdersService, not that the service class itself is broken"
+          ],
+          "fail_criteria": [
+            "Recommends replacing the injected/inject()-obtained OrdersService with `new OrdersService(...)` constructed manually as the fix"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "NullInjectorError means the injector tree resolving whatever calls `inject(OrdersService)` (or has it in its constructor) has no provider for it anywhere above it -- the class itself is fine, it's a configuration gap. Fix it at the provider level: if OrdersService should be an app-wide singleton, add `@Injectable({ providedIn: 'root' })` to its class decorator. If it's meant to be scoped to a specific feature/route instead, add `OrdersService` to that route's or that standalone component's `providers` array. Don't route around it with `new OrdersService(...)` -- that bypasses Angular's DI graph entirely, breaking TestBed overrides and any other service OrdersService itself depends on via injection. After adding the provider, re-run `ng build` (and the app) and confirm the error is gone.",
+        "known_wrong": "Simplest fix: instead of injecting it, just construct it directly wherever it's used: `private orders = new OrdersService();`. That sidesteps the whole provider error since you're not going through Angular's injector at all.",
+        "vague": "You need to make sure OrdersService is actually provided somewhere the injector can find it.",
+        "subtle_wrong": "I'd fix this by adding `providers: [OrdersService]` to every component that injects it, one by one, so each component has its own local instance and provider entry -- that guarantees no injector in the tree is ever missing it, without needing to figure out whether it should really be root-scoped or feature-scoped."
+      }
+    }
+  ]
+}