Astro
Skill Syo-M/codex-frontend-skills/plugins/codex-frontend-skills/skills/astro
Codex-native frontend skills, custom agents, profiles, and an evidence-backed evaluation harness for React, Next.js, Vite, and Astro.
npx -y skills add Syo-M/codex-frontend-skills --skill astroAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 24 days oldThe repository was created 24 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Astro-specific pages, routing/rendering, islands, client directives, content collections, and .astro components. Not for framework-neutral styling or tests merely because Astro is installed. 日本語の依頼例:「Astroで実装」「アイランド」「コンテンツコレクション」「.astroコンポーネント」。
SKILL.md
2.8 KB, as published. Nobody here has run it
Astro
Zero-JS by default
- Default to
.astrocomponents rendering static HTML. Ship JS only for genuinely interactive islands. - Choose the cheapest
client:directive that works:client:visible(below the fold) >client:idle(non-critical) >client:load(immediately needed).client:onlyis a last resort (no SSR, layout shift risk) — except for components that cannot render on the server, e.g. DOM-measuring charts (seedata-viz). - Before reaching for a React island, ask: can this be a
<details>, CSS, or a few lines of vanilla JS in a<script>tag? Many "interactive" widgets need no framework. - Share state between islands with nano stores, not prop drilling through the static layer.
Components
.astrofor layout/static content; framework components (React) only inside islands that need them.- Props typed via
interface Props+Astro.propsdestructuring in.astrofiles; React island components followreact-patterns(type Props). - Styles follow the active styling profile for both
.astrofiles and framework islands. Astro scoped<style>is allowed for purely local, single-file styling; pick one approach per component and do not introduce a parallel styling system.
Content Collections
- All structured content (blog, docs, data) goes through content collections defined in
src/content.config.tswith a Content Layer loader (glob()/file()fromastro/loaders) and a zod schema — never loose globs of untyped markdown. (The legacy loader-less collection config was removed in Astro 5+.) - The schema is the contract: required frontmatter fields, date coercion (
z.coerce.date()), enums for categories. Build fails on bad content — that's the point.
Data & rendering
- Fetch at build time in frontmatter for static pages. For per-request data, mark the page/route as server-rendered explicitly — know which mode each page is in.
import.meta.globresults are build-time; don't treat them as dynamic. (Astro.globno longer exists — removed in Astro 5+; useimport.meta.globorgetCollection.)- Use
astro:assets(<Image>,<Picture>) for images — width/height required, prevents CLS.
Security
set:htmlisdangerouslySetInnerHTML— sanitize non-static input first (seefrontend-securityskill).- Endpoints (
src/pages/api/) follow the same validate/authenticate rules as any server endpoint. - Public env vars need the
PUBLIC_prefix; everything else is server-only — same discipline as Next.js.