@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.0

package/skills/frontend/react-component-architecture-review/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: react-component-architecture-review
+description: Statically review React component trees for composition, prop-interface, and state-placement defects (God-components, prop drilling, overbroad context, hook-rule violations) against React's own composition guidance, producing ranked file:line findings.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: architecture
+---
+
+# React Component Architecture Review
+
+## Purpose
+
+Review React component decomposition, prop-interface design, and state-placement decisions (local vs lifted vs context vs external store) without re-litigating styling, live performance profiling, or state-management library selection in every response. This skill exists so those adjacent concerns stay out of scope and the review stays focused on structural defects that erode testability and maintainability.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a React component or feature PR for architecture before merge,
+- answer "is this component doing too much",
+- audit prop-drilling or context usage across a component subtree,
+- assess whether new or existing components should be split, merged, or recomposed.
+
+Do not use this skill for:
+
+- pure styling/CSS review — no architecture concern is in scope,
+- performance profiling that requires live browser traces — that needs a runtime tool, not static review,
+- state-management library selection with no existing code to review — that is a design conversation, not a review.
+
+## Context7 Documentation Protocol
+
+- Resolve the React library ID with `resolve-library-id` (matched result: `/reactjs/react.dev`) before citing any React-specific claim.
+- Before asserting a component-splitting or state-placement recommendation is "React's recommended pattern," call `query-docs` against the repo's actual React major version (read `package.json` first) and cite the doc section — do not assert from memory.
+- If Context7 is unavailable, fall back to the `official_docs` URLs in this skill's `metadata.json` and label the claim `documentation-based, unverified against current release`.
+- Never assume the latest React docs apply to an older major version in the repo; hook rules and context APIs have changed across majors (e.g., `Context.Provider` vs. `<Context value={...}>`).
+
+## Lean operating rules
+
+- First read `package.json` to confirm the installed React major version. Do not make an API-availability claim without confirming the version.
+- Classify each in-scope component as presentational, container, or compound before evaluating it. Do not apply a single decomposition rule to all three uniformly.
+- Context usage is not automatically a smell. Values that change rarely and are needed broadly (theme, auth, locale) are an appropriate use of context per React's own guidance; only flag context when it causes overbroad re-renders or is used in place of straightforward prop passing at shallow depth.
+- Do not recommend a specific state-management library (Redux, Zustand, Jotai, etc.) unless one is already a dependency in the repo. A decomposition problem is not a tooling problem.
+- Do not fabricate re-render counts or performance claims without a live profiler; label such estimates `inference, not measured`.
+- Treat deep prop chains that match an intentional compound-component or render-prop API as a design pattern, not a defect — verify intent before flagging.
+- Cap the blast radius of a single review: if the review would require rewriting more than 5 components, stop and flag it as "requires a dedicated refactor plan" rather than prescribing the rewrite inline.
+- Never execute, build, or run application code as part of this review; this is a static-review skill (Read/Grep/Glob only).
+- Treat any hardcoded API key, token, or secret found in component props, default values, or example data as a HIGH-severity finding requiring immediate escalation, not a style note.
+
+## References
+
+Load these only when needed:
+
+- [Review workflow and findings contract](references/workflow-and-output.md) — use for the step-by-step review procedure, the decision tree for split/context/compound-API calls, and the required output shape.
+- [Composite widget patterns](references/composite-widget-patterns.md) — load only when the component in scope is a composite widget (combobox, tabs, dialog, listbox) where deep prop chains may be an intentional ARIA APG pattern rather than drilling.
+
+## Response minimum
+
+Return, at minimum:
+
+- the component(s) and files in scope,
+- ranked findings with file:line evidence and a concrete refactor sketch per finding,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `inference`),
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., "requires a dedicated refactor plan" cap, missing live re-render data).

package/skills/frontend/react-component-architecture-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "react-component-architecture-review",
+  "name": "React Component Architecture Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews React component trees for composition, prop-interface, and separation-of-concerns defects that erode testability and maintainability, using React's own composition guidance (component decomposition, lifting state, context) loaded progressively and grounded via Context7 against the repo's confirmed React version.",
+  "source_type": "original",
+  "official_docs": [
+    "https://react.dev/learn/thinking-in-react",
+    "https://react.dev/learn/passing-props-to-a-component",
+    "https://react.dev/learn/sharing-state-between-components",
+    "https://react.dev/reference/rules/rules-of-hooks"
+  ],
+  "security_notes": "Static-review-only skill: it reads and greps component source but never executes, builds, or runs application code. Do not review or execute application secrets; treat any API key or token found hardcoded in component props or default values as a HIGH-severity finding requiring immediate escalation, not a style note.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/react-component-architecture-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/react-component-architecture-review/references/composite-widget-patterns.md

