Communitygithub.com

AdityaPratamaS18/website-skill

Baue eine vollständige, SEO-optimierte Next.js-Website für einen Kunden oder ein Unternehmen – von der Briefing-Phase bis zur startbereiten Version.

Was ist website-skill?

Dieses Skill automatisiert den gesamten Workflow zur Erstellung einer Kundenwebsite mit Next.js. Es führt den Benutzer durch acht klar definierte Phasen: vom Einlesen des Briefings, über Keyword-Recherche und Site-Plan-Erstellung bis hin zu Design, Entwicklung, SEO-Prüfung und Launch. Der Fokus liegt auf SEO-Optimierung durch strukturierte Metadaten, eine serverseitige Prüfung (Gate) der Inhalte und die Einhaltung fester Regeln (z. B. eine URL pro Dienst, ein primäres Keyword pro Seite). Das Skill unterstützt sowohl statische als auch serverseitig gerenderte Websites und kann für jede Art von Geschäftskunden eingesetzt werden. Es wird mit CLI-Skripten und einem Gate-System validiert, das Fehler vor dem Launch abfängt.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/AdityaPratamaS18/website-skill/tree/HEAD/skills/website-skill
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

Website-Skill: Ablauf

Dieses Skill erstellt eine Kundenwebsite aus einem Briefing. Jeder Kunde erhält einen genehmigten Plan, eine Codebasis und ein Prüfskript. Der genehmigte Plan steuert die Routen, Titel, Beschreibungen, Überschriften und die Sitemap.

In diesem Dokument ist <skill-dir> der Ordner, der diese Datei enthält, und <client-folder> der Ordner für diesen Kunden. Falls der Benutzer keine Ordnerkonvention hat, verwende clients/<client>/.

Voraussetzungen

  1. Lies die Notizen für diesen Kunden, falls vorhanden. Gib dem Benutzer die zutreffenden Regeln in 2–3 Zeilen.
  2. Finde das Briefing, das Firmenprofil, das Logo und die Fotos.
  3. Stelle sicher, dass Node.js, Python 3 und rsync verfügbar sind.

WARNUNG: SETZE KEINE FAKTEN AUF DIE WEBSITE, DIE NICHT IM BRIEFING STEHEN. EIN ERFUNDENES ZERTIFIKAT, EIN ERFUNDENER KUNDENNAME, EINE ERFUNDENE ZAHL ODER EIN ERFUNDENES TESTIMONIAL IST EIN RECHTLICHES UND VERTRAUENSRISIKO FÜR DEN KUNDEN.

Phase 1: Fakten

  1. Lies references/brief-intake.md.
  2. Lies jede Quelldatei vollständig.
  3. Schreibe <client-folder>/site-brief/facts.md.
  4. Durchsuche die aktuelle Website, falls der Kunde eine hat. Notiere jede URL für die Weiterleitungsliste.
  5. Schreibe <client-folder>/site-brief/questions-for-client.md, falls Fakten fehlen.

TOR 1. Zeige dem Benutzer die Zusammenfassung des Faktenblatts und die Liste der Lücken. Warte, bis der Benutzer antwortet. Fahre nur mit Lücken fort, wenn der Benutzer zustimmt. Eine Seite, die einen fehlenden Fakt benötigt, bleibt außerhalb des Plans oder bleibt ohne diesen Fakt.

Phase 2: Site-Plan

  1. Lies references/site-plan.md.
  2. Führe die Keyword-Recherche für den Markt des Kunden durch.
  3. Kopiere <skill-dir>/assets/site-plan.template.json nach <client-folder>/site-brief/site-plan.json.
  4. Fülle einen Eintrag für jede Seite aus.
  5. Vergleiche den Plan mit dem Angebot, falls vorhanden. Jeder Punkt im Umfang muss eine Seite oder ein Feature haben. Ein Formular im Umfang benötigt server-Hosting oder einen vereinbarten Ersatz.
  6. Führe das Plan-Tor aus. Korrigiere jedes FEHLGESCHLAGEN.
python3 <skill-dir>/scripts/site_gate.py plan <client-folder>/site-brief/site-plan.json

TOR 2. Zeige dem Benutzer eine Tabelle mit diesen Spalten: URL, primäres Keyword, monatliches Suchvolumen, Titel. Gib auch die Hosting-Wahl an. Warte auf die Zustimmung des Benutzers. Schreibe dann die Zustimmung in den Plan als "approved_by" und "approved_on". Das Build-Tor schlägt ohne diese Felder fehl.

Phase 3: Grundgerüst

  1. Wähle den Ordner <client-folder>/website/.
  2. Führe das Grundgerüst-Skript aus. Das Skript funktioniert mit Leerzeichen und Großbuchstaben im Pfad.
bash <skill-dir>/scripts/scaffold.sh "<client-folder>/website" static
  1. Verwende server anstelle von static nur, wenn der Plan ein Server-Feature benötigt (siehe references/launch.md).
  2. Kopiere das genehmigte site-plan.json nach src/lib/site-plan.json.
  3. Ersetze jeden __FILL-Wert in src/lib/site.ts mit einem Wert aus dem Faktenblatt.
  4. Lies die Anleitungen für Metadaten, Bilder, Schriftarten und statische Exporte in node_modules/next/dist/docs/01-app/.

