@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.1

package/skills/frontend/monorepo-package-governance-review/references/npm-supply-chain-governance.md

@@ -0,0 +1,95 @@
+# npm Dependency-Confusion & Supply-Chain Governance
+
+Use this reference for reviewing npm registry configuration (`.npmrc`), lockfile commitment/enforcement, and lifecycle-script exposure as a dependency-confusion and supply-chain surface — distinct from (and complementary to) the pnpm-catalog/npm-`overrides` drift-consolidation concerns in `dependency-lockfile-governance.md`. This reference is static-review-only: read and grep `.npmrc`, `package.json`, `package-lock.json`, and CI workflow files; never run `npm install`, `npm ci`, or any registry-touching command.
+
+> Version note: all claims below are grounded in npm CLI docs (`scope.md`, `npmrc.md`, `npm-ci.md`, `npm-approve-scripts.md`) via Context7 on the current stable npm CLI (v10+) documentation set. Label any claim not directly confirmed there as `documentation-based (unverified this session)` rather than asserting it as current default behavior.
+
+## What people get wrong
+
+The naive story is:
+
+> "If it's in `package.json` and installs cleanly, the dependency is trusted."
+
+Wrong. A scoped internal package name (`@myco/internal-lib`) is only routed to a private registry if `.npmrc` (or CI's registry config) explicitly maps that scope to it. Absent that mapping, npm's default resolution falls back to the public registry — and an attacker who publishes a same-named (or higher-versioned) public package under that scope can have it installed instead of the intended internal package. This is **dependency confusion**, and it is a configuration-file finding, not an install-time anomaly you'd only catch by running the install.
+
+## Officially grounded facts
+
+From npm docs (`scope.md`, `npmrc.md`, `npm-ci.md`, `npm-approve-scripts.md`):
+
+1. **Scope-to-registry mapping is the dependency-confusion prevention gate.** `@scope:registry=https://private-registry.example.com` in `.npmrc` (or set via `npm config set @myco:registry=...` / `npm login --registry=... --scope=@myco`) routes every package under that scope to the private registry. A scoped package referenced in `package.json` with no matching `@scope:registry` entry anywhere in the effective `.npmrc` chain (project, user, CI env) resolves against the public npm registry by default.
+2. **`npm ci` requires and enforces a committed `package-lock.json`; `npm install` does not.** `npm ci` is documented as designed for automated/CI environments: it requires an existing lockfile, errors if the lockfile's dependencies don't match `package.json`, and never modifies `package.json`/`package-lock.json` — "ensuring a consistent and frozen state." `npm install` can silently re-resolve and rewrite the lockfile on drift. A CI workflow that runs `npm install` instead of `npm ci` gives up frozen-install enforcement even if a lockfile is committed.
+3. **Dependency lifecycle scripts (`preinstall`/`install`/`postinstall`/`prepare`) are blocked by default and gated by the `allowScripts` field.** `npm approve-scripts` manages an `allowScripts` field in the project's own `package.json`; by default, dependency install scripts are blocked and npm silently skips them for packages not listed in `allowScripts`. A newly added or bumped dependency that ships a `postinstall` script is only a live risk if it is (a) already present in `allowScripts`, or (b) the project has disabled this gate (e.g., an older npm major without the block, or `--ignore-scripts` not enforced the other way). Confirm which npm major is in use before asserting the default-blocked behavior applies — treat as `documentation-based (unverified this session)` if the installed version can't be confirmed from repo evidence.
+4. **Registry-auth credentials must be scoped to a registry host/path, never set bare.** npm docs explicitly contrast a "bad config" (`_authToken=MYTOKEN`, unscoped, applies globally) against "good config" scoped forms: `//registry.example.com/:_authToken=MYTOKEN` (applies to that host) or the narrower `//registry.example.com/myorg/:_authToken=MYTOKEN1` (applies only under that org path). The settings `_auth`, `_authToken`, `username`, `_password`, `email`, `cafile`, `certfile`, and `keyfile` "must all be scoped to a specific registry" — an unscoped `_authToken` line in `.npmrc` is itself a finding, independent of whether the token value is a live secret.
+5. **A lockfile with no committed `package-lock.json` at all is a stronger finding than a stale one.** If the repo has no `package-lock.json` (or it is `.gitignore`d), there is nothing for `npm ci` to enforce against — every install re-resolves ranges live, and the install-time set of resolved versions is unverifiable from the repo alone. Check `.gitignore` for a `package-lock.json` entry as part of this review, not just its presence in the working tree.
+
+## Non-negotiable design rules
+
+### 1. Every referenced scope needs a traceable registry mapping
+
+For each `@scope/name` package referenced anywhere in `package.json` (dependencies, devDependencies, peerDependencies) that is not a well-known public-scope package (e.g., `@types/*` is normally fine unmapped), confirm the scope has a corresponding `@scope:registry=` entry in a `.npmrc` file in scope (project-level `.npmrc` committed to the repo, or documented CI environment/secrets config). If you cannot find the mapping in the repo and the user has not pointed you at a CI-side equivalent, report it as an open finding — do not assume it exists in CI secrets you cannot see.
+
+### 2. Lockfile presence, commitment, and CI enforcement are three separate checks
+
+Do not collapse "there's a `package-lock.json`" into "lockfile governance is fine." Check, separately: (a) does `package-lock.json` exist in the working tree, (b) is it tracked by git (not `.gitignore`d, and appears in `git log`/`git ls-files` history rather than only untracked), and (c) does the CI workflow invoke `npm ci` (or an equivalent frozen-install command) rather than `npm install`. All three must hold for the lockfile to function as a supply-chain control.
+
+### 3. New/bumped dependencies are checked for lifecycle scripts before merge, not after
+
+When a diff adds or bumps a dependency, check that dependency's `package.json` (in `node_modules` if present, or its published manifest) for `preinstall`/`install`/`postinstall`/`prepare`. If present, quote the script content verbatim (same rule as in `dependency-lockfile-governance.md`) and check whether it is already listed in the root `package.json`'s `allowScripts`. A script silently added to `allowScripts` in the same diff that adds the dependency is worth flagging on its own — it means a reviewer approved script execution for a package they may not have separately vetted.
+
+### 4. Unscoped credential lines in `.npmrc` are a blocking finding regardless of the token's live validity
+
+Do not wait to determine whether a token found in `.npmrc` is still active before flagging it. An unscoped `_authToken=...` (or `_auth=`, `_password=`, etc.) line is a structural misconfiguration per npm's own documented guidance, independent of whether the credential is currently valid, because it would apply to *every* registry request npm makes, including ones to the public registry.
+
+### 5. Version-range looseness on sensitive dependencies is a supply-chain question, not a churn question
+
+For dependencies with elevated blast radius (auth, crypto, serialization, CI/build tooling itself), an unpinned wide range (`^1.0.0`, `*`, `latest`) combined with either no lockfile or a non-frozen CI install means the actual installed version is effectively whatever the registry serves at install time. Flag this pairing specifically — a wide range alone, with a committed lockfile and enforced frozen install, is a narrower and less urgent finding than the same range with no enforcement.
+
+## Minimal safe review flow
+
+1. List every `@scope/name` dependency in `package.json`; for each non-public-convention scope, search `.npmrc` (project, and any repo-documented CI config) for a matching `@scope:registry=` entry. Flag any scope with no mapping found in repo evidence.
+2. Confirm `package-lock.json` exists, is tracked by git, and is not listed in `.gitignore`.
+3. Search CI workflow files for the install command; flag `npm install` where `npm ci` is expected, and flag any workflow with no explicit install-frozen step at all.
+4. For new/bumped dependencies in the diff, check for lifecycle scripts and cross-reference the root `package.json`'s `allowScripts` array; quote any script found verbatim.
+5. Grep `.npmrc` for `_authToken`, `_auth`, `_password`, `_password`, `email`, `cafile`, `certfile`, `keyfile` keys; flag any instance not prefixed with a `//host/[path]:` scope fragment.
+6. Report findings with exact file:line citations; propose the `.npmrc` scope entry / CI command / `allowScripts` diff without applying it.
+
+## Greppable sinks (static patterns, no install required)
+
+1. **Missing scope-to-registry mapping for an internal scoped package**
+   - Dangerous pattern: a scoped package name appears in `package.json` (e.g., `grep -E '"@[a-z0-9-]+/[a-z0-9.-]+"' package.json` matching a non-`@types` scope) but `.npmrc` has zero `@scope:registry=` lines for that scope (`grep '@<scope>:registry' .npmrc` returns nothing).
+   - Safe pattern: every non-public scope referenced in `package.json` has a matching `@scope:registry=` line in a committed `.npmrc`, or the user has confirmed an equivalent CI-side registry config exists.
+
+2. **Unscoped auth token or credential in `.npmrc`**
+   - Dangerous pattern: a line at the start of `.npmrc` sets `_authToken`, `_auth`, or `_password` directly (no `//host/path:` prefix) — greppable as an unprefixed `_authToken`, `_auth`, or `_password` key assignment.
+   - Safe pattern: credentials appear only as `//<registry-host>/[optional-path]:_authToken=...` (host- or path-scoped), matching npm's documented good-config form.
+
+3. **CI install step using `npm install` instead of `npm ci` with a committed lockfile present**
+   - Dangerous pattern: `package-lock.json` is tracked in git, but the CI workflow contains `npm install` (not `npm ci`) ahead of build/test steps — searchable via `grep -n 'npm install' .github/workflows/*.yml` (or the equivalent CI config path) with no adjacent `npm ci`.
+   - Safe pattern: CI workflow's dependency-install step is `npm ci`, and a committed `package-lock.json` exists for it to enforce against.
+
+4. **New dependency lifecycle script with no corresponding `allowScripts` review**
+   - Dangerous pattern: diff adds a dependency whose `package.json` contains `"postinstall"` (or `preinstall`/`prepare`), and the root `package.json`'s `allowScripts` array either doesn't exist or doesn't list that package — meaning the reviewer has not made an explicit allow/deny decision visible in the diff.
+   - Safe pattern: the new dependency's lifecycle script is either absent, or present and accompanied by an explicit, reviewed `allowScripts` entry (or a documented `--ignore-scripts` policy) in the same diff.
+
+## Adversarial checklist
+
+Before closing out a supply-chain review as clean, answer these:
+
+- For every scoped package referenced in the diff, did I find an explicit `@scope:registry=` mapping in repo evidence, or am I assuming one exists in CI secrets I cannot see?
+- Is `package-lock.json` both present *and* tracked by git *and* enforced by `npm ci` in CI — not just one or two of the three?
+- Did I search `.npmrc` for every credential-shaped key (`_auth`, `_authToken`, `_password`, `email`, `cafile`, `certfile`, `keyfile`), not just `_authToken`?
+- For any new/bumped dependency, did I check its actual `package.json` for lifecycle scripts rather than assuming a well-known package name is safe?
+- Did I confirm which npm major version is in play before asserting the default-blocked lifecycle-script behavior applies, or did I label it `documentation-based (unverified this session)` because the version isn't visible from repo evidence?
+
+If you cannot answer these from repo evidence, say so rather than declaring the supply-chain surface clean.
+
+## When to push back
+
+Push back if the user asks to:
+
+- treat a missing `@scope:registry` mapping as low-priority because "we've never had an incident" — dependency confusion is a pre-registration attack against a name that doesn't yet need to exist maliciously; absence of a past incident is not evidence of absence of exposure,
+- accept `npm install` in CI because "the lockfile is there anyway" — a committed lockfile with no frozen-install enforcement provides no guarantee about what CI actually installed,
+- allowlist a dependency's lifecycle script "for now" without reading its content, to unblock a merge — this converts a reviewable static finding into an unreviewed trust decision,
+- treat an unscoped `_authToken` in `.npmrc` as fine because "it's a read-only token" — the structural risk is which hosts receive the credential, independent of the token's granted permissions.
+
+Those are not shortcuts. They trade a diagnosable, static, pre-install finding for an assumption that only fails once a malicious package is actually published or a credential actually leaks to the wrong host.

package/skills/frontend/monorepo-package-governance-review/references/task-graph-review.md

@@ -0,0 +1,82 @@
+# Task-Graph Review (Turborepo / Nx)
+
+Use this reference for reviewing `turbo.json` or `nx.json` task-graph configuration to catch false-green CI: a task that reports success/cache-hit without actually re-running against a real upstream change.
+
+> Version note: Turborepo renamed the top-level `pipeline` key to `tasks` (current schema uses `tasks`). Nx task defaults live in `nx.json` under `targetDefaults`, or per-project under an `nx` block in `package.json`/`project.json`. Verify which key the installed major version expects via Context7 before proposing a diff — do not silently rewrite `pipeline` to `tasks` (or vice versa) without confirming the installed version.
+
+## What people get wrong
+
+The naive story is:
+
+> "The task graph is just for parallelism/ordering; caching is a separate, unrelated performance feature."
+
+Wrong. In both Turborepo and Nx, the task graph and the cache key are the same mechanism: a task's cache hit/miss is computed from its declared `inputs` (Nx) or the combination of source files plus `env`/`globalEnv` (Turborepo), plus the recursive hash of everything in its `dependsOn` chain. A gap in either the dependency edges or the cache-key inputs does not just cause wasted rebuilds — it causes **wrongly cached passes**: CI reports green using output from a version of the code that no longer exists in the branch being tested.
+
+## Officially grounded shape
+
+From Turborepo docs (`configuring-tasks`, `caching`, `reference/configuration`):
+
+- `tasks.<name>.dependsOn` — declares task ordering and cross-package dependency. `"^build"` means "the `build` task of every package this package depends on must run first." Omitting this for a task that reads another package's build output is the single most common false-green cause.
+- `tasks.<name>.outputs` — file globs that get cached. Without `outputs`, nothing is cached for that task (Turborepo does not silently assume `dist/**`).
+- `tasks.<name>.inputs` — restricts which source files affect the cache hash for that task specifically; if omitted, Turborepo hashes the package's full file set by default (verify current default behavior against docs for the installed version, since defaults have changed across majors).
+- `tasks.<name>.env` / top-level `globalEnv` — environment variables that affect the cache hash. A task whose output depends on an env var not listed here can produce a cache **hit** even though the env var changed — a classic false-green pattern (e.g., `API_SERVICE_KEY` changed but `build` still serves the stale cached bundle).
+
+From Nx docs (`concepts/task-pipeline-configuration`, `reference/project-configuration`, `features/cache-task-results`):
+
+- `targetDefaults.<target>.dependsOn` — same role as Turborepo's `dependsOn`; `"^build"` again means upstream-project build first.
+- `namedInputs` + `targetDefaults.<target>.inputs` — Nx's cache-key input set. A `production` named input that excludes test files is common; if a target's `inputs` accidentally excludes a file that genuinely affects its output (e.g., a shared `tsconfig.json` not covered by any named input), that target can cache-hit on a real change.
+- `outputs` — same caching role as Turborepo; must match what the target actually writes.
+- Per-project `nx` blocks in `package.json` or `project.json` can override `targetDefaults` — always check both locations before concluding a target has no cache configuration.
+
+## Non-negotiable design rules
+
+### 1. Every cross-package read needs a graph edge
+
+If package B's task reads package A's build output (imports `A/dist`, reads a generated type file, etc.), B's task must declare `dependsOn: ["^build"]` (or the Nx equivalent) referencing that relationship. Do not accept "it happens to work because of task ordering in CI scripts" as a substitute — that is fragile and breaks under `--parallel`/affected-only runs.
+
+### 2. Cache key completeness is a correctness property, not an optimization
+
+Treat a missing `env` entry or an under-scoped `inputs`/`namedInputs` pattern as a bug report, not a suggestion. Ask: "if I change only this file/env var and nothing else, does the declared cache key change?" If the answer is no and the file/var genuinely affects output, that is a blocking finding.
+
+### 3. Do not conflate `outputs` misconfiguration with `inputs` misconfiguration
+
+`outputs` gaps cause **missing** cached artifacts (annoying, but safe — forces a rebuild). `inputs`/`env` gaps cause **wrongly reused** cached artifacts (unsafe — false green). Report these as distinct severities; do not lump them into one "caching issue" finding.
+
+### 4. Legacy `pipeline` key requires a version check, not a silent rewrite
+
+If a `turbo.json` uses `pipeline` instead of `tasks`, do not assume it is simply outdated syntax to "fix." Confirm the installed Turborepo major version via `package.json`/lockfile before recommending the rename, since `pipeline` may still be the correct key for an older pinned version.
+
+### 5. Remote cache tokens are CI secrets, not repo config
+
+`TURBO_TOKEN`/`TURBO_TEAM` (Turborepo Remote Cache) or Nx Cloud access tokens must be sourced from CI secret stores (e.g., referenced as `${{ secrets.TURBO_TOKEN }}` in a GitHub Actions workflow), never hardcoded in `turbo.json`, `nx.json`, or committed CI YAML. Any literal token-shaped string in these files is an automatic blocking finding.
+
+## Minimal safe review flow
+
+1. Identify the tool (`turbo.json` present → Turborepo; `nx.json` present → Nx; both possible in migration).
+2. For the task(s) in scope, list every `dependsOn`/`targetDefaults.dependsOn` edge and cross-check against actual cross-package imports/reads in the source (grep for imports of other workspace packages' build output paths).
+3. For each task with caching enabled, list declared `inputs`/`env`/`globalEnv` and cross-check against files/env vars the task's underlying command actually reads (config files, `.env` references, shared tsconfig/eslint config).
+4. Check for any remote-cache token or registry auth token literal in `turbo.json`, `nx.json`, or CI workflow files.
+5. Report gaps with exact file:line citations and the specific missing key/edge — do not apply the fix; propose the diff.
+
+## Adversarial checklist
+
+Before signing off on a task-graph config, answer these:
+
+- If I changed one source file in an upstream package and nothing else, would every downstream task that reads it show a cache miss?
+- If I changed one environment variable that affects a task's build output, would that task show a cache miss?
+- Does every `outputs` glob match what the underlying build command actually writes — no more, no less?
+- Is there a task that depends on another package's output without declaring `dependsOn` for it, relying instead on incidental script ordering?
+- Is a remote-cache or registry token present as a literal anywhere in this config or adjacent CI YAML?
+
+If you cannot answer all of these from repo evidence, the review is incomplete — say so rather than approving.
+
+## When to push back
+
+Push back if the user asks to:
+
+- "just add `dependsOn: []` everywhere to speed things up" — this removes correctness guarantees, not just performance overhead,
+- silently rewrite `pipeline` to `tasks` (or the reverse) without checking the installed version first,
+- disable caching entirely as a workaround for a false-green bug instead of fixing the missing `inputs`/`env` entry — that hides the symptom without fixing the cache-key gap, and reintroduces it the moment caching is re-enabled,
+- commit a remote-cache token directly into `turbo.json`/`nx.json`/CI YAML "just to get CI working."
+
+Those are not shortcuts. They trade a diagnosable correctness bug for either wasted CI time or a live credential exposure.

package/skills/frontend/nextjs-app-router-data-fetching-review/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: nextjs-app-router-data-fetching-review
+description: Statically review Next.js App Router Server/Client Component boundaries and Server Action data mutations for correct data-fetching placement, bundle-leak risk, and authorization-trust integrity, escalating client-trusted authorization to a security finding rather than a style note.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: architecture
+---
+
+# Next.js App Router Data Fetching Review
+
+## Purpose
+
+Review the Server Component / Client Component boundary (`'use client'` placement and its import graph) and Server Action (`'use server'`) authorization logic in a Next.js App Router codebase, without re-litigating rendering mode, `fetch()` caching, or component decomposition in every response. This skill exists so bundle-leak risk and Server Action authorization-trust defects stay the focus, and so those adjacent concerns stay out of scope.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a `'use client'`/`'use server'` boundary in a diff or PR,
+- determine whether a Server Action correctly authorizes its caller,
+- investigate a report that server-only code or a secret appears to be reaching the browser bundle.
+
+Do not use this skill for:
+
+- pure UI/styling changes with no data-fetching or boundary change,
+- Pages Router API routes (`pages/api/*`) — different security model, not Server Actions; use general API-route review instead,
+- rendering-mode selection (static/ISR/dynamic) or `fetch()` cache-configuration review — that is `nextjs-rendering-caching-review`,
+- component decomposition or state-placement review with no boundary or Server Action involved — that is `react-component-architecture-review`.
+
+## Context7 Documentation Protocol
+
+- Resolve `/vercel/next.js` with `resolve-library-id` before citing any Server Component restriction or Server Action security claim.
+- Before asserting what is or is not safe to import into a Client Component, or what a Server Action must re-verify, read the repo's `package.json` to confirm the installed Next.js major version, then call `query-docs` scoped to that version for "Server Actions security" and "Server Components restrictions." The exact bundling/serialization rules and the availability of the Taint API (`experimental_taintObjectReference` / `experimental_taintUniqueValue`, gated behind `experimental.taint` in `next.config`) are version-specific.
+- 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
+
+- Server Components are the App Router default; `'use client'` is an opt-in boundary marker at the top of a file, above imports. Once a file is marked `'use client'`, everything it imports and directly renders is included in the client bundle — trace that import graph, do not eyeball the single file.
+- Treat a Client Component's import graph reaching a server-only module (a DB/ORM client, a module reading a non-`NEXT_PUBLIC_`-prefixed env var, filesystem access, or any module importing `server-only`) as a HIGH-severity bundle-leak finding. This is the hard security gate for this skill's boundary half.
+- A Server Action's arguments (including `FormData`) are fully client-controlled, even though the function body runs on the server. Treat any Server Action that derives its authorization decision from its own input parameters or `FormData` — instead of re-deriving identity from the server-side session (`cookies()`, an `auth()`/session helper) — as a HIGH-severity Broken Access Control finding (OWASP Top Ten A01), not a style note.
+- Page-level or layout-level authentication/authorization checks do not extend into a Server Action invoked from that page. Each Server Action must independently re-verify session and, for resource-scoped mutations, ownership/role — absence of that re-check is a defect even if an upstream page already checked auth.
+- Do not recommend converting a Client Component to a Server Component without first checking it doesn't rely on browser-only APIs, local state, effects, or event handlers — that breaks functionality, it does not fix a boundary defect.
+- Do not flag every `'use client'` directive as a problem. Only flag it when the boundary is placed higher than the smallest interactive leaf needs, or when its import graph leaks server-only code.
+- 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, session secret, or credential found in a Server Action, Client Component, or example data as a HIGH-severity finding requiring immediate escalation, not a boundary 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 bundle-leak trace method, the authorization decision tree, and the required output shape.
+- [OWASP A01 — Broken Access Control](references/owasp-a01-broken-access-control.md) — load only when a Server Action authorization finding is present, to ground the finding's severity and framing.
+
+## Response minimum
+
+Return, at minimum:
+
+- per-boundary table (`'use client'` file, traced import-graph leak or clean, evidence file:line),
+- per-Server-Action table (action, authorization source used, verdict),
+- ranked findings with file:line, risk class, and fix,
+- the Next.js major version the claims were verified against,
+- verdict: approve / approve-with-notes / block,
+- evidence level and open questions.

package/skills/frontend/nextjs-app-router-data-fetching-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "nextjs-app-router-data-fetching-review",
+  "name": "Next.js App Router Data Fetching Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Server/Client Component boundaries and Server Action authorization trust for data-fetching correctness and security, using Next.js's own Server Components/Server Actions documentation loaded progressively and grounded via Context7 against the repo's confirmed Next.js version.",
+  "source_type": "original",
+  "official_docs": [
+    "https://nextjs.org/docs/app/building-your-application/rendering/server-components",
+    "https://nextjs.org/docs/app/building-your-application/rendering/client-components",
+    "https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations",
+    "https://owasp.org/www-project-top-ten/"
+  ],
+  "security_notes": "A Server Action that derives an authorization decision from client-supplied form data instead of the server-side session is a Broken Access Control finding (OWASP A01) and must be escalated as HIGH, not filed as a style note. A Client Component whose import graph reaches a server-only module (DB client, non-NEXT_PUBLIC_ env access, server-only-guarded module) is a HIGH-severity bundle-leak finding. Static-review-only skill: it reads and greps component/action source but never executes, builds, or runs application code. Treat any hardcoded API key, token, or credential found in a Server Action or Client Component as a HIGH-severity finding requiring immediate escalation.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/nextjs-app-router-data-fetching-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/nextjs-app-router-data-fetching-review/references/owasp-a01-broken-access-control.md

@@ -0,0 +1,42 @@
+# OWASP A01 — Broken Access Control
+
+Use this reference only when a Server Action authorization finding is present, to ground the finding's severity and framing. Do not load this for bundle-leak-only findings.
+
+## What people get wrong
+
+The naive story is:
+
+> The Server Action is protected because it only runs on the server — the client can't tamper with server-side code.
+
+That confuses **where code executes** with **what data the code trusts**. The code executes on the server; the arguments it receives (function parameters, `FormData` fields) originate entirely from the client and are attacker-controlled, whether the caller uses the rendered form or crafts a direct request bypassing the UI. OWASP's A01:2021 — Broken Access Control category exists precisely for this class of defect: access-control decisions enforced only on the client, or derived from client-supplied data, rather than re-verified server-side against a trusted source (the session).
+
+## Why this maps to A01, not a generic bug
+
+OWASP Top Ten A01 (Broken Access Control) covers failures where a user can act outside their intended permissions. The Server Action pattern in this skill's scope produces exactly that failure class when:
+
+- **Authorization uses client-supplied identity** — the action reads a `userId` or `role` field out of its own parameters/`FormData` instead of the server session, so any caller can claim to be any user or role.
+- **Insecure Direct Object Reference (IDOR)** — the action re-derives the session correctly (so the caller's identity is trustworthy) but never checks that the session's user owns or may act on the specific resource ID supplied, so an authenticated user can act on another user's resource.
+- **Missing function-level access control** — the action performs a privileged mutation with no authorization check at all, relying on an upstream UI/page-level gate that the direct-invocation path bypasses entirely.
+
+All three are Broken Access Control, not merely "missing validation" or "input sanitization" — the defect is that the access-control decision was placed in the wrong trust zone.
+
+## Non-negotiable framing rules
+
+- **Severity floor**: any of the three patterns above is HIGH severity. Do not downgrade because the UI "normally" prevents the bad path — Server Actions are directly invokable independent of the rendered UI, and the review must assume a caller that bypasses it.
+- **Evidence requirement**: cite the exact client-controlled field (parameter name or `FormData` key) being trusted, and cite the absence (or presence, for IDOR) of a resource-ownership check.
+- **Do not conflate with input validation**: a missing `zod`/schema validation on `FormData` shape is a data-integrity note, not an A01 finding by itself. A01 applies specifically to the authorization *decision*, not to whether the input is well-formed.
+- **Page-level checks do not transfer**: an `auth()` check in the page component that renders the form does not protect the Server Action. State this explicitly in the finding so the fix targets the action, not the page.
+
+## Minimal safe fix pattern
+
+Every HIGH finding from this reference should point toward the same shape of fix: re-derive identity from the server-side session inside the action itself, and, for resource-scoped mutations, verify ownership/role against that re-derived identity before performing the mutation. The fix is inside the Server Action, not in the calling page or the client form.
+
+## When to push back
+
+Push back if the user proposes:
+
+- "the page already checks auth, so the action doesn't need to" — reject; each Server Action is an independent invocation surface.
+- "we'll trust the role field the client sends since the form only shows it to admins" — reject; UI visibility is not an access control.
+- "IDOR checks can wait, the session check is the important part" — reject; an authenticated-but-unauthorized mutation is still Broken Access Control.
+
+Those are not shortcuts. They are the exact failure mode this reference exists to catch.

package/skills/frontend/nextjs-app-router-data-fetching-review/references/workflow-and-output.md

@@ -0,0 +1,94 @@
+# Review workflow and findings contract
+
+Use this reference for the full boundary/authorization review procedure and the required output shape.
+
+## What people get wrong
+
+The naive story is:
+
+> `'use client'` just means "this component runs in the browser too" — eyeball the file, check it doesn't obviously import a DB client, and move on. Server Actions "run on the server," so whatever they do is trusted.
+
+Wrong, on both halves.
+
+- `'use client'` marks a **module-graph boundary**, not a single-file property. Once a file has `'use client'`, every module it imports and every component it directly renders is pulled into the client bundle — including transitive imports through shared barrel files (`lib/index.ts` re-exporting both a pure util and a DB client). A file that "looks clean" can still leak a secret three imports deep.
+- A Server Action's function body runs on the server, but its **inputs are fully attacker-controlled**. Nothing stops a caller from invoking the action directly with crafted `FormData`, bypassing the UI, any client-side validation, and any upstream page-level auth check entirely. "It runs on the server" says nothing about whether the action re-verifies who is calling it.
+
+The review has to operate at both the **import-graph** level (boundary/bundle-leak) and the **argument-trust** level (Server Action authorization), and it must not let a passing check on one half stand in for the other.
+
+## Workflow
+
+1. **Confirm the Next.js major version**
+   - Read `package.json` for the exact Next.js version. Server Component restrictions and the availability of the Taint API (`experimental_taintObjectReference`, `experimental_taintUniqueValue`, gated behind `experimental.taint`) are version-sensitive — see the Context7 Documentation Protocol in SKILL.md.
+
+2. **Enumerate every `'use client'` file in scope**
+   - For each, read its import list.
+   - Trace transitively: if it imports a local module, open that module and check its imports too, until you reach either a leaf (no further local imports) or a module that imports `server-only`, reads a non-`NEXT_PUBLIC_`-prefixed environment variable, touches the filesystem, or instantiates a DB/ORM client.
+   - Record the exact chain (file A imports file B imports file C which reads `DATABASE_URL`) — a bundle-leak finding without a traced chain is not a finding, it is a guess.
+
+3. **Enumerate every Server Action (`'use server'`) in scope**
+   - This includes files with a top-level `'use server'` directive and inline `async function` bodies marked `'use server'` inside a Server Component.
+   - For each action, identify: what mutation/read does it perform, and what value gates whether it is allowed to proceed?
+
+4. **Classify each Server Action's authorization source**
+   - **Session-derived (correct)**: the action calls a session/auth helper (`auth()`, `verifySession()`, a `cookies()`-backed session read) and uses the identity/role returned from that call to gate the mutation.
+   - **Input-derived (defect)**: the action reads a user ID, role, or "isAdmin"-style flag from its own parameters or from `formData.get(...)` and uses that value — not a freshly re-derived session — to gate the mutation or to decide *whose* data to act on.
+   - **Missing (defect)**: the action performs a mutation with no authorization check at all, relying solely on an upstream page-level check that does not extend into the action.
+   - **Resource-scoped (verify ownership, not just auth)**: even with a valid session, if the action acts on a specific resource ID (e.g. `deletePost(postId)`), confirm it checks that the session's user actually owns/may act on that resource — an authenticated-but-unauthorized mutation is an IDOR (Insecure Direct Object Reference), still Broken Access Control.
+
+5. **Check for boundary-placement inefficiency (non-security)**
+   - If a `'use client'` directive sits on a large subtree (e.g. an entire page or layout) where only a small leaf component actually needs interactivity/state/browser APIs, note it as a MEDIUM bundle-size finding — recommend pushing the boundary down to the smallest interactive leaf. Do not treat this the same as a traced server-only leak.
+
+6. **Produce ranked findings**
+   - Order by blast radius: confirmed bundle leaks and Broken Access Control findings first (HIGH), then missing resource-ownership checks, then boundary-placement/bundle-size notes (MEDIUM/LOW).
+
+## Decision tree
+
+- A `'use client'` file's traced import graph reaches a module importing `server-only`, reading a non-`NEXT_PUBLIC_` env var, or instantiating a DB/ORM client → **HIGH: bundle-leak risk.** Cite the exact import chain.
+- A Server Action gates its mutation/authorization using a value taken from its own parameters or `FormData` instead of a freshly re-derived session → **HIGH: Broken Access Control (OWASP A01).** Load `references/owasp-a01-broken-access-control.md` and frame the finding per that reference.
+- A Server Action re-derives session correctly but never checks that the session's user owns/may act on the specific resource ID it was given → **HIGH: IDOR / Broken Access Control (OWASP A01).**
+- A Server Action has no authorization check at all, relying on an upstream page-level check → **HIGH: Broken Access Control (OWASP A01).** Note explicitly that page-level checks do not extend into Server Actions.
+- `'use client'` is placed on a subtree larger than the interactive leaf requires, with no traced server-only leak → **MEDIUM: avoidable bundle-size cost.** Recommend pushing the boundary down; do not escalate to HIGH.
+- A Client Component genuinely needs conversion consideration but relies on browser-only APIs, local state, effects, or event handlers → do not recommend converting it to a Server Component; note the constraint instead.
+
+## Output contract
+
+Return:
+
+1. Next.js major version confirmed (or explicitly noted as unconfirmed)
+2. Per-boundary table: `'use client'` file | traced import-graph result (clean / leak with chain) | evidence (file:line)
+3. Per-Server-Action table: action | authorization source (session-derived / input-derived / missing / resource-scoped-unverified) | verdict
+4. Ranked findings, each with:
+   - file:line evidence
+   - risk class (bundle-leak / broken-access-control / IDOR / missing-auth-check / avoidable-bundle-size)
+   - concrete fix, scoped to the narrowest sufficient change
+   - severity (HIGH / MEDIUM / LOW)
+   - evidence level (`repo evidence`, `documentation-based`, `inference`)
+5. Verdict: approve / approve-with-notes / block
+6. Open questions or explicitly out-of-scope items (e.g. Pages Router API routes encountered, or rendering/caching concerns deferred to `nextjs-rendering-caching-review`)
+
+## Validation gates
+
+- Every bundle-leak finding traces the actual import chain from the `'use client'` file to the leaked server-only module — no finding asserts bundle contents without a traced chain.
+- Every authorization finding identifies exactly which client-controlled value (parameter name, `FormData` key) is being trusted in place of a session re-derivation.
+- No finding recommends converting a Client Component to a Server Component without first confirming it has no browser-only API, state, effect, or event-handler dependency.
+- No Broken Access Control finding is downgraded to a style note or MEDIUM severity for "code cleanliness" reasons — the security-notes hard gate in `metadata.json` applies regardless of how small the fix looks.
+
+## Common failure modes
+
+- Flagging every `'use client'` directive as a problem regardless of whether interactivity is actually needed there.
+- Missing transitive imports — checking only the top-level imports of a `'use client'` file and stopping, rather than following a shared `lib/db.ts` imported through an intermediate barrel file.
+- Assuming Server Actions are inherently safe "because they run on the server," while ignoring that their inputs are fully client-controlled and can be invoked directly, bypassing the UI.
+- Treating a page-level or layout-level auth check as sufficient for a Server Action invoked from that page, without checking the action re-verifies independently.
+- Confusing "authenticated" with "authorized for this specific resource" — a valid session does not imply the session's user may act on the resource ID supplied.
+
+## Adversarial checklist
+
+Before finalizing a finding, answer these:
+
+- Does a Server Action re-derive the acting user's identity from the server session, or trust an id/role passed in from the client?
+- Does the import graph of every `'use client'` file actually avoid server-only modules, traced transitively, not just at the top level?
+- Is `'use client'` placed at the smallest necessary leaf, or does it needlessly convert a large subtree?
+- Would this Server Action behave safely if called directly with crafted `FormData` bypassing the UI entirely?
+- For resource-scoped actions, does the check confirm the session's user owns/may act on the specific resource ID, not just that a session exists?
+
+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, except for Broken Access Control findings with clear file:line evidence of client-controlled authorization, which stay HIGH regardless.

package/skills/frontend/nextjs-rendering-caching-review/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: nextjs-rendering-caching-review
+description: Statically review Next.js App Router route segments and fetch() calls for rendering-mode (static/ISR/dynamic) and Data-Cache misconfiguration, escalating cross-user data leakage to a security finding rather than a performance nit.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: architecture
+---
+
+# Next.js Rendering & Caching Review
+
+## Purpose
+
+Review Next.js App Router rendering-mode selection (static / ISR / dynamic) and `fetch()` / Data-Cache configuration without re-litigating component architecture, styling, or Pages Router APIs in every response. This skill exists so caching-staleness and cross-user data-leakage risk stay the focus, and so those adjacent concerns stay out of scope.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review caching/revalidation behavior in an App Router PR,
+- investigate a report of stale data being served,
+- investigate a report of one user seeing another user's data,
+- decide whether a route should be static, ISR, or dynamic.
+
+Do not use this skill for:
+
+- Pages Router codebases (`getStaticProps` / `getServerSideProps`) — different API surface; do not apply App Router `fetch()`-cache guidance to it,
+- purely client-side SWR/React Query caching with no server `fetch()` involved,
+- component decomposition or state-placement review — that is `react-component-architecture-review`.
+
+## Context7 Documentation Protocol
+
+- Resolve `/vercel/next.js` with `resolve-library-id` before citing any caching-default claim.
+- Before asserting a `fetch()` caching default, read the repo's `package.json` to confirm the installed Next.js major version, then call `query-docs` scoped to that version. Next's `fetch()` caching default changed between Next 14 (`cache: 'force-cache'` default) and Next 15 (uncached by default; `GET` Route Handlers also uncached by default). A default claim verified against one major must never be reused for another.
+- If the repo has adopted the `use cache` / Cache Components model (Next 15.x canary / Next 16 opt-in via the top-level `cacheComponents` config, which replaced the removed `experimental.dynamicIO`/`experimental.useCache` flags), treat that as a distinct caching paradigm from the classic `fetch()`-options model — do not mix `cacheLife`/`cacheTag` guidance with classic `next: { revalidate, tags }` guidance in the same finding without confirming which model the route actually uses.
+- `revalidateTag(tag)` accepts a second, version-sensitive `options.profile` argument in newer releases: `profile: "max"` marks the tag stale for background stale-while-revalidate on next visit (the currently recommended pattern); omitting it schedules an immediate expire-on-next-request, which current docs mark as deprecated in favor of `profile: "max"` or `updateTag`. Confirm which signature the installed version supports via `query-docs` before recommending one — do not assume the two-argument form exists on an older major.
+- 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
+
+- First read `package.json` to confirm the installed Next.js major version and whether the deployment target is Vercel or self-hosted. Do not assert a caching default or a platform-specific cache primitive (e.g. Vercel Data Cache persistence across deployments) without confirming both.
+- Classify every in-scope route segment as static, ISR, or fully dynamic before evaluating its `fetch()` calls. A route with no `revalidate` export, no `dynamic` export, and no dynamic API (`cookies()`, `headers()`, `searchParams`) usage defaults to static; do not assume dynamic without evidence.
+- Treat cross-user Data Cache leakage — a per-user or session-scoped response cached as if it were shared/public — as a HIGH-severity security finding requiring security-review sign-off, not a caching-strategy suggestion. This is the hard security gate for this skill.
+- Do not recommend `export const dynamic = 'force-dynamic'` on a whole route to fix a leakage finding without first checking whether a scoped `cache: 'no-store'` on the offending `fetch()` call, or a user-scoped cache tag/key, is sufficient. Route-wide `force-dynamic` is a real TTFB/cost overcorrection.
+- Do not conflate Request Memoization (per-render dedup of identical `fetch()` calls, scoped to a single render pass) with the Data Cache (persists across requests/deployments). A finding that treats memoization as if it persisted across users is wrong on its face.
+- Do not treat every dynamic route as a defect. Routes that genuinely require per-request data (auth-gated dashboards, personalized content) are correctly dynamic; only flag dynamic classification when the same correctness could be achieved with static or ISR.
+- 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, session secret, or credential found in a `fetch()` call, header, or example data as a HIGH-severity finding requiring immediate escalation, not a caching 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 rendering-mode classification table, the leakage decision tree, and the required output shape.
+- [ISR reference](references/isr-reference.md) — load only for routes using `generateStaticParams` + `revalidate`, or on-demand revalidation via `revalidatePath`/`revalidateTag`.
+- [Cache-tag invalidation reference](references/cache-tag-invalidation.md) — load only when tag-based invalidation (`next: { tags }`, `revalidateTag`) is present in the diff.
+
+## Response minimum
+
+Return, at minimum:
+
+- per-route rendering-mode table (route, mode, justification),
+- ranked caching findings with file:line, risk class, and fix,
+- the Next.js major version the claims were verified against,
+- verdict: approve / approve-with-notes / block,
+- evidence level and open questions.

package/skills/frontend/nextjs-rendering-caching-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "nextjs-rendering-caching-review",
+  "name": "Next.js Rendering & Caching Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Next.js App Router rendering-mode selection and fetch()/Data-Cache configuration for staleness and cross-user data-leakage risk, using Next.js's own caching documentation loaded progressively and grounded via Context7 against the repo's confirmed Next.js version.",
+  "source_type": "original",
+  "official_docs": [
+    "https://nextjs.org/docs/app/building-your-application/caching",
+    "https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating",
+    "https://nextjs.org/docs/app/guides/incremental-static-regeneration",
+    "https://nextjs.org/docs/app/api-reference/functions/revalidateTag"
+  ],
+  "security_notes": "Cross-user Data Cache leakage (caching a per-user response as if it were shared/public) is a data-exposure defect, not merely a performance nit — this skill escalates such findings to HIGH severity and requires a security-review sign-off, not just a caching-strategy note. Static-review-only skill: it reads and greps route/fetch source but never executes, builds, or runs application code. Treat any hardcoded API key, token, or credential found in a fetch() call or header as a HIGH-severity finding requiring immediate escalation.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/nextjs-rendering-caching-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/nextjs-rendering-caching-review/references/cache-tag-invalidation.md

@@ -0,0 +1,45 @@
+# Cache-tag invalidation reference (next: { tags }, revalidateTag)
+
+Use this reference only when the diff includes `next: { tags: [...] }` on a `fetch()` call, or a `revalidateTag`/`revalidatePath` call. Do not load it for routes with no tag-based invalidation.
+
+## What people get wrong
+
+The naive story is:
+
+> Tag it, call `revalidateTag` on mutation, done — invalidation is invalidation.
+
+Wrong. Tag scope is a design decision with the same over-/under-invalidation failure modes as cache-key design anywhere else: too coarse a tag invalidates far more cached data than the mutation actually changed (cache-hit-rate and cost regression across unrelated routes); too fine or simply mismatched a tag misses the mutation entirely (stale-data bug that looks like "the cache is broken" but is actually "the tag was never invalidated"). Official Next.js guidance itself states a preference for tag-based revalidation over path-based (`revalidatePath`) specifically because it is more precise — but precision only helps if the tag design matches the actual data-ownership boundaries.
+
+## Officially grounded shape
+
+- `fetch(url, { next: { tags: ['posts'] } })` associates that cached entry with the tag `'posts'`. Multiple unrelated `fetch()` calls can share a tag; a single `fetch()` call can carry multiple tags.
+- `revalidateTag(tag)` (imported from `next/cache`, called from a Server Action or Route Handler) invalidates **every** cached entry carrying that tag, forcing a re-fetch on the next request to any route that reads it — not just the route that triggered the mutation.
+- `revalidatePath(path)` invalidates all cached data for a specific route path, without needing to know which tags are attached to it. Official guidance recommends preferring tag-based revalidation over path-based when the tag structure is known, precisely because path-based invalidation is coarser and easier to over-invalidate with.
+- Route Handlers are a common on-demand-revalidation entry point (e.g., a webhook receiver calling `revalidateTag` in response to an external CMS publish event) — verify any such handler is itself access-controlled (secret/token check) so an unauthenticated caller cannot trigger arbitrary cache invalidation (a cost/DoS-adjacent concern, not just a staleness one).
+
+## Non-negotiable design rules
+
+1. **Tag granularity should match data-ownership boundaries, not convenience.** A single `'posts'` tag shared by every post's detail page means updating one post's title invalidates every post's cached page. If the mutation is scoped to one entity, prefer a per-entity tag (`post-${id}`) plus a broader list-level tag (`posts`) only where the list view genuinely needs to reflect the change too — and invalidate both explicitly when both are affected.
+
+2. **Every mutation that changes tagged data must call the matching invalidation, and only that data's tag.** Trace each `revalidateTag`/`revalidatePath` call back to the mutation that triggers it; confirm the tag argument matches a tag actually used by a `fetch()` in the affected route, not a stale or copy-pasted tag name from an unrelated feature.
+
+3. **On-demand revalidation entry points (webhook/API routes) must be access-controlled.** An unauthenticated `revalidateTag`/`revalidatePath` endpoint lets any caller force full cache invalidation on demand — flag as a MEDIUM-or-higher availability/cost finding if no secret/token/signature check gates the handler.
+
+4. **Do not use tag-based invalidation as a substitute for per-user cache scoping.** Tags invalidate shared cache entries; they do not make a shared cache entry safe to serve to multiple users. If the underlying leakage concern from SKILL.md's hard security gate applies (per-user data cached without a `no-store`/scoped key), adding a tag does not resolve it — the fetch still needs `cache: 'no-store'` or a genuinely user-scoped cache key, independent of tagging.
+
+## Minimal safe verification flow
+
+1. List every tag used across in-scope `fetch()` calls and every `revalidateTag`/`revalidatePath` call in the diff.
+2. For each mutation, confirm it invalidates exactly the tags that cover data it changed — no more, no less.
+3. For each on-demand-revalidation Route Handler, confirm it is access-controlled.
+4. Confirm no leakage concern is being "fixed" with tagging alone when it actually requires `no-store` or per-user cache-key scoping.
+
+## When to push back
+
+Push back if the user asks for:
+
+- one broad tag applied to "everything on this page" to avoid designing per-entity tags — that guarantees over-invalidation as the app grows,
+- an on-demand revalidation Route Handler with no auth check "since it's just a cache refresh" — uncontrolled invalidation is a cost and availability surface, not a harmless refresh,
+- using `revalidateTag` as the fix for a reported "user A sees user B's data" bug — that is a caching-scope/leakage bug, not a staleness bug, and tagging does not address it.
+
+Those are not shortcuts. They convert a precise invalidation model into either a blunt one or a papered-over security defect.