@@ -0,0 +1,41 @@
+# Composite widget patterns
+
+> Load this reference only when the component in scope is a composite/compound widget — combobox, tabs, dialog, listbox, accordion, menu — where deep prop or context threading may be an intentional API rather than an architectural defect.
+
+## What people get wrong
+
+The naive story is:
+
+> Any prop passed through 3+ components is prop drilling; any component with a lot of internal cross-talk is doing too much.
+
+Wrong for composite widgets. A compound-component API (e.g. `<Tabs><Tabs.List><Tabs.Tab/></Tabs.List><Tabs.Panels>...</Tabs.Panels></Tabs>`) intentionally threads shared state (active index, orientation, disabled state) across a family of subcomponents via context or cloned props, because the alternative — flattening everything into one component — would produce a worse, less composable, less accessible API. Flagging that threading as "drilling" without checking intent produces a false-positive finding that erodes reviewer credibility.
+
+## How to tell intentional threading from accidental drilling
+
+- **Naming convention**: subcomponents namespaced under a parent (`Tabs.Tab`, `Menu.Item`, `Dialog.Trigger`) signal a deliberate compound-component API, not incidental nesting.
+- **Shared context scoped to the family**: a context provider created and consumed only within the widget's own file/module (not app-wide) is a scoping signal of intentional design, not overbroad context.
+- **ARIA role relationships**: if the DOM structure maps to a documented ARIA Authoring Practices Guide (APG) pattern — combobox, listbox, tablist/tab/tabpanel, menu/menuitem — the parent-child prop/state relationship usually exists to satisfy the accessibility contract (e.g., `aria-activedescendant`, `aria-selected`, `aria-expanded` synchronization across the family), not because of poor decomposition.
+- **Reuse boundary**: subcomponents of a compound API are not meant to be reused independently outside their parent; that is by design, not a coupling defect. Do not recommend "extracting" a `Tabs.Tab` to be reused standalone unless the user has an actual standalone-reuse requirement.
+
+## When to still flag a composite widget
+
+Even for compound APIs, still flag:
+
+- Hook-rule violations inside any subcomponent (unconditional top-level rule always applies).
+- A shared context value that changes on every keystroke/interaction and re-renders every sibling subcomponent when only one needs to update — recommend splitting state (e.g., "active index" context separate from "orientation" context) or memoizing consumers.
+- Hardcoded ARIA attributes that contradict the actual interaction model (e.g., `role="listbox"` on a widget that behaves like a menu) — this is a defect regardless of component-architecture concerns and should be flagged as an accessibility finding, not folded into an architecture finding.
+- A compound API that silently duplicates state between a controlled prop and internal state without a documented reconciliation strategy (uncontrolled/controlled conflict).
+
+## Reference pattern shape
+
+React's own composition guidance underlies compound components: children are passed through `props.children`, and shared behavior is coordinated via context scoped to the family, consistent with `Sharing State Between Components` (lift state to the nearest common owner) and `Passing Data Deeply with Context` (use context when passing props becomes genuinely inconvenient across the family, not as a first resort).
+
+## When to push back
+
+Push back if the user asks to:
+
+- flatten a compound-component API into a single component "to reduce prop drilling" — that removes composability without removing coupling,
+- extract a namespaced subcomponent for standalone reuse without an actual standalone-reuse requirement,
+- remove the family-scoped context and thread every value as explicit props across 4+ compound subcomponents — that reintroduces the exact verbosity context was scoped to solve.
+
+That is not simplification. It is a worse API with the same underlying coupling.

package/skills/frontend/react-component-architecture-review/references/workflow-and-output.md

