@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.0

package/skills/frontend/angular-architecture-signals-review/references/linked-signal-and-di-boundaries.md

@@ -0,0 +1,46 @@
+# linkedSignal and DI-boundary patterns
+
+> Load this reference only when `linkedSignal` appears in the diff under review, or when the review scope includes service/DI ownership review.
+
+## What people get wrong
+
+The naive story is:
+
+> `linkedSignal` is just `computed` with a different name; if it appears in a diff, check it the same way you'd check `computed` for purity.
+
+Wrong. `linkedSignal` exists for a distinct problem `computed` cannot solve: **dependent state that must stay valid when its source changes, but can also be manually overridden**. Angular's own guidance frames this as ensuring "the `linkedSignal` always maintains a valid value, even when its underlying dependencies change" — while still allowing `.set()` calls that a plain `computed()` (read-only) would reject. Flagging a `linkedSignal` as "should be a `computed`" without checking whether manual override is a real requirement produces a false-positive finding.
+
+The second naive story, on the DI side:
+
+> A service exists, so as long as it's `providedIn: 'root'`, the DI design is fine.
+
+Wrong. `providedIn: 'root'` is Angular's documented default for singleton services (per Angular's own style guide: "Design services around a single responsibility. Use the `providedIn: 'root'` option for singleton services"), but blast-radius and ownership are separate questions from injection scope. A root-provided service holding cross-cutting mutable state with no documented ownership model (who writes, who reads, what the lifetime and reset story is) is a design gap regardless of whether the DI scope itself is "correct."
+
+## `linkedSignal` review rules
+
+- **Confirm the source relationship.** `linkedSignal(() => source())` (shorthand form) or `linkedSignal({ source: ..., computation: ... })` (object form, which also grants access to the previous value) should have a clear, traceable source signal. Flag a `linkedSignal` with no discernible source dependency as unclear intent.
+- **Check for a genuine override requirement.** If nothing in the component ever calls `.set()` on the `linkedSignal`, it is not using the "dependent but overridable" capability and should likely be a plain `computed()` instead — recommend the simpler primitive.
+- **Object form for prior-value access.** The object form (`{ source, computation: (sourceValue, previous) => ... }`) exists specifically for cases that need the prior computed/linked value (e.g. preserving a chat history while new content streams in, or converting a domain model to a form model only once a resource loads, per Angular's own AI/forms design-pattern guidance). Do not flag this as unnecessary complexity without checking whether prior-value access is actually used.
+- **Do not conflate with `effect`-based derivation.** A `linkedSignal` reset-on-source-change pattern is the documented, correct tool for "resettable derived state" — it is not a workaround for avoiding `effect()`; do not suggest replacing it with an `effect()` that writes to a `signal()`, which reintroduces the state-propagation-via-effect anti-pattern this skill flags elsewhere.
+
+## DI/service-boundary review rules
+
+- **Single responsibility per service.** Per Angular's own style guide, a service should be designed around a single responsibility. A service accumulating multiple unrelated concerns (e.g. auth state + feature-flag cache + analytics buffer in one class) is a boundary finding — recommend splitting along responsibility lines, not along "make it smaller" alone.
+- **`inject()` over constructor injection for new/modified code.** Per the official Angular `angular-developer` skill and Angular's current style guidance, new code should prefer the `inject()` function over constructor-parameter injection — note this as a MEDIUM style finding when reviewing new service code that still uses constructor injection, not as a blocking defect for existing code that hasn't been touched.
+- **Ownership model for mutable state.** For any injectable service exposing mutable `signal()` state, confirm the review can answer: who is allowed to call `.set()`/`.update()` on it, what triggers a reset, and what the lifetime is (root-singleton for app-lifetime state vs. component-provided for a narrower scope). If the code gives no evidence of an ownership model — e.g. the mutable signal is exposed as a public writable `Signal` rather than behind a method that encapsulates the mutation — flag it as a LOW/MEDIUM boundary gap and request either encapsulation (expose a read-only `Signal` via `.asReadonly()` and a controlled setter method) or explicit documentation, rather than prescribing a specific DI scope.
+- **Do not prescribe DI scope changes speculatively.** Do not recommend moving a service from `providedIn: 'root'` to a component-level provider (or vice versa) unless the code in scope shows evidence of the actual lifetime/sharing requirement (e.g. multiple independent component instances each needing isolated state currently share one root singleton). A DI-scope change is a behavioral change, not a style preference.
+
+## When to still flag regardless of `linkedSignal`/DI context
+
+- Any `computed()` purity violation, missing injection-context on an `effect()`, or untracked post-await signal read found incidentally while reviewing `linkedSignal`/DI code — those checks always apply per the main workflow.
+- A hardcoded API key, token, or secret found in service state or a `linkedSignal` default/computation — HIGH severity, immediate escalation, regardless of scope.
+
+## When to push back
+
+Push back if the user asks to:
+
+- replace a `linkedSignal` that has a real manual-override requirement with a plain `computed()` "to simplify" — that removes a capability the component actually needs, it doesn't simplify anything,
+- move a service to `providedIn: 'root'` or split it into a component-provided instance without evidence of the actual lifetime/sharing requirement — that is a behavioral change being requested as if it were a style fix,
+- expose a service's internal mutable signal directly (without `.asReadonly()` or an encapsulating method) "to save a line" — that removes the ownership boundary the review is meant to protect.
+
+That is not simplification. It is removing the guardrail the finding exists to establish.

package/skills/frontend/angular-architecture-signals-review/references/workflow-and-output.md

@@ -0,0 +1,99 @@
+# Review workflow and findings contract
+
+Use this reference for the full Signals-architecture review procedure and the required output shape.
+
+## What people get wrong
+
+The naive story is:
+
+> `effect()` is the reactive hook, so use it whenever a value should update when something else changes. `computed()` is just a lighter-weight version of the same idea.
+
+Wrong. Angular's own guidance draws a hard line: `computed()` is for **derived state** — it is lazily evaluated, memoized, and must be pure. `effect()` is for **syncing signal state to non-reactive, imperative APIs** (logging, `window.localStorage`, custom DOM behavior, third-party UI library integration) — not for propagating state changes between signals. Angular's docs are explicit that using effects to propagate state changes "can lead to `ExpressionChangedAfterItHasBeenChecked` errors, infinite circular updates, or unnecessary change detection cycles." Treating `effect()` as a generic "run this when that changes" tool, rather than checking whether the callback is actually a side effect on a non-reactive API, is the single most common Signals-architecture defect.
+
+The second most common mistake: assuming every component that hasn't adopted `ChangeDetectionStrategy.OnPush` is behind on best practice. Signals do not require OnPush to function correctly — they improve the precision of change detection either way. Recommending OnPush without checking whether the component relies on implicit mutation-based update paths (rather than signal reads, `async` pipe, or explicit `markForCheck()`) produces broken advice, not an optimization.
+
+## Source priority reminder
+
+Per the official Angular `angular-developer` skill (github.com/angular/skills), idiomatic modern Angular is Signals-first: prefer `signal`/`computed`/`linkedSignal`/`resource` for state, modern control flow (`@if`/`@for`/`@switch`), standalone components by default, and `inject()` + `providedIn: 'root'` for DI. The official skill also notes that Angular best practices vary significantly by version, so it analyzes the Angular version first — the same version-first discipline this workflow enforces in step 1. Treat that official skill (confirmed against the repo's pinned `angular_dev` major) as the authority on which primitive is idiomatic; use the rules below only to decide what to FLAG when code deviates.
+
+## Workflow
+
+1. **Confirm the Angular major version**
+   - Read `package.json` for the installed `@angular/core` version before evaluating any Signals-API claim (`linkedSignal`, `afterRenderEffect`, `@Service` decorator, `provideZonelessChangeDetection`) — these landed at different points across v16–v22.
+
+2. **Classify each reactive primitive in scope**
+   - `signal(...)` — mutable state.
+   - `computed(...)` — derived, read-only, must be pure, lazily evaluated and memoized per Angular's docs.
+   - `effect(...)` — side effect on a non-reactive API; requires an injection context.
+   - `linkedSignal(...)` — dependent, resettable derived state that can also be manually `.set()` (see `references/linked-signal-and-di-boundaries.md`).
+
+3. **Check `computed()` purity**
+   - Read every `computed()` callback. Flag any signal write, DOM mutation, HTTP call, or logging call inside it as a HIGH-severity purity violation — computed callbacks may re-run any number of times (or not at all, if never read) and must not have observable side effects.
+
+4. **Check whether each `effect()` is a genuine side effect**
+   - Ask: does this callback interact with a non-reactive, imperative API (DOM, storage, third-party library, logging)? If yes, it's a legitimate use.
+   - If the callback only computes a value and writes it into another signal with no other side effect, it is state propagation through an effect — recommend `computed()` (pure derivation) or `linkedSignal()` (derived-but-resettable state) instead, citing the specific Angular guidance against using effects for state propagation.
+   - Confirm the `effect()` call site has an injection context (component/directive/service constructor, or an explicit `Injector` in options). Flag a missing injection context as a correctness bug.
+   - Check for signal reads after an `await` inside the effect callback — the reactive context does not survive an async boundary, so those reads are untracked and the effect will not re-run when they change. Flag this as a correctness bug, not a style note.
+
+5. **Check change-detection strategy**
+   - Note whether each component in scope declares `changeDetection: ChangeDetectionStrategy.OnPush`.
+   - If a Signals-adopting component is still on the default strategy, check whether it relies on implicit mutation-based updates (direct property mutation observed via Zone.js, not signal reads or `async` pipe) that OnPush would silently break.
+   - If no such reliance is found, flag as a MEDIUM missed-performance-opportunity finding — not a defect.
+
+6. **Check service/DI boundaries**
+   - For services holding cross-cutting mutable state, confirm there is a documented (or at least inferable-from-code) ownership model: who writes, who reads, what the lifetime is.
+   - Do not prescribe a specific DI scope (`providedIn: 'root'` vs component-provided) without evidence of the actual sharing/lifetime requirement — see `references/linked-signal-and-di-boundaries.md` when this is in scope.
+
+7. **Produce ranked findings**
+   - Order by blast radius: correctness bugs (purity violations, missing injection context, untracked post-await reads, leaked secrets) first, then reactive-graph design defects (effect-as-computed misuse), then lower-severity notes (missed OnPush opportunity, DI-ownership documentation gaps).
+
+## Decision tree
+
+- `computed()` callback has **any side effect** (signal write, DOM mutation, HTTP call) → HIGH finding: purity-contract violation. Fix: move the side effect into an `effect()`, keep `computed()` pure.
+- `effect()` callback **only derives and stores** a value with no genuine side effect (no DOM/logging/storage/third-party sync) → MEDIUM finding: recommend `computed()` (if the value doesn't need manual override) or `linkedSignal()` (if it does).
+- `effect()` **reads a signal after an `await`** → HIGH finding: untracked dependency, effect will not re-run correctly.
+- `effect()` call site has **no resolvable injection context** → HIGH finding: correctness bug (Angular requires an injection context or explicit `Injector`).
+- Component uses **signal-based state but Default change-detection strategy**, and does **not** rely on implicit mutation-based updates → MEDIUM finding: missed OnPush opportunity, not a block.
+- Component uses **signal-based state but Default strategy**, and **does** rely on implicit mutation-based updates that OnPush would break → do not recommend OnPush without also flagging the mutation-based update paths that must be migrated first; treat as a scoped follow-up, not an inline fix.
+- Service holds cross-cutting mutable state with **no ownership model evident from the code** → LOW/MEDIUM finding: request explicit ownership documentation; do not prescribe a DI scope change without more evidence.
+
+## Output contract
+
+Return:
+
+1. Component(s)/service(s)/files in scope
+2. Ranked findings, each with:
+   - file:line evidence
+   - primitive-misuse category (purity violation / derivation-via-effect / injection-context error / untracked-post-await read / missed-OnPush-opportunity / DI-ownership gap)
+   - concrete fix sketch (e.g. "move to `computed()`", "add `Injector` option", "confirm no implicit-mutation reliance before adding OnPush")
+   - severity (HIGH / MEDIUM / LOW)
+   - evidence level (`repo evidence`, `documentation-based`, `inference`)
+3. Verdict: approve / approve-with-notes / block
+4. Open questions or explicitly out-of-scope items (e.g. zoneless migration recommendation excluded by design, unconfirmed Angular major version, SSR/hydration concerns deferred to `angular-ssr-hydration-review`)
+
+## Validation gates
+
+- Every Signals-semantics claim cites the version-matched Angular docs (via Context7 `query-docs` against the confirmed major, or `metadata.json` `official_docs` with an "unverified against current release" label if Context7 is unavailable).
+- Every "`computed()` must be pure" finding shows the specific side effect present in the callback — no bare assertion.
+- No finding recommends a blanket OnPush migration across the whole app in one review — scope findings to the files actually under review.
+- No finding recommends removing Zone.js or adopting `provideZonelessChangeDetection` — that is out of scope by design.
+
+## Common failure modes
+
+- Treating every `effect()` as wrong. `effect()` is correct for genuine side effects (logging, DOM sync, `localStorage` writes, third-party UI library integration) — Angular's docs list these as the intended use cases.
+- Missing that `linkedSignal` is intentionally different from `computed` — it exists specifically for resettable derived state that can also be manually overridden (e.g. a selected shipping option that resets when the options list changes but can also be user-set); do not flag `linkedSignal` usage as "should be `computed`" without checking whether manual override is a real requirement.
+- Assuming OnPush is always strictly better without checking for other change-detection triggers the component relies on — `async` pipe subscriptions and signal reads still work under OnPush, but manual property mutation observed only via Zone.js does not trigger a check under OnPush.
+- Recommending a DI-scope change (root vs component-provided) as a drive-by note without evidence of the actual lifetime/sharing requirement.
+
+## Adversarial checklist
+
+Before finalizing a finding, answer these:
+
+- Does any `computed()` callback perform a side effect (write, log, HTTP call, DOM mutation)?
+- Is an `effect()` actually necessary, or does it just compute-and-store a value that `computed()` (or `linkedSignal()`) should own?
+- Is the Signals-API claim (e.g. `linkedSignal` availability, `@Service` decorator) checked against this repo's actual Angular version, not assumed from the latest docs?
+- Would switching this component to OnPush break any implicit mutation-based update path it currently relies on?
+- Does the `effect()` read any signal after an `await`, silently breaking its reactive tracking?
+
+If any answer is "not sure," lower the finding's confidence and label the evidence level accordingly — do not present it as a confirmed defect.

package/skills/frontend/angular-ssr-hydration-review/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: angular-ssr-hydration-review
+description: Statically review Angular SSR bootstrap configuration and component templates for hydration-mismatch risk (NG0500-class errors), unjustified ngSkipHydration usage, and direct-DOM-manipulation patterns that bypass Angular's template-owned DOM model, grounded in Angular's own hydration guide and error catalog.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: architecture
+---
+
+# Angular SSR & Hydration Review
+
+## Purpose
+
+Review Angular server-side-rendered bootstrap configuration and component templates for hydration-mismatch risk without re-litigating Signals/change-detection architecture, RxJS-only legacy code, or a full zoneless-migration plan in every response. This skill exists so hydration correctness — whether the DOM Angular produces on the client actually matches the DOM the server sent, per Angular's own reconciliation model — stays a focused, verifiable review instead of a vague "SSR looks fine" pass.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review an SSR-enabled Angular app before or after enabling `provideClientHydration()`,
+- diagnose a reported flash-of-unstyled-content / re-render-on-load symptom consistent with a hydration mismatch,
+- assess whether a component's direct DOM manipulation is hydration-safe,
+- review existing `ngSkipHydration` usage for justification and tech-debt tracking,
+- confirm i18n-block hydration is correctly configured (`withI18nSupport()`).
+
+Do not use this skill for:
+
+- a purely client-rendered (non-SSR) Angular app with no SSR bootstrap/`provideClientHydration()` configuration — hydration concerns do not apply,
+- general Signals/change-detection/DI architecture review with no SSR dimension — use `angular-architecture-signals-review` instead.
+
+## Source priority (official Angular skills first)
+
+Consult sources in this fixed order, and label findings by which layer they draw from:
+
+1. **The official Angular team's `angular-developer` skill** ([github.com/angular/skills](https://github.com/angular/skills/tree/main/angular-developer)) is the AUTHORITATIVE primary source for idiomatic Angular SSR/hydration — `provideClientHydration()`, `withI18nSupport()`, `withEventReplay()`, incremental hydration, and template-driven (Angular-owned) DOM. Prefer its idioms over memory.
+2. **Context7 `angular_dev` docs** (`/websites/angular_dev`, or the version-pinned `/websites/v20_angular_dev`) confirm hydration-feature availability and the NG0500 mechanism against the repo's pinned `@angular/core` major (read `package.json` first) — hydration support landed and matured incrementally, so the official skill states the modern shape and the versioned docs confirm it applies to THIS repo's major.
+3. **This skill's static-review judgment** (hydration-mismatch detection, SSR-path-vs-browser-guarded classification, `ngSkipHydration` tech-debt rules, sanitization-bypass detection, pre-hydration accessibility checks) is the review layer applied ON TOP of 1 and 2.
+
+Where guidance conflicts: the official Angular `angular-developer` skill + version-matched `angular_dev` docs WIN on "what is idiomatic Angular" (correct hydration setup and the recommended fix shape). THIS skill governs "what to flag in review" (which DOM-mutation, `ngSkipHydration`, i18n, or sanitization patterns rise to a HIGH/MEDIUM finding and why). Never let this skill's flagging override an idiom the official skill and pinned docs endorse; conversely, an idiom being official does not exempt a concrete hydration-mismatch or sanitization-bypass defect from being flagged.
+
+## Context7 Documentation Protocol
+
+- Resolve the Angular library ID with `resolve-library-id` (matched result: `/websites/angular_dev` or the version-pinned `/websites/v20_angular_dev` when the repo's confirmed major is known) before citing any hydration-mechanism or error-code claim.
+- Before classifying a DOM-manipulation pattern as hydration-breaking, call `query-docs` against the repo's confirmed Angular major (read `package.json` — `@angular/core` — first) for `hydration`, `NG0500`, and `provideClientHydration`, and cite the doc section. The set of hydration-incompatible patterns is documented precisely by Angular (native `insertBefore`/`createElement`/`innerHTML`/`outerHTML` inside the reconciled tree) and is not safely inferable from general React/Vue hydration knowledge — the mechanisms differ.
+- If Context7 is unavailable, fall back to the `official_docs` URLs in this skill's `metadata.json` and label the claim `documentation-based, unverified against current release`.
+- Do not assume a hydration feature (`withI18nSupport`, `withEventReplay`, incremental hydration) is available or behaves identically across Angular majors without confirming the version — hydration support landed and matured incrementally.
+
+## Lean operating rules
+
+- First confirm SSR/hydration is actually configured: find `provideClientHydration(...)` in the bootstrap providers (`app.config.ts` / `main.server.ts` or equivalent). If it is absent, do not review the app as a hydration-mismatch problem — flag the larger finding that the app is not hydrating at all (full client remount on load), which is a different and more consequential issue than a mismatch.
+- Classify every native DOM API call found (`document.createElement`, `.insertBefore`, `.appendChild`, `.removeChild`, `innerHTML`, `outerHTML`, direct `ElementRef.nativeElement` mutation) by whether it executes inside an SSR-rendered code path or is guarded to browser-only execution. A call guarded by `isPlatformBrowser(...)` (or an equivalent browser-only lifecycle boundary) that only runs after hydration completes is not a hydration-mismatch risk — do not flag it as one.
+- Any native DOM mutation of a node inside the component's own reconciled template tree that runs during the SSR-rendered path is a hydration-mismatch risk matching Angular's documented NG0500 mechanism: Angular loses track of what the server actually rendered at that position and looks for the wrong node during reconciliation. Cite the specific call site and the specific NG0500 mechanism it matches — never assert "this may cause a mismatch" without naming the mechanism.
+- Never recommend `ngSkipHydration` as the fix for a hydration-mismatch finding. Angular's own guidance frames it as a last-resort/temporary workaround (e.g. for third-party DOM-manipulating libraries), not a solution — it causes the component and its children to skip reconciliation and re-render from scratch, which is exactly the SSR-defeating behavior the review exists to catch. The default fix recommendation is refactoring the mutation to be template-driven (Angular-owned DOM creation) or, when the mutation is genuinely display-only DOM Angular does not need to reconcile, isolating it behind a browser-only guard.
+- Treat every existing `ngSkipHydration` usage found in scope as a finding requiring a linked justification (comment or tracked issue reference). An unjustified `ngSkipHydration` is a MEDIUM tech-debt finding, not automatically a blocker — it silently disables hydration reconciliation for that component and its children with no record of why.
+- If the app renders i18n blocks (`i18n` template attributes, `$localize`) and hydration is enabled, confirm `withI18nSupport()` is present in the `provideClientHydration(...)` call per Angular's documented default (Angular skips hydration for i18n-block components without it, causing an unrecorded re-render-from-scratch). Flag its absence as a MEDIUM hydration finding.
+- SSR-rendered, pre-hydration content must remain accessible on its own — do not treat WCAG conformance as a post-hydration-only concern. If pre-hydration markup (what the server actually sends) drops accessible names, landmark structure, or focus order that the post-hydration DOM restores, flag it: users on slow connections or with assistive tech querying the DOM before hydration completes are affected by the pre-hydration state, not just the final one.
+- Treat any native DOM insertion of dynamic, user-influenced string content (`innerHTML`, `outerHTML`, or an equivalent native-API string-injection call) as a HIGH-severity finding on two independent axes simultaneously: the hydration-mismatch risk described above, and a bypass of Angular's built-in sanitization pipeline (Angular's template bindings sanitize `[innerHTML]`; direct native DOM API calls do not) — an XSS-class finding. Report both; do not fold one into the other or drop either.
+- Never execute, build, or run application code as part of this review; this is a static-review skill (Read/Grep/Glob only).
+
+## References
+
+Load these only when needed:
+
+- [Review workflow and findings contract](references/workflow-and-output.md) — use for the step-by-step review procedure, the SSR-rendered-vs-browser-guarded decision tree, and the required output shape.
+- [i18n, event replay, and third-party DOM libraries](references/i18n-event-replay-and-third-party-libs.md) — load only when the diff includes i18n blocks, `withEventReplay()` configuration, or a third-party library known to perform direct DOM manipulation (e.g. D3, chart libraries, non-Angular widget wrappers).
+
+## Response minimum
+
+Return, at minimum:
+
+- the component(s)/bootstrap file(s) in scope, and whether `provideClientHydration()` is confirmed present,
+- ranked findings with file:line evidence, hydration-mechanism category (SSR-path native DOM mutation / unjustified ngSkipHydration / missing i18n hydration support / pre-hydration accessibility gap / sanitization-bypass-plus-hydration-risk), and a concrete fix sketch defaulting to template-driven DOM per finding,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `inference`),
+- verdict (approve / approve-with-notes / block),
+- open questions or explicitly out-of-scope items (e.g. Signals/change-detection concerns deferred to `angular-architecture-signals-review`, hydration not configured at all so mismatch review does not apply).

package/skills/frontend/angular-ssr-hydration-review/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "angular-ssr-hydration-review",
+  "name": "Angular SSR & Hydration Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Angular SSR bootstrap configuration and component templates for hydration-mismatch risk (NG0500-class errors), unjustified ngSkipHydration usage, and direct-DOM-manipulation patterns that bypass Angular's template-owned DOM model, using Angular's own hydration guide and error catalog loaded progressively and grounded via Context7 against the repo's confirmed Angular version.",
+  "source_type": "original",
+  "official_docs": [
+    "https://github.com/angular/skills/tree/main/angular-developer",
+    "https://angular.dev/guide/hydration",
+    "https://angular.dev/errors/NG0500",
+    "https://angular.dev/api/platform-browser/provideClientHydration",
+    "https://www.w3.org/WAI/WCAG22/quickref/"
+  ],
+  "security_notes": "Direct DOM manipulation combined with dynamic string content (innerHTML-equivalent native calls) bypasses Angular's built-in sanitization pipeline -- treat any such pattern touching user-influenced data as an XSS-class finding, escalated to HIGH, in addition to the hydration-correctness finding. Static-review-only skill: it reads and greps bootstrap configuration and component source but never executes, builds, or runs application code.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/angular-ssr-hydration-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/angular-ssr-hydration-review/references/i18n-event-replay-and-third-party-libs.md

@@ -0,0 +1,50 @@
+# i18n, event replay, and third-party DOM libraries
+
+> Load this reference only when the diff under review includes i18n blocks, `withEventReplay()` configuration, or a third-party library known to perform direct DOM manipulation (e.g. D3, chart libraries, non-Angular widget wrappers).
+
+## What people get wrong
+
+The naive story on i18n:
+
+> Hydration is hydration — if `provideClientHydration()` is configured, every component hydrates, including ones using i18n blocks.
+
+Wrong. Angular's own hydration guide states its default plainly: "By default, Angular skips hydration for components using i18n blocks, causing them to re-render from scratch." `provideClientHydration()` alone does not cover i18n content — it requires the explicit `withI18nSupport()` feature. A review that confirms `provideClientHydration()` is present and stops there, without checking i18n-block components specifically, will miss that those components are silently falling back to full client re-render even though hydration "looks" enabled.
+
+The naive story on third-party libraries:
+
+> If a third-party library breaks hydration, that's a library bug — nothing to do at the integration layer except wait for a fix.
+
+Incomplete. Angular's own guidance names this exact class of problem and gives the sanctioned mitigation: "Third-party libraries that rely on direct DOM manipulation, such as D3 charts, might cause DOM mismatch errors with hydration enabled. If you encounter such issues, applying the `ngSkipHydration` attribute to the component rendering the library can serve as a workaround." This is the one context where `ngSkipHydration` is Angular's own documented recommendation — but it is still scoped as a workaround for a specific, named class of problem (uncontrolled third-party DOM manipulation), not a general-purpose fix for any hydration mismatch, including ones caused by the application's own code.
+
+## Source priority reminder
+
+Per the official Angular `angular-developer` skill (github.com/angular/skills), the idiomatic SSR/hydration setup is `provideClientHydration()` with the opt-in features (`withI18nSupport()`, `withEventReplay()`, incremental hydration) added as the app requires them, and DOM ownership kept template-driven. Treat that official skill (confirmed against the repo's pinned `angular_dev` major) as the authority on the correct hydration configuration and the recommended fix shape; use the rules below only to decide what to FLAG when code deviates.
+
+## i18n hydration review rules
+
+- Confirm `withI18nSupport()` is present in the `provideClientHydration(...)` call whenever the codebase uses `i18n` template attributes or `$localize` anywhere in scope. Its absence is a MEDIUM finding: those components silently re-render from scratch, which is a real (if less severe) SSR-benefit loss, not a hard error.
+- Do not assume `withI18nSupport()` is a no-op addition — confirm the Angular major version supports it (check `package.json` for `@angular/core`, then verify against Context7 `query-docs` for the confirmed version) before recommending it as a one-line fix.
+- If `withI18nSupport()` is present, do not separately flag i18n-block components as hydration-risky purely for using i18n — the feature exists specifically to make that safe.
+
+## Third-party DOM library review rules
+
+- When a component wraps a library known to perform direct DOM manipulation outside Angular's control (charting libraries, D3-based visualizations, non-Angular widget wrappers, map libraries), and that component shows an `ngSkipHydration` usage, treat the usage as the Angular-sanctioned workaround for this specific case — do not flag it with the same severity as an unjustified `ngSkipHydration` elsewhere in the app. Still require the justification comment/issue link (per the main workflow's tech-debt rule) so the workaround is tracked and revisited if the library adds hydration-safe integration later.
+- Do not recommend removing `ngSkipHydration` from a genuine third-party-DOM-manipulation component without first confirming the library itself no longer performs uncontrolled native DOM mutation in the version pinned in the repo — removing the guard prematurely reintroduces the exact NG0500-class mismatch it exists to prevent.
+- If a component wraps a third-party library but the library's DOM manipulation is confined to a container element genuinely outside Angular's reconciled tree (e.g. the library owns a `<div>` marked with `ngSkipHydration` and Angular does not attempt to reconcile anything inside it), do not also flag the library's internal DOM calls as separate hydration-mismatch findings — the `ngSkipHydration` boundary already scopes that correctly, per Angular's own guidance.
+- Distinguish a third-party library's DOM manipulation from the *hosting component's own* unguarded native DOM calls. `ngSkipHydration` on the wrapper does not excuse unrelated unguarded DOM manipulation the application's own code performs elsewhere in the same component outside the library-owned region — evaluate those against the main workflow's SSR-path rules independently.
+
+## Event replay review rules
+
+- `withEventReplay()` captures user interactions (clicks, and other supported native events) that occur before hydration completes and replays them once hydration finishes, per Angular's documented behavior. Its presence does not change hydration-mismatch risk — it changes interaction responsiveness during the hydration window. Do not conflate a missing `withEventReplay()` with a hydration-mismatch finding; it is a UX/responsiveness consideration, not a correctness one.
+- If incremental hydration is configured, note that event replay is automatically active per Angular's documented behavior — do not flag `withEventReplay()` as separately required in that configuration.
+- If the review scope includes a reported "clicks are lost/ignored right after page load" symptom (as opposed to a visual mismatch/flash symptom), treat that as a `withEventReplay()` gap, not an NG0500-class hydration-mismatch finding — the two symptom classes map to different mechanisms and different fixes.
+
+## When to push back
+
+Push back if the user asks to:
+
+- add `ngSkipHydration` to a component whose native DOM manipulation is the **application's own** unguarded code (not a third-party library boundary) "to make the error go away" — that suppresses the mismatch symptom while leaving the app fully re-rendering that component on every load, which is the outcome the review exists to prevent,
+- skip confirming `withI18nSupport()` because "hydration is already enabled" — the i18n feature is opt-in and separate from the base `provideClientHydration()` call, per Angular's own documented default,
+- treat every third-party-library `ngSkipHydration` usage as pre-approved without a justification link — the mitigation being Angular-sanctioned for this class of problem does not exempt it from the tracking requirement the main workflow applies to all `ngSkipHydration` usage.
+
+That is not a workaround. It is silently disabling the SSR benefit the review exists to protect.

package/skills/frontend/angular-ssr-hydration-review/references/workflow-and-output.md

@@ -0,0 +1,101 @@
+# Review workflow and findings contract
+
+Use this reference for the full SSR/hydration review procedure and the required output shape.
+
+## What people get wrong
+
+The naive story is:
+
+> Angular SSR just server-renders the HTML and then "boots up" on the client. Any DOM manipulation is fine as long as the app works.
+
+Wrong. Once `provideClientHydration()` is configured, Angular does not throw away and re-render the server-sent DOM — it **reconciles** against it, walking the existing DOM tree and matching it node-for-node against what the client-side render would have produced, then attaching event listeners and internal state to the existing nodes instead of replacing them. Angular's own error documentation is explicit about the failure mode: when a native DOM API creates or moves a node inside that reconciled tree, "Angular has no information about" the new node, so it looks for the wrong node at that position and throws a hydration mismatch (NG0500). Treating "the app still renders correctly in the end" as proof hydration is safe misses that Angular may have already thrown, logged an error, or silently fallen back to a client-side re-render of the affected subtree — defeating the SSR investment even when the visible symptom is subtle (a flash, a layout shift, a slower Largest Contentful Paint).
+
+The second common mistake: assuming a hydration review applies to any Angular app with server-rendering. It does not — SSR without `provideClientHydration()` configured still full-remounts on the client (Angular's pre-hydration behavior), so there is no reconciliation to break. Reviewing DOM-manipulation patterns as "hydration risks" in that context produces findings that don't apply; the actual finding is that the app isn't hydrating and is losing the SSR performance benefit entirely.
+
+## Workflow
+
+1. **Confirm hydration is actually configured**
+   - Search the bootstrap entry point (`app.config.ts`, `main.server.ts`, or equivalent `bootstrapApplication` call) for `provideClientHydration(...)` in the providers array.
+   - If absent, do not proceed with a mismatch-pattern review. Report the larger finding: SSR is configured but hydration is not, so the app fully re-renders client-side on every load. Stop the hydration-mismatch-specific checks; this is a different, higher-severity finding than any individual mismatch would be.
+   - Note the Angular major version from `package.json` (`@angular/core`) — hydration feature availability (`withI18nSupport`, `withEventReplay`, incremental hydration) differs by version.
+
+2. **Inventory native DOM API usage**
+   - Grep for `document.createElement`, `document.querySelector` combined with mutation, `.insertBefore`, `.appendChild`, `.removeChild`, `.replaceChild`, `innerHTML =`, `outerHTML =`, and direct `ElementRef.nativeElement` property/method access that mutates the DOM, across components, directives, and any structural (not purely cosmetic-class-toggle) DOM work.
+   - For each hit, capture the enclosing lifecycle hook or method (`ngOnInit`, `ngAfterViewInit`, a directive host binding, an event handler) — the lifecycle context determines whether the call can execute during the SSR-reconciled render path.
+
+3. **Classify each hit: SSR-path vs browser-guarded**
+   - If the call is wrapped in (or its containing method is only invoked from) an `isPlatformBrowser(...)` check, or is registered via `afterNextRender`/`afterRender` (Angular's documented browser-only render callbacks), and there is no reachable path for it to run during the reconciled initial render, classify it as **safe / post-hydration**. Do not flag it as a mismatch risk.
+   - If the call has no such guard and executes in a lifecycle hook that runs during SSR (e.g. unguarded `ngOnInit`, unguarded constructor logic), classify it as **SSR-path**. Continue to step 4.
+
+4. **Confirm the SSR-path hit actually touches the reconciled tree**
+   - Determine whether the mutated node is inside the component's own template-rendered subtree (the tree Angular reconciles) versus a node genuinely outside Angular's knowledge (e.g. a detached, never-inserted-into-the-DOM canvas element used purely as an offscreen buffer). Angular's own NG0500 example shows the failure mode precisely: inserting a native node as a sibling/child within the host element Angular is walking during reconciliation.
+   - If the mutated node is inside the reconciled tree → HIGH finding, cite the NG0500 mechanism, and check whether the mutation also injects dynamic/user-influenced string content (see the sanitization-bypass rule below).
+   - If the node is genuinely outside Angular's reconciled tree → not a hydration finding; note it only if relevant to a different concern (e.g. memory-leak risk from an unmanaged node).
+
+5. **Check for dynamic-content-plus-hydration double risk**
+   - If the flagged SSR-path native DOM mutation also sets `innerHTML`/`outerHTML` (or an equivalent native string-injection call) with data that is user-influenced (query params, form input, API response echoing user data, route params), report it as two findings: the hydration-mismatch finding from step 4, and a separate HIGH-severity sanitization-bypass finding — Angular's template bindings (`[innerHTML]`) sanitize by default, but direct native DOM API calls do not pass through that pipeline.
+
+6. **Audit existing `ngSkipHydration` usage**
+   - Grep for `ngSkipHydration` (as a host binding, template attribute, or `[ngSkipHydration]`/`host: {ngSkipHydration: 'true'}`).
+   - For each usage, look for an adjacent comment or a referenced tracked issue explaining why hydration is being skipped for that component. No justification → MEDIUM tech-debt finding. A justification tied to a known limitation (e.g. a third-party DOM-manipulating library — see `references/i18n-event-replay-and-third-party-libs.md`) → note it as acceptable but still worth a tracked-removal follow-up if the underlying library constraint might be resolved.
+
+7. **Check i18n hydration configuration**
+   - If the app uses `i18n` template attributes or `$localize`, confirm `withI18nSupport()` is present in the `provideClientHydration(...)` call. Its absence means i18n-block components silently skip hydration and re-render from scratch by Angular's documented default — flag as MEDIUM.
+
+8. **Check pre-hydration accessibility**
+   - Compare what the server actually sends (the pre-hydration markup) against what the fully-hydrated DOM exposes, for accessible names, landmark roles, and focus order on interactive elements in scope. If pre-hydration markup is missing accessibility structure that only appears after a client-side patch, flag it — assistive technology and slow-network users interact with the pre-hydration state, not just the final one.
+
+9. **Produce ranked findings**
+   - Order by blast radius: SSR-not-configured-at-all (if found in step 1, report this alone and stop), then SSR-path native DOM mutations touching the reconciled tree (HIGH, split into hydration + sanitization findings when both apply), then missing i18n hydration support and pre-hydration accessibility gaps (MEDIUM), then unjustified `ngSkipHydration` usage (MEDIUM tech-debt).
+
+## Decision tree
+
+- `provideClientHydration()` **absent** from bootstrap providers → single overriding finding: app is not hydrating, full client remount on every load. Stop mismatch-specific review.
+- Native DOM mutation **guarded to browser-only execution** (`isPlatformBrowser`, `afterNextRender`/`afterRender`) with no reachable SSR-path call → not a finding.
+- Native DOM mutation **runs during the SSR-rendered path** and **mutates a node inside the component's reconciled template tree** → HIGH finding: hydration-mismatch risk matching the NG0500 mechanism. Fix: refactor to template-driven DOM creation (bind the content through the template instead of imperative node insertion); do not recommend `ngSkipHydration` as the fix.
+- Same as above, **and** the mutation injects dynamic/user-influenced string content via `innerHTML`/`outerHTML` or equivalent → report both the HIGH hydration finding and a separate HIGH sanitization-bypass (XSS-class) finding.
+- `ngSkipHydration` present with **no linked justification** → MEDIUM finding: request a comment or tracked issue; do not treat presence alone as disqualifying.
+- i18n blocks present, hydration enabled, **`withI18nSupport()` absent** → MEDIUM finding per Angular's documented default behavior.
+- Pre-hydration markup **missing accessible structure** present only post-hydration → finding at a severity proportional to the affected interaction (focus-order or landmark loss on a primary interactive flow → HIGH; a secondary/decorative region → MEDIUM).
+
+## Output contract
+
+Return:
+
+1. Component(s)/bootstrap file(s) in scope, and whether `provideClientHydration()` is confirmed present (with file:line)
+2. Ranked findings, each with:
+   - file:line evidence
+   - hydration-mechanism category (SSR-path native DOM mutation / unjustified ngSkipHydration / missing i18n hydration support / pre-hydration accessibility gap / sanitization-bypass-plus-hydration-risk)
+   - concrete fix sketch defaulting to template-driven DOM (never `ngSkipHydration` as the fix)
+   - severity (HIGH / MEDIUM / LOW)
+   - evidence level (`repo evidence`, `documentation-based`, `inference`)
+3. Verdict: approve / approve-with-notes / block
+4. Open questions or explicitly out-of-scope items (e.g. Signals/change-detection concerns deferred to `angular-architecture-signals-review`, hydration not configured so mismatch review does not apply, unconfirmed Angular major version)
+
+## Validation gates
+
+- Every hydration-mismatch claim names the specific native DOM call and the specific NG0500 mechanism it matches, version-matched to the repo's confirmed Angular major — no bare "this may cause a mismatch."
+- Every `ngSkipHydration` finding states explicitly whether a justification (comment or tracked issue) is present.
+- No finding recommends `ngSkipHydration` as the resolution to a hydration-mismatch finding — the fix recommendation defaults to template-driven DOM refactoring.
+- No finding claims a mismatch "will happen" without confirming the mutation executes on the SSR-rendered path (not behind an `isPlatformBrowser`/`afterNextRender` guard).
+
+## Common failure modes
+
+- Flagging DOM manipulation that only executes inside an `isPlatformBrowser(...)` guard or an `afterNextRender`/`afterRender` callback as a hydration risk — those are Angular's documented browser-only execution points and do not participate in SSR reconciliation.
+- Missing that `provideClientHydration()` itself is entirely absent, and reviewing the app for mismatch patterns anyway — when hydration isn't configured, there's nothing to reconcile, and the real finding (full client remount, no SSR benefit realized) is larger and different from any individual mismatch.
+- Recommending `ngSkipHydration` as a fix rather than a last-resort workaround — it silently disables reconciliation for the component and its children, which is the SSR-defeating outcome the review exists to prevent.
+- Assuming WCAG/accessibility requirements apply only to the final, fully-hydrated DOM — the server-rendered, pre-hydration markup is what users on slow connections or assistive technology querying early actually receive.
+- Treating a hydration-mismatch finding and a sanitization-bypass finding as the same finding when both apply to one `innerHTML`-equivalent native call — they are independent risks (DOM-reconciliation correctness vs. XSS) and both must be reported.
+
+## Adversarial checklist
+
+Before finalizing a finding, answer these:
+
+- Is `provideClientHydration()` actually present in the bootstrap providers, or is "hydration" being reviewed on an app that never configured it?
+- Does the flagged native DOM manipulation occur inside an SSR-rendered code path, or is it guarded to browser-only execution (`isPlatformBrowser`, `afterNextRender`/`afterRender`)?
+- Does every `ngSkipHydration` usage in scope have a linked justification (comment or tracked issue)?
+- Is dynamic content ever inserted via a native `innerHTML`/`outerHTML`-equivalent call on user-influenced data — and if so, has both the hydration risk and the XSS risk been reported as separate findings?
+- Is the NG0500 mechanism claim matched to this repo's actual confirmed Angular version, not assumed from the latest docs?
+- Does the pre-hydration (server-sent) markup, not just the final hydrated DOM, retain the accessibility structure being evaluated?
+
+If any answer is "not sure," lower the finding's confidence and label the evidence level accordingly — do not present it as a confirmed defect.

package/skills/frontend/angular-template-sanitizer-security-review/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: angular-template-sanitizer-security-review
+description: Statically review Angular templates and components for injection via DomSanitizer bypass calls (bypassSecurityTrustHtml, bypassSecurityTrustUrl, bypassSecurityTrustResourceUrl), unsanitized [innerHTML] bindings, and dynamically bound iframe security attributes such as [attr.sandbox], grounded in Angular's own sanitizer and NG0910 documentation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-03"
+  category: security
+---
+
+# Angular Template Sanitizer Security Review
+
+## Purpose
+
+Review Angular templates, components, and their data-flow for the documented injection classes Angular's own sanitizer architecture is built to catch, and that are only unsafe when application code deliberately or accidentally routes around it: `DomSanitizer` bypass calls (`bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, `bypassSecurityTrustResourceUrl`) fed by user-reachable input, unsanitized `[innerHTML]` bindings, and dynamically bound iframe security attributes such as `[attr.sandbox]` that Angular's own NG0910 check exists to reject. This skill exists so the review stays anchored to these documented, concrete sinks instead of drifting into a general "Angular code review" — it does not re-litigate change detection, signals architecture, or component design in every response.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review whether a `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, or `bypassSecurityTrustResourceUrl` call is safe,
+- assess whether an `[innerHTML]` binding is safe,
+- review an `<iframe>` embed for a dynamically bound security attribute (`[attr.sandbox]`, `[sandbox]`, `[attr.allow]`, `[attr.credentialless]`) or an NG0910 error,
+- perform a pre-launch security review of Angular templates that render user- or third-party-supplied content.
+
+Do not use this skill for:
+
+- Angular architecture review with no security angle (signals usage, change-detection strategy, component decomposition quality) — use `angular-architecture-signals-review` instead,
+- SSR/hydration-specific defects (`TransferState` leakage, hydration mismatches) — use `angular-ssr-hydration-review` instead,
+- a bug that requires live traffic reproduction (a captured XSS payload in a running app, a browser-based exploit proof) to confirm exploitation — static analysis proves the structural risk, not that it has already been exploited in production.
+
+## Context7 Documentation Protocol
+
+- Resolve the Angular library ID with `resolve-library-id` (matched result: `/angular/angular`) before citing any sanitizer-mechanism or NG0910 claim.
+- `/angular/angular` is Angular's own source-and-docs repository (high reputation, corroborated against `packages/platform-browser/src/security/dom_sanitization_service.ts`, `packages/core/src/sanitization/html_sanitizer.ts`, `packages/core/src/render3/instructions/shared.ts`, and `adev/src/content/reference/errors/NG0910.md`). Use `query-docs` against it to confirm low-level sanitizer mechanics directly from source: that `bypassSecurityTrustHtml` (and its URL/resource-URL siblings) mark a value trusted so `sanitize()` skips the HTML/URL sanitizer and returns the value unchanged, that property bindings like `[innerHTML]` accept a compiler-added sanitizer function that only risky properties receive, and that text interpolation instead calls `renderer.setValue()` on a text node — a path that never parses HTML and needs no sanitizer.
+- Before flagging a `[attr.sandbox]`/`[sandbox]`/`[attr.allow]`/`[attr.credentialless]` binding, confirm Angular's own NG0910 check: these attributes are documented as required to be static (fixed at element-creation time) because they configure the iframe's security model before `src`/`srcdoc` load — a dynamic binding either throws NG0910 in dev or, if that check is suppressed, lets a runtime value weaken the sandbox.
+- Read the component's imports first to confirm `DomSanitizer` (from `@angular/platform-browser`) is actually in use before assuming a bypass call exists — do not assume a project uses the bypass APIs without confirming the import and call site.
+- If Context7 is unavailable, fall back to the `official_docs` URLs in this skill's `metadata.json` and label the claim `documentation-based, unverified against current release`.
+
+## Lean operating rules
+
+- Injection findings default to HIGH severity. This is a security-scoped skill: do not downgrade an untraced `bypassSecurityTrustHtml`/`bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` call or an unsanitized `[innerHTML]` binding to MEDIUM just because it has not been observed exploited yet — the risk is in the structure, not in whether someone has already hit it.
+- Trace every finding to a concrete file:line and a concrete data-flow path. A finding that says "this bypass call might be unsafe" or "this innerHTML might be risky" without showing the specific origin (route param, query string, request body, or a third-party API response that itself echoes user input) and the specific sink is not a valid finding — it is a guess.
+- Do not approve any `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, or `bypassSecurityTrustResourceUrl` call whose input includes user-reachable data unless the trace shows the value was validated or sanitized on that exact path before the bypass call — the bypass APIs are intentional escape hatches from Angular's compiler-driven sanitization, not accidental gaps, so their mere presence is not evidence of prior review.
+- Do not approve an `[innerHTML]` binding fed by user-reachable input unless a named sanitizer call (e.g., `DomSanitizer.sanitize(SecurityContext.HTML, ...)`, or a project-specific equivalent) is visibly present on that exact data-flow path. A sanitizer import existing elsewhere in the codebase does not clear this bar — trace the specific path under review.
+- Flag any `[attr.sandbox]`, `[sandbox]`, `[attr.allow]`, or `[attr.credentialless]` binding on an `<iframe>` as a finding regardless of whether NG0910 is currently thrown in the reviewed environment — a suppressed or bypassed dev-mode check does not make the underlying dynamic-security-attribute pattern safe in production.
+- Check dynamic `[href]`/`[src]` bindings fed through `bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` for scheme validation (an allowlist rejecting `javascript:` and other non-`http(s)` schemes) on the traced path before the bypass call — the bypass call itself performs no validation.
+- Never execute, build, or run application code, and never send live requests, as part of this review; this is a static-review skill (Read/Grep/Glob only).
+- Load only the reference needed for the concern in scope.
+
+## References
+
+Load these only when needed:
+
+- [Review workflow and findings contract](references/workflow-and-output.md) — use for the step-by-step review procedure, the sanitizer-bypass/innerHTML/iframe decision tree, and the required output shape.
+- [DomSanitizer bypass calls and innerHTML](references/sanitizer-bypass-and-innerhtml.md) — load only when the review scope includes a `bypassSecurityTrustHtml`/`bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` call or an `[innerHTML]` binding. Includes the OWASP XSS grounding reference; load that citation only when a finding is actually present.
+- [Dynamic iframe security attributes](references/iframe-security-attributes.md) — load only when the review scope includes an `<iframe>` element with a bound `sandbox`, `allow`, or `credentialless` attribute, or a reported NG0910 error.
+
+## Response minimum
+
+Return, at minimum:
+
+- the component(s), template binding(s), and/or `DomSanitizer` call site(s) in scope,
+- ranked findings with file:line evidence, defect category (`xss`, `url-injection`, or `iframe-sandbox-escape`), the concrete data-flow trace (origin-to-sink path naming every hop), and a fix sketch matching Angular's documented pattern,
+- for every bypass call or `[innerHTML]` finding, an explicit statement of whether validation or sanitization is present on the traced path — never approve on the assumption one exists elsewhere,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `inference`), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited,
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., "confirming actual exploitation requires a live payload test in a running browser session, not static review").

package/skills/frontend/angular-template-sanitizer-security-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "angular-template-sanitizer-security-review",
+  "name": "Angular Template Sanitizer Security Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Angular templates and components for injection via DomSanitizer bypass calls (bypassSecurityTrustHtml, bypassSecurityTrustUrl, bypassSecurityTrustResourceUrl), unsanitized [innerHTML] bindings, and dynamically bound iframe security attributes such as [attr.sandbox], grounding claims via Context7 and Angular's own sanitizer and NG0910 documentation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://angular.dev/best-practices/security",
+    "https://angular.dev/errors/NG0910",
+    "https://owasp.org/www-project-top-ten/",
+    "https://owasp.org/www-community/attacks/xss/"
+  ],
+  "security_notes": "This skill's entire scope is security-critical: DomSanitizer bypass calls and unsanitized [innerHTML] bindings are XSS vectors, and dynamically bound iframe security attributes are a sandbox-escape vector Angular's own NG0910 check exists to reject. Every finding defaults to HIGH severity unless proven otherwise with concrete validation/sanitizer evidence on the traced path. Static-review-only skill: it reads and greps components and templates but never executes, builds, or runs application code, and never sends live requests.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/angular-template-sanitizer-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/angular-template-sanitizer-security-review/references/iframe-security-attributes.md

@@ -0,0 +1,63 @@
+# Dynamic Iframe Security Attributes
+
+Use this reference only when the review scope includes an `<iframe>` element with a bound `sandbox`, `allow`, `credentialless`, `csp`, `referrerPolicy`, or `fetchPriority` attribute, or a reported NG0910 error.
+
+## What people get wrong
+
+The naive assumption is:
+
+> "Angular throws NG0910 if I bind these attributes dynamically, so if my app runs without that error, my iframe binding must be fine."
+
+Wrong in two ways. First, the check can be suppressed or not exercised in the exact code path under review (a conditional branch not hit during development, or an older Angular version without the check). Second, even when the error is correctly thrown and "fixed" by refactoring around it, the underlying intent — a *dynamic*, potentially user-influenced sandbox/allow value — is still the actual security concern, independent of whether the specific Angular version enforces it at compile/runtime.
+
+## Officially grounded rules
+
+Angular's own documentation (`documentation-based`, `adev/src/content/reference/errors/NG0910.md`, confirmed via Context7 `/angular/angular`) states directly:
+
+- **Angular throws NG0910 when it detects a binding on specific security-related `<iframe>` attributes**: `sandbox`, `allow`, `allowFullscreen`, `referrerPolicy`, `csp`, `fetchPriority`, or `credentialless`. These attributes configure the iframe's security model and must be applied before the `src`/`srcdoc` attributes load content, so Angular requires them to be static — their values fixed at element-creation time and never bound as a property (`[sandbox]="..."`) or attribute (`[attr.sandbox]="..."`) binding, including via a directive's host bindings.
+- **The recommended fix is a static attribute**, e.g. `sandbox="allow-scripts"`, or Angular's `@if`/`@switch` control-flow blocks to conditionally render entire `<iframe>` elements with different static attribute values, rather than binding the attribute's value dynamically on one persistent element.
+
+## Non-negotiable design rules
+
+### 1. Flag the pattern regardless of whether NG0910 currently fires
+
+A dynamically bound security-sensitive iframe attribute is the finding — not the NG0910 error message itself. If the error is suppressed (an older Angular version, a downgraded compiler check, or code that technically avoids triggering the exact check Angular implements) but the underlying dynamic-binding pattern is present, it is still a finding: the sandbox's actual value can still be influenced by whatever expression it is bound to.
+
+### 2. Check reachability of the bound expression
+
+A `[attr.sandbox]` bound to a hardcoded, non-configurable constant expression evaluated once at compile time is a lower-severity finding (still worth fixing for forward-compatibility with future Angular checks) than one bound to a value that traces back to user-reachable input (a query parameter, a per-tenant config value editable by end users, or similar) — the latter is a HIGH finding because an attacker-influenced value can directly weaken the iframe sandbox.
+
+### 3. Use static attributes or conditional rendering, not dynamic binding
+
+The correct fix is either a static attribute value or Angular's `@if`/`@switch` blocks rendering distinct `<iframe>` elements per case — not attempting to bind the attribute dynamically through a workaround (e.g., manual DOM manipulation via `ElementRef` to set the attribute outside Angular's binding system), which reintroduces the same risk outside Angular's own safety check.
+
+## Minimal safe implementation pattern
+
+```html
+<!-- Static attribute, fixed at element-creation time. -->
+<iframe sandbox="allow-scripts" [src]="trustedEmbedUrl"></iframe>
+```
+
+```html
+<!-- Conditional rendering of distinct static configurations. -->
+@if (isTrustedPartner) {
+  <iframe sandbox="allow-scripts allow-same-origin" [src]="trustedEmbedUrl"></iframe>
+} @else {
+  <iframe sandbox="allow-scripts" [src]="trustedEmbedUrl"></iframe>
+}
+```
+
+Anti-pattern (dynamic binding — do not approve):
+
+```html
+<!-- userSandbox may originate from a per-tenant config value; even if
+     NG0910 is not currently thrown in this environment, the sandbox's
+     effective value can be influenced by that input at runtime. -->
+<iframe [attr.sandbox]="userSandbox" [src]="trustedEmbedUrl"></iframe>
+```
+
+## Verification targets
+
+- Grep `<iframe>` elements for `[sandbox]`, `[attr.sandbox]`, `[allow]`, `[attr.allow]`, `[credentialless]`, `[attr.credentialless]`, `[csp]`, `[attr.csp]`, `[referrerPolicy]`, `[attr.referrerPolicy]`, `[fetchPriority]`, and `[attr.fetchPriority]`.
+- For each match, trace the bound expression backward to determine whether it is a fixed compile-time constant or reachable from user-influenced input (query params, tenant config editable by end users, form state).
+- Grep for `ElementRef`-based manual attribute manipulation on iframe elements, which can reintroduce the same dynamic-binding risk outside Angular's compiler-enforced static-attribute check.