FW Astro schreiben

Was macht FW Astro schreiben?

Umfang und erste Entscheidungen

Verwenden Sie diese Skill für Astro-spezifische Komponenten, Routing, Inhalte, Rendering und Integrationen. Verwenden Sie sie nicht, um React-Interna, eine Backend-Architektur oder einen Deployment-Provider vorzuschreiben; kombinieren Sie die relevante Framework/Runtime-Skill nur bei Bedarf.

Überprüfen Sie vor dem Bearbeiten die package.json, die Lockdatei, die Astro- und Adapter-Versionen, die astro.config.*, die tsconfig, die vorhandenen Routen/Layouts/Content-Konfiguration und die Repository-Skripte. Befolgen Sie die Dokumentation der installierten Version und die bestehenden Konventionen. Installieren Sie keine Integrationen, aktualisieren Sie keine Abhängigkeiten, deployen Sie keine Anwendungen und rufen Sie keine kostenpflichtigen Dienste ohne Autorisierung auf.

• Bevorzugen Sie prerendered HTML für Inhalte, die vorab erstellt werden können. Frontmatter wird zur Build-Zeit für prerendered Routen und auf dem Server für On-Demand-Routen ausgeführt; es ist kein Browser-Code.
• Verwenden Sie SSR für tatsächliche Request-Time-Anforderungen wie authentifizierte Inhalte oder aktuelle Daten. Es ist ein kompatibler Adapter erforderlich. In Versionen, die das aktuelle Modell unterstützen, kann der standardmäßige statische Output einzelne Routen mit export const prerender = false für SSR optieren; output: 'server' macht SSR zum Standard und erlaubt Ausnahmen mit prerender = true. Ältere Versionen haben eine andere Hybrid-Konfiguration: Überprüfen Sie sie vor der Migration.
• Eine vollständig statische Seite benötigt normalerweise keinen Adapter. Setzen Sie Astro nicht mit Cloudflare gleich oder zwingen Sie SSR statischen Inhalten auf.
• Bewahren Sie Barrierefreiheit, Escaping und Trust Boundaries. Interpolieren Sie kein unvertrautes HTML mit set:html; bereinigen Sie das Rendering im vertrauenswürdigen Format an seiner tatsächlichen Eingabegrenze.

Native Komponenten und gültige Props

Verwenden Sie .astro-Komponenten für Layouts und statische Inhalte. Deklarieren Sie Props, wenn eine Komponente Props akzeptiert; prop-freie Seiten benötigen keine zeremonielle Schnittstelle. Verwenden Sie die tatsächlichen Attribute des Elements, geben Sie Attribute absichtlich weiter und vermeiden Sie ein polymorphes Tag mit inkompatiblen Attributsätzen. Eine verlinkte Karte kann einen Link innerhalb eines Artikels verwenden, anstatt href an einen Artikel zu senden. Verschachteln Sie keine interaktiven Steuerelemente innerhalb eines umschließenden Anchors.

ASTRO-CARD — vollständige src/components/Card.astro; kein CSS-Bibliothek erforderlich:

---
import type { HTMLAttributes } from 'astro/types';

interface Props extends Omit<HTMLAttributes<'article'>, 'title'> {
  title: string;
  description?: string;
  href?: string;
}

const { title, description, href, class: className, ...rest } = Astro.props;
---

<article {...rest} class:list={['card', className]}>
  <h2>{href ? <a href={href}>{title}</a> : title}</h2>
  {description && <p>{description}</p>}
  <slot />
</article>

Verwenden Sie benannte Slots für explizite Inhaltsbereiche und class:list für bedingte Klassen. Validieren Sie unvertraute Linkziele separat; ein String-Typ ist keine URL-Validierung.

Kleines Browser-Verhalten vor Framework-Islands

Verwenden Sie zuerst semantisches HTML (details, native Formulare), dann ein kleines verarbeitetes <script>, wenn Browser-Verhalten benötigt wird. Fügen Sie React/Vue/Svelte nicht nur zum Umschalten eines Menüs hinzu. Astro-Skripte werden gebündelt/dedupliziert; wählen Sie alle Komponenteninstanzen aus oder verwenden Sie ein scoped custom element. Folgen Sie bei Client-seitiger Navigation dem Lebenszyklus des installierten Routers und vermeiden Sie doppelte Listener. Frontmatter-Werte sind in Browser-Skripten nicht automatisch verfügbar; übergeben Sie nur nicht-vertrauliche Daten über explizite DOM-Attribute oder Props.

