| name | platform-web |
| description | Platform web architecture — framework/runtime selection, rendering modes, static assets, and web auth boundaries |
Use this skill when planning, implementing, or reviewing web application
architecture across frameworks and hosting providers.
Keep this skill provider/implementation agnostic. Put framework- or provider-
specific notes in sibling files and reference them here rather than creating a
new top-level skill for every tool.
Supporting references
Read the relevant files before making design or implementation decisions:
- Astro implementation notes — Astro static, SPA, hybrid, SSR,
local Node/Bun, Cloudflare adapter, and Auth.js patterns observed across
local repos.
- Static assets and SPA delivery — immutable assets,
SPA fallback, cache boundaries, build-time env, and asset auth gates.
Decision areas
Use this skill for:
- Web framework/runtime selection.
- Static vs SPA vs hybrid vs SSR rendering decisions.
- Adapter/runtime selection: Node/Bun, edge workers, static hosts, or custom
serving shells.
- Client-side build environment and public variable handling.
- Static asset delivery, cache policy, SPA fallback, and protected assets.
- Web auth boundary placement: client-only hints vs server/edge enforcement.
- Porting web apps across frameworks or hosting runtimes.
Grouping convention
- Add framework-specific files here:
astro.md, nextjs.md, remix.md, etc.
- Add web delivery topic files here:
static-assets.md, forms.md,
web-auth-boundaries.md, etc.
- Do not create a top-level
platform-<framework> skill unless the framework
becomes broad enough to own multiple subdocuments.
- Put deployment pipeline/provider mechanics in
platform-ci-cd; link back here
when a web runtime depends on those mechanics.
