astrolisted

REQUIRED BACKGROUND: You MUST also follow the core `frontend-fundamentals` skill (generic UI patterns) and `clean-code`. This skill adds Astro-specific patterns on top. # astro ## Layer contract (matches `structure.tree`) | Layer | May import | Never | |---|---|---| | `pages/*.astro` | layouts, components, `getCollection()` data | request-time globals (runs at build) | | `components/*.astro` | child components, props | page-level data fetching for the whole page | | islands (`client:*`) | the leaf framework component only | wrapping a whole page/layout | | `pages/api/*.ts` | `lib/problem.ts`, domain logic | building an error body inline | | `content/config.ts` | `astro:content`, Zod | runtime side effects | | `lib/problem.ts` | nothing app-specific | leaking internals to the client | Pages and `.astro` frontmatter run at **build time** (SSG) — no request context there. Anything needing a request lives in an endpoint or an island, so a page stays a static, zero-JS artifact. ## Rendering & islands - `output: "static"` is the default; a page ships **zero client JS**. Switch a single route to `hybrid`/`server` only when it genuinely needs request-time rendering — never flip the whole app. - Hydrate the **narrowest** island: `client:visible` / `client:idle` over `client:load`; `client:only` only when SSR truly cannot run. - Islands are **leaf** components — extract the interactive part into a framework component (React/Svelte/Vue) and keep the page/layout shell stati