ASTRO-BUTTON — vollständige src/components/Counter.astro für gewöhnliche vollständige Seitennavigation:

<button type="button" data-counter aria-label="Increment count">0</button>
<script>
  document.querySelectorAll<HTMLButtonElement>('button[data-counter]').forEach((button) => {
    let count = 0;
    button.addEventListener('click', () => {
      button.textContent = String(++count);
    });
  });
</script>

Verwenden Sie eine Framework-Island, wenn vorhandene Framework-Komponenten oder umfangreicher interaktiver Zustand dies rechtfertigen, mit einer bereits installierten Integration. Wählen Sie client:load für sofort benötigtes Verhalten, client:idle für nichtkritisches Verhalten, client:visible für außerhalb des Bildschirms befindliche Inhalte und client:media für eine tatsächliche medienabhängige Anforderung. Komponenten ohne client:*-Direktive rendern HTML ohne Framework-Hydration. client:only überspringt das Server-Rendering und benötigt eine absichtliche Lade-/Fallback-Erfahrung, keine pauschale Problemumgehung.

Content Collections folgen der installierten Version

Verwenden Sie Collections für wiederholte strukturierte Inhalte, nicht für jede isolierte Seite. Überprüfen Sie die vorhandene Konfiguration und Eintrags-IDs vor dem Bearbeiten:

• Astro 5 hat das Content Layer Loader-Modell eingeführt, normalerweise in src/content.config.ts. Legacy-Projekte können src/content/config.ts und type: 'content' anstelle von Loadern verwenden. Dies sind nicht austauschbare Dateipfade/APIs.
• Überprüfen Sie den installierten Zod-Export. Das folgende Beispiel zielt auf Astro 5s z-Export aus astro:content ab; die aktuelle Dokumentation verwendet astro/zod. Ersetzen Sie Imports nicht mechanisch in einer Version, der dieses Modul fehlt.
• Loader-Einträge verwenden id; gehen Sie nicht von Legacy-slug- oder entry.render()-APIs aus. Verwenden Sie für das Content Layer-Rendering den unterstützten render(entry)-Helfer. MDX erfordert seine Integration, wenn MDX-Dateien enthalten sind.

ASTRO-COLLECTION-V5 — vollständige src/content.config.ts für Astro 5 mit lokalen Markdown-Einträgen:

import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
    updatedDate: z.coerce.date().optional(),
    tags: z.array(z.string()).default([]),
    draft: z.boolean().default(false),
  }),
});

export const collections = { blog };

ASTRO-COLLECTION-LIST — vollständige Seite src/pages/blog/index.astro, gepaart mit dieser Collection und mindestens einem schema-gültigen Markdown-Eintrag:

