Portfolio-Builder

Was macht Portfolio-Builder?

Verwandelt die Arbeit einer Person in ein einseitiges Portfolio. Claude plant den Inhalt im Chat, fixiert ihn in einer BRIEF.md und übergibt dann Claude-Code-Prompts. Claude Code baut lokal, pusht zu GitHub, Netlify deployed. Claude prüft dann das Repo und die Live-Website.

Schreibregeln für alles, was dieser Skill produziert: lockerer, direkter Ton, kurze Sätze, keine Gedankenstriche (nur normale Bindestriche).

Phase 1: Sammeln, bevor fragen

• Ziehen, was bereits bekannt ist: Gedächtnis, frühere Chats, Live-Websites (diese abrufen, um echte Feature-Listen und Texte zu erhalten).
• Zuerst eine Inhaltsinventur erstellen. Niemals mit einem leeren Fragebogen beginnen.

Phase 2: Brief-Entwurf v1 erstellen, dann maximal 4 Entscheidungen erfragen

Abschnitte mit echten Texten entwerfen, dann nur das erfragen, was den Build verändert:

1. Primäres Publikum (Kunden, Personalverantwortliche oder beides, und welches führt).
2. Sichtbarkeitseinschränkungen (aktueller Arbeitgeber namentlich genannt oder allgemein; alles, was privat bleiben soll).
3. Welche Projekte aufgenommen werden.
4. Wo es lebt (Netlify-Subdomain zu Beginn ist in Ordnung).

Leitplanken:

• Keine erfundenen Metriken, Erfahrungsberichte oder Kunden.
• Keine Behauptungen, die die Person nicht aufgestellt hat (z. B. KI-Arbeit im Hauptjob, die sie nicht gemacht hat).
• Teamerfolge werden als Teamerfolge gutgeschrieben.
• Wenn der Arbeitgeber allgemein bleibt, auch Details weglassen, die ihn trotzdem identifizieren (Länderlisten, genaue Titel plus Branche). Statt der Liste „fünf Märkte“ schreiben.
• Regionale Formulierungen beachten (z. B. „asiatische Märkte“, wenn ein Land Kontinente umspannt) und vage Pronomen im Helden-Text.

Projektaufnahmeregel: Ein Projekt verdient einen Platz, wenn es live ist und eine Fähigkeit zeigt, für die das Publikum bezahlen würde. Zu viele Unternehmungen signalisieren „keine Zeit für dich.“ Abgestellte oder vergangene Arbeiten kommen in eine kleine Zeile „Aus dem Labor“, ehrlich gekennzeichnet. Unbenannte oder nicht gestartete Projekte warten.

Werkzeuge: Nur Werkzeuge auflisten, die praktisch eingesetzt wurden. Werkzeuge, mit denen die Person nur vertraut ist, kommen in eine einzeilige Fußnote („Auch vertraut mit X und Y“).

Phase 3: Lücken füllen

Erfragen nach: Anzeigename, Kopfschuss, ein Screenshot pro Build, Live-URLs, GitHub-URL, Kontakt-E-Mail, Socials. Jeden bereitgestellten Website-Text so umschreiben, dass er portfolio-gerecht ist (was es ist, für wen es ist, was sie gebaut haben). Jeder Karten-Link muss auf eine Live-Seite verweisen, die dieses Element tatsächlich beschreibt. Wenn die Seite nicht bereit ist, kein Link und mit Tag versehen (z. B. „Startet“). Alles verschieben, was noch nicht bereit ist (Buchungslink, „Arbeiten Sie mit mir“, Erfahrungsberichte) auf eine „Später“-Liste, anstatt v1 zu blockieren.

Phase 4: BRIEF.md sperren

BRIEF.md mit diesen Abschnitten in dieser Reihenfolge schreiben:

