skilldrop-cli 0.16.35 → 0.16.36

package/packs/frontend/skills/rendering-strategy/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: rendering-strategy
+description: Decide route by route how each page of a web app is rendered — static at build (SSG), static with revalidation (ISR, stale-while-revalidate), server-rendered per request (SSR, streaming), client-rendered (CSR, SPA), at the edge, or a mix with islands and server components — from how fresh each route's data must be, whether it is personalised, whether it must be indexed or shared, what it costs per request at the stated traffic and how much JavaScript it needs, with the cache keys, invalidation events and failure modes of each choice. Use when the user asks "should this be SSR or static", "SSR vs SSG vs ISR", "how should each page be rendered", "do we need SSR for SEO", "which pages can we cache", or is choosing rendering modes in Next.js, Nuxt, Remix, React Router, SvelteKit or Astro.
+---
+
+# rendering-strategy
+
+Picks a rendering mode for every route of a web app and records why: what the route needs, the
+mode that meets it at the lowest cost, what invalidates it, and what the user sees when its data
+source fails. It decides rendering, not the whole system: the system design is `design-doc`,
+latency and availability targets are `nfr-spec`, and recording the chosen strategy as a
+decision record is `adr-generator`.
+
+## How to respond
+
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** Decide per route, never per app. A page that is the same for everyone and can be minutes stale is cached, and the personalised or seconds-fresh part of a page is rendered on its own, never used as the reason to render the whole page per request.
+
+1. **List the routes and what is known about each.** One row per route or route group: how
+   fresh its data must be, whether it differs per user, whether it must be indexed or shared,
+   its traffic, and what on it is interactive. Take these from the input only. Traffic,
+   freshness and framework version are never invented: ask at most two questions (the
+   freshness of the most volatile data, then traffic), or tag the gap `[assumption]`.
+
+2. **Ask the five questions for each route, in this order.** The first answer that settles the
+   mode wins; later questions refine it.
+   1. **How fresh must the data be?** "Minutes stale is fine" → cacheable. "Within seconds" →
+      only that field is fresh, the page still caches (step 3).
+   2. **Is it the same for everyone?** Same → static or revalidated. Personalised in one corner →
+      cached page plus a personal fragment. Personalised throughout → per request, never cached.
+   3. **Must it be indexed or shared with a preview?** Then the content and the preview meta
+      tags are in the HTML at first byte: static, revalidated or server-rendered, never
+      client-only.
+   4. **What does it cost per request at the stated traffic?** Count renders (step 5).
+   5. **How much JavaScript does it need?** Read-only content ships none or islands; a dense
+      app screen can be client-rendered.
+
+   ✅ *"Blog post: changes on publish, same for everyone, must be indexed → static, rebuilt on
+   the CMS publish event."* — ❌ *"Blog post: SSR, for SEO."*
+
+3. **Split the page, not the mode.** A personalised header, a cart count or a stock figure is a
+   fragment: fetched on the client after a cached page loads, rendered at the edge, or streamed
+   into a static shell (islands, server islands, partial prerendering).
+   ✅ *"Home: revalidated every 10 min; the 'Hi, Sam' greeting and cart badge load client-side
+   from `/api/me`."* — ❌ *"Home must be SSR because the header shows the user's name."*
+   A value that must be fresh within seconds is never left to time-based revalidation: a
+   stale-while-revalidate cache serves the old page to the first visitor after the window
+   ends. ✅ *"Product page cached; stock fetched from a 5-second-TTL endpoint; checkout
+   re-checks stock."* — ❌ *"Product page ISR with revalidate: 5 so stock is fresh."* A
+   CDN TTL on that endpoint also turns a traffic spike into one origin call per TTL per item.
+
+4. **Treat SEO as an HTML question, not an SSR question.** Crawlers and link-preview bots need
+   the content and `og:` tags in the first response. A static page has them; so does a
+   revalidated one. CSR is wrong for any page that must be indexed or shared, and right for
+   logged-in screens nobody searches for.
+   ✅ *"Marketing pages prerendered; the logged-in app stays a client-rendered SPA."* —
+   ❌ *"Move the whole app to SSR so Google can see it."*
+
+5. **Put a number on cost.** When the input gives traffic, write the routes as a CSV (columns
+   in the script header: `route, mode, views_month, pages, revalidate_s, changes_month,
+   builds_month`) and count origin renders under the proposed mode against per-request SSR:
+
+   ```bash
+   # Claude Code
+   python3 "${CLAUDE_SKILL_DIR}/scripts/render_load.py" routes.csv
+   # Other IDEs (from the skill folder)
+   python3 scripts/render_load.py routes.csv
+   ```
+
+   The count also shows when time-based revalidation saves nothing: a long-tail route whose
+   pages each get fewer views than revalidation windows renders nearly once per view, so
+   on-demand revalidation on the change event is the saving. If no script can run, do the
+   same arithmetic by hand and show it. Without traffic, state the comparison as "one render
+   per view vs one per change" and list traffic under To confirm.
+
+6. **Name the cache key and the invalidation event for every cached route.** What event
+   invalidates which pages, and what must never reach a shared cache.
+   ✅ *"Product updated in the PIM → webhook revalidates `/p/[slug]` and its category pages.
+   Cart and account: `Cache-Control: private, no-store`."* — ❌ *"Cache with a 60-second
+   TTL."* Filter and sort query strings multiply cache entries: name the parameters that are
+   part of the key and drop the rest.
+
+7. **Name the failure mode of each row.** What the user sees when the data source is slow or
+   down. SSR ties time to first byte to the slowest call: say the timeout and the fallback, or
+   stream the slow part behind a placeholder. Revalidated pages serve the last good copy on
+   failure. CSR shows a spinner, and nothing without JavaScript. ✅ *"Stock call times out at
+   800 ms → page shows 'Check availability' and the add-to-cart button still works."*
+
+8. **Use framework terms only for the framework the user named.** Then give the exact setting
+   per route from [`reference.md`](reference.md), flag anything that depends on the version in
+   `package.json`, and catch the framework trap (a cookie read in a shared layout that makes
+   every route dynamic; a server cache rule on a personalised path). No framework named →
+   neutral terms only.
+
+9. **Write it up, lean.** First line: the answer, including whether the team's proposal
+   stands. Then the route table: route, mode, why (freshness / personalised / indexed),
+   invalidation, failure mode. Then the traps found, each in one or two lines, the cost
+   numbers if traffic was given, and To confirm. No section for a question nobody asked.
+
+**Non-interactive runs** (subagent, CI, headless): missing traffic, freshness tolerances or
+framework version become `[assumption]` rows listed at the top under To confirm. A request
+that names no routes, pages or app at all emits `BLOCKED: need the app's routes and what each
+page shows`, because a route table of invented pages decides nothing.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — the mode-by-mode cost and failure table, cache headers that are safe for personalised pages, and per-framework settings for Next.js, Nuxt, Remix / React Router, SvelteKit and Astro
+- [`scripts/render_load.py`](scripts/render_load.py) — counts origin renders per month per route against per-request SSR (stdlib only)
+- [`examples/saas-site.md`](examples/saas-site.md) — worked example: marketing site, docs, status page and app in SvelteKit
+
+## Quality bar
+
+- **One row per route or route group,** each with a mode and the deciding reason. One mode for the whole app fails.
+- **Every cached route names its invalidation event** and the pages it touches; time alone is not an invalidation plan for data that changes on an event.
+- **Every personalised response is named as never shared-cached** (`private, no-store`, or kept off the cached page as a fragment).
+- **Seconds-fresh data is a fragment with its own short-lived source,** not the page's revalidation window.
+- **Every row has a failure mode:** what the user sees when its data source is slow or down.
+- **Cost is a computed number when traffic is given,** from the input's figures only.
+- **Framework settings appear only for the named framework,** and version-dependent behaviour is flagged.
+- **Nothing invented:** traffic, freshness and versions come from the input or carry `[assumption]`.
+
+## When to use this skill
+
+- ✅ "Should these pages be SSR, static or ISR?" for an app with several kinds of page
+- ✅ A team proposing SSR (or an SPA) everywhere and wanting it checked
+- ✅ "Our pages don't show up in Google / link previews are blank" on a client-rendered site
+- ✅ Setting route rules, revalidation and cache headers in a named framework
+
+## When NOT to use this skill
+
+- ❌ Designing the whole system (services, data stores, rollout) — `design-doc`
+- ❌ Writing the chosen strategy up as a numbered decision record — `adr-generator`
+- ❌ Setting latency or availability targets for the app — `nfr-spec`
+- ❌ Diagnosing why a page is slow from a Lighthouse report — that is a page-speed review, not a rendering decision
+
+## Anti-patterns to avoid
+
+- ❌ **SSR everywhere "for SEO."** It pays a render per view for pages that are the same for everyone and could be served from a CDN.
+- ❌ **A personalised header forcing the site dynamic.** A name and a cart count are a fragment, not a rendering mode.
+- ❌ **Short revalidation as a freshness guarantee.** Stale-while-revalidate serves the stale copy first; a 5-second window across thousands of pages is also thousands of regenerations nobody needed.
+- ❌ **CSR for a page that must be indexed or shared.** Preview bots don't run JavaScript; the card is blank.
+- ❌ **Caching a logged-in page at the CDN.** One user's account page served to the next visitor is a data leak, not a performance win.
+- ❌ **SSR with no timeout.** The page is as slow as the slowest API it calls, and fails with it.
+- ❌ **Framework advice for a framework nobody named,** or version-specific settings stated without the version.