---
import { getCollection } from 'astro:content';
const posts = await getCollection('blog', ({ data }) => !import.meta.env.PROD || !data.draft);
posts.sort((a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf());
---
<h1>Blog</h1>
<ul>{posts.map((post) => <li>{post.data.title}</li>)}</ul>

Diese Liste erfindet bewusst keine Detailseiten-URLs. Wenn Sie Links hinzufügen, implementieren Sie passende dynamische Routen und getStaticPaths() für prerendered Seiten. Überprüfen Sie Entwürfe sowohl bei Detailrouten als auch bei Auflistungen; das Filtern nur des Indexes ist keine Zugriffskontrolle. Private Inhalte zur Anforderungszeit dürfen nicht über Build-Output oder öffentliche Caches durchsickern.

Locale, Canonical und 404-Konsistenz

Wählen Sie die URL-Richtlinie, bevor Sie Routen ändern: Konfigurierte Produktions-site, Deployment-base, Trailing-Slash/Build-Format, Locale-Präfixe, Root-Verhalten und Fallback-Verhalten müssen mit den tatsächlichen Dateien und Host-Weiterleitungen übereinstimmen.

• Verwenden Sie ordnerbasierte Routen. Mit prefixDefaultLocale: false liegen Standardsprach-Seiten im Root; andere Locales haben Ordner. Mit true haben alle Sprachen Locale-Ordner, und der Root-Index erfordert dennoch eine absichtliche Behandlung.
• Verwenden Sie versionsunterstützte astro:i18n-Helfer, wenn nützlich. Die Konfiguration übersetzt keine Inhalte oder erstellt fehlende Seiten. Verlinken Sie nur vorhandene Übersetzungen; bewahren Sie einen sinnvollen äquivalenten Pfad beim Sprachwechsel.
• Canonicals sollten den Produktions-Origin und den gewählten kanonischen Pfadnamen verwenden, nicht den willkürlichen Request-Host/Query-Parameter von Astro.url.href. Setzen Sie site für das Deployment; berücksichtigen Sie base und Trailing-Slash-Normalisierung. Setzen Sie das Dokument lang und geben Sie hreflang-Alternativen nur für echte Äquivalente mit gegenseitigen Links aus. Kanonisieren Sie nicht alle Locales auf Englisch.
• Implementieren Sie src/pages/404.astro, wenn eine benutzerdefinierte Fehlerseite benötigt wird. Geben Sie auf SSR-Pfaden einen echten 404-Status zurück, keinen erfolgreichen Fehlerbody. Überprüfen Sie bei statischem Hosting, dass die generierte 404-Datei mit Status 404 ausgeliefert wird. Verwenden Sie kein SPA-Fallback für eine Multi-Page-Seite oder leiten Sie jeden fehlenden Locale-Pfad auf die Startseite weiter. Vermeiden Sie die Indexierung von Fehlerseiten und geben Sie nicht jeder fehlenden URL eine Selbst-Kanonikale.

ASTRO-CANONICAL-FRAGMENT — partielles Layout-Beispiel, keine eigenständige Seite. Setzt voraus, dass site konfiguriert ist und der aktuelle Pfadname bereits der Base/Locale/Slash-Richtlinie des Repositorys folgt:

---
if (!Astro.site) throw new Error('Konfigurieren Sie die Produktions-URL der Site');
const canonical = new URL(Astro.url.pathname, Astro.site);
---
<link rel="canonical" href={canonical} />

Assets und Deployment-Grenzen

Bevorzugen Sie src/assets/ und Image aus astro:assets für Bilder, die von einer Verarbeitung profitieren. Behalten Sie Assets, die unveränderte URLs erfordern, robots.txt und Icons in public/; normales <img> ist für bewusste Durchleitungs-/Remote-Fälle gültig. Geben Sie sinnvolles alt (leer für dekorative Bilder) und intrinsische Dimensionen oder äquivalente Layout-Einschränkungen an. Passen Sie responsive-image-APIs an die installierte Version an und vermeiden Sie es, jedes Bild eifrig zu laden; priorisieren Sie nur wirklich über dem Falz liegende kritische Bilder. Überprüfen Sie SSR-Bilddienste und deren Runtime-/Kostenanforderungen, bevor Sie sie aktivieren.

Verwenden Sie die vorhandenen Header-/Weiterleitungsmechanismen des Hosts nur bei Bedarf. _headers und _redirects sind providerspezifisch, keine universellen Astro-Anforderungen. Folgen Sie für Adapter-SSR der generierten Ausgabe und den Runtime-Binding-Konventionen der Adapter-Version anstelle einer handgeschriebenen generischen statischen/SPA-Konfiguration.

Überprüfung und Berichterstellung

Verwenden Sie die vorhandenen Check-/Build-/Test-Skripte des Repositorys, wenn autorisiert. Überprüfen Sie Prop-Typisierung, ausgegebene Routen, Collection-Validierung, Belichtung von Entwurfsdetailseiten, Links zum Locale-Wechsel, kanonische Origin/Query-Entfernung, Base/Slash-Verhalten, Status unbekannter Routen, Tastaturverhalten und Browser-Konsolenfehler. Ein erfolgreicher statischer Build beweist keine SSR-Runtime-Kompatibilität oder Produktions-Weiterleitungen. Melden Sie tatsächlich ausgeführte Befehle, Versionsannahmen, fehlende Integrationen/Inhalts-Fixtures und nicht verifiziertes Hosting-Verhalten. Installieren, deployen oder lösen Sie keine Remote-Dienste als impliziten Überprüfungsschritt aus.

Quellen und Herkunft

Dies ist die Synthese des Autors, kein Massenkopie von Drittanbieter-Skills. Lesen Sie nur die für die Aufgabe und die installierte Version relevante Dokumentation:

• Offizielles Astro: Komponenten und Props, Browser-Skripte, On-Demand-Rendering.
• Offizielles Astro: Content Collections, Astro 5 Migration, i18n Routing, Cloudflare Adapter.
• astrolicious/agent-skills ist eine Community-Referenz, keine offizielle Astro-Dokumentation oder Kompatibilitätsgarantie. Konsultieren Sie sie selektiv; die offizielle versionierte API-Dokumentation hat Vorrang.