HINWEIS: Next.js ändert sich zwischen Hauptversionen. Die Anleitungen in node_modules passen zur installierten Version. Deine Trainingsdaten tun das nicht.

Phase 4: Designrichtung

  1. Lies references/design-and-copy.md.
  2. Erstelle die Farb- und Schrift-Tokens aus dem Logo. Füge sie in globals.css ein.
  3. Erstelle public/logo.webp, public/og.webp (1200 x 630 Pixel) und src/app/icon.png aus dem Logo.
  4. Baue nur den Header, den Footer und die Startseite.
  5. Starte die Vorschau. Verwende npx serve out -l 3210 für eine statische Website nach einem Build. Verwende npm run dev für eine Server-Website.
  6. Öffne http://127.0.0.1:3210 in einem Browser. Überprüfe die Seite bei 375, 768 und 1280 Pixeln.

HINWEIS: Ein eingebetteter Browser kann HTTP 431 für localhost zurückgeben. Die Adresse 127.0.0.1 hat diesen Fehler nicht.

TOR 3. Zeige dem Benutzer die Startseite. Warte auf die Zustimmung des Benutzers zum Design. Alle anderen Seiten verwenden dieses Design.

VORSICHT: BAUE DIE ANDEREN SEITEN NICHT VOR TOR 3. EINE SPÄTE DESIGNÄNDERUNG FÜHRT ZU EINER MIGRATION ALLER SEITEN.

Phase 5: Seiten

  1. Lies references/seo-build-spec.md.
  2. Lege Inhalte in typisierten Datendateien in src/lib/ ab (z. B. services.ts). Halte die Seitendateien schlank.
  3. Verwende eine dynamische Route mit generateStaticParams für jeden wiederholten Seitentyp.
  4. Hole jeden Titel, jede Beschreibung und jede H1 aus dem Plan mit pageMetadata() und getPage().
  5. Schreibe den Text für den Käufer in der Stimme des Kunden. Verwende nur Fakten aus facts.md.
  6. Füge interne Links gemäß der Spezifikation hinzu.
  7. Baue die Website.
npm run build
  1. Führe das Build-Tor aus. Korrigiere jedes FEHLGESCHLAGEN an seiner Ursache. Ändere NICHT das Tor, um ein Bestehen zu erreichen.
python3 <skill-dir>/scripts/site_gate.py build <client-folder>/website
  1. Führe npx tsc --noEmit und npm run lint aus.

Phase 6: Überprüfung

  1. Überprüfe jeden Seitentyp im Browser bei 375, 768 und 1280 Pixeln.
  2. Überprüfe jeden CTA: Telefon, WhatsApp, E-Mail und Formular.
  3. Falls der Benutzer es wünscht, bereite den Seitentext für den Kunden in einem Dokument vor. Folge references/design-and-copy.md.
  4. Stelle eine Vorschau nur dann bereit, wenn der Benutzer dich dazu auffordert. Ein Vorschau-Build ist nicht indexierbar.

TOR 4. Gib dem Benutzer die Vorschau-URL und das Tor-Ergebnis. Warte auf die Zustimmung des Benutzers zum Launch.

Phase 7: Launch

  1. Lies references/launch.md.
  2. Baue mit SITE_INDEXABLE=1.
  3. Führe das Build-Tor mit --release aus. Das Tor muss bestehen.
  4. Führe die Launch-Schritte in references/launch.md aus.

WARNUNG: VERBINDE DIE DOMAIN NICHT UND PUSHE NICHT IN DIE PRODUKTION OHNE EINE GENEHMIGUNG IN DER AKTUELLEN SITZUNG. DIE LIVE-DOMAIN BEEINTRÄCHTIGT DAS GESCHÄFT DES KUNDEN.

Abschluss

  1. Gib dem Benutzer eine Liste der verbleibenden Kundenaktionen.
  2. Notiere Pfade, Entscheidungen und Erkenntnisse in den Notizen für diesen Kunden.
  3. Teile dem Benutzer mit, dass die Website für SEO-Inhaltsarbeit bereit ist.

Feste Regeln

RegelGrund
Eine URL pro DienstEine Ein-Seiten-Website gibt einem Dienst keine URL, die ranken kann
Ein primäres Keyword pro URLZwei Seiten zu einem Keyword konkurrieren miteinander
Der Plan ist die einzige Quelle für Titel und RoutenDas Tor vergleicht das gebaute HTML mit dem Plan
Keine animierten ZahlenzählerDas HTML zeigt 0, bevor das Skript läuft
Tore sind SkripteJeder Fehler, den die Skripte abfangen, ist zuvor einer Person entgangen

Referenzen

DateiLies sie in
references/brief-intake.mdPhase 1
references/site-plan.mdPhase 2
references/design-and-copy.mdPhase 4 und Phase 6
references/seo-build-spec.mdPhase 5
references/launch.mdPhase 2 (Hosting) und Phase 7

Verwandte Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community