• Ziel (10-Sekunden-Test: was sie bauen, Nachweis, wie man sie erreicht)
• Publikum
• Regeln für Texte (Stimme, keine Gedankenstriche, Sichtbarkeits- und Genauigkeitsleitplanken, Texte wie geschrieben verwenden)
• Technik (reines HTML/CSS/vanilla JS, kein Build-Schritt; index.html, styles.css, main.js, /assets; GitHub + Netlify; Lighthouse 95+; mobil zuerst)
• Designrichtung (standardmäßig Apple-ähnlich: Inter- oder System-Schriftart, großzügiger Weißraum, ~1080px maximale Breite, ~680px Textblöcke, enge große Überschriften, neutrale Palette, 20-24px Kartenradius, hauchdünne Rahmen, ein Akzent sparsam verwendet, hell/dunkel mit Umschalter, subtiles Einblenden unter Berücksichtigung von reduzierter Bewegung, Screenshots in einem minimalistischen Browserrahmen-Karte, klebrige verschwommene Navigation)
• Layoutregeln (von Anfang an einbauen):
  • Navigation und jeder Abschnitt teilen einen Container, sodass alle linken Kanten ausgerichtet sind.
  • Ein Abschnittsabstand-Token (etwa 96px Desktop, 56px Mobil) für jede Lücke; keine gestapelten Abstände.
  • Held passt über den Falz auf 1366x768 und 375x812 inklusive Browser-Symbolleisten (etwa 650px und 635px sichtbar).
  • Überschrift: text-wrap pretty auf Mobil, balance auf Desktop; keine erzwungenen Zeilenumbrüche.
  • Jeder Abschnitt hat eine sichtbare Überschrift oder Etikett, sodass nichts schwebt.
• Assets (exakte Dateipfade; Screenshots in WebP konvertiert mit kleineren Mobilgrößen, Lazy-Loading unterhalb des Falzes; Platzhalter falls fehlend, niemals ein defektes Bild)
• Seiteninhalt, von oben nach unten, mit endgültigen Texten: Held, Was ich mache (3 Karten), Bauten (vorgestellte Karte + Raster + Laborzeile), Wie ich baue, Werkzeuge (gruppierte Pills), Hintergrundstreifen, Prinzipien (in den eigenen Worten der Person, keine geliehenen Zitate), Kontakt, Fußzeile
• SEO und Meta (Titel, Beschreibung, OG-Bild, Favicon, semantisches HTML, Alt-Text, Fokus-Zustände, AA-Kontrast)
• Vorausgefüllte Details: Repo-URL, bevorzugte Subdomain plus Fallback, Social-Handles, E-Mail, sodass Claude Code nicht fragen muss
• Später (nicht in v1)

Akzentfarbe: eine auswählen, die sich von den Farben in den Build-Screenshots unterscheidet. Exakte Hex-Werte für hellen und dunklen Modus angeben und AA-Kontrast für Links UND Schaltflächentext auf dem Akzent in beiden Modi prüfen (dunkle Modus-Schaltflächen benötigen normalerweise dunklen Text auf hellem Akzent).

BRIEF.md als Datei ausliefern.

Phase 5: Setup-Schritte + 4 Prompts

Setup (einmalig):

1. Ein leeres GitHub-Repo erstellen, dann git clone <Repo-URL> in einen lokalen Ordner, damit Git bereits verbunden ist.
2. BRIEF.md in das Root-Verzeichnis legen; /assets und /assets/shots mit den benannten Dateien hinzufügen.
3. Claude Code in diesem Ordner öffnen.

Prompt 1, Planung:

Lies BRIEF.md vollständig. Schreibe noch keinen Code.
Gib mir einen kurzen Build-Plan: Dateistruktur, abschnittsweises Layout, die Farb-Token und Schriftgrößenskala, die du verwenden wirst, und alle Fragen oder Konflikte, die du im Brief siehst. Halte es unter einem Bildschirm.
Akzentfarbe: <LIGHT_HEX> im hellen Modus, <DARK_HEX> im dunklen Modus. Verwende sie sparsam und bestätige, dass beide den AA-Kontrast bestehen, einschließlich Schaltflächentext.

Hilf der Person, ihre Fragen in einer kopierbaren Antwort zu beantworten.

Prompt 2, Bauen:

