agentleFS
lgzarturolgzarturo/codeconductor/.agents/skills/astro/SKILL.md

astro

Skill0 starsChanged 27 days agoMITView on GitHub

Provides expert knowledge for building Astro 5+ sites with Islands Architecture, Content Collections, TypeScript, and performance-first rendering strategies.

17 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use react, accessibility and 2 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • VercelSkill

    react

    React renderer for json-render that turns JSON specs into React components. Use when working with @json-render/react, building React UIs from JSON, creating component catalogs, or rendering AI-generated specs.

    Also in 4 projects that use this

  • ElasticSkill

    accessibility

    Accessibility guidance for Kibana. Use this skill when working with or reviewing EUI components, resolving a11y-related (@elastic/eui) ESLint issues, and ensuring proper use of ARIA attributes, focus management, keyboard interactions, and accessible naming conventions.

    Also in 3 projects that use this

  • nilssonrSkill

    seo

    Full SEO workflow for auditing pages and creating SEO-optimized content. Provides checklists with educational explanations aligned with Google Search Central documentation.

    Also in 3 projects that use this

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 2 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Default to no hydration directive — most UI does not need JavaScript

    line 72
  2. Very specific:

    Do not use client:load for components that could use client:visible

    line 76
  3. Distinctive:

    Every page is pre-rendered at build time.

    line 186
  4. Very specific:

    Use hybrid mode when: most content is static but a few routes need auth or live data.

    line 234
  5. Very specific:

    Use the built-in <Image> and <Picture> components.

    line 240
  6. Very specific:

    Always provide alt — empty string is acceptable only for decorative images

    line 271
  7. Very specific:

    Prefer avif + webp fallback for best compression

    line 272
  8. Very specific:

    Use widths + sizes on above-the-fold images to serve the right size per viewport

    line 273

“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Astro

Islands Architecture

Astro renders everything to static HTML by default. JavaScript ships only for components that explicitly opt in — these are called Islands.

Hydration Directives

DirectiveWhen JS loadsUse case
client:loadOn page loadInteractive above-the-fold UI
client:idleWhen browser is idleNon-critical interactive widgets
client:visibleWhen element enters viewportBelow-the-fold islands
client:mediaWhen CSS media query matchesResponsive interactive components
client:onlyClient-only, no SSRComponents that require the DOM (e.g., charting libs)
---
import Counter from '../components/Counter.tsx';
import HeavyChart from '../components/HeavyChart.tsx';
import MobileNav from '../components/MobileNav.tsx';
---

<!-- Hydrates immediately — user interacts right away -->
<Counter client:load />

<!-- Hydrates when scrolled into view — saves initial JS -->
<HeavyChart client:visible />

<!-- Only on mobile, only when query matches -->
<MobileNav client:media="(max-width: 768px)" />

Rules:

  • Default to no hydration directive — most UI does not need JavaScript
  • client:load is the most expensive directive; use it sparingly
  • client:only skips server rendering entirely — the component receives no props from the server; pass all data via props or fetch inside the component
  • Do not use client:load for components that could use client:visible

Framework Components Inside Astro

---
import ReactButton from './Button.tsx';   // React island
import VueWidget from './Widget.vue';     // Vue island
---

<!-- Both can coexist on the same page -->
<ReactButton client:idle label="Click me" />
<VueWidget client:visible />

Each framework ships its own runtime only when at least one island of that framework is on the page.

Content Collections

Content Collections provide type-safe access to Markdown, MDX, and data files. Define schemas in src/content/config.ts.

Schema Definition

// src/content/config.ts
import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
  type: 'content',   // .md or .mdx files
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
    updatedDate: z.coerce.date().optional(),
    author: z.string().default('Anonymous'),
    tags: z.array(z.string()).default([]),
    draft: z.boolean().default(false),
    image: z.object({
      src: z.string(),
      alt: z.string(),
    }).optional(),
  }),
});

const docs = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    order: z.number(),
    section: z.enum(['guide', 'reference', 'tutorial']),
  }),
});

export const collections = { blog, docs };

Querying Collections

---
import { getCollection, getEntry } from 'astro:content';

// All published posts, sorted by date
const posts = (await getCollection('blog', ({ data }) => !data.draft))
  .sort((a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf());

// Single entry by slug
const post = await getEntry('blog', 'my-first-post');
const { Content } = await post.render();
---

{posts.map(post => (
  <article>
    <h2><a href={`/blog/${post.slug}`}>{post.data.title}</a></h2>
    <time>{post.data.pubDate.toLocaleDateString()}</time>
  </article>
))}

Dynamic Routes from Collections

---
// src/pages/blog/[slug].astro
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map(post => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
const { Content, headings } = await post.render();
---

<article>
  <h1>{post.data.title}</h1>
  <Content />
</article>

Rendering Strategies

SSG (Static Site Generation) — default

Every page is pre-rendered at build time. Best for content that does not change per request.

// astro.config.mjs — no output config needed; SSG is the default
export default defineConfig({
  site: 'https://example.com',
});

SSR (Server-Side Rendering)

Renders pages on each request. Required for: authenticated routes, personalized content, live data.

// astro.config.mjs
import node from '@astrojs/node';

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
});

Hybrid Mode

Mix SSG and SSR on a per-page basis. Most pages are static; specific routes opt into server rendering.

// astro.config.mjs
export default defineConfig({
  output: 'hybrid',
  adapter: node({ mode: 'standalone' }),
});
---
// src/pages/dashboard.astro — this page is server-rendered
export const prerender = false;

// src/pages/about.astro — this page is statically generated (hybrid default)
export const prerender = true;
---

Use hybrid mode when: most content is static but a few routes need auth or live data. Do not make everything output: 'server' — you lose the performance benefits of static generation.

Image Optimization

Use the built-in <Image> and <Picture> components. Never use raw <img> for local assets — you lose automatic optimization.

---
import { Image, Picture } from 'astro:assets';
import heroImage from '../assets/hero.png';
---

<!-- Optimized single image -->
<Image
  src={heroImage}
  alt="Hero illustration"
  width={800}
  height={600}
  format="webp"
  quality={80}
/>

<!-- Responsive with multiple formats -->
<Picture
  src={heroImage}
  formats={['avif', 'webp']}
  alt="Hero illustration"
  widths={[400, 800, 1200]}
  sizes="(max-width: 800px) 100vw, 800px"
/>

Rules:

  • Always provide alt — empty string is acceptable only for decorative images
  • Prefer avif + webp fallback for best compression
  • Use widths + sizes on above-the-fold images to serve the right size per viewport
  • Remote images require explicit width and height to prevent layout shift

Project Structure

src/
  assets/          — images and static assets processed by Astro
  components/      — .astro components (and framework islands)
  content/
    blog/          — .md and .mdx files
    config.ts      — collection schemas
  layouts/         — page shell layouts
  pages/           — file-based routing; every file is a route
  styles/          — global CSS
astro.config.mjs
tsconfig.json

Colocation rule: put framework island components (.tsx, .vue) in src/components/. Do not scatter them in src/pages/.

TypeScript Conventions

// tsconfig.json — use the strict Astro preset
{
  "extends": "astro/tsconfigs/strict"
}
---
// Type props explicitly in the frontmatter
interface Props {
  title: string;
  description?: string;
  tags: string[];
}

const { title, description = '', tags } = Astro.props;
---

Astro infers prop types from interface Props automatically. Do not use any.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.