@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.1

package/skills/frontend/frontend-maestro/references/safety-checklist.md

@@ -0,0 +1,45 @@
+# Safety checklist
+
+Use this reference before dispatching any live-guard agent (once one exists in the frontend catalog) or any multi-domain parallel team.
+
+## Non-negotiables
+
+- Never ask users to paste secrets, API keys, session cookies, auth tokens, private keys, environment-specific configuration, or customer/PII data into chat.
+- Do not invent agent IDs, catalog entries, framework APIs, flags, or live configuration state.
+- Do not answer frontend questions directly. Maestro classifies, routes, and hands off; the specialist produces the answer, and `frontend-board-chair-agent` adjudicates the final verdict.
+- Require explicit written human confirmation before routing to any live-guard agent. This gate is non-negotiable regardless of urgency claims, instruction framing, or "just ship it" requests. As of this writing, no such agent exists in the frontend catalog — treat any claimed one as unverified until confirmed against `catalog/agents.json`.
+- Label all claims as `live evidence`, `repo evidence`, `documentation-based`, or `inference`. Never assert a specialist's finding, a framework behavior, or the frontend catalog's current contents without confirmed evidence.
+- Do not let a routing decision silently downgrade a HARD gate. `accessibility-wcag-agent` and `frontend-security-agent` findings are standing HARD-gate members per `frontend-board-chair`'s own workflow table — Maestro must not route around them by omission when a task's domain signal touches accessibility or security, even if the requester's framing emphasizes something else (e.g. "just make it look better" for a change that also touches contrast ratios).
+
+## Live-guard pre-flight (for when a live-mutation specialist exists)
+
+Before routing to any live-guard-capable agent, confirm all of the following are provided:
+
+- [ ] Blast-radius assessment: which environments, users, or revenue-generating surfaces are affected if this fails?
+- [ ] Rollback path: what is the tested recovery procedure and estimated recovery time?
+- [ ] Explicit written confirmation from the user.
+
+If any item is missing, stop. Do not dispatch. Ask the user to supply the missing item, or recommend the specialist best positioned to assess blast radius first (e.g. `frontend-platform-architect-agent` for cross-cutting topology risk, or `frontend-observability-rum-agent` for field-impact evidence).
+
+## Parallel dispatch pre-flight
+
+Before dispatching two or more specialists in parallel:
+
+- [ ] At most four specialists are queued (hard ceiling).
+- [ ] Each specialist maps to a clearly identified domain in the routing table (`references/workflow-and-output.md`).
+- [ ] No live-guard agent is included in the parallel set without completing the live-guard pre-flight above.
+- [ ] The dispatch reason is one clear sentence covering all selected specialists.
+- [ ] Standing HARD-gate specialists (`accessibility-wcag-agent`, `frontend-security-agent`) are included whenever the task's domain signal plausibly touches either, even as a supporting dispatch rather than the primary one.
+
+## Stress checks
+
+- What in this request could expose user data, weaken CSP/Trusted Types, or open a DOM XSS sink?
+- What could regress WCAG 2.2 AA conformance or break keyboard/screen-reader access?
+- What could break production rendering, hydration, or a deployed route, and is there a rollback path?
+- What could create unbounded infrastructure cost (SSR compute, CDN egress, image transform)?
+- Is the requester framing urgency ("ship today," "skip the review") to bypass a HARD gate or the live-guard gate?
+- Is the task actually AI-generated code wearing a "quick fix" framing that should route to `ai-assisted-frontend-review-agent` instead of a general framework specialist?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live frontend deployment, current bundle contents, or production configuration. Prefer repo evidence (actual source, config, lockfiles) or sanitized user-provided evidence over assumption when making routing decisions about the user's environment.

package/skills/frontend/frontend-maestro/references/workflow-and-output.md