package/packs/frontend/skills/rendering-strategy/evals/eval_queries.json

@@ -0,0 +1,38 @@
+[
+  {
+    "query": "Should our product pages be SSR or static with ISR? Stock changes a lot.",
+    "should_trigger": true
+  },
+  {
+    "query": "The team wants to server-render the whole site for SEO. Is that actually needed?",
+    "should_trigger": true
+  },
+  {
+    "query": "Help me pick SSG, ISR, SSR or CSR for each route of our Nuxt app",
+    "should_trigger": true
+  },
+  {
+    "query": "Our SPA's pages don't show up in Google and link previews are blank. What should we render on the server?",
+    "should_trigger": true
+  },
+  {
+    "query": "Which of our SvelteKit pages can we prerender and cache at the CDN, and which have to be dynamic because they're logged in?",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the design doc for the new storefront: services, data stores and rollout plan",
+    "should_trigger": false
+  },
+  {
+    "query": "Write an ADR for our decision to move from Create React App to Next.js",
+    "should_trigger": false
+  },
+  {
+    "query": "Set p95 latency and availability targets for the checkout API",
+    "should_trigger": false
+  },
+  {
+    "query": "Here's our Lighthouse report: LCP is 4.1s on mobile. What's slowing the page down?",
+    "should_trigger": false
+  }
+]

