create-pracht 0.2.6 → 0.4.0

package/skills/audit-bundles/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: audit-bundles
+version: 1.2.0
+description: |
+  Analyze a pracht production build. Report client bundle size per route,
+  flag fat vendor chunks, find route components that ship large dependencies,
+  and suggest dynamic `import()` and prefetch strategies based on observed
+  navigation patterns.
+  Use when asked to "audit bundles", "why is my JS so big", "bundle size per
+  route", "what's in my vendor chunk", or "tune prefetching".
+allowed-tools:
+  - Bash
+  - Read
+  - Grep
+  - Glob
+---
+
+# Pracht Audit Bundles
+
+Pracht performs route-level code splitting via the Vite plugin and emits a
+manifest. This skill reads that manifest, sizes each route's client payload,
+and surfaces the worst offenders.
+
+## Step 1: Build with analysis
+
+If the pracht MCP server is registered (see docs/MCP.md), prefer its tools
+(`inspect_routes`, `inspect_api`, `inspect_build`, `doctor`, `verify`) over
+shelling out. Prerequisites: `pracht inspect` needs a vite config with the
+pracht plugin; `pracht inspect build` reads artifacts from a prior
+`pracht build`.
+
+```bash
+pracht build --analyze --json
+```
+
+This is the native per-route payload report: for every route (pattern + render
+mode) it emits the transitive client JS chunks with raw and gzip sizes
+(`routes[].chunks`), route-specific and total sums (`routeGzipBytes`,
+`totalGzipBytes`), and the shared entry chunks broken out (`shared`), sorted by
+total gzip descending. A stale `dist/` produces misleading numbers — rebuild,
+don't reuse.
+
+Exit-code footgun: when configured budgets fail, `pracht build --analyze
+--json` sets a nonzero exit code while still printing valid JSON on stdout.
+Do not treat exit 1 as "no output" — parse stdout anyway, or run with
+`--no-budget-fail` to keep the exit code clean.
+
+For a human-readable table, use `pracht build --analyze` instead.
+
+## Step 2: Pull supporting metadata
+
+```bash
+pracht inspect build --json
+```
+
+Captures the resolved adapter, client entry URL, and CSS/JS manifest. Cross
+reference with `dist/client/.vite/manifest.json` for chunk metadata
+(file, imports, dynamicImports, css, isEntry) — needed for vendor fan-in
+analysis (Step 4) and CSS sizing, which the analyze report does not cover.
+
+## Step 3: Interpret per-route payload
+
+From the Step 1 JSON, report:
+
+| Route | Hydration | Route JS (gz) | Shared (gz) | Total (gz) | CSS (gz) | LCP-class? |
+| ----- | --------- | ------------- | ----------- | ---------- | -------- | ---------- |
+
+`gz` = gzip size, taken directly from `routeGzipBytes` / `shared.gzipBytes` /
+`totalGzipBytes`. Size CSS chunks (from `cssManifest`) with `zlib.gzipSync`.
+
+Account for the per-route `hydration` field the analyze JSON emits (omitted
+means `"full"`) before judging sizes:
+
+- `hydration: "none"` routes ship **0 bytes** of JS — the report already
+  zeroes them out. Never flag them.
+- `hydration: "islands"` routes never load the shared client entry; their
+  total is the islands bootstrap plus **every** island chunk in the app — an
+  upper bound, since which islands a page actually uses is only known at
+  render time. Treat their totals as pessimistic.
+- Only `"full"` routes pay route JS + shared entry.
+
+`LCP-class?` is `yes` when total gz exceeds 200 KB — that's the order of
+magnitude where mid-tier mobile starts losing LCP budget. Apply the threshold
+after the hydration adjustment above.
+
+If the app declares `budgets` in the pracht plugin config, the Step 1 JSON also
+contains a `budgets` section with per-route pass/fail — lead the report with any
+failures. If no budgets are configured, suggest adding them (see
+docs/PERFORMANCE.md), starting from the current sizes plus ~10% headroom.
+
+## Step 4: Vendor chunk health
+
+Identify chunks under `node_modules/`. For each:
+- Size (raw and gz).
+- Number of route chunks that import it (fan-in).
+
+A vendor chunk imported by every route is the framework runtime — expected.
+A vendor chunk imported by ONE route is a code-splitting opportunity (move
+the import inside that route's component or lazy-load it).
+
+A vendor chunk over 100 KB gz that is imported by every route is worth a
+manual review — common offenders: date libraries, validation libraries,
+icon sets, charting libraries.
+
+## Step 5: Heavy dependencies in route components
+
+For each route chunk over 50 KB gz, run `pracht inspect build --json` plus
+`du`-style analysis on the chunk contents:
+
+- Grep the chunk source for known heavy module headers (`moment`, `lodash`,
+  `chart.js`, `three`, `@stripe/stripe-js`, etc.).
+- For each, recommend: (a) tree-shakeable alternative, (b) dynamic import
+  inside an event handler, (c) lazy-load via `lazy()` from `preact-suspense`.
+
+## Step 6: Prefetch strategy
+
+`pracht inspect routes --json` exposes `prefetch` per route on a current
+`@pracht/cli`. If your CLI version predates the field (it's absent from the
+JSON), fall back to grepping the route manifest source for `prefetch:`.
+Route-level strategies are `"none"`, `"hover"`, `"intent"`, `"viewport"`
+(`"render"` exists only as a per-link override — see below). Recommend:
+
+- `"viewport"` for primary-nav links.
+- `"hover"` for content links inside long pages.
+- `"intent"` (default) is fine if you're not sure.
+- `"none"` for routes that are large and rarely visited (admin, settings) so
+  hover doesn't preload them.
+
+Cost model for `"viewport"`: the IntersectionObserver fires once per anchor —
+it unobserves the anchor after the first prefetch, and prefetched route state
+is cached for 30 seconds — so a link in a marketing footer costs at most one
+prefetch per anchor per page view, not one per scroll. It's still wasteful
+for a 300 KB route that footer visitors rarely click; prefer `"none"` or
+`"hover"` there. Also note the per-link escape hatch: `<Link prefetch="...">`
+overrides the route-level strategy for a single anchor (and accepts the extra
+`"render"` value — prefetch as soon as the link renders, the most eager
+option), so a route can stay on `"intent"` while its primary-nav link opts
+into `"viewport"` or `"render"`.
+
+## Step 7: Report
+
+Three sections:
+
+1. **Top 10 routes by total client payload** — sorted desc.
+2. **Top 10 vendor chunks by size** — with fan-in.
+3. **Suggestions** — ordered by impact (KB saved × routes affected).
+
+Tag every finding with a primary severity — `error` (budget failure), `warn`
+(LCP-class route, single-route vendor chunk), `info` (tuning opportunity) —
+and keep the size numbers as supporting detail.
+
+Include before/after estimates for each suggestion: "Lazy-load `chart.js`
+inside `Component`: -180 KB gz off `/dashboard/analytics`."
+
+## Rules
+
+1. Always run `pracht build --analyze --json` first. A stale build is a source
+   of bad advice.
+2. Use the Vite manifest as the source of truth — chunk names rotate per
+   build.
+3. Report gzip size, not raw — the wire size is what users pay.
+4. Distinguish "shared" code (entry + framework) from "route-specific" code
+   when reporting; users can only optimize the latter.
+5. Do not auto-edit. Bundle changes have render-blocking implications;
+   surface and let the user choose.
+
+$ARGUMENTS

package/skills/audit-csrf/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: audit-csrf
+version: 1.2.0
+description: |
+  Inventory every form submission and mutation API in the project, then verify
+  the CSRF posture. Pracht enforces same-origin on mutation API requests by
+  default (`api.requireSameOrigin`); this skill checks that the default is
+  intact and that cookie strategy, middleware, or tokens cover whatever the
+  built-in check does not.
+  Use when asked to "audit CSRF", "check CSRF protection", "are forms safe",
+  "review session security", or after enabling cross-origin form usage.
+allowed-tools:
+  - Bash
+  - Read
+  - Grep
+  - Glob
+---
+
+# Pracht Audit CSRF
+
+What the framework guarantees: by default (`ApiConfig.requireSameOrigin`,
+`true` unless explicitly disabled), the runtime rejects state-changing API
+requests (`POST`/`PUT`/`PATCH`/`DELETE`) with a 403 unless the browser signals
+an exact same-origin fetch (`Sec-Fetch-Site: same-origin`) or the request's
+`Origin`/`Referer` matches the request URL's origin. `same-site` is not
+accepted (sibling subdomains can be attacker-controlled). Requests with no
+browser provenance headers at all (curl, server-to-server) are allowed — the
+threat model is browser-form CSRF, which cannot strip those headers. Page
+routes reject unsafe methods outright, so the API surface is where mutations
+live.
+
+The same check also covers **WebSocket upgrade requests** (any request carrying
+an `Upgrade` header), even though they are `GET`. Browsers do not apply CORS to
+WebSocket, so an upgrade is a cross-site-reachable, cookie-carrying request —
+cross-site WebSocket hijacking. `requireSameOrigin: false` therefore opens
+sockets as well as mutations.
+
+The audit therefore targets the OPT-OUTS and the remaining layers, in order of
+preference:
+
+1. **Built-in same-origin enforcement** (`requireSameOrigin`, on by default).
+2. **`SameSite=Lax` (or `Strict`) on session cookies** — defense in depth.
+3. **Origin-check middleware** — only needed when `requireSameOrigin` is
+   disabled or for non-`/api` endpoints.
+4. **Per-request tokens** — only when `SameSite=None` is required.
+
+Prerequisites: `pracht inspect` requires a vite config that registers the
+pracht plugin.
+
+## Step 0: Check the built-in guard
+
+Read `src/routes.ts` (the app manifest) for
+`defineApp({ api: { requireSameOrigin } })`. Absent means `true` (the
+default). An explicit `requireSameOrigin: false` is a top finding (`error`):
+the project has opted out of the built-in CSRF protection and MUST show
+compensating layers (origin-check middleware or token protocol) — demand them
+in the report.
+
+## Step 1: Inventory mutation surfaces
+
+### Forms
+
+Grep for `<Form ` across `src/`. For each occurrence:
+- Capture `method` (default is `get` — only `post`/`put`/`patch`/`delete` are
+  CSRF-relevant).
+- Capture `action`.
+
+### API mutations
+
+```bash
+pracht inspect api --json
+```
+
+If the pracht MCP server is registered (see `docs/MCP.md`), prefer its tools
+(`inspect_routes`, `inspect_api`, `inspect_build`, `doctor`, `verify`) over
+shelling out.
+
+For each API route, read the exported `methods`. Mutation methods: `POST`,
+`PUT`, `PATCH`, `DELETE`. Caveat: a `default`-export handler serves ALL
+methods but reports `methods: []` — check the `hasDefaultHandler` field
+(requires a current `@pracht/cli`) or, on older CLIs, grep the handler file
+for `export default`. A default handler counts as exposing all mutation
+methods unless it gates on `request.method` itself.
+
+### WebSocket upgrades
+
+Grep API handlers for `upgrade`, `WebSocketPair`, and `status: 101`. A route
+that returns a handshake is a mutation-equivalent surface: it is reachable
+cross-site, carries cookies, and — once open — is not covered by any
+per-request check. Treat it as a mutation surface in Step 5, and additionally
+verify:
+
+- The handler **authenticates the handshake** (session check in the handler or
+  in `api.middleware`). The built-in origin check stops other *websites*; it
+  does nothing about an unauthenticated client.
+- Authorization is re-checked per message where messages carry authority. The
+  socket outlives the request that opened it, so a session revoked afterwards
+  does not close it.
+
+## Step 2: Inspect the session cookie
+
+Locate cookie issuance — typically `src/server/session.ts`, `src/api/auth/*`,
+or anywhere `Set-Cookie` appears in a response. For every cookie set:
+
+| Attribute        | Required posture             | Failure mode                |
+| ---------------- | ---------------------------- | --------------------------- |
+| `HttpOnly`       | Present                      | XSS can steal the session   |
+| `Secure`         | Present in production        | Sniffable on HTTP           |
+| `SameSite`       | `Lax` or `Strict`            | Cross-site sends the cookie |
+| `Path`           | Set (usually `/`)            | Scope confusion             |
+
+Flag any cookie missing `HttpOnly`, missing `SameSite`, or with
+`SameSite=None` without an accompanying token check. A missing
+`Max-Age`/`Expires` is `info` only — session cookies are legitimate and
+strictly shorter-lived, not a failure.
+
+## Step 3: Origin-check middleware (only for opt-outs)
+
+A manual origin-check middleware is only needed when `requireSameOrigin` is
+disabled, or for mutation endpoints outside `/api` handled by custom code.
+If Step 0 found `requireSameOrigin: false`, look for middleware that:
+
+- Reads `request.headers.get('origin')`.
+- Compares against `url.origin` and an allowlist.
+- Rejects unsafe-method requests on mismatch.
+
+The canonical shape is in `recipes-auth.md` (the `origin-check.ts` example).
+
+Verify the wiring: the middleware name must appear in
+`defineApp({ api: { middleware: [...] } })` — that single global list applies
+to every API route. There is no per-group API middleware, and
+`pracht inspect api --json` output has no middleware field, so the manifest is
+the only place to check.
+
+## Step 4: Look for token-based CSRF
+
+Grep for: `csrf`, `csrfToken`, hidden form fields with token values, headers
+like `x-csrf-token`. Verify both sides of the protocol exist (issue + verify).
+A token issuer with no verifier (or vice versa) is a bug.
+
+## Step 5: Score each mutation surface
+
+For each `<Form>` and each mutation API, assign a severity (primary) and a
+posture verdict (secondary):
+
+- `info` / **Strong** — built-in same-origin enforcement intact (default) +
+  `SameSite=Lax`/`Strict` cookies.
+- `info` / **Adequate** — built-in enforcement intact; cookie posture unknown
+  or `SameSite` unset (the runtime check still blocks browser CSRF).
+- `warn` / **Compensated** — `requireSameOrigin: false` but a verified
+  origin-check middleware or token protocol covers the surface.
+- `warn` / **Token-only** — token verified, cookie has `SameSite=None`.
+- `error` / **Weak** — `requireSameOrigin: false` and no token / no
+  origin-check.
+- `warn` / **Unknown** — cookie source not located — investigate.
+
+Produce:
+
+| Surface | File:Line | Method | requireSameOrigin | Cookie posture | Middleware/Token? | Severity | Verdict |
+| ------- | --------- | ------ | ----------------- | -------------- | ----------------- | -------- | ------- |
+
+## Rules
+
+1. Point users at `examples/docs/src/routes/docs/recipes-auth.md` for cookie
+   and middleware patterns, and at `ApiConfig.requireSameOrigin` for the
+   built-in guard.
+2. Do not flag GET-only forms or read-only API methods.
+3. Remember: a hydrated `<Form>` intercepts unsafe-method submissions and
+   issues `fetch(actionUrl, { method, body: formData })` — not a document
+   POST. Fetch's default credentials mode is `same-origin`, so a cross-origin
+   `action` gets no cookies at all; same-origin submissions carry cookies and
+   the browser's `Sec-Fetch-Site`/`Origin` headers, which the built-in check
+   validates.
+4. If the project sets `SameSite=None`, require either a token check or an
+   origin-check in addition to the built-in guard — explain why in the report.
+5. Do not auto-fix. CSRF strategy is a policy decision; surface the gaps and
+   let the user choose layers.
+
+$ARGUMENTS

package/skills/audit-deps/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: audit-deps
+version: 1.1.0
+description: |
+  Run a dependency vulnerability audit and map each finding to the pracht
+  routes, loaders, middleware, or API handlers that import the affected
+  package — so users know which surface area they need to test after upgrading.
+  Use when asked to "audit deps", "scan for CVEs", "which routes use this
+  vulnerable package", "npm audit", or "dependency security review".
+allowed-tools:
+  - Bash
+  - Read
+  - Grep
+  - Glob
+---
+
+# Pracht Audit Deps
+
+`npm audit` (or `pnpm audit`) gives you a list of vulnerable packages. This
+skill goes one step further: for each advisory, it tells you **which routes
+and APIs touch the vulnerable code path** so you can prioritize and write
+targeted regression tests after upgrading.
+
+Prerequisites: `pracht inspect` requires a vite config that registers the
+pracht plugin.
+
+## Step 1: Run the audit
+
+Detect the package manager from the lockfile in repo root; for yarn,
+disambiguate Classic vs Berry via the `packageManager` field in
+`package.json` (fall back to `yarn --version`):
+
+| Lockfile             | Manager        | Command                          |
+| -------------------- | -------------- | -------------------------------- |
+| `pnpm-lock.yaml`     | pnpm           | `pnpm audit --json`              |
+| `package-lock.json`  | npm            | `npm audit --json`               |
+| `yarn.lock`          | yarn Classic (`yarn@1.x`) | `yarn audit --json`   |
+| `yarn.lock`          | yarn Berry (`yarn@2+`)    | `yarn npm audit --json --recursive` |
+| `bun.lockb` / `bun.lock` | bun        | `bun audit --json` (if available; otherwise note as gap) |
+
+Capture the JSON. Track each advisory: package, severity, range, fixed-in.
+
+## Step 2: Resolve "which package depends on the vulnerable one"
+
+For transitive vulns, the direct importer matters more than the leaf. Use the
+package manager:
+
+```bash
+pnpm why <package>
+# or
+npm ls <package>
+```
+
+Capture the dependency chain. The first non-pracht-internal direct dependency
+is the one the user owns.
+
+## Step 3: Map to routes/APIs
+
+If the pracht MCP server is registered (see `docs/MCP.md`), prefer its tools
+(`inspect_routes`, `inspect_api`, `inspect_build`, `doctor`, `verify`) over
+shelling out.
+
+For each direct dependency identified in step 2:
+
+1. Grep `src/` for `import .* from "<dep>"` and `require("<dep>")`.
+2. Classify each hit file against the resolved graph — do NOT classify by
+   directory convention (pages mode uses a configurable `pagesDir`, and app
+   layout is not fixed). From `pracht inspect routes --json`, match the hit
+   against each route's `file`, `loaderFile`, and `shellFile`; resolve
+   `middleware` names to files via the `defineApp({ middleware })` map in the
+   manifest. From `pracht inspect api --json`, match against each API route's
+   `file`.
+3. A hit that matches none of those is a shared module — trace its importers
+   upward until you reach a route, loader, shell, middleware, or API file
+   from the graph.
+
+This produces a "blast radius" per advisory.
+
+## Step 4: Categorize urgency
+
+For each advisory, score:
+
+| Factor                                  | Weight |
+| --------------------------------------- | ------ |
+| Advisory severity (`critical`/`high`/`moderate`/`low`) | base |
+| Reachable from a request handler        | +1 tier |
+| Reachable from an unauthenticated route | +1 tier |
+| Reachable only from build scripts / dev tools | -1 tier |
+
+Build scripts that never ship to runtime (e.g., a Vite plugin used only at
+build time) are lower priority than a package imported into a production
+loader.
+
+## Step 5: Report
+
+Report severity is the primary scale — `error` (critical/high reachable from
+runtime), `warn` (moderate, or high but build-time only), `info` (low, or
+unreachable) — with the advisory's own severity as a secondary column:
+
+```
+## error
+
+- <pkg> @ <version> — advisory: <severity> — <CVE>
+  Direct importer: <dep>
+  Reachable from:
+    - GET  /api/users          (src/api/users.ts)
+    - SSR  /dashboard          (src/routes/dashboard.tsx → src/server/db.ts)
+  Fix: upgrade to <range>
+  Test after upgrade: <list of routes/APIs above>
+```
+
+End with a one-line verdict: `N critical, N high, N moderate, N low — N
+reachable from runtime`.
+
+## Step 6: Recommend the upgrade
+
+This skill is report-only — do not run any install or upgrade command. For
+each fix:
+
+- If the direct dependency has a non-breaking range covering the fix:
+  recommend running `pnpm up <dep>` (or the equivalent for the detected
+  package manager).
+- If a major bump is required: link to the package's CHANGELOG and recommend
+  a deliberate migration.
+- Recommend running `pnpm test` and the route-targeted tests derived from
+  step 3 after any upgrade.
+
+## Rules
+
+1. Always determine the direct importer; transitive-only output is unhelpful.
+2. Distinguish runtime vs. build-time exposure — they have very different
+   urgency.
+3. Do not run any upgrade; propose commands only. The user applies them.
+4. If the audit tool reports zero advisories, still note the package counts
+   and lockfile age — staleness is a precursor to advisories.
+5. Cross-reference with `pre-deploy` before shipping any post-upgrade build.
+
+$ARGUMENTS

package/skills/audit-headers/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: audit-headers
+version: 1.2.0
+description: |
+  Audit security header coverage in a pracht app. The framework applies four
+  default security headers on every response path; this skill audits the
+  exceptions — static output served outside first-party adapters, `headers()`
+  exports that weaken the defaults, and the headers only the user can decide
+  (HSTS, CSP).
+  Use when asked to "audit security headers", "check CSP", "harden headers",
+  "set up HSTS", or "review header policy".
+allowed-tools:
+  - Bash
+  - Read
+  - Grep
+  - Glob
+---
+
+# Pracht Audit Headers
+
+What the framework guarantees: four default security headers are applied
+automatically on EVERY framework response path — SSR pages, API responses,
+404s, and static/ISG output on the first-party adapters (`adapter-node`,
+`adapter-cloudflare`) as well as the Vercel headers config generated at build
+time:
+
+- `permissions-policy` (disables device sensors)
+- `referrer-policy: strict-origin-when-cross-origin`
+- `x-content-type-options: nosniff`
+- `x-frame-options: SAMEORIGIN`
+
+The helper behind this (`applyDefaultSecurityHeaders`) only sets a header
+**when missing** — so a route or shell `headers()` export always wins,
+including when it weakens a default. The framework does NOT set
+`strict-transport-security`, `content-security-policy`, or `cross-origin-*`
+headers — those need a project decision.
+
+One deliberate exception: **protocol-switch responses** (a `101` WebSocket
+handshake, or any response carrying a `webSocket` handle) are returned exactly
+as the handler produced them, with no headers applied. This is not a gap —
+copying the response would destroy the socket, and a handshake has no body for
+a sniffing or framing policy to protect. Do not report it as a finding.
+
+The audit surface is therefore:
+
+- **(a)** `dist/client` served by a custom CDN/host outside the first-party
+  adapters — nothing applies the defaults there.
+- **(b)** `headers()` exports that override a default with a weaker value.
+- **(c)** HSTS and CSP, which genuinely need user action.
+
+Prerequisites: `pracht inspect` requires a vite config that registers the
+pracht plugin; `pracht inspect build` and `dist/client/_pracht/headers.json`
+require a prior `pracht build`.
+
+## Step 1: Inventory header sources
+
+```bash
+pracht inspect routes --json
+pracht inspect api --json
+```
+
+If the pracht MCP server is registered (see `docs/MCP.md`), prefer its tools
+(`inspect_routes`, `inspect_api`, `inspect_build`, `doctor`, `verify`) over
+shelling out.
+
+Only route modules and shells have a `headers()` export — API handlers do not
+(there is no `headers` in the API module shape; API handlers set headers
+inline on the `Response` they build, and the runtime applies the defaults on
+top). Inventory:
+
+- `headers()` exports in route files, loader files (`loaderFile`), and shells
+  (`shellFile`).
+- Hand-rolled `Response` constructions in API handlers and middleware where
+  security-relevant headers are set inline.
+
+## Step 2: Find weakened defaults and uncovered static hosting
+
+Defaults are framework-applied, so do not build a "which route is covered"
+matrix — instead:
+
+1. For each `headers()` source from Step 1, flag any of the four default
+   header names set to a weaker value (e.g. `x-frame-options: ALLOWALL`,
+   an over-permissive `permissions-policy`, `referrer-policy: unsafe-url`).
+   Because the defaults are set-when-missing, the route value wins.
+2. Ask how `dist/client` is deployed. On `adapter-node`, `adapter-cloudflare`,
+   or the generated Vercel config, static/ISG responses get the defaults. If
+   a custom CDN or host serves `dist/client` directly, flag it (`warn`) and
+   recommend replicating the four defaults in that host's header config.
+
+## Step 3: HSTS
+
+Grep for `strict-transport-security`. If absent everywhere, recommend adding
+it (e.g. via a shell `headers()` export or the host's config):
+
+```ts
+"strict-transport-security": "max-age=63072000; includeSubDomains; preload"
+```
+
+Only recommend `preload` if the user confirms they want to commit to HTTPS
+permanently and submit to the preload list.
+
+## Step 4: Content-Security-Policy
+
+Start from the canonical starter policy in `docs/CSP.md` — it includes
+`'inline-speculation-rules'` in `script-src`, required for routes that opt
+into `speculation` (they emit an inline
+`<script type="speculationrules">`). Then add observed origins:
+
+1. Check which routes use `speculation`: read the `speculation` field from
+   `pracht inspect routes --json` (requires a current `@pracht/cli`; on older
+   CLIs, grep the manifest for `speculation:` instead). If none do,
+   `'inline-speculation-rules'` can be dropped.
+2. Grep the app for fetch URLs, image URLs, CSS `@import`, `<script src>`,
+   `<link href>`, font URLs, iframe sources.
+3. Group by directive: `default-src`, `script-src`, `style-src`, `img-src`,
+   `font-src`, `connect-src`, `frame-src`; always include `'self'` per
+   directive, per the starter policy.
+4. Pracht injects hydration state in a non-executable
+   `<script id="pracht-state" type="application/json">` — it does not need
+   `'unsafe-inline'`. Do not add `'unsafe-inline'` unless the app truly emits
+   executable inline scripts and the tradeoff is documented.
+
+Output a draft CSP referencing `docs/CSP.md` and explain what each origin is
+for. Do not hand the user a CSP that breaks their site — present as draft.
+
+## Step 5: Prerendered header manifest safety
+
+For SSG/ISG output, the framework refuses to prerender any route whose
+document headers include dangerous names (`set-cookie`, `authorization`,
+`proxy-authorization`, `www-authenticate`, `proxy-authenticate`) or
+secret-shaped custom `x-*` names (token/secret/key/credential patterns) — a
+build containing them hard-fails. So do not hunt for those at runtime; audit
+the `headers()` sources statically to catch them **before** a build failure,
+and report each as `error` with the prerender failure it would cause.
+
+The real target is the `warn` class the framework cannot catch: innocuously
+named headers carrying user-specific values, which get copied into
+`dist/client/_pracht/headers.json` (public client output) and replayed across
+users on static responses.
+
+Secret VALUES in headers are owned by `audit-secrets`; this skill owns policy
+headers. Cross-reference `audit-secrets` for value-level findings.
+
+## Step 6: Cross-origin isolation (optional)
+
+If the user mentions `SharedArrayBuffer`, WASM threading, or high-precision
+timers, recommend:
+
+- `cross-origin-opener-policy: same-origin`
+- `cross-origin-embedder-policy: require-corp`
+- `cross-origin-resource-policy: same-origin` on assets
+
+Otherwise leave these unset — they break embedded third-party content.
+
+## Step 7: Report
+
+Two outputs:
+
+1. **Findings table** (source × header × severity).
+2. **Recommendations**, in priority order:
+   - `error`: `headers()` values that would fail prerender (Step 5).
+   - `error`: `headers()` exports that weaken a default.
+   - `warn`: `dist/client` served by a host that does not apply the defaults.
+   - `warn`: Missing HSTS in production-grade apps.
+   - `warn`: User-specific headers in prerendered static output.
+   - `info`: CSP draft, COOP/COEP suggestions.
+
+Show the exact code change required (e.g. the `headers()` export to fix, or
+the CDN header config to add).
+
+## Rules
+
+1. The four defaults are framework-applied — do not recommend re-adding them
+   in app code; audit for weakening and for hosting paths outside the
+   first-party adapters.
+2. Never recommend a CSP with `'unsafe-eval'` unless the user has documented
+   why they need it.
+3. `applyDefaultSecurityHeaders` is set-when-missing, so per-route `headers()`
+   wins over the defaults — weakened values are the primary finding, not
+   missing ones.
+4. Static/ISG responses already get the defaults on first-party adapters and
+   the generated Vercel config; only flag static hosting that bypasses those.
+5. Treat prerender header manifests as public artifacts.
+6. Do not auto-edit. Headers are policy; surface gaps, propose patches.
+
+$ARGUMENTS