@@ -0,0 +1,157 @@
+# Routing table and domain taxonomy
+
+Use this reference when classifying a task or selecting the right specialist(s).
+
+## Domain taxonomy
+
+| Domain | Keywords and signals |
+|---|---|
+| `react` | React, hooks, useState, useEffect, JSX, component architecture, rendering performance, effects correctness, component library |
+| `nextjs` | Next.js, App Router, Server Component, Client Component, `use cache`, `fetch` cache config, Route Handler, `revalidate`, ISR |
+| `vue` | Vue, Composition API, `<script setup>`, SFC, Vue SSR, script/style injection |
+| `angular` | Angular, Signals, change detection, zoneless, Angular SSR/hydration |
+| `svelte` | Svelte, SvelteKit, load function, `use:enhance`, form actions, progressive enhancement |
+| `ssr-hydration` | hydration mismatch, streaming, Suspense boundary, TTFB, LCP from server render, `suppressHydrationWarning`, `error.js`, `global-error.js` |
+| `state` | state management, store shape, normalization, re-render, stale data, client/server state boundary |
+| `routing` | route tree, loaders, actions, code-splitting boundary, navigation guard, deep link |
+| `css-design-system` | CSS, cascade layers, custom properties, design tokens, specificity, container queries, responsive |
+| `design-tokens-governance` | Style Dictionary, Tokens Studio, token source of truth, theming, dark mode, contrast guarantee |
+| `visual-regression` | pixel diff, screenshot test, Chromatic, Storybook test-runner, DOM snapshot |
+| `testing` | unit test, component test, integration test, E2E, test pyramid, flaky suite |
+| `performance-cwv` | Core Web Vitals, LCP, INP, CLS, lab data, field data, performance budget |
+| `build-tooling` | Vite, Webpack, Rollup, code splitting, bundle size budget, vendor chunk, duplicate dependency |
+| `package-governance` | package.json, lockfile, pnpm catalog, npm override, Renovate, Dependabot, dependency confusion |
+| `monorepo-dx` | Turborepo, Nx, workspace topology, remote caching, task graph, stale cache |
+| `browser-compat` | Baseline, caniuse, polyfill, graceful degradation, unsupported browser feature |
+| `accessibility` | WCAG, ARIA, screen reader, keyboard trap, focus order, alt text, a11y audit |
+| `html-semantics` | landmark, heading hierarchy, native element, WHATWG HTML, structured data, semantic markup |
+| `i18n-l10n` | ICU MessageFormat, CLDR, plural rule, RTL, locale, translation readiness |
+| `security` | XSS, CSP, Trusted Types, DOM sink, client-side supply chain, OWASP |
+| `api-bff` | BFF, trust boundary, over-fetching, backend contract, authorization at the edge |
+| `observability-rum` | RUM, OpenTelemetry Web, error tracking, sampling, cardinality, PII in telemetry |
+| `analytics-experimentation` | A/B test, experimentation, event schema, statistical validity, conversion tracking |
+| `pwa-offline` | service worker, web app manifest, offline fallback, installability |
+| `typescript` | tsconfig strictness, type contract, narrowing, `any`-laundering, public API surface |
+| `migration` | legacy jQuery/AngularJS/Backbone migration, monolith-to-microfrontend, framework major-version upgrade, strangler-fig |
+| `finops-cost` | CDN egress, edge/SSR compute cost, image transform cost, build minutes, cost-to-serve |
+| `platform-architecture` | module boundary, build/runtime topology, shared-platform contract, technology-adoption gate, cross-team drift |
+| `platform-foundation` | new-project scaffolding, framework-vs-platform tradeoff, browser-support baseline, cross-cutting HTML/CSS/JS/TS decision that doesn't fit one specialist |
+| `ai-generated-review` | AI-generated code, LLM-generated component, hallucinated API, generated hooks/glue code |
+| `red-team` | adversarial review, elevated review bar, red-team pass, second-opinion security/a11y check |
+
+## Full routing table
+
+### Frameworks
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `react-specialist-agent` | react | Reviewing React component architecture, hooks/effects correctness, or rendering-performance risk |
+| `nextjs-specialist-agent` | nextjs, ssr-hydration | Reviewing Next.js App Router rendering strategy, fetch/cache configuration, or Server/Client Component boundary correctness |
+| `vue-specialist-agent` | vue | Reviewing Vue 3 Composition API architecture or Vue SSR security posture |
+| `angular-specialist-agent` | angular, ssr-hydration | Reviewing Angular Signals architecture, change-detection strategy, or SSR/hydration correctness |
+| `svelte-sveltekit-specialist-agent` | svelte | Reviewing SvelteKit routing/load-function correctness or progressive-enhancement resilience |
+
+### Rendering
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `ssr-hydration-streaming-agent` | ssr-hydration | Diagnosing hydration-mismatch errors, slow-data waterfalls, or incorrect Suspense/error-boundary placement |
+
+### State and routing
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `state-management-data-flow-agent` | state | Reviewing client/server state boundaries, store shape, normalization, or re-render performance |
+| `routing-navigation-agent` | routing | Reviewing route-tree structure, data-loading strategy, code-splitting boundaries, or navigation-guard logic |
+
+### Styling and design systems
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `css-architecture-agent` | css-design-system | Reviewing CSS specificity, cascade-layer strategy, or custom-property/design-token architecture |
+| `design-systems-governance-agent` | design-tokens-governance | Reviewing design-token pipelines and component-library governance |
+| `visual-regression-agent` | visual-regression | Reviewing pixel-diff or DOM-snapshot visual regression pipelines |
+
+### Testing and quality
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `testing-quality-engineering-agent` | testing | Reviewing or designing frontend test strategy across unit, component, integration, and E2E layers |
+
+### Performance and build
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `web-performance-core-vitals-agent` | performance-cwv | Triaging Core Web Vitals (LCP, INP, CLS) using lab and field evidence |
+| `build-tooling-bundling-agent` | build-tooling | Reviewing Vite/Webpack/Rollup build configuration, code-splitting strategy, or bundle budgets |
+| `package-governance-agent` | package-governance | Reviewing package.json manifests, lockfiles, or dependency version policy |
+| `monorepo-dx-agent` | monorepo-dx | Reviewing monorepo task-graph orchestration or remote-caching correctness |
+
+### Compatibility and semantics
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `browser-compatibility-agent` | browser-compat | Checking used web-platform features against the org's supported-browser matrix |
+| `accessibility-wcag-agent` | accessibility | Auditing markup and components against WCAG 2.2 A/AA success criteria |
+| `html-semantics-agent` | html-semantics | Reviewing markup structure, landmark/heading hierarchy, or ARIA application |
+| `internationalization-localization-agent` | i18n-l10n | Verifying i18n architecture and l10n readiness |
+
+### Security and boundaries
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `frontend-security-agent` | security | Hunting DOM XSS sinks, CSP/Trusted Types gaps, or client-side supply-chain risk |
+| `api-integration-bff-agent` | api-bff | Reviewing the contract, ownership, and trust boundary between frontend clients and backend/BFF layers |
+
+### Observability, analytics, and offline
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `frontend-observability-rum-agent` | observability-rum | Reviewing or designing RUM instrumentation (Core Web Vitals, OTel Web traces, error tracking) |
+| `product-analytics-experimentation-agent` | analytics-experimentation | Reviewing frontend analytics instrumentation and A/B experimentation setups |
+| `pwa-offline-capability-agent` | pwa-offline | Validating service-worker caching behavior, manifest installability, or offline-fallback coverage |
+
+### Contracts, migration, and cost
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `typescript-contracts-agent` | typescript | Reviewing tsconfig strictness posture, exported type contracts, or narrowing correctness |
+| `frontend-migration-modernization-agent` | migration | Planning or de-risking a large-scale frontend migration or framework major-version upgrade |
+| `frontend-finops-cost-to-serve-agent` | finops-cost | Quantifying CDN egress, edge/SSR compute, image-transform, or build-minute cost impact |
+
+### Cross-cutting architecture
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `frontend-platform-architect-agent` | platform-architecture | Deciding cross-cutting module boundaries, build/runtime topology, or technology-adoption gates |
+| `web-platform-foundation-agent` | platform-foundation | Handling a cross-cutting HTML/CSS/JS/TS decision (new-project scaffolding, framework-vs-platform tradeoff, browser-support baseline) that doesn't fit one narrow specialist |
+| `javascript-runtime-agent` | ssr-hydration, platform-foundation | Reviewing event-loop/microtask ordering, Promise composition, or DOM event-handling lifecycle for race conditions or listener leaks |
+
+### AI-generated code and red-team
+
+| Agent | Domain(s) | Use when… |
+|---|---|---|
+| `ai-assisted-frontend-review-agent` | ai-generated-review | Applying an elevated review bar to AI/LLM-generated frontend code |
+| `enterprise-red-team-review-agent` | red-team | Running a mandatory or spot-check adversarial second-opinion pass (security review, AI-generated code review, or production incident workflows, per `frontend-board-chair`'s workflow table) |
+
+### Live-guard (none currently cataloged)
+
+No agent in the frontend catalog is currently capable of a live/production mutation (deploy, feature-flag flip in prod, cache purge, rollback trigger). If a task carries a live-guard signal, say so explicitly and stop — do not invent a live-guard agent, and do not route the task to a static-review specialist as a substitute for a production-mutation gate. Re-check `catalog/agents.json` for a `frontend` provider agent whose ID or summary indicates live/production-mutation capability before asserting this is still true.
+
+## Live-guard gate protocol
+
+If a future frontend catalog addition introduces a live-mutation-capable specialist, before routing to it, surface all three and wait for explicit written confirmation:
+
+1. **Blast-radius assessment** — what environments, users, or revenue-generating surfaces are affected if this goes wrong?
+2. **Rollback path** — what is the tested rollback procedure and estimated recovery time?
+3. **Explicit confirmation** — "I confirm I understand the blast radius and rollback path. Proceed."
+
+## Response shape
+
+Every Maestro response begins with the routing header:
+```
+Route: <agent-name(s)>
+Reason: <one sentence>
+Mode: <single | parallel (N specialists) | live-guard-gate | unclassified>
+```
+Followed by: dispatched specialist output (summarized), then a handoff note to `frontend-board-chair-agent`.

package/skills/frontend/frontend-migration-modernization-plan/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: frontend-migration-modernization-plan
+description: Build a phased, reversible plan to migrate or modernize a legacy frontend surface (jQuery/Backbone/AngularJS to a modern framework, CRA/Webpack to Vite, or a same-framework major-version bump) using strangler-fig sequencing with measurable exit criteria per phase, without defaulting to a full rewrite.
+allowed-tools: Read Grep Glob WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: architecture
+---
+
+# Frontend Migration & Modernization Plan
+
+## Purpose
+
+Most full frontend rewrites blow their timeline/budget or never ship, while unmanaged incremental migrations rot into permanent dual-stack debt. This skill exists to produce a bounded, reversible, metric-gated migration plan without stuffing the entire migration playbook (strangler patterns, legacy-jQuery inventory tactics, framework-upgrade risk analysis, rollback design) into every response — those load only when the task needs them.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- plan a migration off a legacy stack (jQuery, Backbone, AngularJS, old CRA/Webpack setup) to a modern framework or bundler,
+- sequence a same-framework major-version upgrade (React 17→19, Angular N→N+2, Vue 2→3) as a phased rollout,
+- design a strangler-fig boundary (route table, module federation seam, adapter layer) between legacy and modern code,
+- define rollback and legacy-decommission exit criteria for an in-flight migration.
+
+## Lean operating rules
+
+- First classify the migration type: cross-framework (paradigm shift, high risk) vs. same-framework major-version (breaking-change surface, narrower risk). They need different reference material — do not blend them.
+- Do not recommend a full rewrite as the default. Only recommend it when incremental strangling is demonstrably infeasible (e.g. the runtime model itself is incompatible), and say so explicitly with the reason.
+- Every phase must have a stated rollback action completable within one deploy cycle and a measurable exit metric (not a date-only gate).
+- Treat the legacy-decommission step as mandatory and time-boxed; a migration plan with no decommission criteria is incomplete.
+- Verify target-framework migration APIs/codemods via Context7 or official docs before citing them; never invent a codemod name or flag.
+- Never propose a migration phase that merges auth/session state across old and new stacks without a named security review gate.
+- Load `references/strangler-boundary-design.md` only when the user needs the actual seam/proxy design, not for a high-level phase summary.
+- Load `references/rollback-and-exit-criteria.md` only when defining or auditing phase gates.
+- Load `references/rewrite-vs-incremental-decision.md` only when the user is undecided between rewrite and incremental strangling.
+
+## Context7 Documentation Protocol
+
+Every framework-specific migration API, codemod name, config flag, or "recommended path" claim in a response must be traceable to one of:
+
+1. **Context7-verified** — resolved via `mcp__Context7__resolve-library-id` then confirmed with `mcp__Context7__query-docs` against the specific library (e.g. `/reactjs/react.dev`, `/vercel/next.js`) in this session or a prior verification you can cite by source URL.
+2. **Official docs (direct citation)** — a specific docs URL, used when Context7 has no coverage for that library/version.
+3. **Inference** — explicitly labeled as such; never presented as a verified codemod/flag.
+
+Do not invent codemod names, CLI flags, or config keys. If Context7 and official docs both lack coverage for a specific claim (e.g. an exact flag for a niche bundler), say so and mark it `inference — verify against installed tooling` rather than guessing. Re-verify before citing if the last check is not from the current session, since migration tooling and recommended paths change across releases (e.g. Next.js has shipped multiple generations of App Router migration guidance; React Compiler adoption guidance is still evolving).
+
+Confirmed in this skill's authoring session (re-verify if stale):
+
+- Next.js ships `npx @next/codemod cra-to-next` for CRA → Next.js migration, and a `rewrites().fallback` config for proxying unmigrated routes during incremental strangler cutover. Source: `vercel/next.js` docs (`01-app/02-guides/upgrading/codemods.mdx`, `01-app/03-api-reference/05-config/01-next-config-js/rewrites.mdx`).
+- Next.js explicitly supports `app/` and `pages/` directories coexisting during App Router migration and recommends breaking the migration into small incremental steps. Source: `vercel/next.js` docs (`01-app/02-guides/migrating/app-router-migration.mdx`).
+- React Compiler supports incremental adoption via `compilationMode: 'annotation'` plus `"use memo"` / `"use no memo"` directives, letting teams opt components in/out individually before flipping to full inference mode. Source: `reactjs/react.dev` docs (`reference/react-compiler/directives.md`, `learn/react-compiler/incremental-adoption.md`).
+
+## References
+
+Load these only when needed:
+
+- [Strangler boundary design](references/strangler-boundary-design.md) — use when the user needs the actual technical seam (proxy/route-table, module federation, adapter layer) between legacy and modern code, not just a phase list.
+- [Rollback and exit criteria](references/rollback-and-exit-criteria.md) — use when defining or auditing what makes a phase safe to promote, and what makes legacy code eligible for decommission.
+- [Rewrite vs. incremental decision](references/rewrite-vs-incremental-decision.md) — use only when the user is weighing a full rewrite against strangler-fig incrementalism and needs the decision criteria, not for already-decided migrations.
+
+## Response minimum
+
+Return, at minimum:
+
+- the migration type classification (cross-framework vs. same-framework) and why,
+- the phase sequence with entry/exit criteria per phase,
+- the rollback design per phase,
+- the legacy-decommission criteria and time-box,
+- evidence level for any framework API/codemod cited (Context7-verified vs. inference).

package/skills/frontend/frontend-migration-modernization-plan/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "frontend-migration-modernization-plan",
+  "name": "Frontend Migration & Modernization Plan",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Builds a phased strangler-fig migration/modernization plan for legacy frontend stacks (jQuery/Backbone/AngularJS, old bundlers, framework major versions) with rollback gates, exit criteria, and business-risk-first sequencing, loading legacy-pattern, risk, and rollback references progressively rather than dumping the whole migration playbook into every prompt.",
+  "source_type": "original",
+  "official_docs": [
+    "https://react.dev/learn/react-compiler/incremental-adoption",
+    "https://nextjs.org/docs/app/guides/migrating",
+    "https://vitejs.dev/guide/migration",
+    "https://angular.dev/reference/migrations"
+  ],
+  "security_notes": "Never propose a migration phase that merges auth/session state across old and new stacks without a named security review gate. Treat every phase's rollback path as a hard requirement, not optional documentation.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/frontend-migration-modernization-plan",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/frontend-migration-modernization-plan/references/rewrite-vs-incremental-decision.md

@@ -0,0 +1,49 @@
+# Rewrite vs. Incremental Strangler Decision
+
+Use this reference only when the user is genuinely undecided between a full rewrite and an incremental strangler-fig migration. If the user has already committed to one path, do not relitigate it here — go to the relevant execution reference instead.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "The old code is so bad that a rewrite is obviously faster."
+
+That is almost never true at the scope people imagine. A rewrite discards the accumulated bug fixes, edge-case handling, and business-rule knowledge encoded in the legacy UI — knowledge that usually is not written down anywhere else. Teams that rewrite typically re-discover that knowledge the hard way, in production, after cutover, when rollback is hardest.
+
+The inverse bad assumption is also common:
+
+> "We should never rewrite; incremental is always safer."
+
+That is also false. If the legacy runtime model is fundamentally incompatible with the target (e.g. synchronous global-state jQuery plugins that assume full-page reloads, wired into a codebase with no seams at all), forcing an incremental strangler pattern onto it can cost more than a bounded rewrite of a small, well-scoped surface.
+
+## Decision criteria (score each, do not eyeball it)
+
+Ask these questions and get concrete answers, not vibes:
+
+1. **Are there any existing seams?** Route boundaries, iframe boundaries, distinct page loads, or module boundaries where legacy and new code could coexist without deep coupling. No seams at all is the strongest signal toward a bounded rewrite of that specific surface — not the whole app.
+2. **What is the blast radius of the surface in question?** A single internal admin page vs. the primary customer checkout flow have very different risk tolerances for "big bang" replacement.
+3. **Is there a shared auth/session model that both stacks must honor simultaneously?** If yes, this is a hard security gate (see SKILL.md operating rules) and it must be solved before any coexistence phase, regardless of which path you choose.
+4. **How much business logic is embedded in the view layer with no test coverage?** High untested logic in the view layer favors strangling in small verifiable slices, not a big-bang rewrite, because you can diff behavior slice-by-slice.
+5. **What is the team's real capacity to run two stacks in production concurrently?** Strangler patterns are not free — they cost ongoing dual-stack operational overhead (two build pipelines, two deploy paths, two sets of dependencies to patch). If the team cannot sustain that for the migration's duration, say so explicitly; it changes the sequencing, not the recommendation to avoid rewrite.
+6. **Is the target framework migration path officially supported for incremental coexistence?** For example, Next.js explicitly documents `app/` and `pages/` directories coexisting and recommends breaking migration into small steps (Context7-verified: `vercel/next.js` docs, `app-router-migration.mdx`). Absence of an official coexistence path for a given framework pair is a signal toward more conservative, smaller-scoped increments — not automatically toward a rewrite.
+
+## Default and its exception
+
+**Default: incremental strangler-fig migration**, scoped by seam (route, module federation boundary, or adapter layer), sequenced business-risk-first (§ see SKILL.md phase sequencing).
+
+**Exception — recommend a bounded rewrite only when:**
+- no viable seam exists for the surface in question, AND
+- the surface is small/isolated enough that its blast radius is contained, AND
+- the team explicitly accepts the rewrite's discovery risk (silent behavior regressions) with a stated verification plan (parity testing, feature-flagged rollout, or shadow traffic comparison).
+
+Never recommend a rewrite for an entire application as a first move. If the user pushes for "just rewrite it all," push back and ask for the seam analysis above first.
+
+## When to push back
+
+Push back if the user says:
+
+- "The old code is a mess, let's just start over" — with no seam analysis and no scoping of blast radius.
+- "We'll run both stacks forever, it's fine" — dual-stack maintenance without a decommission time-box is not a migration, it's permanent debt (see `rollback-and-exit-criteria.md`).
+- "Auth can stay separate for now, we'll unify it later" — unresolved shared-session risk is a security gate, not a deferred nice-to-have.
+
+Those are not pragmatic shortcuts. They are how migrations become permanent, half-finished liabilities.

package/skills/frontend/frontend-migration-modernization-plan/references/rollback-and-exit-criteria.md

@@ -0,0 +1,75 @@
+# Rollback and Exit Criteria
+
+Use this reference when defining or auditing what makes a migration phase safe to promote, and what makes legacy code eligible for decommission. Every phase in a migration plan produced by this skill must satisfy the rules below — a phase with a date-only gate and no measurable exit criteria is not a real gate.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "We'll know it's done when it feels stable / when the sprint is over."
+
+That is not an exit criterion, it is a shrug. A migration plan that cannot say, in advance, exactly what evidence promotes a phase and exactly what action reverts it is not a plan — it is hope with a Gantt chart.
+
+## Non-negotiable design rules
+
+### 1. Every phase needs a rollback action completable within one deploy cycle
+
+Not "we could revert the commit eventually." A concrete, rehearsed action: flip a feature flag, revert a route-table entry (see `strangler-boundary-design.md`), or redirect the fallback proxy back to the legacy origin. If the rollback action requires a data migration to reverse, it is not a one-deploy-cycle rollback — flag that phase as higher risk and require an explicit sign-off before it ships, not an assumption that "we probably won't need to roll back."
+
+### 2. Every phase needs a measurable exit metric, not a date
+
+Acceptable exit metrics (pick what's relevant to the phase, be specific, not generic):
+
+- **Correctness parity**: error rate / exception rate on the migrated surface within an agreed delta of the legacy baseline over a stated observation window (e.g. 7 days of production traffic, not "looked fine in staging").
+- **Performance budget**: a named Core Web Vitals or custom timing metric within budget on real user traffic (field data), not lab-only Lighthouse runs. State the budget number and the percentile (e.g. p75 LCP) before the phase starts, not after.
+- **Accessibility parity**: no WCAG 2.2 AA regressions introduced on the migrated surface versus the legacy baseline — verified, not assumed, because visual parity does not imply a11y parity (a modern component can look identical and still break keyboard nav or screen-reader semantics).
+- **Functional coverage**: percentage of legacy behavior with an automated test (unit/E2E) proving parity before the legacy path is removed for that surface. "It looks right when I clicked around" is not functional coverage.
+
+A phase gate that only says "ship by end of quarter" with no metric above attached is incomplete — say so explicitly rather than accepting a date-only gate.
+
+### 3. Rollback and forward-progress must not both depend on the same broken assumption
+
+If the rollback path assumes the legacy stack is still fully deployable and the forward path assumes the legacy stack can be safely decommissioned, decide explicitly which is true at each point in time. Common failure: teams decommission legacy build infrastructure or dependencies "since we're mostly migrated" while the rollback plan still assumes that infrastructure exists. State exactly when the legacy stack becomes non-reinstatable, and do not cross that line until the exit criteria for full decommission (below) are met.
+
+### 4. The legacy-decommission step is mandatory and time-boxed
+
+A migration plan that ends at "new code is live in production alongside the old code, indefinitely" is not finished — it has produced a permanent second stack to maintain, patch for security, and onboard new engineers into. Every plan produced by this skill must include an explicit decommission phase with:
+
+- a stated time-box (a date or a trigger condition — e.g. "30 days after the correctness-parity metric holds"),
+- the specific artifacts being removed (routes, build config, dependencies, feature flags, dual-stack CI jobs),
+- a final rollback-of-last-resort note: once legacy code/dependencies are actually deleted (not just unrouted), rollback is no longer a redeploy — it is a restore from version control and a re-provisioning effort. State this transition point explicitly so nobody assumes rollback stays cheap forever.
+
+### 5. Security/auth coexistence gates are checkpoints, not footnotes
+
+If any phase requires legacy and modern stacks to share auth/session state (see `strangler-boundary-design.md`, route-table seam), that phase's exit criteria must include an explicit security review sign-off as a blocking gate — not a "should be fine" assumption. Do not let a convenience shortcut ("just share the cookie") skip this gate.
+
+## Minimal safe phase-gate template
+
+For each phase, state:
+
+1. **Entry criteria** — what must be true before this phase starts (e.g. prior phase's exit metric held for N days).
+2. **Rollback action** — the specific, one-deploy-cycle-or-less action, and who/what triggers it (automatic alert threshold vs. manual call).
+3. **Exit metric(s)** — the specific measurable target(s) from the categories above, with number, percentile/window, and data source (field vs. lab, explicitly labeled).
+4. **Decommission artifacts** (only for the final phase(s)) — exactly what gets deleted and the time-box/trigger for deletion.
+
+## Adversarial checklist
+
+Before finalizing a phase gate, answer these:
+
+- If this phase fails its exit metric, what is the exact command/flag/route change that reverts it, and has anyone rehearsed it?
+- What happens to in-flight user sessions or in-progress transactions at the moment of rollback?
+- Is the exit metric based on field data (real user traffic) or only lab data (synthetic runs)? If only lab, say so — it does not prove field parity.
+- Does any exit metric assume a sample size / observation window long enough to be statistically meaningful, or is it "looked fine after a day"?
+- Who has authority to declare the decommission time-box met, and what happens if the trigger condition never fires (permanent stall)?
+
+If you cannot answer these for a given phase, the phase gate is not ready to ship — say so rather than presenting an incomplete gate as final.
+
+## When to push back
+
+Push back if the user proposes:
+
+- "We'll decide the rollback plan if we need it" — rollback design is not optional and not deferrable to incident time.
+- "Let's skip the decommission step, we can clean up later" — "later" is how dual-stack maintenance becomes permanent.
+- "The exit criteria is just 'ship it and see'" — that is not a gate, it is an unmonitored rollout.
+
+Those are not pragmatic shortcuts. They are how a bounded migration plan turns into indefinite dual-stack technical debt.

package/skills/frontend/frontend-migration-modernization-plan/references/strangler-boundary-design.md

@@ -0,0 +1,63 @@
+# Strangler Boundary Design
+
+Use this reference only when the user needs the actual technical seam between legacy and modern code — a proxy/route table, a module federation boundary, or an in-page adapter layer — not for a high-level phase summary (that belongs in the main SKILL.md response).
+
+## What people get wrong
+
+The naive story is:
+
+> "We'll put the new framework next to the old one and slowly move pages over."
+
+That undersells the seam design problem. The seam is where almost all migration risk concentrates: shared routing, shared auth/session, shared global CSS/JS, and shared build tooling all leak across the boundary unless it is designed deliberately. A vague "next to" is not a seam; it is an accident waiting to surface in production.
+
+Officially grounded seam patterns (Context7-verified where cited):
+
+## 1. Route-table / reverse-proxy seam (cross-stack, coarse-grained)
+
+The legacy app and the new app live at the same origin (or behind a shared edge proxy), and routing decides which stack serves which path. This is the seam Next.js documents directly: a `rewrites().fallback` config that proxies every unmatched route to the existing legacy site, so you migrate route-by-route while the legacy app keeps serving everything not yet migrated (Context7-verified: `vercel/next.js` docs, `rewrites.mdx`).
+
+Design rules for this seam:
+- Decide route ownership explicitly per URL prefix; do not let both stacks claim the same path under different conditions (e.g. query-param-based routing to two different apps at the same path is a maintenance trap).
+- Shared navigation chrome (header/footer/nav) rendered by two different stacks will drift visually and behaviorally. Either keep it duplicated with a visual-regression gate on both, or extract it into a served fragment neither app owns independently.
+- Session/auth cookies must be readable by both origins/apps identically, or you have silently created a security gate (see SKILL.md — this needs an explicit review, not an assumption that "cookies just work").
+
+## 2. Directory/module coexistence seam (same-framework major upgrades, or App Router migrations)
+
+Some frameworks explicitly support two routing/rendering models coexisting in the same codebase during migration — for example, Next.js `app/` and `pages/` directories running side by side, with official guidance to migrate in small incremental steps rather than all at once (Context7-verified: `vercel/next.js` docs, `app-router-migration.mdx`).
+
+Design rules for this seam:
+- Confirm the specific framework version actually supports this coexistence mode before planning around it — do not assume parity across major versions without checking current docs for that version.
+- Treat each migrated unit (page, route segment, module) as independently revertible: moving a route from the old model to the new one should be revertible by moving it back, not by reverting a large multi-file commit.
+- Watch for cross-cutting concerns that do not respect the module boundary: global CSS resets, shared state stores, and app-wide providers/interceptors often need to be dual-registered or bridged, and that bridging code is itself migration debt that must be tracked and later removed.
+
+## 3. Adapter/wrapper seam (embedding new components inside legacy views, or vice versa)
+
+A common fine-grained seam: mount a modern component (e.g. React) inside a specific DOM node that the legacy stack (e.g. jQuery/Backbone) still controls, via an explicit mount/unmount adapter. This is the right seam when there is no clean route-level boundary — e.g. a single complex widget inside an otherwise-legacy page.
+
+Design rules for this seam:
+- The adapter must own an explicit lifecycle contract: who calls mount, who calls unmount, and what happens on the legacy view's re-render (does it destroy and remount the modern component, or does it leave it alone?). An undefined lifecycle contract causes memory leaks or duplicate event listeners — this is the most common actual incident in this pattern.
+- Do not share mutable state between the two stacks by direct object reference across the boundary. Pass data in, read data out via an explicit, versioned contract (props in, callback/event out), so either side can evolve independently.
+- CSS leakage across the boundary (legacy global styles cascading into the modern component's markup, or vice versa) needs a stated containment strategy (scoped classes, shadow DOM, or a documented "no shared class names" rule) before this seam ships to production, not after a visual bug report.
+
+## 4. Module federation / micro-frontend seam (large-scale, multi-team boundary)
+
+When multiple teams own different areas of the surface, a build-time or runtime module federation boundary lets each area upgrade independently. This is a heavier seam — it introduces shared-dependency version negotiation (React/framework version skew between federated modules) as a first-class operational concern.
+
+Design rules for this seam:
+- Explicitly decide and document which shared dependencies (framework, design-system, state library) are singleton-shared vs. independently versioned per module. Undecided version skew is the top failure mode of federation-based strangling.
+- Define a contract for cross-module navigation and shared auth/session state before any module ships, not as each new module is added ad hoc.
+
+## Verification targets
+
+- For any Next.js-specific claim above (rewrites/fallback config, app/pages coexistence), re-verify the exact config shape against the installed Next.js version's current docs before writing production config — minor/major versions have changed this surface across releases.
+- For any other framework/bundler pairing not covered above, resolve the library via Context7 and query current docs for an "incremental adoption" or "migration guide" page before proposing a specific seam mechanism; do not assume feature parity with the Next.js/React examples above.
+
+## When to push back
+
+Push back if the user asks for:
+
+- a seam with no explicit route/module ownership decision ("we'll figure out which app handles what dynamically")
+- shared mutable state passed by direct reference across the legacy/modern boundary "to keep it simple"
+- a module federation boundary with no shared-dependency version policy
+
+Those are not simplifications. They are the exact places migrations go from "in progress" to "permanently half-broken."

package/skills/frontend/frontend-observability-rum-instrumentation/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: frontend-observability-rum-instrumentation
+description: Design or review browser-side Real User Monitoring instrumentation for Core Web Vitals (LCP, INP, CLS) using the web-vitals attribution build and distributed tracing via OpenTelemetry Web, enforcing lab-vs-field evidence labeling, sampling/cardinality sizing, and PII-in-telemetry controls, with library-specific wiring references loaded only when instrumentation code is actually being written or reviewed.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: observability
+---
+
+# Frontend Observability RUM Instrumentation
+
+## Purpose
+
+Lab-only performance testing (Lighthouse, synthetic CI runs) systematically misses the device/network diversity of real users, and ad-hoc telemetry instrumentation routinely leaks PII into span attributes or blows up observability cost through unsampled high-cardinality export. This skill wires and reviews field RUM (web-vitals + OpenTelemetry Web) with explicit evidence labeling and privacy/cost guardrails baked in from the start.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- instrument Core Web Vitals (LCP, INP, CLS) field measurement in a web app,
+- set up or review OpenTelemetry Web browser tracing (document load, fetch/XHR spans),
+- review an existing RUM/telemetry pipeline for PII exposure or sampling/cost issues,
+- interpret or report on Core Web Vitals data and needs a lab-vs-field distinction made explicit,
+- set or validate a performance budget against field p75 data.
+
+## When NOT to use
+
+- Diagnosing *why* a specific LCP/INP/CLS number is high (phase decomposition of an existing regression) — hand off to `core-web-vitals-triage`; this skill instruments the pipeline that produces the data, it does not decompose an already-captured regression.
+- Bundle size, code-splitting, or caching remediation once a cause is known — hand off to `bundle-budget-code-splitting-review` or `service-worker-cache-strategy-review`.
+- Server-side or backend-service tracing with no browser-origin span — this skill is scoped to browser-side RUM and OpenTelemetry Web only.
+
+## Context7 Documentation Protocol
+
+`web-vitals` and OpenTelemetry Web packages ship breaking API changes across major versions (attribution-build option shapes, sampler class names, exporter constructor options), and memorized snippets go stale. Before writing or reviewing instrumentation code:
+
+1. Call `ToolSearch` with query `"context7"` (or `"select:mcp__Context7__resolve-library-id,mcp__Context7__query-docs"`) to load the Context7 tools if not already loaded this session.
+2. Call `mcp__Context7__resolve-library-id` for `web-vitals` and/or `opentelemetry-js` before making any claim about their current API shape. Verified IDs as of this skill's `updated` date: `/googlechrome/web-vitals` and `/open-telemetry/opentelemetry-js`.
+3. Call `mcp__Context7__query-docs` for the specific mechanism in scope — e.g. "attribution build generateTarget option", "INPAttributionReportOpts durationThreshold", "WebTracerProvider spanProcessors config", "TraceIdRatioBasedSampler" — before ruling on it. Do this per review; do not reuse a prior session's memory of these APIs.
+4. Known facts verified via Context7 as of this skill's `updated` date: the attribution build (`web-vitals/attribution`) accepts `AttributionReportOpts` (`reportAllChanges`, `generateTarget`) on `onCLS`/`onFCP`/`onLCP`/`onTTFB`, and `INPAttributionReportOpts` additionally exposes `durationThreshold` (default `40`) and `includeProcessedEventEntries` (default `true`) on `onINP`. `WebTracerProvider` (from `@opentelemetry/sdk-trace-web`) takes a `spanProcessors` array in its constructor — do not tell a user to call a separate `addSpanProcessor` method as the primary pattern without checking the installed SDK version. `TraceIdRatioBasedSampler` takes a single ratio argument (0–1) and is normally wrapped in `ParentBasedSampler({ root: ... })` so that downstream/parent sampling decisions are respected.
+5. If Context7 is unavailable or returns no relevant match, fall back to `official_docs` / `references/*.md` and mark the claim `documentation-based (Context7 unavailable)` rather than presenting it as freshly verified.
+6. Never invent a `web-vitals` metric field, attribution property, OpenTelemetry exporter option, or sampler class that no queried source confirms.
+
+## Lean operating rules
+
+- Always label every performance number as lab evidence (Lighthouse/CI/synthetic) or field evidence (RUM, real users — state the percentile; p75 is the CWV standard) — never let the two blur into an unlabeled "the site is fast" claim.
+- Default to the standard `web-vitals` build (`onLCP`/`onINP`/`onCLS`) for production reporting; only use the `/attribution` build's richer diagnostic payload when actively debugging a specific regression, and only send that extra payload to a dev/debug destination, not blanket production export.
+- Do not enable `reportAllChanges: true` in production by default — it multiplies event volume for a debugging-only benefit.
+- Before adding any custom span/metric attribute, run it through a PII check: no raw URLs with query strings, no user IDs, no free-text form input, no precise geolocation, unless explicitly scrubbed and justified.
+- Size the OpenTelemetry sampling rate (e.g. `TraceIdRatioBasedSampler` wrapped in `ParentBasedSampler`) against the stated/estimated traffic volume and the backend's cost/cardinality limits; never recommend 100% unsampled export for a high-traffic app without an explicit cost review.
+- Use OpenTelemetry Semantic Conventions attribute names instead of inventing ad-hoc span/attribute naming, so telemetry stays queryable/comparable across services.
+- Treat any recommended performance budget threshold as grounded in web.dev's documented "good" ranges (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1 at p75) unless the org has an explicitly stricter documented SLO.
+- This skill performs static review and instrumentation-code authoring only; it does not deploy telemetry configuration to production or flip sampling/export settings on a live collector without explicit human sign-off logged outside this skill.
+
+## References
+
+Load these only when needed:
+
+- [web-vitals attribution build wiring](references/web-vitals-attribution-wiring.md) — use when writing or reviewing the actual `onLCP`/`onINP`/`onCLS` instrumentation call, choosing between standard and attribution builds, or setting `generateTarget`/`durationThreshold`/`reportAllChanges`.
+- [OpenTelemetry Web tracing wiring](references/opentelemetry-web-tracing-wiring.md) — use only when wiring or reviewing `WebTracerProvider`, `DocumentLoadInstrumentation`, `FetchInstrumentation`, exporter, or sampler configuration.
+- [Sampling, cardinality, and PII controls](references/sampling-cardinality-pii-controls.md) — use when sizing sampling rates against traffic/cost, naming attributes via Semantic Conventions, or auditing an existing pipeline for PII leakage.
+
+## Response minimum
+
+Return, at minimum:
+
+- the metric/trace component in scope and whether guidance concerns lab or field measurement,
+- evidence level for any performance claim (lab-evidence, field-evidence with percentile, or documentation-based),
+- instrumentation code or review findings with exact API options used,
+- PII-in-telemetry check result for every attribute touched,
+- sampling-rate rationale tied to stated traffic volume and cost constraints.

package/skills/frontend/frontend-observability-rum-instrumentation/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "frontend-observability-rum-instrumentation",
+  "name": "Frontend Observability RUM Instrumentation",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Skill for designing and reviewing Real User Monitoring instrumentation using the web-vitals attribution build and OpenTelemetry Web, with explicit sampling, cardinality, and PII-in-telemetry controls and lab-vs-field evidence labeling.",
+  "source_type": "adapted",
+  "official_docs": [
+    "https://web.dev/articles/vitals",
+    "https://github.com/GoogleChrome/web-vitals",
+    "https://opentelemetry.io/docs/languages/js/",
+    "https://opentelemetry.io/docs/specs/semconv/"
+  ],
+  "security_notes": "Never recommends capturing full URLs with query strings, user identifiers, or free-text form values as span/metric attributes without explicit scrubbing. Read-only review of existing instrumentation; does not deploy telemetry config changes to production without explicit human sign-off logged outside this skill.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/frontend-observability-rum-instrumentation",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}