@@ -0,0 +1,84 @@
+# Review workflow and findings contract
+
+Use this reference for the full component-architecture review procedure and the required output shape.
+
+## What people get wrong
+
+The naive story is:
+
+> Split anything that "feels big," lift state to the top, and reach for a context or a store whenever a prop is passed more than once.
+
+Wrong. Splitting a component without reducing coupling just moves the same coupling into a new file. Lifting state past the actual point of shared ownership creates unnecessary re-renders and unrelated components that now depend on state they don't own. Reaching for context or a store before checking whether the "problem" is actually decomposition treats a structural defect as a tooling gap.
+
+React's own guidance (`Thinking in React`, `Sharing State Between Components`, `Passing Data Deeply with Context`) is explicit that component boundaries should follow **separation of concerns** — a component should ideally be concerned with one thing — and that context is a last resort after prop passing becomes genuinely inconvenient across a large distance, not a default.
+
+## Workflow
+
+1. **Classify each component in scope**
+   - Presentational (renders UI from props, no data-fetch/business-logic)
+   - Container (owns data-fetch, business-logic, or both, delegates rendering)
+   - Compound (exposes a composite API — e.g. `<Tabs><Tabs.Panel/></Tabs>` — where prop/context threading is intentional)
+
+2. **Count responsibilities per component**
+   - Data-fetching, business-logic, layout/presentation, event-handling are the four responsibility buckets.
+   - A component mixing 3 or more buckets is a decomposition candidate — but only escalate to a "split" recommendation per the decision tree below, not automatically.
+
+3. **Trace prop chains**
+   - Follow each prop 3+ levels deep. Note every intermediate component that receives the prop only to pass it through without consuming it.
+   - Cross-check against the compound-component reference before flagging: an intentional compound API often has legitimate multi-level prop/context threading.
+
+4. **Check context usage**
+   - For each `useContext` / `Context.Provider` (or `<Context value={...}>` in newer React majors — verify against the repo's confirmed version), determine how often the provided value changes.
+   - Flag only when a frequently-changing value is provided broadly and re-renders an oversized subtree, or when context is used in place of a 1–2 level prop pass that would be simpler and more traceable.
+
+5. **Check hook-rule compliance**
+   - Hooks must be called unconditionally at the top level of a function component or custom hook — never inside conditions, loops, nested functions, early returns, or try/catch blocks (per React's Rules of Hooks). Flag any violation as HIGH severity; it is a correctness bug, not a style preference.
+
+6. **Produce ranked findings**
+   - Order by blast radius: correctness bugs (hook-rule violations, leaked secrets) first, then testability/maintainability defects (mixed-responsibility components, real prop drilling), then lower-severity notes (naming, minor duplication).
+
+## Decision tree
+
+- Component has **more than 1 unrelated responsibility** AND is **reused in more than 1 place** → recommend split, with a sketch of the extracted boundary.
+- Prop drilling exceeds **3 levels** AND the prop is passed through **more than 2 non-consuming intermediates** → recommend context or composition (children/slots) per React's own composition guidance — do not default to recommending a global store.
+- A single context value **changes frequently** and **re-renders a large subtree** → recommend splitting the context (e.g., separate state and dispatch contexts) or memoizing consumers, citing the specific re-render evidence available (repo evidence of consumer count, or `inference, not measured` if no profiler data exists).
+- Deep prop/context threading matches a **compound-component or render-prop API** already in use elsewhere in the codebase → do not flag; note it as intentional.
+
+## Output contract
+
+Return:
+
+1. Component(s)/files in scope
+2. Ranked findings, each with:
+   - file:line evidence
+   - responsibility-mix or drilling-depth evidence backing the finding
+   - concrete refactor sketch
+   - severity (HIGH / MEDIUM / LOW)
+   - evidence level (`repo evidence`, `documentation-based`, `inference`)
+3. Verdict: approve / approve-with-notes / block
+4. Open questions or explicitly out-of-scope items (e.g. "requires a dedicated refactor plan" cap when more than 5 components would need rewriting, or missing live re-render data)
+
+## Validation gates
+
+- Every architectural claim traces to a specific file:line.
+- Every "React recommends X" statement is backed by a Context7-queried doc citation matched to the repo's confirmed React version — never asserted from memory.
+- No finding recommends a specific state-management library unless one is already present in the repo's dependencies.
+- No finding proceeds to recommend a rewrite of more than 5 components in one review; flag as "requires a dedicated refactor plan" instead and stop there.
+
+## Common failure modes
+
+- Treating every context usage as bad. Context is appropriate for rarely-changing, broadly-needed values like theme, auth, or locale — that is the documented use case, not an anti-pattern.
+- Recommending Redux/Zustand/Jotai when the actual problem is component decomposition, not state-management tooling.
+- Flagging deep prop chains that are actually intentional render-prop or compound-component APIs as if they were accidental drilling.
+- Estimating re-render frequency or count without a live profiler and presenting it as measured fact instead of `inference, not measured`.
+
+## Adversarial checklist
+
+Before finalizing a finding, answer these:
+
+- Would splitting this component actually reduce coupling, or just move the same coupling into a new file?
+- Is the prop-drilling flagged actually a compound-component API (intentional) rather than an architectural smell?
+- Does the reviewer have repo evidence this component re-renders excessively, or is that assumed?
+- Is the Context7 citation matched to the repo's actual React version, not the latest docs by default?
+
+If any answer is "not sure," lower the finding's confidence and label the evidence level accordingly — do not present it as a confirmed defect.

package/skills/frontend/react-rsc-data-boundary-review/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: react-rsc-data-boundary-review
+description: Statically review React Server Components code for data leaks across the server-to-client serialization boundary — secrets passed as props to Client Components, server-only modules missing the `server-only` guard, `use server` actions with no authorization check, non-public environment variables read in `use client` modules, and tainted values crossing the boundary unnarrowed — grounded in React's and Next.js's own documentation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-03"
+  category: security
+---
+
+# React RSC Data Boundary Review
+
+## Purpose
+
+Review React Server Components (RSC) code for the concrete, documented ways sensitive server-side data leaks across the server-to-client serialization boundary: a secret passed as a prop such as `password={SECRET_API_KEY}` on a Client Component, a server-only data module with no `server-only` guard that a client bundle could accidentally pull in, a `'use server'` Server Action that mutates data with no session/ownership check (missing the `session?.user` check pattern), a `'use client'` module reading a non-`NEXT_PUBLIC_` environment variable, or a value that should have been marked with `experimental_taintUniqueValue` and narrowed before crossing the boundary. This skill exists so the review stays anchored to these five documented defect classes instead of drifting into a general "React code review" of component design, hooks usage, or rendering performance.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a Server Component that passes props to a Client Component,
+- audit a data-access module (`lib/`, `data/`, or similar) that is meant to run only on the server,
+- review a `'use server'` Server Action or Server Function for authorization gaps,
+- check whether a `'use client'` module is reading environment variables safely,
+- perform a pre-launch security review of a Next.js App Router or other RSC-based application's data flow.
+
+Do not use this skill for:
+
+- generic client-side XSS review (`dangerouslySetInnerHTML`, unsanitized `innerHTML`, DOM-based injection) — that is a distinct defect class covered by `frontend-dom-xss-csp-review`, not this skill,
+- Next.js rendering/caching-strategy review (revalidation, cache tags, `fetch` cache options) with no data-boundary security angle — use `nextjs-rendering-caching-review` or `nextjs-app-router-data-fetching-review` instead,
+- confirming that a leak has actually been exploited in production — static analysis proves the structural risk (a secret is reachable across the boundary) and not that an attacker has already captured it; that requires live request/network interception, which this skill does not perform.
+
+## Context7 Documentation Protocol
+
+- Resolve the React library ID with `resolve-library-id` (matched result: `/reactjs/react.dev`) before citing any `experimental_taintUniqueValue` or Server/Client Component serialization claim. Use `query-docs` against it to confirm the exact tainting API shape and the documented anti-pattern (a secret such as `process.env.API_PASSWORD` passed directly as a prop) before flagging a finding as `documentation-based`.
+- Resolve the Next.js library ID with `resolve-library-id` (matched result: `/vercel/next.js`) before citing any `server-only` package usage, `NEXT_PUBLIC_` environment-variable convention, or Server Action authorization pattern claim. Use `query-docs` against it for the `server-only` install/import pattern and the documented Server Action authorization example (`auth()` + ownership check) before labeling a finding `documentation-based`.
+- `experimental_taintUniqueValue` is an experimental React API, not yet stable — label any finding or fix sketch that depends on it as `documentation-based (experimental API)`, and note that the equally valid non-experimental fix is simply omitting the sensitive field from the object passed to the Client Component.
+- Confirm which surface is in scope before citing a documented rule: a "Server Component passing props" claim only applies where a Server Component (no `'use client'` directive, or an RSC-context module) actually renders a Client Component; a `'use server'` claim only applies to a function or file carrying that exact directive; a `NEXT_PUBLIC_` claim is Next.js–specific and does not automatically apply to a different meta-framework's env-var convention.
+- If Context7 is unavailable, fall back to the `official_docs` URLs in this skill's `metadata.json` and label the claim `documentation-based, unverified against current release`.
+
+## Lean operating rules
+
+- All five defect categories default to HIGH severity. This is a security-scoped skill: do not downgrade an untraced secret-prop pass, a missing `server-only` guard, or an unauthorized `use server` mutation to MEDIUM just because it has not been observed exploited yet — the risk is in the structure, not in whether someone has already hit it.
+- Trace every finding to a concrete file:line and a concrete data-flow path. A finding that says "this prop might leak a secret" without naming the specific prop, the specific Server Component that renders it, and the specific Client Component receiving it is not a valid finding — it is a guess.
+- Do not flag every prop passed from a Server Component to a Client Component. Only a prop whose value traces back to an environment variable, a credential, a token, a full unfiltered config/response object, or any other server-only sensitive value is a finding. A plain string, number, or narrowed non-sensitive field (e.g. `config.SERVICE_API_VERSION`) is not a finding.
+- Do not approve a `'use server'` action that mutates or deletes data unless a session check (the `session?.user` pattern) and, where the mutation targets a specific resource, an ownership check comparing the resource's owner to the authenticated user, are both visibly present on that exact function's path. A session check existing in a different action does not clear this bar — trace the specific function under review.
+- Do not treat a `server-only` import anywhere in the codebase as covering every server-only module. Confirm the exact file that reads the sensitive value (`process.env.*`, a database credential, an internal API token) has `server-only` imported at its own top, not merely that some other file in the project has it.
+- Watch for whole-object prop forwarding: a Server Component that fetches a config/response object and forwards it unnarrowed as a same-named prop (e.g. `config={config}`) crosses the boundary with whatever sensitive fields the object holds, even if no single field is individually named "secret" or "password" in the forwarding code. Narrowing to specific non-sensitive fields, or applying `experimental_taintUniqueValue` to the sensitive fields before any possible pass-through, are the two documented mitigations.
+- 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 decision tree across all five defect categories, and the required output shape.
+- [Boundary data leaks and the taint API](references/boundary-data-leaks-and-taint.md) — load only when the review scope includes a prop passed from a Server Component to a Client Component, a `server-only` guard question, or a value that should have been tainted.
+- [Server Action authorization and client environment exposure](references/server-actions-and-env-exposure.md) — load only when the review scope includes a `'use server'` directive or a `'use client'` module reading `process.env`.
+
+## Response minimum
+
+Return, at minimum:
+
+- the Server Component(s), Client Component prop boundaries, `'use server'` action(s), and/or `'use client'` module(s) in scope,
+- ranked findings with file:line evidence, defect category (`boundary-data-leak`, `missing-server-only-guard`, `action-authz-missing`, `env-exposure-in-client`, or `taint-boundary-violation`), the concrete data-flow trace (the sensitive value's origin and every hop to the boundary crossing or missing guard), and a fix sketch matching React's or Next.js's documented pattern,
+- guard status per finding: an explicit statement of whether a `server-only` import, an `experimental_taintUniqueValue` call, or a session/ownership check is present on the traced path — never approve on the assumption one exists elsewhere,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `structural-risk`), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited,
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., "confirming data leakage requires live request interception (network inspection), not static review" or "taint API coverage requires a Context7 audit of all async boundaries where promises serialize, beyond this review's scope").

package/skills/frontend/react-rsc-data-boundary-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "react-rsc-data-boundary-review",
+  "name": "React RSC Data Boundary Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews React Server Components code for data leaks across the server-to-client serialization boundary: secrets passed as props to Client Components, server-only modules missing the server-only guard, use server actions with no authorization check, non-public environment variables read in use client modules, and tainted values crossing the boundary unnarrowed, grounding claims via Context7 and React's and Next.js's own documentation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://react.dev/reference/rsc/server-components",
+    "https://react.dev/reference/react/experimental_taintUniqueValue",
+    "https://nextjs.org/docs/app/getting-started/server-and-client-components",
+    "https://nextjs.org/docs/app/guides/data-security"
+  ],
+  "security_notes": "This skill's entire scope is security-critical: a secret crossing the server-to-client serialization boundary is a data-exposure defect (potential credential/token leakage to every browser rendering the page), a missing server-only guard risks accidental client-bundle inclusion of secret-reading code, an unauthorized use server action is a mutation/IDOR vector, and non-public env exposure in a use client module signals a broken trust boundary. Every finding in this skill defaults to HIGH severity unless proven otherwise with concrete guard/narrowing evidence. Static-review-only skill: it reads and greps Server/Client Component source and server actions but never executes, builds, or runs application code, and never sends live requests.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/react-rsc-data-boundary-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/react-rsc-data-boundary-review/references/boundary-data-leaks-and-taint.md