Baue die Website genau nach BRIEF.md und dem vereinbarten Plan.
- Verwende die Texte wortwörtlich. Keine Gedankenstriche.
- Reines HTML, CSS, vanilla JS. Keine Frameworks, kein Build-Schritt.
- Akzent: <LIGHT_HEX> hell, <DARK_HEX> dunkel. Alles andere neutral.
- Folge den Layoutregeln in BRIEF.md (gemeinsamer Container, ein Abstands-Token, Held über dem Falz).
- Verwende die Bilder in /assets als WebP. Zeige einen sauberen Platzhalter, falls eines fehlt.
- Hellen und dunklen Modus, klebrige verschwommene Navigation, Einblenden beim Scrollen mit Unterstützung für reduzierte Bewegung.
Wenn fertig, starte einen lokalen Server und gib mir die URL, damit ich sie überprüfen kann.

Prompt 3, Verfeinern:

Überprüfe die Website wie ein leitender Designer bei Apple, behebe dann, was du findest:
1. Überprüfe bei 375px, 768px, 1366px und 1440px. Kein horizontales Scrollen, nichts gequetscht.
2. Alle linken Kanten sind ausgerichtet; jeder Abschnittsabstand verwendet das eine Abstands-Token.
3. Held passt über den Falz mit Browser-Symbolleisten bei 1366 und 375.
4. Dunkler Modus wirkt beabsichtigt, nicht invertiert. Akzent liest sich gut in beiden Modi.
5. Barrierefreiheit: Alt-Text, Fokus-Zustände, AA-Kontrast, semantische Überschriften.
6. Durchsuche alle Dateien nach Gedankenstrichen und ersetze sie.
7. Führe Lighthouse aus und bringe alle vier Werte auf 95+.
Gib mir eine kurze Liste, was du geändert hast.

Dann gibt die Person Feedback in Alltagssprache, bis sie zufrieden ist.

Prompt 4, Pushen und deployen:

Dieser Ordner ist bereits von <REPO_URL> geklont.
1. Füge eine .gitignore und eine netlify.toml hinzu (publish dir = root, sinnvolle Cache-Header und 404 für BRIEF.md und Quell-PNGs, damit sie nicht öffentlich sind).
2. Committe alles mit einer klaren Nachricht und pushe auf main.
3. Verbinde das Repo mit Netlify. Versuche zuerst <SUBDOMAIN>, Fallback <FALLBACK>. Wenn die Netlify GitHub-App das Repo nicht sehen kann, sage mir, wie ich Zugriff gewähre.

Hinweis: Claude Code läuft oft voraus und macht Bauen, Verfeinern und Deployen in einem Durchgang. Das ist in Ordnung; überspringe zum Audit.

Phase 6: Audit nach dem Push

Wenn das Repo oder die Live-URL geteilt wird:

1. Repo klonen und prüfen: Texte stimmen mit BRIEF.md überein, nichts erfunden, keine Gedankenstriche, keine eingeschränkten Namen, alle Links korrekt, Bilder WebP mit Alt-Text und Größen, Meta/OG/Favicon vorhanden, interne Dateien von der Live-Seite blockiert.
2. Visuelle Prüfung der Live-Seite im Browser bei 1440 und 1366 (hell) und 375 (dunkel): Kantenausrichtung, Konsistenz der Abstände, Held über dem Falz, Überschriftenumbruch, nichts überlappend.
3. Korrekturen als einen kopierbaren Claude-Code-Prompt geben, dann nach dem Push erneut prüfen. Wenn das Repo leer ist, dies deutlich sagen und bitten, zuerst zu pushen.

Bekannte Fallstricke:

• Netlify fügt auf Free-Plan-Projekten, die nach dem 19. August 2026 erstellt wurden, ein „Powered by Netlify“-Badge hinzu. Es ist nicht im Code: Deaktivieren unter Projektkonfiguration > Allgemein > Powered by Netlify Badge, pro Projekt.
• Live-Lighthouse-Werte variieren bei langsamen Verbindungen; mit pagespeed.web.dev beurteilen, nicht nur mit lokalen Läufen.

Phase 7: Restliche Präsenz synchronisieren

Anbieten, das GitHub-Profil-README (und andere Biografien) mit dem Portfolio abzugleichen: gleiche Positionierungszeile, gleiche Kontakt-E-Mail, Links zu den Live-Builds und dem Portfolio, und Projekte entfernen, die das Portfolio bewusst ausgelassen hat.