@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.0

package/skills/frontend/vue-composition-api-architecture-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "vue-composition-api-architecture-review",
+  "name": "Vue Composition API Architecture Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Vue 3 composables and script-setup components for reactivity-boundary correctness (ref/reactive/computed usage, destructuring-loses-reactivity pitfalls, toRef/toRefs/unref interop, lifecycle-hook synchronous-registration timing) and composable extraction quality, grounding claims via Context7 against Vue's own composables and reactivity documentation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://vuejs.org/guide/extras/composition-api-faq.html",
+    "https://vuejs.org/guide/reusability/composables.html",
+    "https://vuejs.org/api/reactivity-core.html",
+    "https://vuejs.org/guide/essentials/reactivity-fundamentals.html"
+  ],
+  "security_notes": "Static-review-only skill: it reads and greps composable/component source but never executes, builds, or runs application code. No direct security-primitive concern; if a composable is found managing auth tokens, session state, or other credential material, flag it out of scope and recommend the vue-ssr-security-review skill instead of performing credential-handling review here.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/vue-composition-api-architecture-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/vue-composition-api-architecture-review/references/composable-and-script-setup-conventions.md

@@ -0,0 +1,50 @@
+# Composable and Script-Setup Conventions
+
+Use this reference only when reviewing composable naming/structure, lifecycle-hook registration timing, or `<script setup>` responsibility mixing and extraction candidates.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "As long as the code works when I test it manually, where I call `onMounted()` or another composable inside a composable doesn't matter."
+
+That is wrong. Vue's Composition API relies on an internal "current active instance" pointer that is only valid during the synchronous execution of `setup()` (or the top-level, non-awaited body of `<script setup>`). Lifecycle-hook registration functions (`onMounted`, `onUnmounted`, `onUpdated`, etc.) and dependency-injection functions (`provide`, `inject`) read that pointer at call time. If the call happens after an `await`, inside a `setTimeout` callback, inside a conditional branch that runs later, or inside an event-handler function that executes after setup has already returned, the active-instance pointer is no longer set (or points at the wrong instance) and the call either silently no-ops or attaches to the wrong component. This frequently "works" in manual testing because the developer doesn't notice the hook never actually fired, and only surfaces as a subtle bug (a cleanup that never runs, a mount hook that fires late or never) later.
+
+## Officially grounded conventions
+
+- **Naming:** composable functions are named with a `use` prefix (`useMouse`, `useFetch`, `useCounter`) by convention — this signals to readers and tooling (including ESLint plugin rules for Composition API) that the function may call other composition APIs (refs, lifecycle hooks, provide/inject) and has rules-of-hooks-like constraints.
+- **Input/output convention:** composables typically accept plain values, refs, or getters as input (using `unref()`/`toValue()`-style normalization internally) and return an object of refs (or individually-returned refs) so that consumers can destructure safely — see `references/reactivity-boundaries.md` for the mechanics.
+- **Synchronous-registration rule:** lifecycle hooks and `provide`/`inject` must be called synchronously within the composable's/component's initial setup execution. Async work belongs *inside* the hook's callback body (e.g., `onMounted(async () => { await fetchData() })` is correct; `await fetchData(); onMounted(() => {})` is not, because the `onMounted` call itself has been pushed past the synchronous setup window).
+- **`<script setup>` is sugar over `setup()`:** every rule that applies to composable calls inside `setup()` applies identically inside the top-level (non-nested, non-async-continuation) body of a `<script setup>` block.
+
+## Non-negotiable design rules
+
+1. **Every lifecycle-hook call and every nested composable call must be reachable synchronously from the top of `setup()`/`<script setup>` execution.** No exceptions for "it's inside a function that always runs during setup anyway" — if that function is itself invoked asynchronously or conditionally, the guarantee breaks. Trace the actual call chain; do not assume synchronicity from proximity in the source file.
+2. **A composable's `use*` name must reflect that it may call other Composition APIs.** A plain utility function (no refs, no lifecycle hooks, no other composable calls) does not need the `use` prefix and naming it that way is misleading, not a review-blocking defect — note it, do not escalate it.
+3. **Async initialization belongs inside the async operation's own effect (a lifecycle hook body, a `watch`/`watchEffect` callback, or an event handler), never mixed into the composable's own top-level synchronous body in a way that races with hook registration.** If a composable needs to both register a lifecycle hook and kick off an async fetch, register the hook first (synchronously), and start the fetch inside (or after) that synchronous registration completes — not interleaved with it in a way that risks the hook call landing after an early `return`/`await`.
+
+## `<script setup>` organization review
+
+Flag a component for composable extraction when it mixes **three or more** of the following concerns inline, with no existing extraction, **and** the mixed logic has genuine reuse or testability value (not just "this file is long"):
+
+- data-fetching (an inline `fetch`/HTTP client call plus loading/error state),
+- validation or business-rule logic (non-trivial conditional/derived logic beyond simple template formatting),
+- presentation-only local state (toggle flags, form-field bindings) — this one alone is normal and not a concern by itself,
+- non-trivial event-handling logic (more than a one-line dispatch to a store/composable).
+
+When flagging, name the concrete extraction: what the new composable should own (e.g., "extract the fetch + loading/error state into `useOrderHistory(customerId)`"), not a vague "consider extracting some logic." Do not flag a component that has one or two local `ref()`s and a single `fetch` call with no independent business logic — that is normal `<script setup>` usage, not a mixed-concern smell.
+
+## Verification targets
+
+When repo evidence is available, verify each finding against:
+
+- the actual call stack leading to a hook registration — is `onMounted(...)` reachable synchronously from the top of `setup()`, or is it inside a `.then()`, an `async function` body before any `await`... after any `await`, a `v-if`-guarded code path, or a callback passed to `setTimeout`/an event listener?
+- whether the same fetch/business logic already appears in another component in the codebase (strengthens an extraction-candidate finding — it demonstrates real duplication, not just theoretical reuse potential).
+
+## When to push back
+
+Push back if the user asks to:
+
+- "just wrap the whole thing in `nextTick().then()`" to make an async-timing bug with a lifecycle hook go away — that changes when the code runs but does not fix the underlying synchronous-registration violation; the hook registration itself must move, not the work around it,
+- extract every local `ref()` in a component into a composable regardless of reuse potential — that adds indirection without reducing duplication or improving testability, which contradicts the actual goal of composable extraction,
+- rename a plain non-reactive utility function to start with `use` "for consistency" — the `use` prefix is a signal about Composition API usage, not a general naming convention, and misapplying it misleads future readers about the function's constraints.

