P PasteCode
Rule

Regras do AGENTS.md para um Site Estático Astro

Um AGENTS.md pronto para usar em sites estáticos Astro que mantém agentes de IA no stack, evita desvio de SSR e impõe convenções de coleção de conteúdo.

CursorClaude CodeCodexWindsurf AstroTypeScriptTailwind
.md .json Atualizado 8 de jun. de 2026

Coloque isso na raiz do seu repositório como AGENTS.md. Agentes direcionados ao Astro (Cursor, Claude Code, Codex) o leem automaticamente na inicialização e o utilizam para permanecer dentro das convenções em cada sessão de geração de código.

AGENTS.md

AGENTS.md
# Project Rules — Astro Static Site
## Stack
- Astro 5 (static output, `output: "static"`). No SSR adapter unless explicitly requested.
- TypeScript strict mode. All `.astro` component scripts are TypeScript.
- Tailwind CSS v4. No CSS-in-JS. No inline `style` attributes unless value is truly dynamic.
- Content managed via Astro Content Collections (Zod schemas in `src/content.config.ts`).
## Hard rules
- Never switch `output` to `"server"` or `"hybrid"` — this is a static build.
- Never add `client:load` to a component that does not require browser interactivity.
Prefer `client:idle` or `client:visible` when a client directive is genuinely needed.
- All content files live in `src/content/<collection>/`. Do not create ad-hoc markdown
files outside a defined collection.
- Frontmatter must match the Zod schema in `src/content.config.ts`. Validate before
writing — wrong field names cause build failures, not runtime errors.
- Images must go through Astro's `<Image />` component or `getImage()` helper.
Never use bare `<img>` tags — they bypass optimisation and break CLS scores.
- Never read environment variables with `import.meta.env` inside a `.ts` utility that
may be imported on the client; mark those files with a `// server-only` comment and
import them only from `.astro` files or API endpoints.
- Do not add a dependency without stating the reason. Prefer Astro-native solutions
(content collections, view transitions, image optimisation) before reaching for npm.
## Conventions
- Components live in `src/components/`. Page layouts live in `src/layouts/`.
One component per file; file name matches the exported component name.
- Route pages live under `src/pages/`. Dynamic routes use bracket notation:
`src/pages/[slug].astro`. Static paths are generated via `getStaticPaths()`.
- Shared TypeScript utilities live in `src/lib/`. Import with the `@/` alias
(configured in `tsconfig.json`).
- Tailwind classes follow mobile-first order: base → `sm:``md:``lg:`.
No arbitrary values unless a design token does not exist.
- Every page component must export a `<meta>` block via the layout that includes
`title`, `description`, and Open Graph tags.
## SEO conventions
- Every `src/pages/*.astro` page must render a canonical `<link rel="canonical">`.
- Blog / content pages must include `datePublished` and `dateModified` in
JSON-LD structured data.
- Do not create two pages that share the same `<title>` or `<meta name="description">`.
## Definition of done
- `astro check` passes with zero errors.
- `astro build` completes without warnings.
- Lighthouse performance score ≥ 90 on a representative page (run `unlighthouse`).
- No new `any` types. No unused imports.
- All new content frontmatter passes the Zod schema (`bun run typecheck`).

Por que essas regras

  • “Nunca mude a saída para servidor” é a regra de maior impacto para sites estáticos Astro. Agentes que descobrem uma funcionalidade ausente frequentemente sugerem adicionar um adaptador SSR como uma correção rápida — isso muda silenciosamente o destino de implantação, quebra o cache da CDN e adiciona latência de inicialização a frio. A regra força os agentes a resolverem problemas dentro do paradigma estático.
  • “Imagens devem passar pelo <Image /> elimina o erro de IA mais comum em sites de conteúdo: tags <img> simples que prejudicam o Core Web Vitals. O pipeline de imagens do Astro lida com conversão de formato, srcset responsivo e carregamento lento automaticamente — os agentes o ignoram a menos que sejam explicitamente instruídos a não fazer isso.
  • Validação de frontmatter com Zod detecta incompatibilidades de esquema no momento da verificação de tipos, em vez de no momento da build ou, pior, renderizando silenciosamente dados errados. Agentes que escrevem arquivos markdown frequentemente alucinam nomes de campos de frontmatter.

Boa adequação

  • Sites de marketing, blogs, sites de documentação e sites de conteúdo focados em SEO construídos com Astro com um alvo de saída estática fixa.

Não é adequado

  • Projetos Astro que usam output: "server" ou "hybrid" com um adaptador edge/SSR — esses precisam de um conjunto de regras diferente que permita client:load e padrões de busca de dados no lado do servidor.