package/packs/frontend/skills/rendering-strategy/evals/evals.json

@@ -0,0 +1,77 @@
+{
+  "skill_name": "rendering-strategy",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're rebuilding our outdoor gear shop in Next.js and the team wants SSR on every page. Everything we know is in fernhill-app.md. How should each route be rendered? Keep it to what we need to decide.",
+      "assertions": [
+        "Opens with the answer, including that SSR on every page is not needed, and gives a decision for each route (home, listing, product detail, cart, account, blog) rather than one mode for the app",
+        "Says SEO needs the content in the HTML of the first response, which static or revalidated pages provide, so the home, listing, blog and product content do not need per-request SSR",
+        "Keeps the personalised header off the rendering decision: the greeting and cart count load as a client or edge fragment on cached pages, and it flags that reading the session cookie in the root layout (or force-dynamic there) makes every route dynamic",
+        "Does not rely on time-based revalidation for the 10-second stock requirement: keeps the product page cached, fetches stock separately from a short-lived source, and says checkout or add-to-cart must re-check stock",
+        "Names what the product page shows when the inventory API is slow or times out during a drop (a timeout and a fallback), rather than letting the whole page wait",
+        "Names invalidation events and the pages they touch: the PIM webhook revalidates the product page and its category pages, the CMS publish webhook revalidates the post and the blog index; and states that cart and account are never stored in a shared cache",
+        "Compares renders or server load under SSR everywhere with the proposed mix using the file's traffic figures, with arithmetic that matches them",
+        "Does not invent traffic, freshness requirements, versions or services not in the file; anything else is tagged [assumption] or listed under To confirm"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Our product is one React SPA built with Vite: marketing pages, pricing, docs and the logged-in app all in the same bundle. Marketing says our pages barely show up in Google and when people share our pricing page on LinkedIn the preview is blank. Someone wants to move the whole thing to server-side rendering. Is that the right call?",
+      "assertions": [
+        "Answers in the first lines that the whole app does not need server rendering: the public pages need HTML at first byte and the logged-in app can stay client-rendered",
+        "Splits the decision by route group (marketing, pricing, docs, logged-in app) rather than one mode for everything",
+        "Explains the blank link preview as the Open Graph tags not being in the initial HTML, because preview bots do not run JavaScript, and that prerendering the public pages fixes it",
+        "Recommends prerendering (static at build) or revalidation for marketing, pricing and docs rather than per-request SSR, since they are the same for every visitor",
+        "Says how the prerendered pages get updated (rebuild on deploy or on a content-change event)",
+        "Stays framework-neutral or offers options, and does not present one specific meta-framework's API as required",
+        "Does not invent traffic, page counts or update frequencies; anything it needs is asked for or tagged [assumption]",
+        "Is a chat-length answer, not a long design document"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Election night is in two weeks and I'm worried our Nuxt config won't hold. routes.md has our routes, traffic and the draft routeRules. What would you change, route by route?",
+      "assertions": [
+        "Flags the swr rule on /account/** as caching personalised pages in a shared server cache, so one reader's account page can be served to another, and replaces it with no shared caching (ssr: false or private, no-store)",
+        "Does not keep per-request SSR for the results pages: they are the same for everyone and a minute of staleness is acceptable, so they get a short swr or isr window (or a cached shell with a short-TTL results endpoint)",
+        "Uses the election-night traffic to show what per-request SSR on results would cost against a cached window, with arithmetic that matches the file",
+        "Keeps article pages cached and moves the paywall meter to a client-side (or edge) fragment read from the cookie, instead of rendering every article per request",
+        "Flags that prerender: true on topic pages freezes them until the next deploy while 150 articles a day are published, and replaces it with revalidation or on-demand invalidation on the CMS webhook",
+        "Names invalidation events: article publish or correction purges that article plus its topic pages and the home page",
+        "Names what results pages show if the results feed stalls (the last good copy, with an updated-at time)",
+        "Gives settings in Nuxt routeRules terms only, and does not invent traffic, versions or hosting details beyond the file"
+      ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-20",
+      "prompt": "our recipe site (nuxt) is a spa and google barely indexes it, also when people share a recipe on whatsapp the preview is just blank. routes.md has the page list, nuxt.config.ts and pages/recipes/[slug].vue are in here too, and build-notes.txt has what we tried. what should each page actually be - ssr, static, something else? we're on a static bucket + cdn right now if that matters",
+      "assertions": [
+        "Answers the question directly with a rendering mode for each of the seven routes in routes.md (/, /recipes/[slug], /category/[name], /search?q=, /account/saved, /account/settings, /print/[slug]), e.g. as a table, before or alongside the explanation.",
+        "Flags that the current setup (nitro preset 'static', files in a bucket behind a CDN, no servers) cannot run SSR or ISR, so any per-request or revalidating route needs a server/edge runtime; either recommends that hosting change explicitly or gives a static-only path (prerender plus rebuild on the Larder webhook) and states the trade-off.",
+        "Uses build-notes.txt to estimate that prerendering all ~42,000 recipes at the observed rate (1,200 in 6 min) takes about 3.5 hours (~210 min), and therefore recommends prerendering a subset and generating the rest on demand/incrementally rather than a full rebuild per CMS edit.",
+        "Keeps /recipes/[slug] shared-cacheable (static or revalidated) and moves the per-user Save heart to a client-side island/fetch; does not make the whole recipe page per-request SSR or vary its cache on the user's login just for the heart.",
+        "Explains that WhatsApp and similar link-preview crawlers do not run JavaScript, so title, description and og:image must be in the initial HTML, and points out that [slug].vue fetches the recipe and calls useHead inside onMounted, so that fetch must move to server-side data loading (useAsyncData/useFetch) - turning ssr on alone will not fix previews.",
+        "Ties invalidation to real events from the input: the Larder publish/edit/unpublish webhook for recipe (and affected category) pages and the daily 06:00 editor swap for the home page, and treats the ~3,000 reviews/day rating as tolerating a short revalidation window or a client fetch rather than requiring SSR.",
+        "Marks /search and /account/* as not for indexing or shared caching (client-rendered or private per-request), and gives /print/[slug] a canonical to /recipes/[slug] or noindex as duplicate content.",
+        "Invents nothing not in the input: no traffic figures, costs, recipe counts, build times, hosting providers, or Larder/FindIt API features beyond what the files state; anything needing the network (e.g. testing a URL with a preview debugger) is given as a command or step for the user to run."
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-20",
+      "prompt": "Our tech lead wants to ship the whole SvelteKit app (Tallyhub) as SSR on Stratus Functions next sprint - 'one mode, less to think about.' Marketing wants pricing and docs to be fast, and finance is asking what SSR-everything will cost us. The relevant bits are in the repo: traffic.md, routes.txt, svelte.config.js, src/hooks.server.ts, src/routes/+layout.server.ts and src/routes/(marketing)/pricing/+page.server.ts. Can you give me a rendering plan per route and tell me straight whether SSR-everything is actually a cost problem? I'm bringing this to Thursday's architecture review, so keep it to something I can put on a slide or two plus notes.",
+      "assertions": [
+        "Answers both questions directly: gives a rendering mode for each route or route group in routes.txt (/, /pricing, /customers/:slug, /docs/*, /blog/:slug, /app/* pages, api/*) and gives a clear yes/no on whether SSR-everything is a cost problem.",
+        "Computes cost from traffic.md: public pages 2.4M x 0.22 s x 1 GB = ~528,000 GB-s = ~$9.50 plus ~$0.96 invocations, about $10-11/month (and/or the app's ~2.52M navigations adding roughly another $11), and concludes compute cost is not a strong argument against SSR - the stronger reasons are cold-start latency (p95 900 ms) and cacheability.",
+        "Flags as the top-priority issue that src/hooks.server.ts sets 'cache-control: public, max-age=300' on every response, which would let the CDN serve one customer's authenticated /app pages (dashboard, billing) to another; says app and API responses must be private/no-store and the header must be set per route, not globally.",
+        "Notices that the root src/routes/+layout.server.ts returns locals.user for every page, so public pages depend on the session cookie and cannot be prerendered or shared-cached; recommends moving the user load into the app layout and rendering the nav's Log in/Open dashboard state on the client (or from a cheap check) for public pages.",
+        "Handles /pricing's per-country currency (x-country header -> USD/EUR/GBP): prerender or cache one variant per currency with country/currency in the cache key, resolve at the edge, or pick currency on the client - and warns that a single prerendered or shared-cached pricing page would show one currency to everyone.",
+        "Recommends prerendering docs (~900 repo markdown pages), blog (~250) and customers (40) at build, e.g. with SvelteKit's per-route `export const prerender = true`, with deploy as the invalidation event since the content lives in the repo.",
+        "Keeps /app/dashboard (live usage metrics) and other /app pages per-request or client-fetched behind login, never shared-cached, and notes that SvelteKit client navigations still hit functions for load data.",
+        "Invents nothing not in the input: no Stratus features, prices, traffic numbers, adapters or routes beyond the files (adapter-auto is noted as-is; any platform capability it can't verify offline is stated as something to check), and the answer is sized for a slide or two plus notes rather than a long essay."
+      ]
+    }
+  ]
+}

package/packs/frontend/skills/rendering-strategy/evals/files/1/fernhill-app.md

@@ -0,0 +1,40 @@
+# Fernhill Outdoor — web shop rebuild
+
+We sell hiking and climbing gear online. The current site is a client-rendered single-page app
+and we lost a lot of Google traffic after launching it. We are rebuilding on **Next.js 15
+(App Router)**, self-hosted on two Node containers behind a CDN that honours `Cache-Control`.
+
+## The team's proposal
+
+> Render every page with SSR (`export const dynamic = 'force-dynamic'` in the root layout).
+> SSR is what fixes SEO, and it means every page always shows the right header and stock.
+
+## Routes
+
+| Route | What it shows | Pages | Page views / month |
+|---|---|---:|---:|
+| `/` home | hero, featured products, seasonal banners | 1 | 900,000 |
+| `/c/[category]` product listing | product grid, filters as query params (`?size=`, `?colour=`, `?brand=`, `?sort=`) | 60 | 1,400,000 |
+| `/p/[slug]` product detail | photos, description, price, reviews, **stock level** ("Only 3 left") | 4,000 | 2,600,000 |
+| `/cart` | the user's basket | 1 | 380,000 |
+| `/account` | orders, addresses, saved items | 1 | 150,000 |
+| `/blog/[slug]` and `/blog` | trip reports and gear guides | 300 | 220,000 |
+
+## What changes, and how fast
+
+- **Product content and prices** live in our PIM. It sends a webhook on every product update.
+  Prices change in a nightly batch plus a few flash sales a month. About 2,000 product updates
+  a month in total.
+- **Stock** comes from the inventory API. Twice a month we run a limited "drop": one product,
+  a few hundred units, sold out in minutes. During a drop, the stock shown on the product page
+  must be right to within 10 seconds or we get angry customers who saw "in stock" and then
+  couldn't buy.
+- The inventory API answers in about 180 ms normally; during drops it slows to 2–3 seconds and
+  sometimes times out.
+- **Blog** posts come from a headless CMS that sends a webhook on publish. About 12 posts a month.
+- **Header:** every page shows "Hi, {first name}" and the cart count when the visitor is
+  logged in. The design has it in the root layout, reading the session cookie.
+
+## Ask
+
+How should each route be rendered? We need to decide before the sprint starts.

package/packs/frontend/skills/rendering-strategy/evals/files/3/routes.md

@@ -0,0 +1,33 @@
+# Valley Courier — election night
+
+Local news site on **Nuxt 3**, deployed on our own Node servers (Nitro) behind a CDN.
+
+## Routes
+
+| Route | What it shows | Pages | Traffic |
+|---|---|---:|---|
+| `/` | top stories, results ticker | 1 | 600,000 views / month |
+| `/news/[slug]` | articles; metered paywall: anonymous readers get 5 free articles a month, with a "3 free articles left" bar | 12,000 | 4,000,000 views / month |
+| `/topics/[topic]` | latest articles on one topic | 200 | 300,000 views / month |
+| `/results/[race]` | live election results by race | 40 | expected 1,800,000 views between 21:00 and 03:00 on election night |
+| `/account/**` | subscription, saved articles, newsletter settings | 3 | 40,000 views / month |
+
+- The results feed updates about every 30 seconds on the night. Readers expect results no more
+  than a minute old.
+- The newsroom publishes about 150 articles a day and corrects some after publishing. The CMS
+  sends a webhook on publish and on edit.
+- The paywall meter is counted from a cookie.
+
+## Draft config
+
+```ts
+export default defineNuxtConfig({
+  routeRules: {
+    '/': { swr: 300 },
+    '/news/**': { ssr: true },     // per request, so the meter is right
+    '/topics/**': { prerender: true },
+    '/results/**': { ssr: true },  // must be live
+    '/account/**': { swr: 60 },    // takes load off the servers
+  },
+})
+```

package/packs/frontend/skills/rendering-strategy/evals/files/4/build-notes.txt

@@ -0,0 +1,5 @@
+2026-10-02  tried `nuxi generate` with ssr on as a test, prerendering 1,200 recipes only
+            -> took 6 min on CI
+            didn't try the full set
+2026-10-05  Search Console: 42k recipe URLs discovered, ~3.1k indexed
+            most crawled pages show just the spinner in the screenshot

package/packs/frontend/skills/rendering-strategy/evals/files/4/nuxt.config.ts

@@ -0,0 +1,19 @@
+// Crumbly Kitchen - Nuxt 3
+export default defineNuxtConfig({
+  ssr: false,
+  nitro: {
+    preset: 'static',
+  },
+  app: {
+    head: {
+      title: 'Crumbly Kitchen',
+      meta: [{ name: 'description', content: 'Recipes for every day' }],
+    },
+  },
+  runtimeConfig: {
+    public: {
+      larderApiBase: 'https://cms.example.invalid/api',
+      findItKey: 'PLACEHOLDER_SEARCH_KEY',
+    },
+  },
+})

package/packs/frontend/skills/rendering-strategy/evals/files/4/pages/recipes/[slug].vue

@@ -0,0 +1,37 @@
+<script setup lang="ts">
+const route = useRoute()
+const recipe = ref<any>(null)
+const saved = ref(false)
+
+onMounted(async () => {
+  recipe.value = await $fetch(`/recipes/${route.params.slug}`, {
+    baseURL: useRuntimeConfig().public.larderApiBase,
+  })
+  useHead({
+    title: recipe.value.title,
+    meta: [
+      { property: 'og:title', content: recipe.value.title },
+      { property: 'og:image', content: recipe.value.heroImage },
+      { name: 'description', content: recipe.value.summary },
+    ],
+  })
+  const token = localStorage.getItem('ck_token')
+  if (token) {
+    const res: any = await $fetch(`/api/saved/${route.params.slug}`, {
+      headers: { Authorization: `Bearer ${token}` },
+    })
+    saved.value = res.saved
+  }
+})
+</script>
+
+<template>
+  <div v-if="recipe">
+    <h1>{{ recipe.title }}</h1>
+    <SaveHeart :saved="saved" />
+    <RatingStars :avg="recipe.ratingAvg" :count="recipe.reviewCount" />
+    <IngredientList :items="recipe.ingredients" />
+    <MethodSteps :steps="recipe.steps" />
+  </div>
+  <Spinner v-else />
+</template>

package/packs/frontend/skills/rendering-strategy/evals/files/4/routes.md

@@ -0,0 +1,15 @@
+# Crumbly Kitchen routes
+
+| Route | What's on it | Notes |
+|---|---|---|
+| `/` | featured recipes, seasonal picks | editors swap the featured set every day at 06:00 |
+| `/recipes/[slug]` | the recipe: title, hero image, ingredients, steps, avg rating + review count, "Save" heart | ~42,000 recipes. Recipe text rarely changes after publish. ~3,000 reviews posted per day across the site. Heart is filled if the logged-in user saved it |
+| `/category/[name]` | paginated list of recipes in a category, 24 per page | 180 categories |
+| `/search?q=` | search results from FindIt | |
+| `/account/saved` | the logged-in user's saved recipes | login required |
+| `/account/settings` | email, password, newsletter prefs | login required |
+| `/print/[slug]` | printer-friendly version of a recipe | same content as /recipes/[slug] |
+
+Content comes from Larder CMS. Larder can send a webhook on publish, edit and unpublish.
+
+Hosting: static files in a storage bucket behind a CDN. No servers.

package/packs/frontend/skills/rendering-strategy/evals/files/5/routes.txt

@@ -0,0 +1,18 @@
+Tallyhub - SvelteKit route map (src/routes)
+
+PUBLIC
+  (marketing)/+page.svelte              /                  landing page, edited by marketing ~2x/month
+  (marketing)/pricing/                  /pricing           3 plans, price shown in USD/EUR/GBP by visitor country (x-country header)
+  (marketing)/customers/[slug]/         /customers/:slug   40 case studies
+  docs/[...path]/                       /docs/*            ~900 pages, markdown files in the repo (docs/content/)
+  blog/[slug]/                          /blog/:slug        ~250 posts, markdown in the repo
+
+BEHIND LOGIN
+  app/+layout.server.ts                 redirects to /login if no user
+  app/dashboard/                        /app/dashboard     live usage metrics for the customer's org
+  app/projects/[id]/                    /app/projects/:id
+  app/settings/                         /app/settings
+  app/billing/                          /app/billing       invoices, card on file (last 4)
+
+API
+  api/*                                 JSON endpoints used by the app

package/packs/frontend/skills/rendering-strategy/evals/files/5/src/hooks.server.ts

@@ -0,0 +1,14 @@
+import type { Handle } from '@sveltejs/kit';
+import { getUserBySession } from '$lib/server/auth';
+
+export const handle: Handle = async ({ event, resolve }) => {
+  const sid = event.cookies.get('sid');
+  event.locals.user = sid ? await getUserBySession(sid) : null;
+
+  const response = await resolve(event);
+
+  // let the CDN take some load off the functions (added by Priya, sprint 41)
+  response.headers.set('cache-control', 'public, max-age=300');
+
+  return response;
+};

package/packs/frontend/skills/rendering-strategy/evals/files/5/src/routes/(marketing)/pricing/+page.server.ts

@@ -0,0 +1,10 @@
+import type { PageServerLoad } from './$types';
+import { priceTable } from '$lib/pricing';
+
+const CURRENCY: Record<string, 'USD' | 'EUR' | 'GBP'> = { GB: 'GBP', DE: 'EUR', FR: 'EUR', NL: 'EUR' };
+
+export const load: PageServerLoad = async ({ request }) => {
+  const country = request.headers.get('x-country') ?? 'US';
+  const currency = CURRENCY[country] ?? 'USD';
+  return { currency, plans: priceTable(currency) };
+};

package/packs/frontend/skills/rendering-strategy/evals/files/5/src/routes/+layout.server.ts

@@ -0,0 +1,10 @@
+import type { LayoutServerLoad } from './$types';
+
+// root layout: every page gets the user so the nav can show "Log in" or "Open dashboard"
+export const load: LayoutServerLoad = async ({ locals }) => {
+  return {
+    user: locals.user
+      ? { name: locals.user.name, org: locals.user.orgName, plan: locals.user.plan }
+      : null
+  };
+};

package/packs/frontend/skills/rendering-strategy/evals/files/5/svelte.config.js

@@ -0,0 +1,10 @@
+import adapter from '@sveltejs/adapter-auto';
+
+/** @type {import('@sveltejs/kit').Config} */
+const config = {
+  kit: {
+    adapter: adapter()
+  }
+};
+
+export default config;

package/packs/frontend/skills/rendering-strategy/evals/files/5/traffic.md

@@ -0,0 +1,18 @@
+# Traffic and platform numbers (from Dan, Oct 2026)
+
+Monthly, last 90 days averaged:
+- Public pageviews: 2.4M total
+  - marketing (/, /pricing, /customers): 0.9M
+  - docs: 1.3M
+  - blog: 0.2M
+- App: 180k sessions/month, avg 14 page navigations per session
+
+Stratus Functions pricing (our plan):
+- $0.40 per 1M invocations
+- $0.000018 per GB-second
+- functions configured at 1024 MB
+- static/CDN-served requests: no per-request charge, bandwidth included up to 1 TB/month
+
+Measured on staging with SSR on:
+- avg SSR duration: 220 ms per page
+- cold start p95: 900 ms

package/packs/frontend/skills/rendering-strategy/examples/saas-site.md

@@ -0,0 +1,42 @@
+# Worked example: SaaS marketing site, docs, status page and app (SvelteKit)
+
+## Input
+
+> We're moving Tallyhook (invoicing SaaS) to one SvelteKit app on Node behind a CDN. Routes:
+> `/` and `/pricing` (marketing, edited a few times a month, the pricing table shows the
+> visitor's currency from their country); `/docs/**` (about 500 pages, markdown in the repo,
+> deployed on merge); `/changelog` (one entry a week); `/status` (must show an incident within
+> 60 seconds, and has to work when the app is down); `/app/**` (the logged-in product).
+> Traffic a month: marketing and changelog 300,000 views, docs 450,000, `/app` 900,000. We were
+> going to set `ssr = true` everywhere and be done. How should each route render?
+
+## Output
+
+Don't render everything per request: only `/app` needs per-user pages, and even there the
+choice is client- or server-rendered behind no shared cache. Everything public is prerendered
+or cached, and the status page must not depend on the app at all.
+
+| Route | Mode | Why | Invalidated by | When its source fails |
+|---|---|---|---|---|
+| `/`, `/pricing` | prerendered; currency picked by a CDN-geo cache key or a small client fragment | same for everyone in a country, indexed, shared | deploy (content is in the repo) `[assumption]` | page serves; currency falls back to USD `[assumption]` |
+| `/docs/**` | prerendered (`export const prerender = true` on the docs layout), `csr = false` on pages with no widgets | same for everyone, indexed, changes only on merge | deploy on merge | served from the CDN |
+| `/changelog` | prerendered | weekly change, indexed | deploy | served from the CDN |
+| `/status` | static page on separate hosting, polling a status JSON with a 30-second TTL | must work when the app is down; 60-second freshness | the status JSON updates; the page never needs a rebuild | page loads; shows the last status with its time |
+| `/app/**` | `ssr = false` (client-rendered SPA) or SSR with `private, no-store` | per user, never indexed | — | spinner, then an error state with retry |
+
+**Traps found**
+
+- `/status` inside the same SvelteKit app goes down with it. Host it apart from the app.
+- Currency from geo makes `/pricing` vary per country: put the country in the CDN cache key
+  (a few entries), not `Vary: Cookie` (one entry per visitor).
+- `prerender = true` on the root layout would reach `/app` too; set it on the public layouts only.
+
+**Cost.** SSR on every route: 1,650,000 renders a month. This plan: public pages render at
+build only (500-odd pages per deploy); `/app` at most 900,000 if server-rendered, 0 if
+client-rendered.
+
+**To confirm**
+
+- How often marketing pages are edited outside a deploy (if a CMS edits them, add an on-demand
+  rebuild on its publish event).
+- The fallback currency.

package/packs/frontend/skills/rendering-strategy/manifest.json

@@ -0,0 +1,50 @@
+{
+  "name": "rendering-strategy",
+  "version": "0.1.0",
+  "description": "Decide route by route how each page of a web app is rendered — static at build (SSG), static with revalidation (ISR, stale-while-revalidate), server-rendered per request (SSR, streaming), client-rendered (CSR, SPA), at the edge, or a mix with islands and server components — from how fresh each route's data must be, whether it is personalised, whether it must be indexed or shared, what it costs per request at the stated traffic and how much JavaScript it needs, with the cache keys, invalidation events and failure modes of each choice. Use when the user asks \"should this be SSR or static\", \"SSR vs SSG vs ISR\", \"how should each page be rendered\", \"do we need SSR for SEO\", \"which pages can we cache\", or is choosing rendering modes in Next.js, Nuxt, Remix, React Router, SvelteKit or Astro.",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "adr-generator",
+    "design-doc",
+    "nfr-spec"
+  ],
+  "handoff": [
+    {
+      "to": "nfr-spec",
+      "when": "the routes have no stated freshness, latency or availability targets to decide against",
+      "purpose": "Pin the freshness and time-to-first-byte targets each route's mode must meet.",
+      "fallback": "If nfr-spec is absent, state each route's freshness tolerance and TTFB target inline, tagged [assumption] where the user gave none."
+    },
+    {
+      "to": "adr-generator",
+      "when": "the route table is agreed and the team wants it on record",
+      "purpose": "Record the rendering strategy, the options rejected and why, as a numbered decision.",
+      "fallback": "If adr-generator is absent, add a short decision note under the table: the decision, the alternative rejected (such as SSR everywhere) and the reason."
+    }
+  ],
+  "tags": [
+    "frontend",
+    "rendering",
+    "ssr",
+    "caching",
+    "seo"
+  ],
+  "permissions": {
+    "network": [],
+    "commands": [],
+    "files": "named-paths",
+    "notes": "scripts/render_load.py reads a routes CSV from a named path or stdin and writes a Markdown report to stdout or the path given with -o. No network."
+  },
+  "model": {
+    "tier": "standard",
+    "rationale": "Choosing static, server, client or incremental rendering per route follows fixed trade-offs (freshness, personalisation, SEO, cost); bounded judgment."
+  }
+}