@raishin/vanguard-frontier-agentic 3.0.1 → 3.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@raishin/vanguard-frontier-agentic",
-  "version": "3.0.1",
+  "version": "3.1.0",
   "description": "Cloud and zero-trust agentic workflow marketplace for skills, agents, rules, MCP references, and compliance-aware architecture.",
   "license": "Apache-2.0",
   "repository": {
@@ -61,6 +61,7 @@
     "validate:finops-fixtures": "python3 tests/validate-finops-price-fixtures.py",
     "validate:readme-counts": "node tests/validate-readme-counts.mjs",
     "validate:qa-cluster": "node tests/eval-qa-cluster.mjs",
+    "validate:frontend-security-detection": "python3 tests/validate-frontend-security-detection.py",
     "readme-counts:write": "node scripts/generate-readme-counts.mjs",
     "test:marketplace-validators": "python3 tests/test-marketplace-validators.py",
     "maestro-routing:write": "python3 tests/_generate_maestro_routing_fixtures.py",
@@ -73,7 +74,7 @@
     "test:gemini-bundling": "python3 tests/test-gemini-skill-bundling.py",
     "test:cursor-kiro-notices": "node tests/export-cursor-kiro-skill-notice.test.mjs",
     "test:fuzz": "node tests/fuzz-properties.test.mjs",
-    "validate": "npm run validate:catalog && npm run validate:aws && npm run manifest:check && npm run validate:allowed-tools && npm run validate:skill-schema && npm run validate:agent-schema && npm run validate:links && npm run validate:asset-integrity && npm run validate:mcp-trust-matrix && npm run validate:no-lifecycle-scripts && npm run validate:promotion-gatekeeper && npm run validate:install-coverage && npm run validate:maestro-routing && npm run validate:plugin-manifest && npm run validate:kiro-powers && npm run validate:multi-harness-marketplace && npm run validate:codex-marketplace && npm run validate:finops-fixtures && npm run validate:readme-counts && npm run validate:qa-cluster",
+    "validate": "npm run validate:catalog && npm run validate:aws && npm run manifest:check && npm run validate:allowed-tools && npm run validate:skill-schema && npm run validate:agent-schema && npm run validate:links && npm run validate:asset-integrity && npm run validate:mcp-trust-matrix && npm run validate:no-lifecycle-scripts && npm run validate:promotion-gatekeeper && npm run validate:install-coverage && npm run validate:maestro-routing && npm run validate:plugin-manifest && npm run validate:kiro-powers && npm run validate:multi-harness-marketplace && npm run validate:codex-marketplace && npm run validate:finops-fixtures && npm run validate:readme-counts && npm run validate:qa-cluster && npm run validate:frontend-security-detection",
     "release:sbom": "command -v syft >/dev/null 2>&1 && syft scan dir:. -o spdx-json=sbom.spdx.json || echo 'syft not installed; SBOM is generated in CI by anchore/sbom-action'",
     "lint:md": "npx --yes markdownlint-cli2 \"**/*.md\" \"#node_modules\" \"#.git\" \"#.code-review-graph\" \"#CHANGELOG.md\"",
     "lint:spell": "codespell",

package/plugins/vanguard-frontier-agentic/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vanguard-frontier-agentic",
-  "version": "3.0.1",
+  "version": "3.1.0",
   "description": "Curated marketplace for cloud and zero-trust AI workflows. 331 agents, 286 skills, and rules across AWS, Azure, OCI, GCP, Alibaba Cloud, Huawei Cloud, Kubernetes, and Terraform.",
   "author": {
     "name": "Raishin",

package/powers/README.md

@@ -1,6 +1,6 @@
 # `powers/` — Kiro Powers
 
-This directory holds **39 Kiro Powers** for `vanguard-frontier-agentic`, one
+This directory holds **40 Kiro Powers** for `vanguard-frontier-agentic`, one
 per cloud/platform/IaC provider. Each Power is a directory containing a
 `POWER.md` file with strict-5 frontmatter and steering content.
 
@@ -22,6 +22,7 @@ powers/
 ├── vanguard-falco/POWER.md
 ├── vanguard-finance/POWER.md
 ├── vanguard-fluxcd/POWER.md
+├── vanguard-frontend/POWER.md
 ├── vanguard-gcp/POWER.md
 ├── vanguard-generic/POWER.md
 ├── vanguard-hetzner/POWER.md
@@ -83,7 +84,7 @@ cd vanguard-frontier-agentic
 ## How to update
 
 ```bash
-# Regenerate the 39 Powers from catalog/agents.json + per-provider config:
+# Regenerate the 40 Powers from catalog/agents.json + per-provider config:
 npm run kiro-powers:write
 
 # Then verify everything is in sync:

package/powers/vanguard-frontend/POWER.md

@@ -0,0 +1,42 @@
+---
+name: "vanguard-frontend"
+displayName: "Vanguard Frontier — Frontend"
+description: "Curated frontend and web development agents for component architecture, accessibility, performance, testing, and security posture — static review only, no live builds, deploys, or dependency mutations. Routes via frontend-maestro to specialist agents. Framework, bundler, and testing-tool surfaces are drift-prone; agents always verify against current official documentation before rendering findings."
+keywords: ["frontend", "web", "react", "vue", "accessibility", "performance", "testing", "static-review"]
+author: "Raishin"
+---
+# Vanguard Frontier — Frontend
+
+Curated frontend and web development agents for component architecture, accessibility, performance, testing, and security posture — static review only, no live builds, deploys, or dependency mutations. Routes via frontend-maestro to specialist agents. Framework, bundler, and testing-tool surfaces are drift-prone; agents always verify against current official documentation before rendering findings.
+
+## When to engage this Power
+
+Activate when the task references Frontend services, resources, or operations. Do not activate on unrelated requests — narrow keyword matching is required to avoid false activations (Kiro Powers convention).
+
+## Routing pattern
+
+- **`frontend-maestro-agent`** — classifies and routes the task to the right specialist
+
+Use the maestro as the entry point: classify the task, then dispatch to one specialist or a parallel team of specialists. Never have the maestro itself execute a live mutation.
+
+## Live-guard agents (gate_mode only)
+
+- *(none — this provider has no live-mutation guards in the catalog)*
+
+Live-guard agents enforce approval, target confirmation, evidence capture, and rollback plans before executing a mutation. They are never auto-dispatched — the maestro must place them in `live-guard-gate` or `runtime-evidence-gate` mode.
+
+## Invariants
+
+- Static review only — agents never request API keys, auth tokens, or customer data, and never run live build, deploy, or dependency-mutation commands.
+- Route all tasks through frontend-maestro for proper classification and dispatch to specialist agents.
+- Review covers framework/component architecture, accessibility (WCAG) compliance, performance budgets, test coverage, and supply-chain integrity.
+- Production-impacting actions (deploys, dependency upgrades, build-config changes) are live-guard gated — never auto-dispatched; require explicit approval and rollback plan.
+
+## Where the agents live
+
+Agent specs and adapters are part of the [Vanguard Frontier Agentic](https://github.com/Raishin/vanguard-frontier-agentic) marketplace. For this provider, see `agents/frontend/` in that repository. All 35 agents in this provider ship a Kiro adapter (`harnesses/kiro-ide.agent.md`, `kiro-cli.agent.json`).
+
+## Companion install paths
+
+- **Claude Code:** `/plugin marketplace add Raishin/vanguard-frontier-agentic` then `/plugin install vanguard-frontier-agentic@vanguard-frontier-agentic`
+- **Codex / Copilot / Cursor / Gemini CLI / Kiro (file export):** `npx vfa-export-agents --platform <harness> --provider frontend --repo .`

package/schemas/agent.schema.json

@@ -50,6 +50,7 @@
         "terraform",
         "multi-cloud",
         "generic",
+        "frontend",
         "dotnet",
         "hr",
         "legal",

package/schemas/skill.schema.json

@@ -43,6 +43,7 @@
         "terraform",
         "multi-cloud",
         "generic",
+        "frontend",
         "dotnet",
         "hr",
         "legal",

package/scripts/generate-docs-data.mjs

@@ -55,6 +55,7 @@ const taxonomy = [
   { category: 'Observability', providers: ['opentelemetry', 'prometheus'] },
   { category: 'Infrastructure as Code', providers: ['terraform'] },
   { category: 'AI & Compute', providers: ['nvidia'] },
+  { category: 'Frontend & Web', providers: ['frontend'] },
   { category: 'Developer Platforms', providers: ['backstage', 'dotnet', 'generic', 'multi-cloud'] },
   { category: 'ERP & Finance', providers: ['netsuite', 'accounting', 'finance', 'sap'] },
   { category: 'Business Functions', providers: ['salesforce', 'legal', 'hr', 'marketing'] },

package/scripts/generate-kiro-powers.mjs

@@ -244,6 +244,18 @@ const PROVIDERS = {
       "Production grant/role/policy/cluster changes are live-guard gated — never auto-dispatched; require explicit approval, scope confirmation, and rollback plan.",
     ],
   },
+  frontend: {
+    displayName: "Vanguard Frontier — Frontend",
+    description:
+      "Curated frontend and web development agents for component architecture, accessibility, performance, testing, and security posture — static review only, no live builds, deploys, or dependency mutations. Routes via frontend-maestro to specialist agents. Framework, bundler, and testing-tool surfaces are drift-prone; agents always verify against current official documentation before rendering findings.",
+    keywords: ["frontend", "web", "react", "vue", "accessibility", "performance", "testing", "static-review"],
+    invariants: [
+      "Static review only — agents never request API keys, auth tokens, or customer data, and never run live build, deploy, or dependency-mutation commands.",
+      "Route all tasks through frontend-maestro for proper classification and dispatch to specialist agents.",
+      "Review covers framework/component architecture, accessibility (WCAG) compliance, performance budgets, test coverage, and supply-chain integrity.",
+      "Production-impacting actions (deploys, dependency upgrades, build-config changes) are live-guard gated — never auto-dispatched; require explicit approval and rollback plan.",
+    ],
+  },
   snowflake: {
     displayName: "Vanguard Frontier — Snowflake (Azure)",
     description:

package/scripts/update-catalog-new-agents.py

@@ -14,7 +14,7 @@ CATALOG_SKILLS = ROOT / "catalog" / "skills.json"
 CATALOG_FIELDS_AGENT = {
     "id", "name", "type", "provider", "summary", "path",
     "harnesses", "last_verified", "official_docs", "security_notes",
-    "source_type", "version",
+    "source_type", "version", "companion_skills",
 }
 CATALOG_FIELDS_SKILL = CATALOG_FIELDS_AGENT | {"author"}
 
@@ -26,6 +26,11 @@ def metadata_to_catalog_entry(m: dict, kind: str) -> dict:
                 "last_verified", "path", "version"):
         if key in m:
             entry[key] = m[key]
+    # Preserve agent→skill edges so catalog consumers (e.g. the TUI dependency
+    # graph, which reads catalog/agents.json directly) see the same companion
+    # linkage as the adjacent metadata.json.
+    if kind == "agent" and "companion_skills" in m:
+        entry["companion_skills"] = m["companion_skills"]
     # Normalise path — strip trailing slash
     if "path" in entry and isinstance(entry["path"], str):
         entry["path"] = entry["path"].rstrip("/")

package/skills/frontend/ai-generated-frontend-code-review/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: ai-generated-frontend-code-review
+description: Apply an elevated review pass to AI or LLM-generated frontend code changes, checking specifically for hallucinated framework APIs, slopsquatted or non-existent dependency names, unsanitized dynamic-HTML sinks, and missing accessibility semantics before the diff is merged.
+allowed-tools: Read Grep Glob WebFetch WebSearch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: ai
+---
+
+# AI-Generated Frontend Code Review
+
+## Purpose
+
+AI-generated frontend code fails in ways human-authored code rarely does at the same volume: it invokes framework APIs that read as idiomatic but do not exist for the project's installed version, it proposes installing packages whose names sound plausible but are not on the real registry (a slopsquat vector an attacker can pre-register), and it reproduces visually-correct interactive markup that is semantically empty because visual training signal does not capture keyboard/ARIA behavior. A diff that compiles and looks right is not evidence any of this was checked. This skill exists to apply a specifically elevated, adversarial bar to generated diffs — treating "the code compiles" and "this looks like normal code" as exactly zero evidence of correctness or safety — rather than folding AI-origin code into a generic review pass where these failure modes go unchecked.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a pull request or diff known or suspected to be AI/LLM-generated before merge,
+- verify that framework or library APIs used in generated code actually exist and behave as claimed for the project's installed version,
+- check newly introduced dependency names in a lockfile/manifest diff for registry legitimacy before install is approved,
+- audit generated interactive components (menus, modals, tabs, forms, comboboxes) for missing accessibility semantics.
+
+Do not use this skill for:
+
+- a general code-quality or architecture review with no AI-origin signal and no hallucination/slopsquat/sink/a11y concern — use the relevant framework-specific review skill instead,
+- confirming a dependency is not just spelled correctly but is also free of known CVEs — that is a separate supply-chain vulnerability scan, not a name-legitimacy check,
+- live penetration testing of a confirmed unsanitized sink — this is a static-review skill; escalate confirmed exploitable sinks to a live security review process.
+
+## Context7 Documentation Protocol
+
+- Resolve each in-scope framework/library's Context7 ID with `resolve-library-id` before accepting or rejecting any API call in the diff as real (React: `/reactjs/react.dev` or `/websites/react_dev_reference`; use the equivalent resolved ID for other frameworks in scope). Read the project's actual manifest (`package.json` and lockfile) first to pin the installed major version — an API that exists in one major version and not another is exactly the kind of claim generated code gets wrong.
+- Query Context7 for the specific hook, component prop, lifecycle method, or utility function named in the diff. If Context7 returns no matching API for that name/signature, treat the call as `unverified — possible hallucination`, not as a minor style note; do not assume the API exists because it "sounds like something React/Vue/Angular would have."
+- For dependency-registry legitimacy, Context7 is not authoritative — it indexes documentation, not registry existence. Ground every new-dependency check in a live registry lookup (npm registry, JSR, or the ecosystem's canonical registry) via `WebFetch`/`WebSearch`, and label the result `registry-verified` or `registry-lookup-failed / could not verify`, never `documentation-based`.
+- For accessibility semantics, Context7 does not reliably index the W3C ARIA Authoring Practices Guide as a queryable library; ground every ARIA pattern claim directly in the `official_docs` URL for the APG in this skill's `metadata.json` and label it `documentation-based`.
+- If Context7 is unavailable for a framework in scope, fall back to the framework's official docs URL and label every API claim `documentation-based, unverified against current release` rather than answering from training-data memory alone.
+
+## Lean operating rules
+
+- Treat "this compiles" and "this looks like normal, idiomatic code" as zero evidence of correctness. Every non-trivial framework/library API call newly introduced in the diff must be checked against Context7 or the framework's official docs for the project's actual installed version before it is accepted as real.
+- Check every newly introduced package name in a lockfile or manifest diff against the real public registry before approving the change. A name that "sounds right" and does not resolve on the registry, or resolves to an unrelated/typosquat-shaped package, is a slopsquat risk to flag — not a typo to silently correct and move past.
+- Flag every `dangerouslySetInnerHTML`, `innerHTML` assignment, `v-html`, `document.write`, or equivalent dynamic-HTML sink newly introduced in the diff. For each, trace whether the value can carry attacker- or user-controlled data and verify a sanitizer is actually applied on that path — a sink with no traced taint source is a lower-severity pattern-only note, not a confirmed finding, and the distinction must be stated explicitly.
+- Check every new interactive component (menu, modal, tabs, combobox, disclosure, tooltip) against the relevant W3C ARIA Authoring Practices Guide pattern for required role, keyboard operability, and focus management. Do not assume visual/DOM-structure correctness implies semantic correctness — AI-generated markup routinely nails the visual layout while omitting `role`, `aria-*` state, or keyboard handlers entirely.
+- Do not lower the review bar because the change is "just AI-generated boilerplate" or because the diff is small. Apply the same or higher scrutiny than human-authored code, precisely because these four failure modes are systematically more likely in generated output than in it.
+- Load `references/hallucinated-api-verification.md` only when verifying a specific framework/library API claim in the diff.
+- Load `references/slopsquat-dependency-check.md` only when the diff introduces a new package dependency.
+- Load `references/generated-a11y-gap-audit.md` only when the diff introduces or modifies an interactive component.
+
+## References
+
+Load these only when needed:
+
+- [Hallucinated API verification](references/hallucinated-api-verification.md) — use to check whether a framework/library API used in generated code actually exists and behaves as claimed for the project's installed version, and how to classify the result when it does not.
+- [Slopsquat dependency check](references/slopsquat-dependency-check.md) — use whenever the diff introduces a new package dependency, to verify registry legitimacy and typosquat/slopsquat risk before install is approved.
+- [Generated accessibility gap audit](references/generated-a11y-gap-audit.md) — use when reviewing new or modified interactive components generated by AI, to check for missing keyboard operability and ARIA semantics against the APG.
+
+## Response minimum
+
+Return, at minimum:
+
+- a per-finding verdict (`hallucinated-api` / `slopsquat-risk` / `unsanitized-sink` / `a11y-gap` / `clean`) tied to a specific file and line,
+- the Context7 or official-doc citation backing each API-existence claim, or an explicit `unverified — possible hallucination` label when none is found,
+- the registry-verification result for every newly introduced dependency (`registry-verified` with resolved package/publisher, or `registry-lookup-failed / could not verify`),
+- a prioritized fix list ordered by security/correctness severity (unsanitized sinks and hallucinated APIs before a11y gaps before style),
+- an explicit statement that the review bar applied was equal to or higher than the standard human-authored-code bar, plus what remains to be manually confirmed (e.g., live exploitability of a traced sink requires a controlled security review, not static review).

package/skills/frontend/ai-generated-frontend-code-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "ai-generated-frontend-code-review",
+  "name": "AI-Generated Frontend Code Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Applies an elevated review pass specifically to AI/LLM-generated frontend diffs, checking for hallucinated framework APIs, slopsquatted dependency names, unsanitized dynamic-HTML sinks, and missing accessibility semantics — the failure patterns unique to generated-but-plausible-looking code — before merge.",
+  "source_type": "original",
+  "official_docs": [
+    "https://owasp.org/www-project-top-10-for-large-language-model-applications/",
+    "https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html",
+    "https://www.w3.org/WAI/ARIA/apg/",
+    "https://react.dev/reference/rules"
+  ],
+  "security_notes": "Treat all AI-generated code as untrusted input requiring verification, not a lower-scrutiny fast path. Check every new dependency name against the real package registry before approving install (slopsquat defense). Check every dynamic-HTML sink for sanitization. Never execute exploit payloads against live/staging systems; static-review-only skill (Read/Grep/Glob/WebFetch/WebSearch, no mutation, no live target traffic). Never reproduce discovered secrets/tokens verbatim in findings output.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/ai-generated-frontend-code-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/ai-generated-frontend-code-review/references/generated-a11y-gap-audit.md

@@ -0,0 +1,55 @@
+# Generated Accessibility Gap Audit
+
+Use this reference when a diff introduces or modifies an interactive component — a menu, modal/dialog, tabs, combobox, disclosure, tooltip, accordion, or custom form control — and the component's origin is AI/LLM-generated or suspected to be.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "It looks and behaves correctly in a mouse-driven click-through, so it's accessible."
+
+That is incomplete, and it is the specific gap generated frontend code falls into systematically. Models trained heavily on visual/structural patterns reproduce a component's DOM shape and CSS with high fidelity — divs, click handlers, conditional rendering, styling — because that is the dense part of the training signal. Keyboard operability, focus management, and ARIA state are comparatively sparse and easy to omit while still producing something that *looks* like a working component in a quick visual check. A generated `<div onClick={...}>` styled to look exactly like a button, with no `role="button"`, no `tabIndex`, no `onKeyDown` for Enter/Space, and no focus-visible state, passes every visual QA pass and fails every keyboard/screen-reader user.
+
+## Officially grounded shape (W3C ARIA Authoring Practices Guide)
+
+The APG defines, per widget pattern, the required:
+
+- **role** — the ARIA role (or correct native HTML element) that identifies the widget's semantic type to assistive technology,
+- **keyboard interaction** — the specific key bindings required for that pattern (e.g., a menu requires Arrow Up/Down to move focus among items, Escape to close, Enter/Space to activate; a tabs widget requires Arrow Left/Right to move between tabs and typically automatic or manual activation),
+- **focus management** — where focus moves on open/close/activation (e.g., a modal must trap focus within itself while open and restore focus to the triggering element on close),
+- **required states/properties** — the ARIA attributes that communicate current state (`aria-expanded`, `aria-selected`, `aria-checked`, `aria-haspopup`, `aria-controls`, `aria-activedescendant`, etc., depending on pattern).
+
+Do not treat these as optional polish. A component missing any of the four is not "mostly accessible" — it is non-operable for keyboard-only and screen-reader users for that specific interaction.
+
+## Non-negotiable audit rules
+
+1. **Identify the correct APG pattern first.** Match the component to its specific APG pattern (menu vs. menubar vs. listbox vs. combobox are not interchangeable) before auditing — applying the wrong pattern's checklist produces false passes and false negatives.
+2. **Test keyboard operability by tracing code, not by assuming it from visual markup.** Confirm there is an actual `onKeyDown`/`onKeyUp` handler (or native element providing it for free) implementing every key binding the APG pattern requires — a component with only `onClick` is not keyboard-operable regardless of how it looks.
+3. **Verify focus management explicitly for overlay patterns.** For any modal, dialog, or popover pattern, confirm: focus moves into the overlay on open, focus is trapped within it while open, and focus returns to a sensible element (typically the trigger) on close. Absence of any of these three is a confirmed gap, not a style preference.
+4. **Check that ARIA state attributes are wired to actual component state, not hardcoded.** `aria-expanded="false"` hardcoded in JSX/template that never updates when the component opens is a common generated-code pattern — flag it as equivalent to having no `aria-expanded` at all, since it actively communicates wrong state.
+5. **Prefer native HTML elements over ARIA-patched divs wherever the pattern allows it**, per the APG's own guidance that native semantics are more robust than reconstructed ARIA — flag a custom `<div>`-based reconstruction of something a native `<button>`, `<dialog>`, or `<select>` already provides for free, unless there's a stated, real constraint the native element can't meet.
+6. **Do not accept a passing automated accessibility linter (eslint-plugin-jsx-a11y, axe-core static rules) as sufficient evidence of full compliance.** Static linters catch a meaningful but partial subset (missing `alt`, some ARIA misuse); keyboard operability and focus-trap correctness generally require code tracing or runtime interaction testing beyond static lint rules — say so explicitly rather than treating a clean lint run as a full pass.
+
+## Audit workflow
+
+1. Identify each new/modified interactive component in the diff and match it to its specific APG pattern.
+2. Pull the APG page for that exact pattern (`official_docs` URL in this skill's `metadata.json`) and extract its required role, keyboard bindings, focus-management behavior, and ARIA state attributes.
+3. Trace the component's actual code against each of the four requirement categories; do not infer from the visual/CSS layer.
+4. For each requirement category, classify as: `present and correctly wired`, `present but not wired to real state` (e.g., hardcoded ARIA attribute), or `missing`.
+5. Prioritize `missing` keyboard-operability and focus-management findings above missing/incorrect ARIA attributes above missing native-element preference — a component nobody can reach by keyboard is a harder blocker than a suboptimal role choice.
+
+## High-risk assumptions to kill
+
+- "It has an ARIA role, so it's accessible." A role without the matching keyboard interaction and state management is worse than no role at all — it advertises a contract to assistive technology that the component does not fulfill.
+- "The design system's base component is accessible, so anything built from AI-generated composition around it is too." Verify the generated wiring code didn't strip or override the base component's accessible behavior (e.g., replacing a native `<button>` wrapper with a styled `<div>` for layout convenience).
+- "This passed a quick manual click-through, so keyboard/screen-reader behavior is fine." A mouse-driven manual check exercises none of the keyboard or AT-specific code paths that are exactly where generated code is most likely to have gaps.
+
+## When to push back
+
+Push back if the user asks you to:
+
+- approve an interactive component with no traced keyboard-handler evidence because "it looks right,"
+- treat a passing static a11y linter run as proof of full APG-pattern compliance,
+- skip focus-management review on a modal/overlay pattern because "it's just a small popover."
+
+Those are exactly the corners where generated code's semantic gaps hide.

package/skills/frontend/ai-generated-frontend-code-review/references/hallucinated-api-verification.md

@@ -0,0 +1,56 @@
+# Hallucinated API Verification
+
+Use this reference when a diff — especially one flagged or suspected as AI/LLM-generated — calls a framework/library API (a hook, a component prop, a lifecycle method, a utility export, a CLI flag) and you need to determine whether that API actually exists and behaves as claimed for the project's installed version.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "It compiles, TypeScript didn't complain, and it reads like idiomatic React/Vue/Angular — so the API is real."
+
+That is not evidence. Three independent failure modes hide behind a clean-looking call:
+
+1. **Version drift** — the API existed in an earlier or later major version than the one installed (e.g., a hook or lifecycle method from a different major, a removed legacy API reintroduced from training data).
+2. **Cross-framework bleed** — the model composed a plausible-sounding API by blending conventions from a *different* framework or library (e.g., invoking a Vue-shaped lifecycle name inside a React component, or a Redux Toolkit-shaped selector inside a Zustand store).
+3. **Fully invented surface** — a prop, config key, or method that never existed in any version, constructed by pattern-completing the surrounding code's naming conventions.
+
+TypeScript type-checking and successful compilation catch none of these reliably: overly-permissive types (`any`, loose generic constraints, ambient `declare` fallbacks), stale `@types` packages, or type-narrowing gaps let a nonexistent runtime API pass static checks silently.
+
+## Non-negotiable verification rules
+
+1. **Pin the version before checking the API.** Read `package.json` and the lockfile (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`) to determine the *actual installed* major/minor version of the framework or library in scope. Do not check an API claim against "React" in the abstract — check it against the resolved version.
+2. **Resolve the Context7 library ID before querying.** Call `resolve-library-id` for the framework/library named in the diff, then `query-docs` with the specific API name/signature as the query. Do not skip straight to `query-docs` with a guessed ID.
+3. **A miss on Context7 is not automatically a hallucination, but it is not automatically fine either.** If Context7 has no documentation coverage for a library, fall back to the library's official docs site directly (fetch or search), and only after that fails, label the claim `unverified — possible hallucination` rather than silently accepting it.
+4. **Do not accept "it's probably a newer/undocumented API."** Generated code asserting the use of a bleeding-edge, unstable, or "experimental" API is a signal to verify harder, not a license to skip verification — check the changelog/release notes for the pinned version, not just the latest docs.
+5. **Distinguish "does not exist" from "exists but deprecated/discouraged."** Both are findings, but they carry different severity and different remediation (delete the call vs. migrate to the current-recommended replacement per official docs).
+6. **Never paraphrase from training-data memory as if it were verified.** If Context7 and official docs are both unreachable for a given library, say so explicitly and mark every affected claim `inference — not independently verified`, not `documentation-based`.
+
+## Verification workflow
+
+1. Extract every non-trivial framework/library API call touched or added in the diff (hooks, component props, lifecycle/lifecycle-like methods, exported utilities, CLI flags/config keys).
+2. Resolve the pinned version for each library from the manifest/lockfile.
+3. Resolve the Context7 library ID for that library (`resolve-library-id`), preferring a version-matched result when the tool exposes one.
+4. Query Context7 for each API name/signature (`query-docs`) with a specific, non-generic query (e.g., "React 18 useDeferredValue signature" — not "React hooks").
+5. Cross-check any result against the pinned version's changelog/release notes if the API's introduction or removal version is ambiguous.
+6. Classify each API call as one of:
+   - `verified` — found in Context7/official docs for the pinned version, cite the source,
+   - `verified but deprecated for this version` — exists, but current docs recommend a replacement,
+   - `unverified — possible hallucination` — not found after checking Context7 and official docs,
+   - `inference — not independently verified` — verification tooling was unreachable.
+
+## High-risk assumptions to kill
+
+- "The model probably trained on the latest docs, so it's current." Training cutoffs lag releases and generated code frequently mixes API eras.
+- "It's a small helper method, not worth checking." Small invented helpers (a nonexistent utility export, a fabricated config key) are exactly the pattern that slips through review silently because no one runs it until production.
+- "The linter/type-checker would have caught a nonexistent API." Loose types, ambient declarations, and stale `@types` packages routinely let a nonexistent runtime member pass static analysis.
+- "This project always uses the latest version, so version pinning doesn't matter here." Verify the actual lockfile — do not assume.
+
+## When to push back
+
+Push back if the user asks you to:
+
+- approve an API call because "it looks right" without running the verification workflow above,
+- skip version-pinning because "we're always on latest" without checking the lockfile,
+- treat a Context7 miss as automatic proof the API doesn't exist without a fallback official-docs check.
+
+Those are shortcuts that convert a verification claim into an unverified guess.

package/skills/frontend/ai-generated-frontend-code-review/references/slopsquat-dependency-check.md

@@ -0,0 +1,49 @@
+# Slopsquat Dependency Check
+
+Use this reference whenever a diff introduces a new package dependency — a new entry in `package.json`/`requirements.txt`/equivalent manifest, a new lockfile entry, or an import statement pulling from a package not previously present in the project.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "The model wrote this import, the package name sounds like a real, well-known library, so it must exist and be the right one."
+
+That is the exact mechanism of a slopsquat attack. LLMs, when asked to solve a problem, will sometimes hallucinate a plausible-sounding package name that does not exist — a name that reads as if it *should* be the canonical solution to the stated problem. Attackers monitor this pattern and pre-register those exact hallucinated names on public registries (npm, PyPI, etc.) with malicious payloads, betting that a generated suggestion will eventually get installed verbatim by someone who does not check. A name "sounding right" is therefore not weak evidence of legitimacy — it is close to zero evidence, because it is the precise signal an attacker optimizes for.
+
+This is distinct from classic typosquatting (a deliberate misspelling of a real popular package, e.g. `reactt` or `lodash-es-`) — slopsquatting targets names an AI model is likely to *invent* for a given task, which may not resemble any existing real package at all.
+
+## Non-negotiable check rules
+
+1. **Every new dependency gets a live registry lookup — no exceptions for "obviously real" names.** Resolve the package on its actual public registry (npm registry for JS/TS, PyPI for Python, crates.io for Rust, RubyGems, etc.) via `WebFetch`/`WebSearch`. Do not accept the name on the strength of it sounding familiar or matching a well-known naming convention.
+2. **Verify identity, not just existence.** A registry hit is not sufficient — confirm the resolved package's publisher/maintainer, description, weekly download count, repository link, and first-publish date align with what the diff claims the package does. A newly-squatted name can exist on the registry with near-zero downloads and no meaningful history.
+3. **Treat a registry miss as a hard blocker, not a note.** If the exact package name does not resolve on the registry at all, this is the strongest possible slopsquat signal — the install must not proceed until the correct real package name is identified and independently confirmed.
+4. **Check for confusable near-misses even on a registry hit.** Compare the found package against the likely *intended* real package for the stated purpose (e.g., is there a much more widely-used, near-identically-named alternative that this name is shadowing or bidding to be confused with?).
+5. **Do not let version-pinning or lockfile presence substitute for a registry check.** A lockfile entry only proves something was resolved and installed at some point — potentially by an earlier, equally unverified step — not that the package is legitimate.
+6. **Escalate, do not silently "fix," a suspicious name.** If a dependency looks slopsquatted, do not unilaterally swap in what you assume is the "real" package — flag it explicitly and require the author to confirm intent, since silently substituting could also introduce the wrong package.
+
+## Verification workflow
+
+1. Diff the manifest/lockfile to enumerate every newly introduced package name and version constraint.
+2. For each new name, perform a live registry lookup (`WebFetch`/`WebSearch` against the registry's public package page or API).
+3. Record, per package: registry hit/miss, publisher, download volume/popularity signal, repository URL, first-publish date.
+4. Cross-reference the package's stated purpose in the diff/commit message against what the registry listing actually describes.
+5. Classify each new dependency as:
+   - `registry-verified` — resolves to a real, actively-maintained package matching the claimed purpose; cite the registry URL,
+   - `registry-verified but low-confidence` — resolves, but with signals worth a human look (very new, near-zero downloads, unrelated description, generic/unmaintained-looking repo),
+   - `slopsquat-risk / registry-lookup-failed` — does not resolve, or resolves to something that plausibly is a hallucinated-name squat.
+
+## High-risk assumptions to kill
+
+- "It's a scoped package under a name I recognize (e.g., `@react-...`), so the scope itself vouches for it." Scopes can be squatted or created by unrelated parties; verify the specific scope owner too.
+- "The AI tool that generated this surely only suggests real packages." That is precisely the failure mode this check exists to catch — treat every model-suggested package name with the same suspicion regardless of tool confidence.
+- "It installed successfully, so it must be real." A successful `npm install`/`pip install` only proves the name resolved on the registry at install time — it says nothing about whether the package is the legitimate, intended one or a malicious squat.
+
+## When to push back
+
+Push back if the user asks you to:
+
+- approve a new dependency without a registry lookup because "we're in a hurry,"
+- silently rename a suspicious dependency to what you guess was intended, rather than flagging it for explicit confirmation,
+- treat popularity of the *stated* library concept (e.g., "everyone uses a library like this") as a substitute for verifying *this specific* package name resolves to that library.
+
+Those shortcuts reintroduce exactly the supply-chain risk this check exists to close.

package/skills/frontend/angular-architecture-signals-review/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: angular-architecture-signals-review
+description: Statically review Angular component and service architecture for correct Signals usage (signal/computed/effect boundaries and purity), appropriate change-detection strategy (OnPush vs default), and service/DI boundary design, grounded in Angular's own Signals, change-detection, and dependency-injection guidance.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: architecture
+---
+
+# Angular Architecture & Signals Review
+
+## Purpose
+
+Review Angular reactive-primitive boundaries (`signal`/`computed`/`effect`/`linkedSignal`), change-detection strategy, and service/DI ownership without re-litigating SSR/hydration concerns, RxJS-only legacy code with no Signals involved, or full zoneless-migration planning in every response. This skill exists so those adjacent concerns stay out of scope and the review stays focused on reactive-graph correctness and change-detection performance opportunities that are actually verifiable from the diff.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a component migrated to or newly written with Signals for correctness,
+- assess whether an `effect()` call has an inappropriate or missing side effect,
+- review whether `computed()` usage stays pure,
+- perform a change-detection performance review (OnPush adoption, strategy mismatches),
+- review service/DI boundaries for ownership of cross-cutting mutable state.
+
+Do not use this skill for:
+
+- pure RxJS-only legacy code with no Signals involved and no stated migration plan — that is a different, RxJS-specific review,
+- SSR/hydration-specific concerns — use `angular-ssr-hydration-review` instead,
+- recommending an app-wide zoneless migration — that is a dedicated architectural decision, not a PR-review fix.
+
+## 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 what is idiomatic Angular — Signals-first reactivity (`signal`/`computed`/`linkedSignal`/`resource`), modern control flow (`@if`/`@for`/`@switch`), standalone-by-default, `inject()` + `providedIn: 'root'` DI, and SSR/hydration strategy. Prefer its idioms over memory.
+2. **Context7 `angular_dev` docs** (`/websites/angular_dev`, or the version-pinned `/websites/v20_angular_dev`) confirm those idioms against the repo's pinned `@angular/core` major (read `package.json` first). API/primitive availability is versioned — the official skill states the modern shape, the versioned docs confirm it applies to THIS repo's major.
+3. **This skill's static-review judgment** (severity classification, `computed()` purity rules, effect-vs-derivation rules, injection-context and post-await-tracking checks, missed-OnPush and DI-ownership findings) 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" (which primitive/API to use, current recommended shape). THIS skill governs "what to flag in review" (which deviations rise to a HIGH/MEDIUM/LOW 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 purity/effect/injection defect from being flagged.
+
+## Context7 Documentation Protocol
+
+- Resolve the Angular library ID with `resolve-library-id` (matched result: `/websites/angular_dev` or `/websites/v20_angular_dev` when the repo's confirmed major is pinned) before citing any Signals-, change-detection-, or DI-specific claim.
+- Before asserting a `computed`/`effect`/`linkedSignal` usage is correct or incorrect, call `query-docs` against the repo's actual Angular major version (read `package.json` first — `@angular/core`) and cite the doc section. Signals stabilized incrementally across Angular v16-v20 and `linkedSignal` is a newer primitive; do not assume availability without confirming the version.
+- 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`.
+- Never assume the latest Angular docs (e.g. `@Service` decorator preference noted for v22+, `provideZonelessChangeDetection`) apply to an older major present in the repo.
+
+## Lean operating rules
+
+- First read `package.json` to confirm the installed `@angular/core` major version. Do not make a Signals-API-availability claim (e.g. `linkedSignal`) without confirming the version supports it.
+- Classify each reactive primitive in scope as `signal` (state), `computed` (derived, pure, memoized) or `effect` (side effect on non-reactive APIs) before evaluating it. Do not apply one correctness rule to all three uniformly.
+- `computed()` must be pure per Angular's own guidance (lazily evaluated and memoized). Any side effect inside a `computed()` callback (signal writes, DOM mutation, HTTP calls, logging) is a HIGH-severity purity violation, not a style note.
+- `effect()` exists for syncing signal state to imperative, non-reactive APIs (logging, `window.localStorage`, custom DOM behavior, third-party UI library sync) per Angular's documented use cases. An `effect()` that only derives and stores a value other state depends on is propagating state through a side-effect channel — Angular's own docs warn this risks `ExpressionChangedAfterItHasBeenChecked` errors, circular updates, and unnecessary change-detection cycles; recommend `computed()` or `linkedSignal()` instead.
+- `effect()` requires an injection context (component/directive/service constructor, or an explicit `Injector` passed via options). Flag any `effect()` call site that cannot resolve an injection context as a correctness bug, not a style preference.
+- Signals read after an `await` inside an `effect()` lose reactive tracking (the reactive context does not survive the async boundary). Flag any effect that reads a signal post-await and expects it to be tracked as a dependency.
+- Do not flag a component that stays at the default (non-OnPush) change-detection strategy as broken. Signals adoption without OnPush is a missed performance opportunity (MEDIUM), not a defect — verify the component doesn't rely on an implicit mutation-based update path that OnPush would break before recommending the switch.
+- Do not recommend removing Zone.js or switching to zoneless (`provideZonelessChangeDetection`) as a review finding. That is an app-wide architectural decision requiring a dedicated migration plan.
+- Treat services holding cross-cutting mutable state without a documented ownership model as a DI-boundary finding, but do not recommend a specific DI pattern (`providedIn: 'root'` singleton vs component-scoped provider) without confirming the actual sharing/lifetime requirement from the code in scope.
+- Never execute, build, or run application code as part of this review; this is a static-review skill (Read/Grep/Glob only).
+- Treat any hardcoded API key, token, or secret found in component/service state, default values, or example data as a HIGH-severity finding requiring immediate escalation, not a style note.
+
+## 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 effect-vs-computed decision tree, the OnPush escalation rule, and the required output shape.
+- [linkedSignal and DI-boundary patterns](references/linked-signal-and-di-boundaries.md) — load only when `linkedSignal` appears in the diff, or when the review scope includes service/DI ownership review.
+
+## Response minimum
+
+Return, at minimum:
+
+- the component(s)/service(s) and files in scope,
+- ranked findings 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), and a concrete fix sketch 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. zoneless migration flagged as out of scope, missing confirmed Angular major version).

package/skills/frontend/angular-architecture-signals-review/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "angular-architecture-signals-review",
+  "name": "Angular Architecture & Signals Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Angular component/service architecture for correct Signals usage, computed/effect semantics, and change-detection strategy, using Angular's own Signals, change-detection, and dependency-injection guidance 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/signals",
+    "https://angular.dev/guide/signals/linked-signal",
+    "https://angular.dev/guide/components/change-detection",
+    "https://angular.dev/guide/di/dependency-injection"
+  ],
+  "security_notes": "No direct security-primitive concern in this skill's scope; escalate any bypassSecurityTrust* usage discovered incidentally to the angular-ssr-hydration-review skill or a security reviewer rather than handling it here. Static-review-only skill: it reads and greps component/service source but never executes, builds, or runs application code. Treat any API key or token found hardcoded in component/service state or default values as a HIGH-severity finding requiring immediate escalation, not a style note.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/angular-architecture-signals-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}