@mrciphersmith/keryx 0.3.0 → 0.3.2

package/src/gdskills/bundled/stacks/angular/skills/angular-code-review/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: angular-code-review
+description: "Use when reviewing an Angular component/service/directive diff for framework-specific correctness -- untracked RxJS subscriptions missing takeUntilDestroyed/async-pipe cleanup, OnPush components mutating an @Input reference in place instead of replacing it, an inject() call made outside a valid Angular injection context (NG0203), DomSanitizer bypassSecurityTrust* calls on user-influenced data, and NgModule/standalone mixing. Read-only: reports findings only, never edits the reviewed files, and leaves plain TypeScript correctness and MobX-specific logic to their own reviewers. Not for implementing or fixing the reviewed diff (use angular-implementation or angular-build-fix)."
+triggers:
+  - "review this Angular component diff for RxJS subscription leaks"
+  - "check this Angular PR for OnPush change detection mistakes"
+  - "review this Angular service for DomSanitizer bypass usage"
+  - "audit this Angular component for inject() misuse"
+  - "review this standalone Angular component for signal anti-patterns"
+  - "check this Angular diff before merging"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Angular code review
+
+Review an Angular component/service/directive/pipe diff for
+framework-specific correctness issues. This skill only reports findings —
+it never edits the reviewed code. See `rules/patterns.mdc` and
+`rules/security.mdc` for the full rule set this review draws its checks
+from.
+
+## Scope
+
+Covers Angular-specific concerns: change detection, signals, dependency
+injection, RxJS lifecycle, and template sanitization. It does not repeat
+generic TypeScript/Node review (unused variables, general async
+correctness) already covered by the base `ts-js-node` reviewers, and it
+does not review NestJS backend structure or MobX store logic — those have
+their own reviewers.
+
+## Workflow
+
+### Step 1: Read the diff in full before forming an opinion
+
+Read every changed file, not just the hunk markers — a subscription's
+teardown, or the component's `changeDetection` setting, is often declared
+outside the changed lines.
+
+### Step 2: Check each category against `rules/patterns.mdc` and `rules/security.mdc`
+
+- **RxJS lifecycle**: every `.subscribe()` added has a teardown path —
+  `takeUntilDestroyed()`, the `async` pipe, or an explicit `ngOnDestroy`
+  unsubscribe. Flag any subscription with none.
+- **Change detection**: an `OnPush` component whose template depends on a
+  value that's mutated in place (a pushed array element, a mutated object
+  property) rather than replaced with a new reference/signal update — that
+  mutation won't trigger a re-check under `OnPush`.
+- **Dependency injection**: `inject()` called anywhere outside a
+  constructor/field initializer (inside a callback, a `setTimeout`, a
+  plain method body without `runInInjectionContext`) — that throws at
+  runtime, not compile time, so it's easy to miss without reading the call
+  site.
+- **Sanitization**: any `DomSanitizer.bypassSecurityTrust*` call — verify
+  the value it wraps is genuinely static/developer-authored, not traceable
+  to user input or an external API response; flag any that isn't
+  obviously safe.
+- **Standalone/NgModule consistency**: a new `NgModule`-declared
+  component/directive/pipe added to a codebase that is otherwise
+  standalone (or vice versa) without a stated reason.
+- **Signals**: a `computed()` whose callback has a side effect (an HTTP
+  call, a write to another signal) instead of staying pure.
+
+### Step 3: Report findings
+
+For each finding: file:line, what's wrong, why it matters (cite the
+specific mechanism — e.g. "OnPush won't re-check on this mutation"), and
+the concrete fix (not just "consider using X"). Group by severity: a
+missing subscription teardown or a `bypassSecurityTrust*` on
+user-influenced data is higher severity than a stylistic
+`*ngIf`/`@if` inconsistency.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "The subscription probably gets garbage collected eventually, not worth flagging" | An Observable subscription holds a live reference until explicitly unsubscribed; it does not get cleaned up by GC just because the component view is gone |
+| "This `bypassSecurityTrustHtml` call is fine, the string just looks like static markup" | If the string is built from or includes any user-influenced or API-sourced value, "looks static" isn't a security argument — trace where the value actually comes from before clearing it |
+| "The mutation is inside an OnPush component but it 'usually still updates', so I won't flag it" | An in-place mutation not tracked by `OnPush` is a timing bug waiting to surface under different data/timing, not a hypothetical — flag it even if the current test data happens to trigger a coincidental re-check elsewhere |
+| "I'll just fix the missing takeUntilDestroyed while I'm reviewing, it's a one-line change" | This skill reports findings only; even an obvious one-line fix goes in the report for the author (or angular-implementation) to apply, not applied directly during review |
+
+## Verification
+
+Before finishing the review, confirm:
+
+- Every changed file with a `.subscribe()` call was checked for a
+  teardown path.
+- Every `OnPush` component's template dependencies were checked for
+  in-place mutation.
+- Every `inject()` call site was checked for being inside a valid
+  injection context.
+- Every `bypassSecurityTrust*` call was checked against where its
+  argument value actually originates.
+- No code was edited — the output is a findings report only.

