@raishin/vanguard-frontier-agentic 3.0.1 → 3.1.0

package/skills/frontend/nuxt-fullstack-security-review/references/workflow-and-output.md

@@ -0,0 +1,127 @@
+# Review Workflow and Findings Contract
+
+Use this reference for the step-by-step review procedure, the decision tree across all
+five defect classes, and the required output shape. Load the two domain references only
+for the specific defect class the code under review actually raises.
+
+## Prerequisites
+
+- Read `package.json` / `nuxt.config.ts` to confirm the Nuxt major (3 vs 4) — API names
+  and defaults are stable across 3/4 for everything this skill covers, but confirm
+  before citing version-specific behavior.
+- Identify the review surface: `nuxt.config.ts` (`runtimeConfig`, `routeRules`,
+  `modules`), any `composables/`, `plugins/`, `server/api/`, `server/routes/`,
+  `server/middleware/` files, and any template/component using `useState`/`v-html`.
+
+## Workflow
+
+1. **Read `nuxt.config.ts`'s `runtimeConfig` block in full.** Classify every key as
+   private (top-level, server-only) or public (nested under `public`, or `app`).
+   For every public key, ask whether its name/default value suggests a secret. See
+   `references/runtime-config-and-cross-request-state.md`, Part 1.
+2. **Grep for `NUXT_PUBLIC_*` and other `NUXT_*` env var names** in `.env*` files and
+   deployment config; map each back to the `runtimeConfig` key it overrides and confirm
+   the public/private classification holds.
+3. **Enumerate module-scope declarations reachable from server-rendered code.** Grep
+   `composables/`, `plugins/`, `server/api/`, `server/middleware/` for `useState(`,
+   `ref(`, `reactive(`, and mutable object/array literals declared outside any
+   function body. Classify each by mutability/reactivity and reachability. See
+   `references/runtime-config-and-cross-request-state.md`, Part 2.
+4. **Enumerate every server-route outbound `$fetch`/`ofetch`/`event.$fetch`/
+   `useRequestFetch` call.** Trace the destination URL to its origin; trace which
+   headers are forwarded (via `event.$fetch`'s default context propagation,
+   `useRequestHeaders(...)`, or manual header spreading) and to where. See
+   `references/ssrf-payload-and-response-headers.md`, Part 1.
+5. **Enumerate `useState`/payload values that carry user-controlled or user-echoed
+   content**, and trace them forward to any eventual `v-html`/HTML-injection sink.
+   Separately check for any custom `definePayloadReducer`/`definePayloadReviver` logic
+   that bypasses Nuxt's own `devalue`-based serialization. See
+   `references/ssrf-payload-and-response-headers.md`, Part 2.
+6. **Check for a security-header mechanism**: `routeRules` `headers` entries, a
+   security module in `modules`, or `useResponseHeader(...)` calls, and confirm actual
+   route-glob coverage against the app's real surface (auth pages, forms, admin
+   routes, embedded third-party content). See
+   `references/ssrf-payload-and-response-headers.md`, Part 3.
+7. **Produce ranked findings** using the output contract below.
+
+## Decision tree
+
+- A key under `runtimeConfig.public` (or fed by a `NUXT_PUBLIC_*` env var) holds a
+  secret, credential, or internal-only value → **HIGH**, `runtimeConfig-exposure`.
+- A private `runtimeConfig` key is re-exported into a public-scoped value elsewhere
+  in the app → **HIGH**, `runtimeConfig-exposure`.
+- A private `runtimeConfig` key stays private and is consumed only server-side → not
+  a finding (rubric item 9).
+- `runtimeConfig.public.*` holds a genuinely non-secret value (base URL, feature
+  flag) → not a finding (rubric item 10).
+- `useState`/`ref`/`reactive`/a mutable object is declared at true module scope
+  (outside any function) and is reachable from server-rendered code → **HIGH**,
+  `cross-request-state-pollution`, structural, regardless of whether leakage has been
+  observed.
+- Same declaration is invoked inside a composable/`setup()`/plugin factory body → not
+  a finding (rubric item 11), unless that body itself closes over a separate
+  module-scope mutable reference (still HIGH in that case).
+- Module-scope declaration is an immutable constant with no runtime mutation path →
+  not a finding (rubric item 12).
+- A `server/api`/`server/routes` handler builds its outbound `$fetch`/`ofetch` URL
+  (host, path, or query) from user-reachable input with no allowlist → **HIGH**,
+  `ssrf`.
+- Outbound URL is hardcoded or validated against an explicit host allowlist → not a
+  finding (rubric item 13).
+- A handler forwards `authorization`/`cookie` (via `event.$fetch` defaults,
+  `useRequestHeaders`, or manual spreading) to an external or user-influenceable
+  destination with no header allowlist → **HIGH**, `credential-forwarding`.
+- `event.$fetch` used to reach an internal Nitro route with no external hop → not a
+  finding by itself (rubric item 14); only escalate if sensitive headers are
+  forwarded without justification even internally.
+- A `useState`/payload value carrying user-controlled or user-echoed content reaches
+  a `v-html` (or equivalent unescaped) sink with no sanitizer call on the traced path
+  → **HIGH**, `payload-xss`.
+- Same value's trace terminates at a safe consumer (text interpolation, a sanitizer
+  call on the exact path, or no rendering at all) → not a finding, but state this
+  explicitly rather than omitting the traced value from the review.
+- No `routeRules` `headers` entry, no security module, and no `useResponseHeader`
+  call anywhere cover a route the app actually serves with auth/forms/embeds →
+  **MEDIUM-to-HIGH** depending on the app's surface, `missing-security-headers`.
+- A header mechanism exists and its glob coverage includes the routes in scope → not
+  a finding (rubric item 15) — but call out any gap in coverage for routes it does
+  *not* cover.
+
+## Output contract
+
+Every response from this skill must return:
+
+1. **Scope** — the `runtimeConfig`/`routeRules` blocks, module-scope declarations,
+   server routes, and/or template bindings reviewed.
+2. **Ranked findings** — each with file:line, defect category
+   (`runtimeconfig-exposure` / `cross-request-state-pollution` / `ssrf` /
+   `credential-forwarding` / `payload-xss` / `missing-security-headers`), the
+   concrete data-flow trace (declaration and reachability, or origin-to-sink path),
+   and a fix sketch matching the patterns in the relevant reference.
+3. **Evidence level per finding** — `documentation-based` (Context7-confirmed against
+   `/websites/nuxt_4_x` or `/websites/nuxt_3_x`), `repo evidence`, or `inference`
+   (e.g., third-party module defaults Nuxt's own docs do not enumerate). Label
+   structural risk findings as structural risk, not as confirmed-exploited.
+4. **Verdict** — approve / approve-with-notes / block.
+5. **Open questions or out-of-scope items** — e.g., "confirming actual cross-request
+   leakage requires concurrent-request load testing, not static review," or "the
+   `nuxt-security` module's exact default header set is not documented in Nuxt's own
+   Context7 sources — confirm its configured `security:` block directly rather than
+   assuming defaults."
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve a `runtimeConfig.public` secret because "it's minified/obfuscated in the
+  bundle anyway" — minification is not encryption; the value is trivially readable in
+  the browser's network/JS panel,
+- clear a module-scope `useState`/`ref` because "we haven't seen cross-user leakage in
+  production" — this defect class is structural and often invisible until concurrent
+  load exposes it; absence of a reported incident is not evidence of absence,
+- approve an SSRF-shaped `$fetch` call because "we trust our users" — an allowlist on
+  the destination host is the control, not the trust level of the current user base,
+- treat "we sanitize elsewhere" as clearing a specific traced `payload`/`useState` →
+  `v-html` path — the sanitizer must be visible on the exact path under review,
+- skip the security-headers check because "we'll add nuxt-security later" — report the
+  current gap now; a planned future fix is not a mitigating control today.

package/skills/frontend/pci-payment-ui-security-review/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: pci-payment-ui-security-review
+description: Statically review payment-page frontend code for PCI-DSS-relevant defects in the browser/DOM slice only — raw PAN collection in self-controlled inputs instead of Stripe hosted fields, card data persisted client-side or to analytics, raw card data POSTed to a first-party endpoint, and third-party scripts loaded without Subresource Integrity — grounded in Stripe's own tokenization docs and PCI-DSS v4 script-security requirements.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-03"
+  category: security
+---
+
+# PCI Payment UI Security Review
+
+## Purpose
+
+Review payment-collection frontend code — checkout pages, card-entry forms, and any script loaded on a page that collects cardholder data — for the frontend-specific defect classes that keep raw cardholder data out of the DOM and out of merchant-controlled JavaScript: raw PAN/CVV collection in a self-controlled `<input>` instead of Stripe's iframe-isolated hosted fields, card data persistence to `localStorage`/`sessionStorage`/analytics/logs, raw card data POSTed to a first-party endpoint instead of tokenized first, and third-party scripts loaded on the payment page without Subresource Integrity (SRI). This skill exists so the review stays anchored to the frontend tokenization boundary and script-integrity surface instead of drifting into a general "payments code review."
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a checkout page or card-entry form for PCI-relevant frontend risk,
+- assess whether card-number, expiry, or CVV fields are collected safely (hosted fields vs. raw `<input>`),
+- audit which scripts load on a payment-collection page and whether they carry Subresource Integrity,
+- assess SAQ-A scope reduction claims for a page that outsources card collection to Stripe Elements/Payment Element,
+- perform a pre-launch frontend security review of a Stripe-based payment integration.
+
+Do not use this skill for:
+
+- a full PCI-DSS compliance audit — this skill covers **only the frontend slice** (client-side script inventory/integrity, hosted-field isolation, tokenization boundary). Server-side cardholder-data-environment (CDE) segmentation, network firewalling, key management, encryption-at-rest, access control, and the remaining PCI-DSS requirement families are out of scope; route those to a dedicated infrastructure/compliance review,
+- a non-payment page with no card-data collection or third-party script surface — general frontend security review is a different scope,
+- a bug that requires live traffic capture (a proxy/network trace confirming what actually left the browser) to confirm exploitation — static analysis proves the structural risk (the code path that *would* expose or persist raw PAN/CVV), not that raw card data has already left the browser in production.
+
+## Context7 Documentation Protocol
+
+- Resolve the Stripe library ID with `resolve-library-id` before citing any Stripe Elements/Payment Element or tokenization-mechanism claim; use `query-docs` to corroborate the specific API behavior (e.g., `stripe.createToken(cardElement)`, `stripe.confirmPayment()`, `stripe.confirmCardPayment()`) rather than relying on memory.
+- Label every Stripe-API behavioral claim `documentation-based` (or `repo evidence` if confirmed directly against fetched Context7 doc content) — do not assert current Stripe API shape from training memory alone.
+- Label every PCI-DSS requirement claim (6.4.3, 11.6.1, or the general SAQ-A scope-reduction rationale) `standard-based` — this skill does not verify a merchant's actual PCI compliance status or attestation; it evaluates whether the frontend code matches the documented pattern the standard and Stripe's architecture rely on.
+- 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`.
+- Read `package.json`/script tags first to confirm which Stripe integration is in use (`@stripe/stripe-js` + Elements, `Payment Element`, or a legacy/custom integration) — the safe idiom and API names differ; do not assume Elements is in use without confirming.
+
+## Lean operating rules
+
+- Raw PAN/CVV collection outside an iframe-isolated hosted field, and any client-side persistence of raw cardholder data, default to HIGH severity. This is a security-scoped skill: do not downgrade a raw-PAN-in-DOM finding to MEDIUM because "it's only in a dev/staging build" — the structural pattern is the risk, not its current deployment target.
+- Trace every finding to a concrete file:line and a concrete data-flow path. A finding that says "this form might expose card data" without showing the specific `<input>` element, the specific `.value` read, or the specific POST body construction is not a valid finding — it is a guess.
+- Do not flag `<CardNumberElement />`, `<CardExpiryElement />`, `<CardCVCElement />`, or `<PaymentElement />` usage as a defect — these are Stripe's iframe-rendered hosted fields; the PAN/CVV they collect stays inside iframes controlled by Stripe and is never accessible to merchant JavaScript. Only a self-controlled `<input>` (e.g., `<input type="text" id="cardnumber" />`) that application JS reads via `.value` is the raw-pan-input defect.
+- Treat any `localStorage`, `sessionStorage`, in-memory app store, or analytics/logging call that could carry a PAN, CVV, or full cardholder data payload as a HIGH finding regardless of whether the value is currently populated in the traced code path — check the shape of the object being persisted, not just its current runtime value.
+- Treat a first-party POST (`fetch`/`XMLHttpRequest`/form submit to a first-party endpoint) carrying raw card fields (PAN, CVV, expiry) as a HIGH finding. The safe pattern tokenizes first via the Stripe API (`stripe.createToken(cardElement)` or the Payment Element confirmation flow) and POSTs only the resulting token or PaymentIntent/PaymentMethod ID to the first-party endpoint.
+- Treat any third-party `<script src="...">` loaded on a payment-collection page without an `integrity` attribute (Subresource Integrity, e.g. a `sha256-` hash) as a finding — cite PCI-DSS v4 requirement 6.4.3 (script inventory, script authorization, and integrity control) as the standard-based grounding. Do not accept "we trust this vendor" as a substitute for a visible integrity attribute or equivalent cryptographic verification.
+- Stripe's hosted fields (`CardNumberElement`, `CardExpiryElement`, `CardCVCElement`, `PaymentElement`) render inside sandboxed iframes controlled by Stripe, not merchant code — the browser's same-origin policy and the iframe sandbox boundary are what keep merchant JavaScript from ever reading raw PAN/CVV values. A missing-iframe-isolation finding applies when card fields are collected via manual `<input>` elements with no sandboxed hosted-field equivalent in use.
+- When reviewing broader payment-page change-detection posture, note PCI-DSS v4 requirement 11.6.1 (automated change-detection/alerting for unauthorized script modification on payment pages) as a standard-based expectation — but do not fabricate a finding about a change-detection mechanism you cannot observe in the frontend code under review; note it as an open question instead.
+- 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 defect decision tree, and the required output shape.
+- [Hosted fields and tokenization boundary](references/hosted-fields-and-tokenization.md) — load when reviewing card-entry form markup, `raw-pan-input`, `card-data-persistence`, or `self-posted-card-data` defect classes.
+- [Script integrity and SAQ-A scope reduction](references/script-integrity-and-scope.md) — load when reviewing third-party script tags for Subresource Integrity, or assessing whether a page's use of hosted fields plausibly supports SAQ-A scope-reduction claims.
+
+## Response minimum
+
+Return, at minimum:
+
+- the payment-collection page(s), card-entry form markup, script tags, and/or client-side persistence/network calls in scope,
+- ranked findings with file:line evidence, defect category (`raw-pan-input`, `card-data-persistence`, `self-posted-card-data`, `unsigned-third-party-script`, or `missing-iframe-isolation`), the concrete data-flow trace (the raw `<input>`/`.value` read, the `localStorage`/analytics call, the POST body construction, or the missing `integrity` attribute), and a fix sketch matching Stripe's documented idiom (`CardNumberElement`, `PaymentElement`, `stripe.createToken`, or an `integrity`/SRI attribute),
+- for every finding involving PAN/CVV/cardholder data exposure, an explicit statement of whether the value stays inside a Stripe-controlled iframe (safe) or is reachable by merchant JavaScript (unsafe) — never approve on the assumption isolation exists without tracing it,
+- evidence level per finding (`repo evidence`, `documentation-based`, `standard-based`, or `inference`), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited or confirmed non-compliant,
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover — explicitly restate that this is **not a full PCI-DSS audit**: server-side cardholder-data-environment segmentation, key management, network controls, and non-script requirement families are out of scope and require a dedicated compliance/infrastructure review.

package/skills/frontend/pci-payment-ui-security-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "pci-payment-ui-security-review",
+  "name": "PCI Payment UI Security Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews payment-collection frontend code for the PCI-DSS-relevant frontend defect classes: raw PAN/CVV collection in self-controlled inputs instead of Stripe hosted fields, card data persisted client-side or to analytics, raw card data POSTed to a first-party endpoint before tokenization, and third-party scripts loaded without Subresource Integrity — grounded via Context7 Stripe documentation and PCI-DSS v4 script-security requirements (standard-based).",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.stripe.com/js/elements_object/create",
+    "https://docs.stripe.com/security/guide#validating-pci-compliance",
+    "https://www.pcisecuritystandards.org/document_library/",
+    "https://www.pcisecuritystandards.org/documents/SAQ-A-r2-v4_0.pdf"
+  ],
+  "security_notes": "This skill's entire scope is security-critical: raw PAN/CVV collection outside a Stripe-controlled iframe, client-side persistence of cardholder data, and unsigned third-party scripts on payment pages are all cardholder-data-exposure or code-tampering vectors. Every finding in this skill defaults to HIGH severity unless proven otherwise with concrete evidence of iframe isolation, tokenization-before-POST, or a visible integrity attribute. This is the FRONTEND slice of PCI-DSS only — it is NOT a full PCI-DSS audit; server-side cardholder-data-environment segmentation, network controls, and key management are explicitly out of scope. Static-review-only skill: it reads and greps payment-page source but never executes, builds, or runs application code, and never sends live requests.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/pci-payment-ui-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/pci-payment-ui-security-review/references/hosted-fields-and-tokenization.md

@@ -0,0 +1,107 @@
+# Hosted Fields and the Tokenization Boundary
+
+Use this reference when reviewing card-entry form markup, or investigating the `raw-pan-input`, `card-data-persistence`, or `self-posted-card-data` defect classes.
+
+## What people get wrong
+
+The naive assumption is:
+
+> "As long as I send the card data over HTTPS to my own server, it's protected in transit, so a plain `<input>` for the card number is fine."
+
+Wrong for PCI-DSS purposes. Transport encryption protects data in transit between the browser and the first-party server, but it does nothing to prevent the merchant's own JavaScript — or a compromised/malicious third-party script sharing the page — from reading the raw PAN/CVV the instant it sits in a DOM `<input>` or in memory as a plain JS value. The entire architectural point of Stripe's hosted fields is to remove that reachability, not merely to encrypt what is already reachable.
+
+## Officially grounded tokenization flow (Context7 Stripe documentation)
+
+- `stripe.createToken(cardElement)` converts data collected by Stripe Elements into a **single-use token**, passed securely to the server — the merchant's own code never handles the raw values that produced the token.
+- Raw card data (PAN, CVV) collected by `CardNumberElement`, `CardExpiryElement`, and `CardCVCElement` stays **inside iframes controlled by Stripe**, never accessible to merchant JavaScript.
+- `stripe.confirmPayment()` and `stripe.confirmCardPayment()` tokenize directly as part of confirming the PaymentIntent, without ever exposing raw values to the page.
+- The merchant receives only the token, or the PaymentIntent/PaymentMethod confirmation result — never the raw card data itself.
+- **Key architectural guarantee:** Elements render inside sandboxed iframes; merchant code never sees or touches the PAN or CVV. The browser's same-origin policy prevents scripts on the merchant page — including the merchant's own code and any co-located third-party script — from reading iframe content.
+
+## Defect class 1: `raw-pan-input`
+
+Raw PAN collection in a self-controlled `<input>` element.
+
+- **Dangerous:** `<input type="text" id="cardnumber" />` with application JS reading `.value` to obtain the card number. The moment card-number digits exist as a plain string in application-reachable memory or the DOM, they are reachable by merchant JS, any injected script, and any browser extension with page access.
+- **Safe:** `<CardNumberElement />` (iframe-rendered by Stripe; no app JS access to the value inside).
+- **Verification targets:** Grep for `<input` elements with `type="text"`/`type="number"`/`name`/`id` attributes suggestive of card fields (`card`, `pan`, `cardnumber`, `ccnum`), and confirm whether the surrounding component imports and uses `CardNumberElement`/`PaymentElement` instead, or reads `.value` directly from a raw input.
+
+## Defect class 2: `missing-iframe-isolation`
+
+No iframe/hosted-field isolation for card-data collection generally (PAN, CVV, *or* expiry).
+
+- **Dangerous:** Manual `<input>` fields for PAN, CVV, and/or expiry with no iframe sandboxing — a homegrown card form.
+- **Safe:** `<CardNumberElement />`, `<CardExpiryElement />`, `<CardCVCElement />`, or the unified `<PaymentElement />`, all of which render inside a sandboxed iframe boundary that the merchant page cannot reach into.
+- This is the broader structural finding that `raw-pan-input` is one specific instance of — flag it whenever *any* of the three card fields (not just the PAN) is collected outside a hosted field.
+
+## Defect class 3: `card-data-persistence`
+
+Card data persisted to a client-side store, `localStorage`/`sessionStorage`, analytics, or logs.
+
+- **Dangerous:** `localStorage.setItem('card', {pan, cvv, exp})`, a Vuex/Redux/Pinia `store` action that commits raw card fields to persisted state, or an analytics event (`analytics.track('checkout_attempt', {cardNumber, cvv})`) that includes cardholder data fields.
+- **Safe:** Persist only the tokenized `paymentMethod` ID (e.g., `store.commit('setPaymentMethod', paymentMethod.id)`) — never raw PAN, CVV, or full cardholder data.
+- **Verification targets:** Grep for `localStorage.setItem`/`sessionStorage.setItem` calls, and for `store`/state-management writes and analytics/logging calls, in files reachable from the payment form. For each match, inspect the literal object shape being persisted for PAN- or CVV-shaped fields, even under generic key names — a field literally named `PAN` or `CVV`, or one holding a 13–19 digit numeric string or 3–4 digit CVV pattern, is the signal to trace, regardless of the variable name chosen.
+
+## Defect class 4: `self-posted-card-data`
+
+Raw card fields POSTed to a first-party endpoint.
+
+- **Dangerous:** `fetch('/api/pay', {body: {pan, cvv, exp}})` — raw card fields constructed directly into a POST body and sent to the merchant's own `/api/pay` first-party endpoint, with no tokenization step beforehand.
+- **Safe:** `stripe.createToken(cardElement).then(token => fetch('/api/pay', {body: {token: token.id}}))` — the Stripe API tokenizes first; only the resulting token is POSTed to the first-party endpoint.
+- **Verification targets:** Grep for `fetch(`/`XMLHttpRequest`/form `action=` submissions targeting a first-party API path from payment-form components. For each, trace the request body's construction backward: does it reference raw card fields (`pan`, `cardNumber`, `cvv`, `exp`), or does it reference a token/PaymentIntent/PaymentMethod object produced by a preceding Stripe API call?
+
+## Minimal safe implementation pattern
+
+```jsx
+// Safe: hosted fields + tokenize-before-POST
+import { CardNumberElement, CardExpiryElement, CardCVCElement, useStripe, useElements } from '@stripe/react-stripe-js'
+
+function CheckoutForm() {
+  const stripe = useStripe()
+  const elements = useElements()
+
+  async function handleSubmit(e) {
+    e.preventDefault()
+    const cardElement = elements.getElement(CardNumberElement)
+    // Raw PAN/CVV never leave the Stripe iframe; only a token is produced.
+    const { token } = await stripe.createToken(cardElement)
+    // Only the token is persisted or sent to the first-party endpoint.
+    await fetch('/api/pay', { method: 'POST', body: JSON.stringify({ token: token.id }) })
+  }
+
+  return (
+    <form onSubmit={handleSubmit}>
+      <CardNumberElement />
+      <CardExpiryElement />
+      <CardCVCElement />
+    </form>
+  )
+}
+```
+
+Anti-pattern (do not approve):
+
+```html
+<!-- WRONG: raw PAN/CVV in a self-controlled input, read directly by app JS -->
+<input type="text" id="cardnumber" />
+<input type="text" id="cvv" />
+<script>
+  function submitPayment() {
+    const pan = document.getElementById('cardnumber').value
+    const cvv = document.getElementById('cvv').value
+    localStorage.setItem('lastCard', JSON.stringify({ pan, cvv })) // card-data-persistence
+    fetch('/api/pay', { method: 'POST', body: JSON.stringify({ pan, cvv }) }) // self-posted-card-data
+  }
+</script>
+```
+
+## Adversarial checklist
+
+Before clearing a payment form as safe on the tokenization boundary, answer these:
+
+- Is card number, expiry, and CVV collection fully delegated to `CardNumberElement`/`CardExpiryElement`/`CardCVCElement`/`PaymentElement`, or does any field use a manual `<input>`?
+- Does any code path read `.value` from a manual card-shaped input?
+- Does any `localStorage`/`sessionStorage`/store/analytics/log call persist an object containing PAN-, CVV-, or cardholder-data-shaped fields?
+- Does the first-party POST body reference raw card fields, or does it reference only a Stripe token/PaymentIntent/PaymentMethod ID produced by a preceding `stripe.createToken`/`stripe.confirmPayment`/`stripe.confirmCardPayment` call?
+
+If any answer reveals raw PAN/CVV reachable by merchant JS at rest, in a POST body, or in persisted state, the finding is HIGH and structural — report it even without a reproduced data-exfiltration incident.

package/skills/frontend/pci-payment-ui-security-review/references/script-integrity-and-scope.md

@@ -0,0 +1,66 @@
+# Script Integrity and SAQ-A Scope Reduction
+
+Use this reference when reviewing third-party script tags loaded on a payment-collection page for Subresource Integrity, or when assessing whether a page's architecture plausibly supports an SAQ-A scope-reduction claim.
+
+## What people get wrong
+
+The naive assumption is:
+
+> "This third-party script is from a well-known vendor's CDN over HTTPS, so it's safe to load on the checkout page."
+
+Wrong for PCI-DSS purposes. HTTPS protects the script in transit from the CDN to the browser; it does not protect against the CDN itself being compromised, the vendor's build pipeline being compromised, or a supply-chain attack that swaps the script's content while its URL stays identical (the class of attack behind real-world Magecart-style card-skimming incidents). Subresource Integrity closes exactly this gap: it lets the browser refuse to execute a script whose fetched content does not match a cryptographic hash pinned at authorization time.
+
+## PCI-DSS v4 grounding (standard-based)
+
+**6.4.3 — Script Inventory, Authorization & Integrity Control:**
+
+- All scripts loaded on payment collection pages must be inventoried and approved.
+- Scripts must be authorized before loading (script authorization).
+- Integrity verification is required via Subresource Integrity (SRI) or an equivalent cryptographic verification mechanism (e.g., a SHA-256 hash).
+
+**11.6.1 — Change Detection on Payment Pages:**
+
+- Automated change-detection/alerting mechanisms are required for unauthorized code additions or modifications to payment pages.
+- This is intended to detect malicious script injections, DOM tampering, and compromise attempts in near-real time, independent of the SRI control above.
+
+Both of these are standard requirement citations (`standard-based`) — this skill can confirm from frontend code whether SRI is present on a given script tag, but it cannot confirm from static frontend review alone whether a merchant has an operating script-inventory/authorization *process* or a functioning 11.6.1 change-detection deployment. Note any such gap as an open question rather than asserting non-compliance.
+
+## Defect class: `unsigned-third-party-script`
+
+Third-party script loaded without Subresource Integrity.
+
+- **Dangerous:**
+  ```html
+  <script src="https://cdn.example.com/analytics.js"></script>
+  ```
+  No `integrity` attribute means the browser will execute whatever content the CDN serves at request time, with no cryptographic check against what was reviewed/authorized.
+- **Safe:**
+  ```html
+  <script src="https://cdn.example.com/analytics.js"
+          integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh76tviuROE="
+          crossorigin="anonymous"></script>
+  ```
+  The `integrity` attribute pins a SHA-256 (or SHA-384/SHA-512) hash; the browser refuses to execute the script if the fetched bytes don't match. `crossorigin="anonymous"` is required alongside `integrity` for cross-origin script resources so the browser can perform the integrity check.
+- **Verification targets:** Grep every `<script src="...">` tag rendered on a payment-collection page (including scripts injected via a tag-manager snippet, if visible in source) for the presence of an `integrity` attribute. A same-origin/first-party script (served from the merchant's own domain) is lower risk but still benefits from SRI if served via a CDN in front of first-party assets; the primary finding target is third-party origins.
+- A missing `integrity` attribute on a third-party script on a payment page is a HIGH finding regardless of the vendor's reputation — reputation is not a substitute for script authorization and integrity verification under 6.4.3.
+
+## SAQ-A scope reduction (standard-based)
+
+SAQ-A is the PCI-DSS self-assessment questionnaire for merchants that have **fully outsourced** all cardholder data collection and processing to a PCI-validated third party (e.g., Stripe), such that the merchant's own systems never store, process, or transmit cardholder data and never touch it even transiently in the browser.
+
+For a payment page's frontend architecture to plausibly support an SAQ-A claim:
+
+- Every card field (PAN, expiry, CVV) must be collected exclusively via Stripe hosted fields (`CardNumberElement`/`CardExpiryElement`/`CardCVCElement`) or the unified `PaymentElement` — no manual `<input>` anywhere in the flow (would otherwise be a `raw-pan-input`/`missing-iframe-isolation` finding).
+- No client-side persistence of raw cardholder data anywhere in the flow (would otherwise be a `card-data-persistence` finding).
+- No first-party POST of raw card fields anywhere in the flow — only tokens/PaymentIntent/PaymentMethod IDs cross to the first-party server (would otherwise be a `self-posted-card-data` finding).
+
+This skill can confirm the frontend evidence for or against these three conditions. It **cannot** confirm the merchant's actual SAQ-A eligibility determination or attestation — that is a compliance/assessor decision that also depends on the merchant's payment page hosting model (e.g., whether the payment page itself is served from PCI-relevant infrastructure) and other SAQ-A eligibility criteria outside this skill's frontend-only scope. Label any SAQ-A-adjacent conclusion `standard-based` and explicitly note the full-audit exclusion.
+
+## Adversarial checklist
+
+Before clearing a payment page's script surface:
+
+- Does every third-party `<script src="...">` on the page carry an `integrity` attribute with a `sha256-` (or stronger) hash and a `crossorigin` attribute?
+- Is there any script loaded dynamically (via `document.createElement('script')` or a tag-manager container) that bypasses static `integrity` attribution entirely? Flag this as a distinct, harder-to-verify risk — dynamically injected scripts cannot carry a static `integrity` attribute in the same way, and the review should note this as an open question requiring the tag-manager's own vendor controls to be checked separately.
+- If asked about SAQ-A: do all three frontend conditions above hold, with no raw-PAN, persistence, or self-posted-data findings anywhere in the reviewed flow?
+- Is there any observable client-side change-detection or integrity-monitoring code on the page (relevant to 11.6.1), or is this an open question requiring server/ops-side confirmation?

package/skills/frontend/pci-payment-ui-security-review/references/workflow-and-output.md

@@ -0,0 +1,52 @@
+# 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 defect class the payment page under review actually raises.
+
+## Prerequisites
+
+- Confirm the page under review actually collects or handles cardholder data: a checkout form, a saved-card management page, or any page that loads Stripe.js or renders card-entry fields. If no such page exists in scope, this skill does not apply.
+- Identify the Stripe integration shape in use: `@stripe/stripe-js` + `Elements` (`CardNumberElement`/`CardExpiryElement`/`CardCVCElement`), the unified `Payment Element`, or a legacy/custom card-collection integration. The safe idiom and the specific API calls to verify differ by shape.
+- Remember the scope boundary throughout: this is a **frontend-only** PCI-DSS review. Do not extend findings into server-side cardholder-data-environment segmentation, network firewalling, key management, or encryption-at-rest — those require a dedicated infrastructure/compliance review and are out of scope here.
+
+## Workflow
+
+1. **Locate every card-entry surface.** For each checkout/payment form, identify whether card number, expiry, and CVV are collected via Stripe hosted fields (`CardNumberElement`, `CardExpiryElement`, `CardCVCElement`, or `PaymentElement`) or via manual `<input>` elements. See `references/hosted-fields-and-tokenization.md` for the `raw-pan-input` and `missing-iframe-isolation` decision tree.
+2. **Trace client-side persistence and analytics calls.** Grep for `localStorage.setItem`, `sessionStorage.setItem`, in-memory app `store` writes, and analytics/logging calls (`analytics.track`, `console.log`, error-reporting SDK calls) reachable from the payment form's state. For each, inspect the shape of the persisted/logged object for PAN, CVV, or other cardholder data fields. See `references/hosted-fields-and-tokenization.md` for the `card-data-persistence` decision tree.
+3. **Trace network calls from the payment form.** For each `fetch`/`XMLHttpRequest`/form submission triggered by the payment form, determine whether raw card fields (PAN, CVV, expiry) are POSTed directly to a first-party endpoint, or whether a Stripe tokenization call (`stripe.createToken(cardElement)`, `stripe.confirmPayment()`, `stripe.confirmCardPayment()`) runs first and only the resulting token/PaymentIntent/PaymentMethod ID is POSTed. See `references/hosted-fields-and-tokenization.md` for the `self-posted-card-data` decision tree.
+4. **Enumerate every script tag loaded on the payment page.** For each third-party `<script src="...">`, check for an `integrity` attribute (Subresource Integrity) and a `crossorigin` attribute. See `references/script-integrity-and-scope.md` for the `unsigned-third-party-script` decision tree.
+5. **Assess SAQ-A scope-reduction plausibility (if asked).** If the user asks about SAQ-A eligibility, check whether card data collection is fully outsourced to Stripe hosted fields/Payment Element with no raw card data ever touching the merchant's own JavaScript or servers. See `references/script-integrity-and-scope.md`.
+6. **Produce ranked findings** using the output contract below.
+
+## Decision tree
+
+- Card number/expiry/CVV collected via a manual `<input>` element (e.g., `<input type="text" id="cardnumber" />`) with application JS reading `.value` → **HIGH** finding, `raw-pan-input` and `missing-iframe-isolation`. The safe pattern is `<CardNumberElement />`/`<PaymentElement />`.
+- Card number/expiry/CVV collected via `<CardNumberElement />`, `<CardExpiryElement />`, `<CardCVCElement />`, or `<PaymentElement />` → not a finding; these are Stripe's iframe-rendered hosted fields, and the browser's same-origin policy prevents merchant JS from reading iframe content.
+- A `localStorage`/`sessionStorage`/store/analytics call persists an object containing PAN, CVV, or full card data (even if named generically, e.g. `paymentInfo`) → **HIGH** finding, `card-data-persistence`. The safe pattern persists only a tokenized `paymentMethod` ID.
+- A `localStorage`/`sessionStorage`/store/analytics call persists only a Stripe token, PaymentIntent ID, or PaymentMethod ID (no raw card fields) → not a finding.
+- A first-party POST body is constructed from raw card fields (`pan`, `cardNumber`, `cvv`, `exp`) without a preceding Stripe tokenization call → **HIGH** finding, `self-posted-card-data`.
+- A first-party POST body is constructed from a Stripe token (`token.id`) or PaymentIntent/PaymentMethod confirmation result, with the tokenization call (`stripe.createToken`, `stripe.confirmPayment`, `stripe.confirmCardPayment`) preceding it on the same path → not a finding.
+- A third-party `<script src="...">` on the payment page has no `integrity` attribute → **HIGH** finding, `unsigned-third-party-script` (PCI-DSS v4 6.4.3, standard-based).
+- A third-party `<script src="..." integrity="sha256-..." crossorigin="anonymous">` on the payment page → not a finding.
+- User asks about SAQ-A scope reduction and card collection is fully outsourced to Stripe hosted fields/Payment Element with no raw card data touching merchant JS or servers → plausible SAQ-A alignment, label `standard-based`, and note this skill does not verify the merchant's full SAQ-A questionnaire or attestation status.
+- User asks about SAQ-A scope reduction and any `raw-pan-input`, `card-data-persistence`, or `self-posted-card-data` finding is present → SAQ-A eligibility is not plausible on the frontend evidence reviewed; flag the specific defect blocking it.
+
+## Output contract
+
+Every response from this skill must return:
+
+1. **Scope** — the payment-collection page(s), card-entry form markup, script tags, and/or client-side persistence/network calls reviewed.
+2. **Ranked findings** — each with file:line, defect category (`raw-pan-input` / `card-data-persistence` / `self-posted-card-data` / `unsigned-third-party-script` / `missing-iframe-isolation`), the concrete data-flow trace (the raw input read, the persistence/analytics call, the POST body construction, or the missing integrity attribute), and a fix sketch matching Stripe's documented pattern.
+3. **Iframe-isolation status per PAN/CVV-handling finding** — an explicit statement of whether the value stays inside a Stripe-controlled iframe (safe) or is reachable by merchant JavaScript (unsafe); never infer isolation exists without tracing it.
+4. **Evidence level per finding** — `repo evidence`, `documentation-based`, `standard-based`, or `inference`. Label structural risk findings as structural risk — do not imply confirmed exploitation or confirmed non-compliance without live evidence (e.g., a captured network trace, an actual PCI assessor finding).
+5. **Verdict** — approve / approve-with-notes / block.
+6. **Open questions or out-of-scope items** — always restate explicitly that this is not a full PCI-DSS audit: server-side CDE segmentation, network controls, key management, and non-script requirement families are out of scope.
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve a raw `<input>` card field because "we sanitize/mask it before sending" — masking display does not change that raw PAN/CVV briefly exists in merchant-readable DOM/JS state; only Stripe's iframe-isolated hosted fields keep it out of merchant JS entirely,
+- treat a third-party script as safe because "it's from a reputable vendor" without a visible `integrity` attribute — vendor reputation is not equivalent cryptographic verification under PCI-DSS v4 6.4.3,
+- skip the client-side persistence check because "we only store it in memory, not localStorage" — an in-memory app `store` holding raw PAN/CVV is still a `card-data-persistence` finding if it is reachable by other application code, logging, or a crash-reporting SDK,
+- call a page "SAQ-A eligible" solely because it uses Stripe.js somewhere on the page — SAQ-A eligibility requires that raw card data never reaches merchant-controlled JS or servers at all; a page that uses Stripe.js for one flow but also POSTs raw card fields elsewhere does not qualify,
+- treat this review as a full PCI-DSS compliance sign-off — this skill covers only the frontend script/tokenization slice; state the full-audit exclusion explicitly in every response.

package/skills/frontend/product-analytics-experimentation-review/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: product-analytics-experimentation-review
+description: Review frontend analytics instrumentation and A/B or multivariate experiment configurations for event-schema correctness, sample-ratio-mismatch risk, statistically valid stopping rules, and consent-gated privacy compliance before shipping a tracking or experiment change.
+allowed-tools: Read Grep Glob WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: data
+---
+
+# Product Analytics & Experimentation Review
+
+## Purpose
+
+Analytics and experimentation code looks low-risk (it doesn't change what users see) but is exactly where silent, expensive failures accumulate: schema drift that zeroes a KPI dashboard for weeks, sample-ratio mismatch that invalidates a whole test, and unconsented tracking that creates real compliance exposure. This skill exists to apply a measurement-integrity and privacy review before ship, not after a stakeholder notices the dashboard looks wrong.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review new or changed analytics event instrumentation for schema correctness,
+- validate an A/B or multivariate experiment's bucketing logic and statistical plan before launch,
+- audit whether tracking calls are properly consent-gated for privacy compliance,
+- diagnose a suspected sample-ratio mismatch or an experiment result that looks statistically implausible.
+
+## When NOT to use
+
+- Reviewing Core Web Vitals or general RUM/tracing instrumentation with no experiment or event-schema angle — hand off to `frontend-observability-rum-instrumentation`.
+- Reviewing generic security/XSS/CSP posture of a page — hand off to `frontend-dom-xss-csp-review`; this skill only reviews the analytics/experimentation-specific privacy surface (consent gating and PII-in-events), not the broader page security model.
+- Choosing a state-management or component-architecture pattern with no analytics or experiment angle — out of scope.
+
+## Context7 Documentation Protocol
+
+Analytics vendor SDKs (GA4/gtag.js, feature-flag/experimentation platforms) change event-parameter names, consent-mode signal shapes, and SDK method signatures across versions, and memorized snippets go stale fast. Before making any platform-specific claim:
+
+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 the specific analytics/experimentation library actually imported in the code under review (e.g. the GA4/`gtag.js` SDK, a specific feature-flag/experiment SDK) before describing its event or bucketing API. Do not assume GA4 by default — verify the platform from the actual `import`/script-tag evidence first.
+3. Call `mcp__Context7__query-docs` for the specific mechanism in scope — e.g. "GA4 recommended event parameters for purchase event", "Google Consent Mode v2 signal defaults", "GA4 measurement protocol event schema limits" — before ruling on it. Verified library ID for web.dev platform guidance as of this skill's `updated` date: `/websites/web_dev_articles`.
+4. Known facts verified via Context7/web.dev as of this skill's `updated` date: web.dev documents sending `web-vitals` metrics to GA4 via `gtag('event', 'web_vitals', {...})` with `name`/`value`/`delta`/`id`/`label` fields, and shows GA4 BigQuery-export event tables keyed by `event_name`/`event_params`/`event_timestamp`/`user_pseudo_id` — treat any schema claim about GA4's exported event shape as needing this structure, not an invented one. web.dev's Permissions API guidance (`permissions-best-practices`) documents `navigator.permissions.query({name: ...})` returning a `state` of `granted`/`denied`/`prompt`, and states permission grants are scoped per-origin (a grant on one origin does not transfer to a subdomain/different origin) — apply the same non-transferability logic when reasoning about consent scope across subdomains.
+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 an analytics event-parameter name, consent-mode signal name, or experimentation-platform API that no queried source confirms.
+
+## Lean operating rules
+
+- Identify the actual analytics/experimentation platform in use from the imported SDK or script tag before citing platform-specific behavior — do not assume GA4 or any specific vendor by default.
+- Verify that bucketing/assignment logic is deterministic per user (stable hash/seed keyed to a persistent identifier), not re-randomized on refresh, session change, or page reload — this is the single most common cause of invalid experiment results and a leading cause of sample-ratio mismatch.
+- Verify consent gating is enforced at the call site of the tracking function itself, not merely present somewhere else on the page — a consent banner existing does not mean a specific event call respects it; trace the actual conditional guarding the SDK call.
+- Flag any event schema field that could carry PII (free-text fields, email, precise geo/lat-long, payment data, raw URLs with query strings, user-typed search terms) for hashing/redaction before approving.
+- Require a pre-registered primary metric and minimum detectable effect (MDE) for any experiment reviewed; treat their absence as a blocking finding, not a nice-to-have — an experiment analyzed after the fact against whichever metric moved is not a valid test.
+- Treat any observed sample split materially off the configured ratio (e.g. configured 50/50 showing as 46/54 or further at meaningful volume) as a sample-ratio-mismatch candidate requiring a chi-squared check, not a rounding artifact to wave off.
+- Load `references/srm-and-bucketing-integrity.md` only when auditing assignment/bucketing logic or diagnosing a suspected sample-ratio mismatch.
+- Load `references/consent-and-pii-in-events.md` only when reviewing privacy/consent compliance of tracking calls or event payload PII exposure.
+- Load `references/stopping-rules-and-peeking.md` only when evaluating whether an experiment's statistical significance claim or stop/continue decision is valid.
+- This skill performs static review only; it does not execute experiment code, query a live analytics backend, or flip a feature flag / experiment configuration in production.
+
+## Privacy & Consent Depth for Analytics
+
+The generic consent/PII posture above (banner presence is not compliance, check the call site) covers the baseline. Some tracking changes need standard-specific depth: IAB TCF v2.2 purpose-granular consent, Google Consent Mode v2's default-denied timing requirement, and adjacent surfaces (Global Privacy Control/Do-Not-Track, cookie categorization, analytics-endpoint data residency) that a generic consent check can miss.
+
+- **Consent Mode v2 defaults must be synchronous and denied-by-default** (doc-based, Google Consent Mode v2 docs): `gtag('consent', 'default', {analytics_storage: 'denied', ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied'})` must be set at the top of the page, before the gtag.js/GTM snippet loads and before any `gtag('event', ...)` call — not inside a CMP callback or an async-loaded script. A later `gtag('consent', 'update', ...)` call once the user answers the CMP does not retroactively fix a missing or async default; tags may already have fired under an undefined/permissive state.
+- **IAB TCF v2.2 consent is granular per purpose and per vendor, not a single flag** (standard-based inference from the TCF spec): a compliant check validates a specific `(vendorId, purposeId)` grant from the decoded TC string — "a TC string cookie exists" is presence, not scope. A vendor consented for one purpose (e.g. measurement) is not automatically consented for another (e.g. personalized ads).
+- **Any tracking call — pixel, `gtag`, `sendBeacon`, `fetch` — that fires before a consent signal exists is unrecoverable exposure**: unlike a suppressed JS event, an HTTP request (and any PII in its query string or body) cannot be un-sent once it leaves the client.
+- **PII in event properties is a violation independent of consent state**: consent governs whether tracking may happen, not what may be sent once it does — a consented-but-PII-laden event (raw email, full name, unhashed user ID) is still a data-minimization failure.
+- **Cookies set without a declared category or an explicit expiry cannot be honored by a CMP** — flag any analytics/marketing cookie missing `Max-Age`/`Expires` or a category mapping.
+- **Global Privacy Control (`navigator.globalPrivacyControl`) and Do-Not-Track (`navigator.doNotTrack`) must be checked as an opt-out signal alongside explicit CMP consent**, not replaced by it.
+- **Analytics-endpoint data residency must be identified, not assumed** — note the destination host/region for each analytics call and flag payloads sent to a default/global endpoint when a residency-scoped endpoint is expected.
+- Load `references/privacy-consent-depth-for-analytics.md` when a review needs this standard-specific depth (Consent Mode v2 timing, TCF purpose/vendor granularity, GPC/DNT, cookie categorization, data residency) rather than the general consent/PII check alone.
+
+## References
+
+Load these only when needed:
+
+- [SRM and bucketing integrity](references/srm-and-bucketing-integrity.md) — use to verify deterministic, unbiased user assignment and to diagnose a suspected sample-ratio mismatch.
+- [Consent and PII in events](references/consent-and-pii-in-events.md) — use to verify tracking calls are consent-gated and event payloads do not leak PII.
+- [Stopping rules and peeking](references/stopping-rules-and-peeking.md) — use to evaluate whether an experiment's significance claim is valid given its actual monitoring/stopping behavior.
+- [Privacy and consent depth for analytics](references/privacy-consent-depth-for-analytics.md) — use for IAB TCF v2.2 purpose/vendor granularity, Google Consent Mode v2 default-timing requirements, GPC/Do-Not-Track honoring, cookie categorization/expiry, and analytics-endpoint data residency.
+
+## Response minimum
+
+Return, at minimum:
+
+- the analytics/experimentation platform identified and the docs used to verify its behavior,
+- schema-correctness verdict against the documented data contract,
+- SRM/bucketing-integrity verdict,
+- consent-gate and PII findings,
+- statistical-validity verdict (pre-registered metric/MDE present, stopping rule sound) with evidence level.

package/skills/frontend/product-analytics-experimentation-review/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "product-analytics-experimentation-review",
+  "name": "Product Analytics & Experimentation Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews frontend analytics instrumentation and A/B/multivariate experiment setups for event-schema correctness, sample-ratio-mismatch risk, valid statistical stopping rules, and consent-gated privacy compliance before an experiment or tracking change ships.",
+  "source_type": "adapted",
+  "official_docs": [
+    "https://web.dev/articles/vitals-business-impact",
+    "https://developers.google.com/analytics/devguides/collection/ga4",
+    "https://gdpr.eu/cookies/",
+    "https://www.w3.org/TR/permissions/",
+    "https://developers.google.com/tag-platform/security/guides/consent",
+    "https://iabeurope.eu/iab-europe-transparency-consent-framework/"
+  ],
+  "security_notes": "Require consent-gate verification before any non-essential tracking call is approved; require PII scrubbing/hashing review on every new event schema field before it is marked shippable. Also check IAB TCF v2.2 purpose/vendor-granular consent, Google Consent Mode v2 synchronous default-denied timing, GPC/Do-Not-Track honoring, cookie categorization/expiry, and analytics-endpoint data residency. Read-only static review; does not execute experiment code, query a live analytics backend, or change a live feature-flag/experiment configuration.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/product-analytics-experimentation-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}