casoon Landing- & Site-Builder
Prozess-Skill: verwandelt ein Briefing in eine gebaute, geprüfte Seite — ohne mit Code zu starten und ohne die erste Idee ungeprüft zu übernehmen. Er baut nicht selbst alles, sondern dirigiert die Fach-Skills des Repos.
Zwei Modi
- A · In Claude Code bauen — direkt im Astro-Projekt implementieren (Standard, wenn ein Repo existiert).
- B · An Claude design übergeben — statt zu implementieren einen Design-Brief + einen self-contained Prototyp erzeugen (eine HTML-Datei, CSS inline, keine externen Assets → lauffähig als Artifact / in Claude design). Danach das freigegebene Design nach Astro zurückportieren (Slice für Slice, s.u.). Frage zu Beginn, welcher Modus gewünscht ist.
Vor dem Bauen: Council-Gate
Die strategischen Weichen NICHT aus dem Bauch stellen. Für Positionierung, Seitenstruktur und Design-Richtung [[llm-council]] anwenden (unabhängige Perspektiven → Kritik → Synthese). Verhindert, dass Layout und Copy die erste, womöglich voreingenommene Idee zementieren. Ergebnis: eine begründete Richtung
- erster Schritt.
Der Workflow (Vertical-Slice-Loop)
Nicht horizontal (erst alle Layouts, dann aller Content). Sondern der kleinste nutzbare Ausschnitt end-to-end, dann iterieren. Pro Slice:
- Brainstorming — Was soll die Seite leisten? Ziel, Zielgruppe, eine gewünschte Aktion. Noch nicht bauen.
- Alignment — Erst Rückfragen stellen, nicht raten: Angebot, Zielgruppe, Tonalität, Pflichtinhalte, rechtliche Grenzen, ein oder mehrere CTAs?
- Slice wählen — kleinster nutzbarer Ausschnitt zuerst, z.B. Hero + ein CTA. Rest (Features, FAQ, Footer) bewusst später.
- Plan — kleine, testbare Schritte für genau diesen Slice.
- Definition of Done — Akzeptanzkriterien festlegen (Baseline unten).
- Implementieren — NUR diesen Slice, kein Zusatz-Scope.
- Testen — A11y, SEO, Visuell, Responsive (s. QA-Skills).
- Recap — kurz erklären, was gebaut wurde und wo die Grenzen sind.
- Refactoring — zuerst fragen „was können wir weglassen?", nicht nur „verbessern". Verhalten unverändert lassen.
- Commit — atomar, temporäre Planungs-MDs wieder entfernen.
Danach nächster Slice (Problem/Lösung → Social Proof → FAQ → CTA-Wiederholung).
Slice-Gates (Qualität pro Slice)
- Approval-Gate im Alignment: nach den Rückfragen eine klare Entscheidung einholen — ✅ Approve · 🔄 Revise · ❓ Clarify · ❌ Cancel. Erst bei ✅ bauen.
- Zwei-Stufen-Review pro Slice (stärker als ein DoD-Häkchen): erst
Spec-Compliance (deckt der Build das Briefing? Kein Scope-Creep?), dann
Code-Qualität — jeweils durch einen frischen Subagent (
Agent-Tool). Grundsatz: kein Agent prüft seine eigene Arbeit. Ergänzt das Council-Gate um eine QA-Achse.
Welchen Skill wann (Orchestrierung)
- Struktur & Copy: [[landingpage-from-briefing]] (Abschnitts-Copy), [[content-clarity-a11y-check]] (verständliche Texte, gute Linktexte).
- Ästhetik & Richtung: [[frontend-design]] (Richtung, nicht templated), [[ui-design]] (Hierarchie, Abstände, CTA-Stufen), [[tailwind-ui]] (v4-Setup), [[motion-design]] (Micro-Interactions), [[darkmode]].
- Bau: [[astro-architecture]] (Seiten/Layouts/Rendering), [[mdx-content]] (Content Collections), [[i18n]] (mehrsprachig), [[image-to-webp]] / [[web-performance]] (Bilder, CWV).
- QA je Slice: [[accessibility-audit]], [[seo]] (+ [[local-business-seo]] bei regionalen Seiten), [[playwright]] (E2E/axe), [[post-audit]] (Build-Audit).
Landing vs. Website
- Landing: ein Ziel, ein primäres CTA, minimale/keine Navigation, eine Seite. Alles zahlt auf die eine Aktion ein.
- Website: mehrseitig, Navigation, Sitemap, wiederkehrende Layouts, interne Verlinkung. Council-Gate zusätzlich für die Informationsarchitektur.
Definition of Done (Web-Baseline)
- A11y: semantisches HTML, Kontrast, Tastaturbedienung, Labels, ein
<h1>, Fokus sichtbar (→ accessibility-audit). - SEO: Title ≤ 60, Meta-Description ≤ 160 Zeichen, OG-Tags, Canonical,
passendes JSON-LD,
langgesetzt (→ seo). - Performance: responsive Bilder (WebP), keine Layout-Shifts, kein render-blockierender Ballast.
- Klarheit: ein erkennbares Ziel / CTA; Nutzen vor Features.
Gotchas
- Nicht mit Implementierung starten — erst Brainstorming + Rückfragen.
- Ein Ziel pro Landing; mehrere CTAs verwässern die Conversion.
- Nutzen vor Features formulieren; konkrete statt generischer Claims.
- Weglassen vor Hinzufügen — Agents bauen tendenziell zu viel.
- Modus B: Prototyp strikt self-contained (Inline-CSS, Data-URIs), sonst läuft er in Claude design / als Artifact nicht.
- Temporäre Planungs-Markdown nach dem Commit wieder entfernen.
- Der Mensch bleibt fachlicher Entscheider.