@@ -0,0 +1,115 @@
+# Boundary Data Leaks and the Taint API
+
+Use this reference only when the review scope includes a prop passed from a Server Component to a Client Component, a `server-only` guard question, or a value that should have been tainted before crossing the boundary.
+
+## What people get wrong
+
+The naive assumption is:
+
+> "It's a Server Component doing the fetching, so anything it computes and hands down as props is automatically safe."
+
+Wrong. A Server Component running on the server can read anything the server process can reach — environment variables, database credentials, internal API tokens — but the moment any of that value is passed as a prop to a Client Component, React serializes it into the payload the browser receives. "Computed on the server" is not the same as "safe to send to the client." The recurring real failure mode is not a developer typing `password={rawSecret}` on purpose; it is a Server Component fetching a config or session object for its own server-side use, then forwarding the *entire* object unnarrowed to a Client Component because the object also happens to contain a few fields the client legitimately needs.
+
+## Officially grounded rules
+
+React's own reference documentation states the anti-pattern directly, using exactly this shape:
+
+```js
+export async function Dashboard(props) {
+  // DO NOT DO THIS
+  return <Overview password={process.env.API_PASSWORD} />;
+}
+```
+
+(`documentation-based`, React reference: `experimental_taintUniqueValue`.)
+
+React's documented mitigation is `experimental_taintUniqueValue`, called on the server before the value can ever reach a serialization boundary:
+
+```js
+import "server-only";
+import { experimental_taintUniqueValue } from 'react';
+
+experimental_taintUniqueValue(
+  'Do not pass the API token password to the client. ' +
+    'Instead do all fetches on the server.',
+  process,
+  process.env.API_PASSWORD
+);
+```
+
+Once tainted, React throws if that exact value is later passed to a Client Component or a Server Function — turning an accidental leak into a hard error instead of a silent shipment to the browser. This API is experimental and only available inside Server Components (`documentation-based`, React reference).
+
+The equally valid, non-experimental mitigation — and the one to recommend when the codebase cannot yet depend on an experimental API — is narrowing: return only the specific non-sensitive fields a Client Component needs, never the full object that also carries the sensitive ones (e.g. return `config.SERVICE_API_VERSION`, not `config`).
+
+Next.js's own documentation independently reinforces the server/client environment-variable split this rests on: server-only values (e.g. `process.env.DATABASE_URL`) are read directly in Server Components, while values intended for client code must be exposed through the `NEXT_PUBLIC_` prefix convention — there is no other sanctioned path for a raw secret to reach client code (`documentation-based`, Next.js docs).
+
+## Non-negotiable design rules
+
+### 1. Trace every prop's value to its origin before judging it
+
+Do not evaluate `<ClientComponent someProp={value} />` in isolation. Is `value` a literal? A prop passed through unchanged from further up? A field read from `process.env`? A field on a database row or API response? The finding depends on where that trace terminates, not on the prop name alone — though a prop named `password`, `apiKey`, `secret`, or `token` bound directly to an env-derived value is close to a self-evident finding.
+
+### 2. Whole-object forwarding is a distinct, easy-to-miss failure mode
+
+`<ClientComponent config={config} />`, where `config` is the full object returned by a server-side fetch, forwards every field the object contains — including any the developer never explicitly intended to expose. This does not require a developer to type a dangerous-looking field name; it only requires forgetting that the object holds more than what the Client Component actually renders. Always ask: does this Client Component receive the *exact* fields it needs, or the whole object those fields came from?
+
+### 3. `server-only` guards the module, not the specific call site
+
+`import 'server-only'` at the top of a module causes a build-time error if any Client Component (or a file in the client bundle graph) ever imports that module — but it only protects the module it is declared in. A sibling data-access file with the same kind of `process.env` read and no `server-only` import of its own is not covered by a guard that exists elsewhere in the codebase.
+
+### 4. An unused prop still serialized is still a leak
+
+If a Client Component receives a sensitive prop but never reads it in its render output, the value has still been serialized into the payload sent to the browser and is visible in dev tools, network inspection, or the page source. "It's not rendered anywhere" does not clear a `boundary-data-leak` finding.
+
+### 5. Taint and narrowing are complementary, not alternatives to trace around
+
+Do not accept "this codebase uses `experimental_taintUniqueValue` elsewhere" as clearing a specific untraced prop pass. Confirm the taint call (or the narrowing) is on the exact path from the sensitive origin to this specific Client Component boundary.
+
+## Minimal safe implementation pattern
+
+```tsx
+// Safe: narrow to a specific non-sensitive field.
+import { getSystemConfig } from './config' // has `import 'server-only'` at its top
+
+export async function Dashboard() {
+  const config = await getSystemConfig()
+  return <ClientDashboard version={config.SERVICE_API_VERSION} />
+}
+```
+
+Anti-pattern (do not approve):
+
+```tsx
+export async function Dashboard(props) {
+  // DO NOT DO THIS
+  return <Overview password={process.env.API_PASSWORD} />;
+}
+```
+
+```tsx
+// Also unsafe: whole object forwarded, even with no field literally named "password".
+export async function Dashboard() {
+  const config = await getSystemConfig()
+  return <ClientDashboard config={config} />
+}
+```
+
+## Adversarial checklist
+
+Before clearing a Server Component → Client Component prop boundary as safe:
+
+- What is the literal origin of every prop value — a literal, a narrowed field, or a full object/response?
+- If a full object is forwarded, does it contain any field that reads `process.env`, a credential, or a token anywhere upstream in its construction?
+- Is there a `server-only` import at the top of the specific module that reads the sensitive value, or only somewhere else in the codebase?
+- Is there an `experimental_taintUniqueValue` call on the exact path from the sensitive value's origin to this boundary, or is narrowing the only control in place?
+- Would a future code change (a new field added to the forwarded object, or a refactor that removes the narrowing) reach the client without re-triggering a security review?
+
+If any answer is unclear or reveals a gap, the finding is HIGH — do not soften it to "worth double-checking."
+
+## Verification targets
+
+- Grep for JSX usages that pass a prop from a Server Component to an imported Client Component (a component whose file has `'use client'` at its top), and enumerate every prop value.
+- Grep for `password=`, `apiKey=`, `secret=`, `token=` (and case variants) bound to any non-literal expression in JSX.
+- Grep for a prop name identical to the bound variable name (`config={config}`-shaped whole-object forwarding).
+- Grep every data-access module for `process.env.` reads and confirm `import 'server-only'` is present as the first statement in that same file.
+- Grep for `experimental_taintUniqueValue(` calls and confirm which specific values they cover.

