Use rendering-strategy

Decide route by route how each page of a web app is rendered

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.

Reach for it 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.

Install it

npx skilldrop-cli install rendering-strategy                 # Claude Code, your user folder
npx skilldrop-cli install rendering-strategy --project       # Claude Code, this repo
npx skilldrop-cli install rendering-strategy --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Frontend pack: --pack frontend installs it with its neighbours.

It ships scripts, so it needs Python 3 (standard library only, nothing to install). What they may touch is declared in its manifest.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Should our product pages be SSR or static with ISR? Stock changes a lot."
• "The team wants to server-render the whole site for SEO. Is that actually needed?"
• "Help me pick SSG, ISR, SSR or CSR for each route of our Nuxt app"
• "Our SPA's pages don't show up in Google and link previews are blank. What should we render on the server?"
• "Which of our SvelteKit pages can we prerender and cache at the CDN, and which have to be dynamic because they're logged in?"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Write the design doc for the new storefront: services, data stores and rollout plan"
• "Write an ADR for our decision to move from Create React App to Next.js"
• "Set p95 latency and availability targets for the checkout API"

If another skill answers instead, ask for this one by name: "use rendering-strategy".

Check what you get

A good result:

• 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].

See a worked example

• saas site

Use something else when

• 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

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: adr-generator, design-doc, nfr-spec

Edit this page on GitHub · View source