package/skills/frontend/vue-composition-api-architecture-review/references/reactivity-boundaries.md

@@ -0,0 +1,44 @@
+# Reactivity Boundaries: ref, reactive, computed, and Interop
+
+Use this reference only when reviewing `ref()`/`reactive()`/`computed()` usage, a suspected destructuring-loses-reactivity bug, or `toRef()`/`toRefs()`/`unref()` interop code.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "`reactive()` and `ref()` are interchangeable; I can destructure either one and the result stays reactive."
+
+That is wrong for `reactive()`. Vue's `reactive()` returns a Proxy that tracks property access *through the proxy itself*. Destructuring a primitive-valued property off that proxy — `const { count } = state` — copies the current primitive value out; the local `count` variable is a plain number/string with no connection back to `state.count`. Further mutations to `state.count` will not update `count`, and Vue's own docs document this as the reason `reactive()`'s usefulness is "limited" for values that need to be passed around or destructured. `ref()` does not have this problem: a `ref` is an object with a `.value` property, so extracting it (or wrapping a `reactive()` object's properties in `toRefs()` first) preserves the reactive connection because you are copying a reference to the ref object, not a snapshot of its value.
+
+## Officially grounded shape
+
+- `ref(initialValue)` returns a ref object with a `.value` accessor; reading/writing `.value` is tracked/triggers updates. In `<script setup>` and templates, refs are auto-unwrapped (no `.value` needed in the template).
+- `reactive(obj)` returns a Proxy wrapping `obj`; property access/mutation through the proxy is tracked. Destructuring a primitive property off the proxy loses the reactive connection for that property. Destructuring a nested object/array property does *not* lose reactivity for further mutations on that nested value, because the extracted reference still points at a proxied (or proxy-wrappable) object — the pitfall is specifically about primitive values.
+- `toRefs(reactiveObj)` converts every property of a reactive object into an individual ref, returning a plain object of refs. Destructuring the result of `toRefs()` is safe — each destructured value is a ref, not a primitive snapshot.
+- `toRef(reactiveObj, key)` creates a single ref synced to one property of a reactive object (or normalizes a plain value/getter into a ref-like object) — the documented escape hatch for passing one reactive property into a function that expects a ref, without wrapping the whole object.
+- `unref(refOrValue)` returns `.value` if the argument is a ref, or the argument itself otherwise — the documented escape hatch for composable code that accepts either refs or plain values as arguments.
+- `computed(getterOrOptions)` returns a read-only ref by default when given a getter function. Given `{ get, set }`, it returns a writable ref-like computed — the documented pattern for two-way-bindable derived state (e.g., a computed backing a form field that needs to write back to a different source property).
+
+## Non-negotiable design rules
+
+1. **A composable that expects its return value to be destructured by consumers must return refs, not a plain destructurable `reactive()` object.** Return individual refs, or build internal state with `reactive()` and return `toRefs(state)` at the composable's boundary. This is the single most common Composition API defect class and the one most likely to produce a "state doesn't update in the UI" bug report that is expensive to trace back to its source.
+2. **`reactive()` is correct, not wrong, when the composable's own internal state is never destructured** — only accessed via dot-notation (`state.count`) inside the composable itself, or passed whole to a template/child without destructuring. Do not flag every `reactive()` call site as a defect; check whether the specific value is actually destructured downstream first.
+3. **`computed()` getters must be pure.** No state mutation, no async calls, no network writes inside a getter — Vue may re-run a computed's getter an unpredictable number of times as part of dependency tracking, so any side effect there is nondeterministic and can produce inconsistent state or infinite recomputation loops. A `computed({ get, set })` writable computed's `set` function is not subject to this rule — writing back to source state is its documented purpose.
+4. **`toRef()`/`unref()` are documented interop escape hatches, not bugs.** Do not flag their presence as a finding by default — verify instead that they are being used for their documented purpose (normalizing composable arguments, exposing a single reactive property to a child) rather than papering over a reactivity-loss bug found elsewhere.
+5. **Shallow variants (`shallowRef`, `shallowReactive`) intentionally do not track nested mutations.** Do not flag a nested-property mutation as "not reactive" without first checking whether the top-level ref/reactive was declared shallow on purpose (e.g., for a large object where deep reactivity is a documented performance cost the team opted out of).
+
+## Verification targets
+
+When repo evidence is available, verify each finding against:
+
+- the composable's actual return statement — is it `return { ...state }` (reactive spread, still loses reactivity on destructure), `return toRefs(state)` (safe), or `return { countRef, doubledRef }` (safe, individual refs)?
+- the consumer call site — is it `const { count } = useCounter()` (destructure — check the composable's return shape) or `const counter = useCounter(); counter.count` (property access — reactivity-loss risk does not apply regardless of return shape)?
+- whether a flagged `computed()` side effect is actually reachable during normal getter evaluation, or only inside the `set` function of a writable computed (not a finding).
+
+## When to push back
+
+Push back if the user asks to:
+
+- convert a composable's return value from `reactive()`/`toRefs()` to a plain destructured object "for cleaner syntax" — that reintroduces the exact reactivity-loss pitfall this reference exists to catch,
+- add a `watch()` inside a `computed()` getter to "fix" an impurity finding — that does not make the getter pure, it adds a second reactive side channel; the fix is to move the side effect out of the computed entirely,
+- flag `shallowRef`/`shallowReactive` usage as a bug without first confirming whether the shallow choice was intentional (e.g., checking for an accompanying comment, a large-list-performance context, or explicit `triggerRef()` calls that indicate deliberate manual reactivity control).

package/skills/frontend/vue-composition-api-architecture-review/references/workflow-and-output.md

@@ -0,0 +1,49 @@
+# Review Workflow and Findings Contract
+
+Use this reference for the step-by-step review procedure and the required output shape. Load the other two references only for the specific concern the composable or component under review actually raises.
+
+## Prerequisites
+
+- Confirm Vue 3.x is in use (`package.json` — `vue: ^3.x`). Composition API, `<script setup>`, and the composable conventions this skill reviews against are Vue 3 features; a Vue 2 codebase with no stated migration plan is out of scope.
+- Identify every composable (`use*`-prefixed function) in the diff or review scope, and every component file that consumes one.
+
+## Workflow
+
+1. **Enumerate composables in scope.** For each, read its full body and its return statement.
+2. **Classify the return shape.** Does it return a plain object built from `reactive()`, individual `ref()`s, a `toRefs()`-wrapped reactive object, or a mix? This classification drives the reactivity-boundary review — see `references/reactivity-boundaries.md`.
+3. **Check consumer call sites.** For each place a composable's return value is consumed, check whether the consumer destructures it. Cross-reference the destructuring pattern against the return-shape classification from step 2.
+4. **Check lifecycle-hook and nested-composable call timing.** Verify every `onMounted`/`onUnmounted`/`watch`/`provide`/nested composable call happens synchronously in the initial execution of `setup()` or the `<script setup>` block — not after an `await`, not inside a conditional/loop, not inside an event handler defined during setup and invoked later.
+5. **Check `computed()` purity.** Verify every `computed()` getter is a pure read. If a `computed({ get, set })` writable-computed pair is present, verify the `set` function's role (writing back to source state) is not mistaken for an impurity.
+6. **Review `<script setup>` organization.** For each component, count distinct concerns handled inline (data-fetching, validation, business-rule logic, presentation-only local state, event handling). Flag extraction candidates per the decision tree below.
+7. **Produce ranked findings** using the output contract below.
+
+## Decision tree
+
+- Composable returns a plain `reactive()` object **and** is destructured by a consumer → **HIGH** finding (documented reactivity-loss pitfall). Fix: return `toRefs(state)` or return individual refs from the composable instead of a bare reactive object.
+- Composable calls a lifecycle hook (`onMounted`, etc.) inside an async function, after an `await`, inside a conditional, or inside a callback registered for later invocation → **HIGH** finding (violates Vue's synchronous-registration requirement — the hook silently fails to bind to the intended component instance). Fix: call the hook synchronously in the composable's/component's top-level setup execution; move async work inside the hook's own callback body instead.
+- `<script setup>` component mixes 3+ distinct concerns (e.g., fetch + validation + layout + event handling) inline with no composable extraction, and the mixed logic has genuine reuse or testability value → **MEDIUM** finding, recommend composable extraction with a concrete split (name the composable, name what it should own).
+- `computed()` getter performs a side effect (mutates state, fires a network call, logs with side effects) → **MEDIUM-to-HIGH** finding depending on blast radius (see escalation note below). Fix: move the side effect into a `watch`/`watchEffect` or an explicit method; keep the getter pure.
+- Composable returns a plain `reactive()` object and is **not** destructured (consumed only via property access, e.g., `state.count`) → not a finding. `reactive()` is correct and idiomatic when consumers do not destructure.
+- `toRef()`/`unref()` used to interop between a prop and a local composable, or to normalize a `ref | value` argument → not a finding; these are the documented escape hatches, not bugs.
+
+## Severity note on computed side effects
+
+Treat an impure `computed()` getter as **HIGH** severity when the side effect is a network write, a mutation of state outside the computed's own dependency graph, or a mutation that can re-trigger the same computed's re-evaluation (infinite-loop risk). Otherwise (a benign console log with no state mutation), **MEDIUM** is appropriate — still a documented anti-pattern, since `computed()` getters are expected to be re-run an unpredictable number of times by Vue's reactivity system, but not a data-integrity risk.
+
+## Output contract
+
+Every response from this skill must return:
+
+1. **Scope** — the composable(s) and/or component(s), files, and specific call sites reviewed.
+2. **Ranked findings** — each with file:line, defect category (reactivity-loss / lifecycle-timing / computed-impurity / extraction-candidate), the concrete evidence (the exact destructuring line, the exact async boundary crossed, or the exact mixed-concern list), and a fix sketch matching Vue's documented pattern.
+3. **Evidence level per finding** — `repo evidence`, `documentation-based`, or `inference`.
+4. **Verdict** — approve / approve-with-notes / block.
+5. **Open questions or out-of-scope items** — e.g., "requires Vue Devtools reactivity inspection to confirm the reported UI-not-updating bug traces to this destructuring site," or "auth-token handling in `useSession` is out of scope — recommend vue-ssr-security-review."
+
+## When to push back
+
+Push back if the user asks to:
+
+- treat every `reactive()` usage in the codebase as a bug to convert to `ref()` — `reactive()` is correct and idiomatic for state that is never destructured by consumers; a blanket conversion is unnecessary churn, not a fix,
+- adopt Pinia or Vuex as part of this review's recommendation when neither is already a project dependency — that is a state-management architecture decision outside a composable/reactivity review's scope,
+- migrate an Options API component to Composition API as a review finding when the PR itself does not already touch Composition API elsewhere — that is a repo-wide migration decision, not a PR-level fix.

package/skills/frontend/vue-router-navigation-security-review/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: vue-router-navigation-security-review
+description: Statically review Vue Router navigation guards, redirect flows, and template bindings for client-side guards used as the sole authorization boundary, open redirects via route.query.redirect/returnUrl, javascript:/data: scheme injection through dynamic :to/:href bindings, route params/query reaching v-html/innerHTML (reflected XSS), guard-induced redirect loops, and catch-all/history-mode misconfiguration, grounded in Vue Router's own documentation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-03"
+  category: security
+---
+
+# Vue Router Navigation Security Review
+
+## Purpose
+
+Review Vue Router navigation guards, redirect flows, dynamic link bindings, and route
+configuration for the security-critical defect classes specific to *client-side routing as a
+security surface* — not general route-tree architecture, not component design, and not the
+state-store or SSR-hydration concerns owned by sibling skills. This skill exists to keep the
+review anchored to five documented defect classes: (a) a `beforeEach`/`beforeEnter` guard used
+as the sole authorization boundary with no server-side enforcement behind it, (b) open redirect
+via `route.query.redirect`/`returnUrl` passed unvalidated into `router.push()`/
+`window.location`, (c) `javascript:`/`data:` scheme injection via a dynamic `:to`/`:href`
+binding, (d) `route.params`/`route.query` interpolated into `v-html`/`innerHTML` (reflected XSS
+through the router), and (e) `next(unvalidatedPath)`/guard-returned redirects creating loops or
+bypasses, overly-broad catch-all routes, and `history`-mode server misconfiguration. It does not
+re-litigate general route-tree/code-splitting architecture, Pinia/Vuex store security, or SSR
+cross-request pollution in every response.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a `router.beforeEach`/`beforeEnter` guard (or a Nuxt `definePageMeta`/route-middleware
+  equivalent) that gates access to a route,
+- audit a login/logout flow's post-authentication redirect handling,
+- assess whether a `<router-link :to="...">` or dynamic `:href` binding is safe from scheme
+  injection,
+- investigate whether `route.params`/`route.query` reaching a `v-html` or `.innerHTML` sink is
+  exploitable,
+- review a route table for redirect-loop risk, catch-all overreach, or `history`-mode
+  server-fallback exposure,
+- perform a pre-launch security review of a Vue Router-based application's navigation layer.
+
+Do not use this skill for:
+
+- general route-tree structure, loader/code-splitting, or focus-management review with no
+  security angle — use `routing-navigation-review` instead (and note it targets React
+  Router/Next.js, not Vue Router),
+- Pinia/Vuex store security (persisted sensitive data, SSR store-singleton pollution, untrusted
+  hydration payloads, client-held role flags as an authorization source) — use
+  `vue-state-store-security-review` instead,
+- SSR entry-point cross-request state pollution or general `v-html`/dynamic-URL injection
+  unrelated to router data — use `vue-ssr-security-review` instead; this skill's injection scope
+  is specifically `route.params`/`route.query` reaching a sink, not every `v-html` in the app,
+- broad token-storage, cookie-flag, CSRF, or OAuth/OIDC flow review with no router-specific
+  mechanism in play — use `frontend-auth-session-security-review` instead; this skill covers
+  only the router-mediated open-redirect mechanism (`route.query.redirect`/`returnUrl`), not
+  session/token architecture generally,
+- confirming a bypass has already been exploited in production (concurrent-request reproduction,
+  live penetration testing, a captured attack) — static analysis proves the structural risk, not
+  that it has already been exploited.
+
+## Context7 Documentation Protocol
+
+- Resolve the Vue Router library ID with `resolve-library-id` (matched result: `/vuejs/router`,
+  Vue Router's own source-and-docs repository) before citing any guard-mechanism, redirect-API,
+  or dynamic-matching claim.
+- Use `query-docs` against `/vuejs/router` to corroborate: navigation-guard return semantics
+  (`beforeEach`/`beforeEnter` returning `false`/a location/`undefined`, and the legacy `next`
+  argument's call-exactly-once contract), the documented `to.name !== 'Login'` self-exclusion
+  pattern, redirect function shapes (`redirect: to => ({ path, query })`), `route.params`/
+  `route.query` exposure with no built-in escaping, `router.push`'s acceptance of bare string
+  paths, `createWebHistory()`'s server-fallback requirement, and the `/:pathMatch(.*)*`
+  catch-all pattern. These are all `repo evidence` claims — cite the specific guide file
+  (navigation-guards, redirect-and-alias, dynamic-matching, history-mode) alongside the claim.
+- The conclusion that a client-side guard must not be the *sole* authorization boundary is not
+  itself a Vue-Router API fact — Vue Router's docs describe guards strictly as navigation
+  control flow (cancel/redirect/proceed), never as an access-control mechanism. Label this
+  specific conclusion `inference`, grounded in general server-side-enforcement security practice
+  (`documentation-based` via OWASP), layered on the `repo evidence` fact that guards are
+  browser-executed callbacks.
+- The claim that `v-html` bypasses Vue's default template auto-escaping is general Vue
+  template-compiler behavior, not a Vue-Router API — ground it in the Vue security guide
+  (`documentation-based`, listed in this skill's `official_docs`), not in `/vuejs/router`.
+- Read `package.json` first to confirm the Vue Router major version in use — guard signatures
+  (return-value guards vs. the legacy `next` third argument), redirect object shape, and
+  catch-all syntax (`/:pathMatch(.*)*` in v4 vs. legacy `*` in v3) differ across majors; do not
+  apply v4 API names to a v3 codebase or vice versa.
+- 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
+
+- Every finding in this skill's scope defaults to HIGH severity: broken client-side-only access
+  control, open redirect, scheme injection, and reflected XSS are all directly exploitable
+  without further chaining. Do not downgrade to MEDIUM because "it hasn't been reported
+  exploited yet" — the risk is structural.
+- Trace every finding to a concrete file:line and a concrete data-flow path (guard → endpoint
+  gap, or origin → sink hops for injection/redirect findings). A finding that says "this guard
+  might not be enough" or "this redirect might be exploitable" without the specific trace is a
+  guess, not a finding.
+- Never flag "a `beforeEach`/`beforeEnter` guard exists" by itself. The finding requires the
+  *absence* of confirmed server-side enforcement on the endpoint the protected route depends on
+  — look for evidence (a 401/403 check, a BFF layer, an API contract note) before concluding
+  it's missing, and state explicitly what you found or didn't find.
+- Never accept a type check or substring blocklist as clearing an open-redirect or
+  scheme-injection finding. The only acceptable control is an allowlist: same-origin/
+  relative-path validation for redirects, and an explicit protocol allowlist
+  (`http:`/`https:`/`mailto:`) for dynamic link bindings.
+- Do not approve a `v-html`/`.innerHTML` sink fed by `route.params`/`route.query` unless a named
+  sanitizer call is visibly present on that exact traced path — a sanitizer existing elsewhere
+  in the codebase does not clear this bar.
+- Check every unconditional redirect-on-guard for the framework's own documented self-exclusion
+  pattern (`to.name !== 'Login'` or equivalent). Its absence is a HIGH redirect-loop finding, not
+  a style nit — Vue Router's docs treat it as required.
+- Read the full `routes` array in registration order before clearing a catch-all route; a
+  broad/catch-all pattern registered before a route that should require auth can shadow it.
+- 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 full decision tree across all five defect classes, and the
+  required output shape.
+- [Client-side guards as an authorization boundary, and navigation control-flow risks](references/client-guards-and-control-flow.md)
+  — load when reviewing a `beforeEach`/`beforeEnter` guard, a guard-returned redirect, a
+  catch-all route, or `history`-mode configuration.
+- [Open redirect, scheme injection, and reflected XSS through the router](references/open-redirect-and-injection.md)
+  — load when reviewing a post-login redirect flow, a dynamic `:to`/`:href` binding, or a
+  `v-html`/`innerHTML` sink fed by `route.params`/`route.query`.
+
+## Response minimum
+
+Return, at minimum:
+
+- the guard(s), redirect flow(s), dynamic link binding(s), route table, and/or `v-html`/
+  `innerHTML` sink(s) in scope,
+- ranked findings with file:line evidence, defect category
+  (`client-guard-as-sole-authz` / `open-redirect` / `scheme-injection` / `reflected-xss` /
+  `redirect-loop` / `catch-all-misconfig` / `history-mode-server-misconfig`), the concrete
+  data-flow trace (the guard-to-endpoint gap, or the full origin-to-sink path naming every hop),
+  and a fix sketch matching Vue Router's documented pattern,
+- for every guard finding, an explicit statement of whether server-side enforcement evidence was
+  found and where — never infer it exists without evidence on the traced path,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `inference`), with
+  structural-risk findings explicitly labeled as structural risk, not confirmed-exploited,
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., "confirming the API layer actually
+  rejects unauthorized requests requires a live request or reading server-side code outside this
+  diff's scope").

package/skills/frontend/vue-router-navigation-security-review/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "vue-router-navigation-security-review",
+  "name": "Vue Router Navigation Security Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Statically reviews Vue Router navigation guards, redirect flows, dynamic link bindings, and route configuration for client-side guards used as the sole authorization boundary, open redirects via route.query.redirect/returnUrl, javascript:/data: scheme injection through dynamic :to/:href bindings, reflected XSS from route params/query reaching v-html/innerHTML, guard-induced redirect loops, and catch-all/history-mode misconfiguration, grounding claims via Context7 against Vue Router's own documentation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://router.vuejs.org/guide/advanced/navigation-guards.html",
+    "https://router.vuejs.org/guide/essentials/redirect-and-alias.html",
+    "https://router.vuejs.org/guide/essentials/dynamic-matching.html",
+    "https://router.vuejs.org/guide/essentials/history-mode.html",
+    "https://vuejs.org/guide/best-practices/security.html",
+    "https://owasp.org/www-community/attacks/xss/",
+    "https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html"
+  ],
+  "security_notes": "This skill's entire scope is security-critical: a client-side-only navigation guard treated as an authorization boundary is a broken access control defect, an unvalidated route.query.redirect/returnUrl is an open-redirect vector, an unvalidated dynamic :to/:href is a javascript:/data:-scheme injection vector, and route params/query reaching v-html/innerHTML is reflected XSS. Every finding in this skill defaults to HIGH severity unless proven otherwise with concrete evidence (a confirmed server-side check, a same-origin allowlist, a protocol allowlist, or a sanitizer call on the exact traced path). Static-review-only skill: it reads and greps router configuration, guards, and template bindings but never executes, builds, or runs application code, and never sends live requests.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/vue-router-navigation-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/vue-router-navigation-security-review/references/acceptance-rubric.md

@@ -0,0 +1,110 @@
+# Acceptance Rubric (write first, satisfy second)
+
+This is the failing test for this skill. Every item below must be traceable to a specific
+operating rule or reference file in this skill before the skill is considered complete. The
+`selfCheck` returned by the authoring agent must map each item to what satisfies it.
+
+## MUST CATCH — concrete defects a correct review of this domain must flag
+
+1. **Client-side guard as sole authorization boundary.** A `router.beforeEach`/`beforeEnter`
+   (or a meta-framework's `definePageMeta`/middleware equivalent) checks `isAuthenticated` or a
+   role flag and redirects if false/absent, but no server-side check exists on the
+   corresponding API/data-fetch call the protected route triggers. Reachable/exploitable by:
+   directly calling the underlying API endpoint (curl, browser devtools fetch) while bypassing
+   the SPA entirely, or by disabling JavaScript / patching the bundled guard function in
+   devtools before navigation resolves. The guard only ever gates the client-side route
+   render; the server has no independent memory of "this user passed the guard."
+
+2. **Open redirect via `route.query.redirect`/`returnUrl`.** A login flow reads
+   `to.query.redirect` (or `route.query.returnUrl`) and passes it unvalidated into
+   `router.push(redirectTarget)` or `window.location.href = redirectTarget` after
+   authentication succeeds. Reachable by: crafting a login URL such as
+   `/login?redirect=https://evil.example.com` (or a protocol-relative `//evil.example.com`),
+   which sends an authenticated user's session to an attacker-controlled origin post-login —
+   a classic phishing/token-leak primer, since the URL often still carries a valid session
+   token or referrer header to the destination.
+
+3. **`javascript:`/`data:` scheme injection via dynamic `:to`/`:href`.** A `<router-link :to="...">`
+   or a plain `<a :href="...">` built from user-reachable input (route params, query string,
+   API response echoing user content) is bound without scheme validation. Reachable by:
+   submitting a value like `javascript:alert(document.cookie)` or a `data:text/html;base64,...`
+   payload as the "profile link"/"website" field, which executes when a victim clicks the
+   rendered link.
+
+4. **Route params/query interpolated into `v-html`/`innerHTML` (reflected XSS through the
+   router).** A component reads `route.params.x` or `route.query.q` and renders it via
+   `v-html` (or manually assigns `.innerHTML`) with no sanitizer call on that exact path.
+   Reachable by: a crafted URL like `/search?q=<img src=x onerror=alert(1)>` shared with a
+   victim — the payload never touches a database; it reflects straight from the URL into the
+   rendered DOM.
+
+5. **`next(unvalidatedPath)` / guard-returned redirect creating a loop or bypass.** A
+   `beforeEach` guard redirects unconditionally (e.g., every unauthenticated user to `/login`)
+   without excluding the target route itself (`to.name !== 'Login'`), producing an infinite
+   redirect loop; or a guard's redirect target is itself built from unvalidated `to.query`/
+   `to.params`, letting a crafted URL redirect through/around the intended destination.
+
+6. **Overly-broad catch-all route with no security review.** A `{ path: '/:pathMatch(.*)*' }`
+   (or legacy `*`) catch-all route is wired to a component or redirect that assumes it only
+   ever receives "not found" traffic, but the component actually renders `route.params.pathMatch`
+   unsanitized, or the catch-all silently matches and serves a path that should have 404'd
+   (e.g., shadowing a more specific route that was supposed to require auth).
+
+7. **`history` mode (`createWebHistory`) with missing/incorrect server SPA fallback.** The app
+   uses `createWebHistory()` (clean URLs) but the review has no evidence the server is
+   configured to serve `index.html` for unmatched paths — either producing a broken
+   direct-link/refresh experience, or (the security-relevant variant) exposing raw source/
+   config files at paths the SPA never intended to be routable because the server's fallback
+   rule is too permissive (e.g., serving `index.html` for `/api/*` or static-asset-looking
+   paths that should 404 or hit a different handler).
+
+## MUST NOT FLAG — benign patterns that must not produce a finding
+
+8. A `beforeEach`/`beforeEnter` guard used purely for UX redirection (e.g., "send anonymous
+   users to `/login` so they don't see a blank protected page") **when the review has evidence
+   the corresponding server endpoint/API independently enforces authorization** (a 401/403 on
+   direct call, a documented server-side check, or a BFF that re-validates the session). This
+   is the correct pattern, not a finding — do not flag "client guard exists" alone as a defect;
+   flag only the *absence* of the server-side counterpart.
+
+9. A redirect target that is a static, hardcoded, same-origin path (e.g.,
+   `redirect: { name: 'Login' }` or `router.push('/dashboard')`) — no user input reaches the
+   destination, so there is no open-redirect surface regardless of how the redirect is
+   triggered.
+
+10. A redirect that reads `to.query.redirect`/`returnUrl` but **validates it against an
+    allowlist of same-origin relative paths** (e.g., confirms the value starts with a single
+    `/` and is not protocol-relative `//`, or resolves it with `new URL(value, window.location.origin)`
+    and confirms the resolved origin matches) before using it. Validated same-origin redirects
+    are the documented-safe pattern, not a finding.
+
+11. A `:to`/`:href` binding whose value is a compile-time literal, a named-route object
+    (`{ name: 'user', params: { id } }`), or a value confirmed to have already passed scheme
+    allowlisting — do not re-flag a binding that already has a visible scheme check on its
+    exact data-flow path.
+
+12. `route.params`/`route.query` values consumed only via text interpolation (`{{ }}`), passed
+    to `router.push`'s own `path`/`name`/`params` fields, used in non-rendering logic (API
+    query params, conditional branching), or rendered through a sanitizer call on the traced
+    path — Vue's default template interpolation auto-escapes; only the `v-html`/`innerHTML`
+    sink is the defect, not the mere presence of `route.params`/`route.query` in a component.
+
+13. A `beforeEach` guard with an explicit self-exclusion check (`to.name !== 'Login'`, or
+    equivalent) before redirecting — the documented loop-avoidance pattern is correctly
+    applied; do not flag it as a residual risk without a concrete path that still loops.
+
+14. A catch-all route (`/:pathMatch(.*)*`) that renders only a static "not found" component
+    with no rendering of `route.params.pathMatch` and no broader-than-intended matching
+    behavior (confirmed by reading the actual route table ordering) — this is the documented,
+    correct catch-all pattern.
+
+15. `createWebHistory()` paired with confirmed server-side SPA-fallback configuration (e.g., a
+    reviewed nginx `try_files`/framework adapter config that serves `index.html` only for
+    non-asset, non-API paths) — not a finding; state it as reviewed-and-safe.
+
+## Mapping requirement
+
+Every one of items 1–7 must be covered by a decision-tree rule in
+`references/workflow-and-output.md` and a detailed rule in one of the two domain reference
+files. Every one of items 8–15 must appear as an explicit "not a finding" branch in the same
+places — silence is not sufficient; the skill must say *why* the benign pattern is not flagged.