package/skills/frontend/react-rsc-data-boundary-review/references/server-actions-and-env-exposure.md

@@ -0,0 +1,136 @@
+# Server Action Authorization and Client Environment Exposure
+
+Use this reference only when the review scope includes a `'use server'` directive (a Server Action/Function) or a `'use client'` module reading `process.env`.
+
+## What people get wrong
+
+The naive assumption for Server Actions is:
+
+> "It's a `'use server'` function, so it only runs on the server, and only my app's own UI calls it — that's authorization enough."
+
+Wrong. A `'use server'` directive controls *where the code executes*, not *who is allowed to invoke it*. Next.js compiles every Server Action into a callable server endpoint; anyone who can reach that endpoint — not just users going through the app's own rendered UI — can invoke it directly with an arbitrary argument. A Server Action with no session check is an unauthenticated mutation endpoint. A Server Action with a session check but no ownership check is an authenticated *Insecure Direct Object Reference* (IDOR): any logged-in user can pass any other user's resource ID.
+
+The naive assumption for client-side env access is:
+
+> "I need a config value in this Client Component, so I'll just read `process.env.SOMETHING` like I would on the server."
+
+Wrong. In a `'use client'` module, only environment variables the framework has explicitly exposed to the browser bundle are ever available at runtime; anything else is `undefined` once the code actually runs in the browser, no matter what it appeared to be when read in server-side tooling or type definitions. Beyond the functional bug, the read itself is a signal the developer's mental model of the server/client boundary is broken — a strong prompt to check the rest of that same module for other assumptions that might leak something real.
+
+## Officially grounded rules
+
+Next.js's own documentation shows the required Server Action authorization pattern directly:
+
+```tsx
+'use server'
+
+import { auth } from '@/lib/auth'
+import { db } from '@/lib/db'
+
+export async function deletePost(postId: string) {
+  const session = await auth()
+  if (!session?.user) {
+    throw new Error('Unauthorized')
+  }
+
+  const post = await db.post.findUnique({ where: { id: postId } })
+
+  // Check that the user owns this resource
+  if (post.authorId !== session.user.id) {
+    throw new Error('Forbidden')
+  }
+
+  await db.post.delete({ where: { id: postId } })
+}
+```
+
+(`documentation-based`, Next.js docs: Server Action data-security guide.) Both checks are present: a session check (`session?.user`) proving the caller is authenticated, and an ownership check (`post.authorId !== session.user.id`) proving the caller may act on *this specific* resource — the session check alone does not imply the ownership check.
+
+Next.js's documentation is equally direct on client environment access: `'use client'` modules can read environment variables prefixed `NEXT_PUBLIC_`; anything else read server-side (e.g. `process.env.DATABASE_URL`) is a server-only value with no client-side equivalent (`documentation-based`, Next.js docs).
+
+## Non-negotiable design rules
+
+### 1. A session check is necessary but not sufficient for resource-scoped mutations
+
+For a `'use server'` function that takes an ID and mutates/deletes/reads the corresponding resource, require both: a session check (is anyone authenticated at all) and an ownership/authorization check (may *this* authenticated user act on *this specific* resource). A function that checks only the former and trusts the caller-supplied ID unconditionally is IDOR-shaped.
+
+### 2. Do not accept "the UI never lets you delete someone else's post" as a control
+
+A Server Action is a callable endpoint independent of what the rendered UI happens to expose. The fact that the app's own components never construct a request for another user's resource ID says nothing about what a direct request to the compiled action endpoint can supply.
+
+### 3. `NEXT_PUBLIC_` is the only sanctioned bridge for client-visible env values
+
+There is no other supported mechanism for exposing a build-time environment value to `'use client'` code short of an explicit runtime fetch to a server endpoint that itself performs its own authorization. A non-`NEXT_PUBLIC_` read in a `'use client'` file is either dead code that silently resolves to `undefined`, or evidence of a broken assumption worth investigating further in the same module.
+
+### 4. Trace `'use server'` scope precisely
+
+A file-level `'use server'` directive applies to every export in that file; a function-level `'use server'` directive applies only to that function. Confirm which form is in use before asserting a specific exported function is a Server Action in scope for this review.
+
+## Minimal safe implementation pattern
+
+```tsx
+'use server'
+
+import { auth } from '@/lib/auth'
+import { db } from '@/lib/db'
+
+export async function deletePost(postId: string) {
+  const session = await auth()
+  if (!session?.user) {
+    throw new Error('Unauthorized')
+  }
+
+  const post = await db.post.findUnique({ where: { id: postId } })
+  if (post.authorId !== session.user.id) {
+    throw new Error('Forbidden')
+  }
+
+  await db.post.delete({ where: { id: postId } })
+}
+```
+
+Anti-pattern (do not approve):
+
+```tsx
+'use server'
+
+export async function deletePost(postId: string) {
+  await db.post.delete({ where: { id: postId } })
+}
+```
+
+Client environment access:
+
+```tsx
+'use client'
+
+// Safe: build-time-injected public variable.
+const publicEndpoint = process.env.NEXT_PUBLIC_API_URL
+```
+
+```tsx
+'use client'
+
+// Unsafe: undefined at runtime, and a signal of a broken server/client mental model.
+const apiKey = process.env.DATABASE_URL
+```
+
+## Adversarial checklist
+
+Before clearing a `'use server'` function as safe:
+
+- Is there a session check (`session?.user` or the framework's equivalent) before any read/write/delete against the data layer?
+- If the function mutates or reads a specific resource by ID, is there a separate ownership/authorization check comparing the resource's owner to the authenticated user?
+- Could a caller invoke this function directly (bypassing the app's own rendered UI) with an arbitrary ID and reach the mutation regardless of what the UI would normally allow?
+
+Before clearing a `'use client'` module's environment access as safe:
+
+- Does every `process.env.*` read in this file use the `NEXT_PUBLIC_` prefix (or the framework's equivalent public convention)?
+- If not, is the read genuinely unreachable dead code, or does it suggest the developer believed a server-only value would be available here?
+
+If any answer reveals a gap, the finding is HIGH (`action-authz-missing`) or MEDIUM (`env-exposure-in-client`) — do not soften either to "worth double-checking."
+
+## Verification targets
+
+- Grep for `'use server'` (file-level and function-level) and enumerate every exported function in scope.
+- For each, grep the function body for an `auth(`/`session` check and, separately, for an ownership comparison (`.authorId`, `.userId`, `.ownerId`, or equivalent) against the authenticated session before any `db.*.delete(`/`db.*.update(`/mutating call.
+- Grep for `'use client'` and, within each such file, grep for `process.env.` reads; flag every one not prefixed `NEXT_PUBLIC_`.