agentleFS
Sign inStart free
Sequela02Sequela02/canasta/skills/stack/astro/SKILL.md

astro

Skill0 starsChanged yesterdayMITView on GitHub

Build or debug Astro pages, content collections, islands, rendering, assets, and site configuration.

18 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

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 12 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 17 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use Astro for content-first surfaces and ship the least client JavaScript that fully supports the required behavior.

    line 8
  2. Very specific:

    Keep document structure, content, navigation, metadata, and non-interactive components in .astro files.

    line 16
  3. Very specific:

    Add a framework island only when behavior needs component state or an existing framework component.

    line 18
  4. Distinctive:

    Prefer build-time content and static output for landings.

    line 21
  5. Distinctive:

    Use Astro image components, semantic HTML, canonical metadata, structured content schemas, and accessible forms.

    line 24
  6. Distinctive:

    Use browser-native cross-document View Transitions for navigation when they satisfy the experience.

    line 26
  7. Distinctive:

    Run the repository's Astro check, typecheck, build, and browser verification.

    line 29
  8. Distinctive:

    Do not turn a content site into a React SPA.

    line 35
  9. Distinctive:

    Do not hydrate static navigation, cards, layout, or copy.

    line 36
  10. Distinctive:

    Do not add an adapter to a fully static deployment.

    line 37
  11. Distinctive:

    Do not access browser APIs in server frontmatter.

    line 38
  12. Distinctive:

    Do not add Motion or GSAP for page navigation that native View Transitions express cleanly.

    line 39
  13. Distinctive:

    Do not copy framework versions into this skill.

    line 41
  14. Distinctive:

    Keep credential, tenant, checkout, and authenticated application workflows behind the owning application boundary unless the architecture …

    line 43
  15. Very specific:

    Read references/implementation.md when choosing rendering, hydration, content, transition, or verification patterns.

    line 49

“Common” is measured: kept by at least 6 in 10 of the 17 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

Use Astro for content-first surfaces and ship the least client JavaScript that fully supports the required behavior. Read the repository manifests before choosing APIs or changing dependencies; this skill is not version authority.

Workflow

  1. Identify the surface, output mode, deployment target, content source, and interactions.
  2. Keep document structure, content, navigation, metadata, and non-interactive components in .astro files.
  3. Add a framework island only when behavior needs component state or an existing framework component. Choose the least eager client:* directive that still meets the interaction requirement.
  4. Prefer build-time content and static output for landings. Introduce on-demand rendering, server islands, sessions, actions, or adapters only when request-specific behavior proves the need.
  5. Use Astro image components, semantic HTML, canonical metadata, structured content schemas, and accessible forms.
  6. Use browser-native cross-document View Transitions for navigation when they satisfy the experience. Add a client router only for features that require it and account for script lifecycle changes.
  7. Run the repository's Astro check, typecheck, build, and browser verification. Inspect rendered metadata, responsive layout, keyboard navigation, reduced motion, asset output, and client JavaScript.

Boundaries

  • Do not turn a content site into a React SPA.
  • Do not hydrate static navigation, cards, layout, or copy.
  • Do not add an adapter to a fully static deployment.
  • Do not access browser APIs in server frontmatter.
  • Do not add Motion or GSAP for page navigation that native View Transitions express cleanly.
  • Do not copy framework versions into this skill. Consult the resolved stack profile and current official documentation.
  • Keep credential, tenant, checkout, and authenticated application workflows behind the owning application boundary unless the architecture explicitly assigns them to Astro server routes.

Reference

Read references/implementation.md when choosing rendering, hydration, content, transition, or verification patterns. For APIs that may have changed, consult Astro's official documentation and llms.txt before implementing.

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.

Check your setup, free