package/src/gdskills/bundled/stacks/angular/skills/angular-code-review/evals.json

@@ -0,0 +1,73 @@
+{
+  "triggers": {
+    "positive": [
+      "Before I merge this Angular component, can you check whether any of its .subscribe() calls are missing takeUntilDestroyed or another teardown?",
+      "Does this Angular pull request handle change detection correctly, or is it mutating an @Input array in place under OnPush?",
+      "This Angular service pipes some HTML through DomSanitizer's bypassSecurityTrustHtml — can you check whether that's actually safe here?",
+      "Take a look at where this Angular component calls inject() — are any of those calls happening outside a valid injection context?",
+      "In this standalone Angular component, does the way its computed() signal is written look like an anti-pattern worth flagging in review?",
+      "Check this Angular diff for mixing NgModule and standalone components before merge"
+    ],
+    "negative": [
+      "Review this NestJS controller diff for DTO validation and guard usage",
+      "Review this MobX store diff for observable/action correctness",
+      "Review this React component diff for missing hook dependencies",
+      "Add retry and error handling to this Angular service's outgoing HTTP call chain",
+      "Write a TestBed spec asserting this Angular route guard blocks an unauthenticated user",
+      "Review this Node.js Express route diff for injection vulnerabilities"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "flag-subscription-without-teardown",
+      "prompt": "Reviewing this Angular component diff:\n\n```ts\nexport class OrderPanel implements OnInit {\n  private readonly orders = inject(OrdersService);\n  order?: Order;\n\n  ngOnInit() {\n    this.orders.watchOrder(this.orderId).subscribe(order => {\n      this.order = order;\n    });\n  }\n}\n```\n\nWhat, if anything, should be flagged?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct review flags the .subscribe() call in ngOnInit as having no teardown path -- no takeUntilDestroyed, no async pipe, and no ngOnDestroy unsubscribe -- and names the concrete fix (piping through takeUntilDestroyed(), or switching to the async pipe / toSignal()) rather than leaving the subscription open for the component's full lifetime.",
+          "pass_criteria": [
+            "Identifies that the .subscribe() call has no teardown/unsubscribe mechanism and flags it as a leak risk",
+            "Names a concrete fix: takeUntilDestroyed() piped into the subscription, converting to the async pipe, or using toSignal() -- not just 'add cleanup' in the abstract"
+          ],
+          "fail_criteria": [
+            "Says the code has no issues worth flagging",
+            "Proposes fixing the subscription by editing the code directly instead of reporting it as a finding"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Flag this: `this.orders.watchOrder(this.orderId).subscribe(...)` in ngOnInit has no teardown -- no takeUntilDestroyed(), no async pipe, no ngOnDestroy unsubscribe. As written, the subscription stays open for the component's entire lifetime and beyond if the observable is long-lived (a websocket-backed stream, a polling interval), which is a leak. Fix: pipe it through takeUntilDestroyed() (inject() is already called in a valid field-initializer context here, so takeUntilDestroyed() can be called the same way), e.g. `this.orders.watchOrder(this.orderId).pipe(takeUntilDestroyed()).subscribe(order => this.order = order);` -- or, since this is just mirroring an observable into a field for template use, convert it to `order = toSignal(this.orders.watchOrder(this.orderId))` and drop the manual subscription entirely.",
+        "known_wrong": "This looks fine -- the component subscribes once in ngOnInit and just updates a local field, nothing unusual there. No changes needed.",
+        "vague": "There might be a subscription cleanup concern here worth double-checking before merging.",
+        "subtle_wrong": "Worth a note: I'd suggest adding a comment above the subscribe() call documenting that it's expected to live for the component's full lifetime, so future readers know it's intentional rather than an oversight. That way the review concern is addressed without needing to change the subscription handling itself."
+      }
+    },
+    {
+      "id": "flag-onpush-inplace-mutation",
+      "prompt": "Reviewing this Angular diff. `CartList` is a child OnPush component; `CartPage` is its parent and passes `items` down as an `@Input`:\n\n```ts\n@Component({\n  selector: 'app-cart-list',\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `@for (item of items; track item.id) { <div>{{ item.name }}</div> }`\n})\nexport class CartList {\n  @Input() items: CartItem[] = [];\n}\n\n@Component({ selector: 'app-cart-page', template: `<app-cart-list [items]=\"items\" />` })\nexport class CartPage {\n  items: CartItem[] = [];\n\n  addItem(item: CartItem) {\n    this.items.push(item);\n  }\n}\n```\n\n`CartPage.addItem` runs (e.g. from a button click in `CartPage`'s own template), but `CartList`'s rendered list doesn't update. What should be flagged?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct review flags that CartPage.addItem mutates the items array in place (push) rather than reassigning it, so the SAME array reference is still bound to CartList's @Input -- CartList is OnPush, and OnPush only re-checks a child on a new input reference (or its own event/async-pipe/signal), so a mutation of the same object the parent already passed down produces no reference change for the child to notice. Names the fix: the parent reassigns items to a new array (e.g. this.items = [...this.items, item]) or items is modeled as a signal.",
+          "pass_criteria": [
+            "States that `this.items.push(item)` in CartPage mutates the array in place, so the SAME object reference is still bound to CartList's `items` @Input -- object identity did not change",
+            "States that CartList is OnPush and only re-checks on a new @Input reference (or its own event/async-pipe/signal source), so the child's own re-render is what fails to happen here -- CartPage re-rendering itself (the click handler ran inside CartPage) does not, on its own, make CartList re-check",
+            "Names a concrete fix: CartPage reassigns items to a new array before/instead of mutating in place (e.g. `this.items = [...this.items, item];`), or items is modeled as a signal passed down and read via `input<CartItem[]>()`"
+          ],
+          "fail_criteria": [
+            "Says the code is correct as-is with no OnPush-related concern",
+            "Claims reassigning items to itself (e.g. `this.items = this.items;`) forces CartList to update -- this is a no-op: the reference is identical to what it already was, so CartList's own @Input identity check has nothing new to see. (Spreading into a genuinely new array, e.g. `this.items = [...this.items, item]`, IS a real fix and must not be flagged here -- it produces an actual new reference.)"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Flag `CartPage.addItem`: `this.items.push(item)` mutates the array CartPage already passed to CartList's `items` @Input, so CartList still holds a reference to the SAME object -- its identity never changed. CartList is OnPush, and OnPush only re-checks a component on a new @Input reference, an event that happens inside that component itself, an async pipe emission, or a signal read -- none of which fired for CartList here; CartPage's own click handler running is CartPage's event, not CartList's. Fix by having CartPage reassign the reference: `this.items = [...this.items, item];`, or better, model `items` as a signal input (`items = input<CartItem[]>([]);` on CartList, updated via a signal on CartPage) so the template's `@for` tracks the signal directly.",
+        "known_wrong": "This is fine -- `items` is declared as a regular array field and push() is the normal way to add to it. OnPush doesn't need anything special here since CartList's template just iterates over items and Angular tracks array mutations automatically.",
+        "vague": "Something about how items get passed down here might not play well with OnPush -- worth a second look at how the child picks up the change.",
+        "subtle_wrong": "The real fix is simpler than restructuring the array: right after `this.items.push(item)`, just do `this.items = this.items;` in CartPage. Since Angular's input binding re-evaluates on the parent's own change detection pass, reassigning the field (even to itself) is enough to make CartList see it as a fresh binding and re-render."
+      }
+    }
+  ]
+}

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

@@ -0,0 +1,112 @@
+---
+name: angular-implementation
+description: "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)."
+triggers:
+  - "create a new standalone Angular component for"
+  - "add an Angular service with inject()"
+  - "implement this feature using Angular signals"
+  - "build a typed reactive form in Angular for"
+  - "wire up a new Angular component using inject() and signal state"
+  - "add an Angular route guard for"
+  - "convert this to a standalone Angular component"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Angular implementation
+
+Implement a new Angular component, service, directive, or pipe using
+current Angular idiom: standalone by default, signal-based state,
+`inject()` for dependency injection, and `OnPush` change detection. See
+`rules/coding-style.mdc` for naming/typing conventions and
+`rules/patterns.mdc` for the change-detection and RxJS-interop patterns a
+correct implementation should follow.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+Before writing a new component/service, check:
+
+- `angular.json` for the project's Angular version, builder, and whether
+  strict template type checking (`strictTemplates`) is on.
+- A handful of existing components for: standalone vs. NgModule-based,
+  `*ngIf`/`*ngFor` vs. `@if`/`@for`, `inject()` vs. constructor injection,
+  signal inputs (`input()`) vs. `@Input()` decorators, and the file-suffix
+  convention (`.component.ts` vs. plain `.ts`).
+- Whether the project uses a state-management library (NgRx, a signal
+  store) beyond plain component/service signals — match it rather than
+  introducing a second, competing pattern.
+
+Match the project's existing convention even where it differs from the
+newest Angular idiom described below, unless the task explicitly asks for
+a migration.
+
+### Step 2: Scaffold with the Angular CLI when available
+
+Prefer `ng generate component <name>` / `ng generate service <name>` (or
+the project's own schematics/collection) over hand-writing boilerplate —
+it wires the file into `angular.json`'s conventions and produces a
+standalone component by default on current Angular. Adjust the generated
+file to match the task, don't leave placeholder content.
+
+### Step 3: Design the component/service
+
+- **State**: model changing state with `signal()`; derive values with
+  `computed()`; use `input()`/`model()` for component inputs (typed
+  explicitly), `output()` for events. Keep `computed()` pure — no HTTP
+  calls or writes to other signals inside it (`rules/patterns.mdc`).
+- **DI**: use `inject()` at the field-initializer/constructor level for
+  every dependency, consistently within the class (`rules/coding-style.mdc`).
+- **Change detection**: set `changeDetection: ChangeDetectionStrategy.OnPush`
+  on new components; with signal-based state this needs no extra wiring —
+  reading a signal in the template registers the dependency automatically.
+- **RxJS boundaries**: when a dependency (HTTP, router events, a form's
+  `valueChanges`) is naturally an `Observable`, convert once with
+  `toSignal()` for template/computed use, or pipe a manual subscription
+  through `takeUntilDestroyed()` — never leave a subscription with no
+  teardown path.
+- **Templates**: use `@if`/`@for` (with an explicit `track`)/`@switch`
+  unless the surrounding file already uses structural directives
+  throughout.
+
+### Step 4: Forms (when the task involves user input)
+
+Use typed Reactive Forms (`FormGroup<{...}>`/`FormControl<T>`) with
+`ValidatorFn`s on the controls, per `rules/patterns.mdc` — not template-driven
+forms or ad-hoc validation in a submit handler, unless the project's
+existing forms are template-driven and the task is a small addition to one.
+
+### Step 5: Verify
+
+Run the project's own build/lint/test scripts (see Verification below).
+Fix any new template type error or lint finding by correcting the actual
+mismatch — do not loosen `strictTemplates` or add a suppression to make a
+new component's own code pass.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just use `@Input()` with a plain field, signals are extra ceremony for one input" | A codebase that has otherwise moved to signal inputs (`input()`) gets fine-grained reactivity and `OnPush` compatibility for free; mixing the two styles in the same component is the actual added ceremony |
+| "I'll call `inject()` inside this `setTimeout` callback, it's simpler than passing the service through" | `inject()` only works inside an injection context; calling it later throws at runtime, not compile time -- inject the dependency in the constructor/field initializer and capture it in a closure instead |
+| "I'll subscribe directly and skip `takeUntilDestroyed`, the component doesn't live long anyway" | An unbounded subscription is a real leak the moment that assumption stops holding (a modal reused, a route revisited); tear it down explicitly every time |
+| "I'll leave `ChangeDetectionStrategy.Default` since OnPush might miss an update" | With signal-reads in the template, `OnPush` tracks the real dependency automatically; `Default` just means the component re-checks on every application-wide change detection pass for no benefit |
+
+## Verification
+
+Do not report the implementation done until all of the following hold:
+
+- `ng build` (or the project's build script) succeeds with no new template
+  type errors.
+- The project's lint script (`ng lint` or its `eslint` equivalent) passes
+  on the new/changed files.
+- Any new signal-based input/output is explicitly typed, and any
+  RxJS subscription created in the new code has an explicit teardown
+  (`takeUntilDestroyed`, `async` pipe, or `toSignal()`).
+- `git status` shows changes confined to the component/service the task
+  asked for, plus any routing/module registration it genuinely needs.

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

@@ -0,0 +1,74 @@
+{
+  "triggers": {
+    "positive": [
+      "I need a new component in our Angular app that lists a user's past orders",
+      "We need a service in our Angular app that wraps the orders HTTP endpoints -- how should it get HttpClient?",
+      "How should I hold this component's state in Angular so the template updates when it changes, without plain fields?",
+      "Build me a shipping-address form in Angular where every field is typed and validated",
+      "Only logged-in users should be able to open /account in our Angular app; anyone else goes back to /login",
+      "This component re-renders the whole tree on every parent change -- how do I make it only update when its own signal input actually changes?",
+      "This Angular component still lives in an NgModule's declarations array -- I want it to stand on its own"
+    ],
+    "negative": [
+      "Create a new Vue component using the Composition API with <script setup>",
+      "Create a new React component that fetches and displays a user's order history",
+      "Write a TestBed spec that calls fixture.detectChanges and asserts the rendered template",
+      "Fix this ng build AOT compile error about a missing NgModule declaration",
+      "Review this Angular component's diff for RxJS subscription leaks",
+      "Fix this tsc type error in our Node.js backend service",
+      "Migrate this MobX store's observable state to use runInAction correctly"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "signal-input-not-input-decorator",
+      "prompt": "I'm adding a new standalone Angular component that receives an `order: Order` value as an input. The rest of this codebase uses signals throughout (signal(), computed(), input()). How should I declare and read this input?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer declares the input with the signal-based `input()` function (e.g. `order = input.required<Order>()` or `order = input<Order | null>(null)`), explicitly typed to Order, and reads it in the class/template by calling it as a function (`order()`), rather than declaring a plain class field decorated with `@Input()`.",
+          "pass_criteria": [
+            "Shows the actual declaration using `input()` or `input.required()` with an explicit `Order` type parameter, not just a statement that 'signal inputs should be used'",
+            "Shows reading the value by calling it as a function (e.g. `order()` in the template or class body), matching the signal-input convention"
+          ],
+          "fail_criteria": [
+            "Declares the input as a plain class field with an `@Input()` decorator as the recommended implementation for this signals-based codebase -- naming `@Input()` only to contrast it with the signal-based approach is not a failure",
+            "Reads the declared signal input as a plain property access (`this.order`) instead of calling it as a function"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Since the rest of the codebase already uses signals, declare the input as a signal input rather than a decorated field:\n\nexport class OrderSummary {\n  order = input.required<Order>();\n}\n\nRead it by calling it, both in the template (`{{ order().total }}`) and in class code (`this.order().id`), the same way you'd read any other signal. If the input is genuinely optional, use `input<Order | null>(null)` instead of `.required()` so callers that omit it get an explicit typed default rather than `undefined` leaking through untyped. Avoid mixing this with an `@Input()` decorator on a plain field in the same component -- that would give the component two different ways to receive data and break the OnPush/signal-tracking benefit the rest of the codebase relies on.",
+        "known_wrong": "Just add a normal `@Input() order!: Order;` field like a typical Angular component -- it's simpler than the new signal syntax and Angular still supports it fine. Read it as `this.order` in the template and class code as usual; there's no real need to switch to `input()` just because other parts of the app use signals elsewhere.",
+        "vague": "Use the signal-based way of declaring inputs that matches how the rest of the codebase already handles component state, and read it consistently with the signal convention.",
+        "subtle_wrong": "I declared it with the newer syntax: `order = input<Order>();` without `.required()` or a default, and read it in the template as `order()!` with a non-null assertion since I know the parent always passes it. This keeps the signal style but skips `.required()` since the assertion is shorter to write, and I left the class-body access as `this.order` in one helper method since it read more naturally there without the parentheses."
+      },
+      "anti_patterns": ["@Input()"]
+    },
+    {
+      "id": "inject-inside-injection-context-only",
+      "prompt": "In an Angular component's ngOnInit, I need to call a service method inside a setTimeout callback. Should I call inject() right there inside the setTimeout callback to grab the service?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer explains that inject() only works inside Angular's injection context (constructor or field initializer, or code wrapped in runInInjectionContext) and must not be called inside a setTimeout callback; instead the service should be injected once in the constructor or as a field initializer and the resulting reference captured in a closure for use inside the callback.",
+          "pass_criteria": [
+            "States that inject() must be called inside an injection context (constructor/field initializer), not inside a setTimeout callback, and that calling it there will fail",
+            "Shows or names an actual fix: either injecting the service as a class field/constructor (e.g. `private readonly orders = inject(OrdersService);`) before the setTimeout and referencing that already-injected variable inside the callback, OR wrapping the callback body in `runInInjectionContext(injector, () => { ... })` using an `Injector` that was itself captured in a valid injection context (e.g. `private readonly injector = inject(Injector);` in the constructor/field initializer) before the setTimeout"
+          ],
+          "fail_criteria": [
+            "Recommends calling inject() inside the setTimeout callback as a working fix -- whether directly inline, or one level removed through a private helper method that is itself only ever invoked from inside the callback -- without actually injecting the service in the constructor/field initializer beforehand"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "No -- inject() only works inside Angular's injection context, which is the constructor, a field initializer, or code explicitly wrapped in runInInjectionContext(). A setTimeout callback runs later, outside that context, so calling inject() there throws at runtime instead of returning the service. Inject the service once where the class is constructed and capture the reference in a field, then use that field inside the callback:\n\nexport class OrderPanel {\n  private readonly orders = inject(OrdersService);\n\n  ngOnInit() {\n    setTimeout(() => {\n      this.orders.refresh();\n    }, 500);\n  }\n}\n\nThe closure over `this.orders` is what makes the deferred call work, not calling inject() again inside the timeout.",
+        "known_wrong": "Sure, just call inject(OrdersService) inside the setTimeout callback right where you need it -- that keeps the dependency close to where it's used instead of adding another field to the class. Angular's DI will resolve it fine whenever the callback runs.",
+        "vague": "You shouldn't call inject() just anywhere -- it needs to happen at the right time in the component's lifecycle, so grab the service earlier instead of inside the callback.",
+        "subtle_wrong": "Calling inject() directly inline inside the setTimeout callback throws, but you can fix that by pulling it into its own private method instead: define `private getOrders() { return inject(OrdersService); }` on the class, then call `this.getOrders().refresh()` from inside the setTimeout callback. Since the inject() call now lives in a named method rather than the callback body itself, it's no longer really \"inside\" the callback, so it resolves normally."
+      }
+    }
+  ]
+}

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

@@ -0,0 +1,102 @@
+---
+name: angular-testing
+description: "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)."
+triggers:
+  - "write a TestBed spec for this Angular component"
+  - "test this Angular service's HTTP calls with HttpTestingController"
+  - "add a spec asserting this Angular component's rendered DOM"
+  - "write a fakeAsync test for this Angular component"
+  - "test this Angular CanActivate route guard's logic"
+  - "mock this Angular component's injected service in a spec"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Angular testing (TestBed)
+
+Write or fix a unit test for an Angular component, service, directive, or
+pipe using `TestBed`. See `rules/testing.mdc` for layout, fixture, and
+determinism conventions; this skill is the step-by-step workflow for
+applying them to a specific component or service under test.
+
+## Workflow
+
+### Step 1: Discover the project's test setup
+
+- Check `angular.json`'s `test` builder and `package.json`'s `test` script
+  to confirm the actual runner (`ng test`/Karma, or a migrated Jest/Vitest
+  setup) before assuming Karma.
+- Look at an existing `.spec.ts` in the same directory/module for the
+  project's own conventions: how it configures `TestBed`, whether it uses
+  `HttpTestingController` or a hand-rolled HTTP mock, and its
+  `fakeAsync`/`waitForAsync` usage.
+
+### Step 2: Configure TestBed for the unit under test
+
+- For a standalone component: `TestBed.configureTestingModule({ imports:
+  [MyComponent, ...anySupportingImports] })` -- standalone components are
+  imported, not declared.
+- Provide test doubles for injected dependencies via `providers` (a mock
+  object, a `jasmine.createSpyObj`, or `provideHttpClientTesting()` for
+  `HttpClient`-backed services) rather than letting the real service reach
+  a real network/backend.
+- `TestBed.createComponent(MyComponent)` to get the `ComponentFixture`;
+  keep a reference to `fixture.componentInstance` for direct assertions on
+  class state.
+
+### Step 3: Drive the fixture correctly
+
+- Set a signal-based input with `fixture.componentRef.setInput('name',
+  value)` -- never by assigning the component instance's field directly,
+  since that skips Angular's actual input-binding path.
+- Call `fixture.detectChanges()` after any state change that should affect
+  the DOM, and `await fixture.whenStable()` after anything asynchronous
+  (a resolved promise, a flushed HTTP request) before asserting on
+  rendered markup.
+- Query with `fixture.debugElement.query(By.css(...))` or
+  `fixture.nativeElement.querySelector(...)`, preferring a stable selector
+  (`data-testid`, semantic role/label) over a styling-only CSS class.
+
+### Step 4: HTTP and async determinism
+
+- For a service/component that calls `HttpClient`, provide
+  `provideHttpClientTesting()` and assert with `HttpTestingController`:
+  `httpTestingController.expectOne(url).flush(mockResponse)`. Call
+  `httpTestingController.verify()` at the end of the test (or in an
+  `afterEach`) to catch an unexpected extra request.
+- Wrap a test that depends on timers/microtasks in `fakeAsync` and advance
+  time with `tick(<exact ms>)` (matching the real delay the code under
+  test uses) rather than a real `setTimeout` in the spec -- a real timer
+  makes the test's runtime and reliability depend on wall-clock timing.
+
+### Step 5: Verify
+
+Run the project's actual test command and confirm the new/changed spec
+passes without weakening an existing assertion.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just set `component.order = mockOrder` directly instead of `setInput`" | Direct field assignment on a signal input skips Angular's input-binding path; a real caller's binding wouldn't reach the component that way, so the test can pass while the actual binding is broken |
+| "I'll skip `httpTestingController.verify()`, the test already checked the response I care about" | `verify()` is what catches an unexpected *extra* request (e.g. a duplicated HTTP call from a bug); skipping it lets that regression through silently |
+| "I'll use a real `setTimeout(..., 1000)` in the test instead of `fakeAsync`/`tick`" | A real timer makes the test's speed and reliability depend on wall-clock timing and CI load; `tick()` advances virtual time deterministically |
+| "This assertion fails right after `setInput`, I'll just delete it since the feature clearly still works manually" | The assertion is failing because `detectChanges()`/`whenStable()` wasn't called before it, not because the feature is broken -- fix the missing call, don't delete the check |
+
+## Verification
+
+Do not report the test done until all of the following hold:
+
+- The project's actual test command (`ng test` or its configured
+  equivalent) passes, including the new/changed spec.
+- Every signal-based input in the test is set via
+  `fixture.componentRef.setInput(...)`, not direct field assignment.
+- Every `HttpClient` call the test exercises goes through
+  `HttpTestingController`, and `verify()` runs (no unexpected leftover
+  request).
+- No existing assertion was weakened, skipped, or deleted to make the
+  suite pass.

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

@@ -0,0 +1,71 @@
+{
+  "triggers": {
+    "positive": [
+      "This Angular component reads its data through a signal input — what's the right TestBed setup to cover it with tests?",
+      "This Angular service fires off a couple of HTTP requests — how do I mock them out with HttpTestingController for a proper spec?",
+      "I need a fakeAsync TestBed spec for this Angular component that proves its debounced search waits the full delay before calling the service — how do I structure the tick() calls?",
+      "Test this standalone Angular component's OnPush rendering when the input changes",
+      "In a TestBed spec for this component, what's the right way to swap out its injected OrdersService for a mock/fake?",
+      "What's the best way to unit test whether this route guard's CanActivate correctly blocks a logged-out user, in Angular?"
+    ],
+    "negative": [
+      "Write Vitest component tests for this Vue component using Vue Test Utils",
+      "Write React Testing Library tests for this component's rendered list",
+      "Implement a new standalone Angular component that shows order history",
+      "Fix this ng build AOT compile error about a missing provider",
+      "Write a Playwright e2e test for the login flow in our Angular app",
+      "Write unit tests for this Go struct's JSON marshaling using the standard testing package"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "setinput-not-direct-assignment",
+      "prompt": "I'm writing a TestBed spec for a standalone Angular component that has a signal input declared as `order = input.required<Order>();`. In the test, should I just set `component.order = someMockOrder` before calling detectChanges?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer explains that a signal input must be set through fixture.componentRef.setInput('order', mockOrder), not by directly assigning the component instance's field, because direct assignment bypasses Angular's actual input-binding mechanism and would not reflect what a real caller's template binding does; it should also call fixture.detectChanges() afterward before asserting on the DOM.",
+          "pass_criteria": [
+            "States directly that assigning `component.order = mockOrder` does not go through Angular's real input-binding path and should not be used",
+            "Shows the correct call: `fixture.componentRef.setInput('order', mockOrder)` before `fixture.detectChanges()`"
+          ],
+          "fail_criteria": [
+            "Recommends direct field assignment (`component.order = mockOrder`) as a working way to set the input for the test"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "No -- don't assign `component.order` directly. That field is a signal created by `input.required<Order>()`, and assigning over it doesn't go through Angular's input-binding machinery the way a real caller's template binding would; it also just overwrites the signal reference rather than setting its value through the framework. Use the fixture's binding API instead:\n\nfixture.componentRef.setInput('order', mockOrder);\nfixture.detectChanges();\n\nThat's the same mechanism a real parent template's `[order]=\"someOrder\"` binding goes through, so the test exercises the actual input path, and `detectChanges()` after it makes sure the template re-renders before you assert on the DOM.",
+        "known_wrong": "Sure, that's fine -- just do `component.order = someMockOrder;` then `fixture.detectChanges();`. It's the simplest way to get a value into the component for the test and detectChanges() will pick it up either way.",
+        "vague": "You shouldn't set inputs directly on the component instance in a test -- use the fixture's proper way of setting inputs instead so it behaves like a real binding.",
+        "subtle_wrong": "I'd avoid touching `component.order` directly, so instead I re-declared the field in the test by doing `(component as any).order = signal(mockOrder);`, replacing the whole input signal with a new one I control, then called `fixture.detectChanges()`. This keeps the test off the plain-assignment anti-pattern since it's still a signal, just one I constructed myself instead of going through Angular's binding."
+      },
+      "anti_patterns": ["component.order ="]
+    },
+    {
+      "id": "http-testing-controller-verify",
+      "prompt": "I'm testing an Angular service method that calls HttpClient.get() and returns the parsed response. I've set up HttpTestingController and flushed a mock response, and the assertion on the returned value passes. Is that test complete?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer says the test is not complete until httpTestingController.verify() is called (directly or in an afterEach), because expectOne/flush alone confirm the expected request happened but do not catch an unexpected additional HTTP request the code under test might also be making.",
+          "pass_criteria": [
+            "States that httpTestingController.verify() must be called (e.g. in afterEach or at the end of the test) to catch any unexpected outstanding/extra request",
+            "Explains that verify() checks for requests beyond the one already asserted with expectOne, not just re-checking the one that was flushed"
+          ],
+          "fail_criteria": [
+            "Says the test is already complete once the flushed response's assertion passes, with no mention of verify()"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Not quite -- asserting on the flushed response only proves the one request you called expectOne on returned what you expected. It doesn't catch a bug where the method under test also fires a second, unexpected HTTP call (a duplicated request, a stray retry). Add httpTestingController.verify() -- typically in an afterEach so every test in the file is covered -- which fails the test if there's any outstanding or unmatched request left over. That's the check that actually proves the method made exactly the request you expected and nothing else.",
+        "known_wrong": "Yes, that's complete -- you flushed the mock response and the assertion on the parsed value passed, so the HTTP call and the parsing logic are both verified. No need to add anything else.",
+        "vague": "Not fully -- there's usually one more step with HttpTestingController to make sure everything about the request is properly checked before calling it done.",
+        "subtle_wrong": "Close, but I'd also add a second `httpMock.expectOne(url)` call right after the first flush just to double-check the same request is still tracked correctly, then flush it again with the same mock response. That extra check makes sure the request handling is solid without needing a separate verify() step in afterEach."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/mobx/agent-refs.json

@@ -0,0 +1,4 @@
+{
+  "agents": [],
+  "note": "No generated agent pair by design, matching W2's original decision: mobx has no agentProfile in pack.json, so `agents generate --stack mobx` is refused (agents-catalog-commands.test.ts pins this). code-mobx-store-review already covers MobX-specific review, and ts-js-node/react build-fix already cover the build-failure case, so a generated mobx-code-auditor/mobx-build-fixer pair would duplicate existing coverage rather than add any -- this holds regardless of gate status. Separately (R1 review round 2, PR #719, N-M1): the same realism sweep that demoted angular found mobx-store-implementation's positives were trigger-prefix near-copies too; rewritten with natural phrasing, not iterated against the router. Honest result: mobx-store-implementation's trigger accuracy dropped (TP 4/8), accepted as the true signal. mobx-observable-testing still passes cleanly. mobx's own pack.json stability is demoted to \"experimental\" -- a pack needs every skill to pass."
+}