Portfolio-Design

Was macht Portfolio-Design?

Dieser Skill erstellt das spezifische Portfolio-Design für jede Person neu. Das Design ist festgelegt und bereits optimiert. Ihre Aufgabe ist es, das Material der Person zu sammeln, ihren Text in der richtigen Stimme zu verfassen, die Website zu generieren, deren Funktion zu überprüfen und sie nach Freigabe zu veröffentlichen.

Alles befindet sich in diesem Skill-Ordner:

Pfad	Beschreibung
template/assets/	CSS, JavaScript-Module, Schriftarten und Bibliotheken (GSAP, Lenis) der Website. Niemals pro Person bearbeiten: Der Build kopiert und thematisiert sie.
scripts/build.mjs	Erstellt aus einer portfolio.json die fertige statische Website. Node 18+, keine Abhängigkeiten.
scripts/prepare_photos.py	Schneidet das Porträt aus (Hintergrundentfernung) und quadriert das About-Foto.
scripts/discover_github.mjs	Listet die öffentlichen Repos eines GitHub-Benutzers mit README-Taglines und Bannerbildern auf, um Projekte auszuwählen.
scripts/snapshot_github.mjs	Speichert die Liste der öffentlichen Repos, auf die das Archiv zurückgreift.
scripts/render_images.py	Rendert die Share-Karte (og.jpg) und das Touch-Icon.
scripts/serve.py	Lokaler Vorschau-Server für die erstellte Website.
scripts/qa/run_all.py	Browser-Qualitätsprüfungen. Ein Build ist erst fertig, wenn er diese besteht.
examples/portfolio.example.json	Vollständige Konfiguration für eine fiktive Person mit Platzhalterbildern.
reference/	Konfigurationsschema, Interview-Skript, Designsystem, Kopierregeln, QA-Prüfungen, Bereitstellungsanleitung.

In den folgenden Befehlen bedeutet scripts/... den Ordner dieses Skills (verwenden Sie den absoluten Pfad beim Ausführen) und portfolio/... ist der Projektordner der Person in ihrem Arbeitsverzeichnis.

Lesen Sie reference/config-schema.md, bevor Sie eine Konfiguration schreiben, und reference/copywriting.md, bevor Sie Texte verfassen.

Grundregeln

• Nichts wird ohne klares Ja veröffentlicht. Kein git push, kein Deployment, keine Repository-Erstellung, bevor die Person diesen Schritt genehmigt. Bauen und Vorschau lokal ist in Ordnung.
• Datenschutz. Es werden nur öffentliche GitHub-Daten verwendet (beide GitHub-Skripte rufen absichtlich die nicht authentifizierte API auf). Bevor das Archiv live geht, zeigen Sie die Liste der öffentlichen Repos an, die es anzeigen wird, und fragen Sie, welche ausgeblendet werden sollen. Geben Sie niemals Telefonnummern, Privatadressen oder private Repos auf der Seite an, es sei denn, die Person wünscht dies.
• Die Fotos bleiben Eigentum der Person. Arbeiten Sie mit Kopien im Projektordner. Laden Sie sie nirgendwo hoch, außer auf die von ihr genehmigte Website.
• Das Design ist das Produkt. Fügen Sie keine Abschnitte hinzu, tauschen Sie keine Schriftarten aus oder gestalten Sie Komponenten neu, nur weil eine Person etwas Vages wünscht. Passen Sie Inhalte, Themenvorgabe, Maskottchen und Texte an. Wenn die Person etwas Strukturelles wünscht, sagen Sie, was es kosten würde, und bestätigen Sie es zuerst.
• Kopie wird geschrieben, nicht ausgefüllt. Die Notizen der Person sind Rohmaterial. Verfassen Sie jede Zeile in ihrer Stimme, halten Sie sich an die Längenvorgaben und zeigen Sie es ihr vor dem endgültigen Build.

Arbeitsablauf

1. Überprüfen Sie die Werkzeugkette

node --version          # 18 oder neuer
python --version        # 3.10 oder neuer
python -m pip install playwright pillow numpy
python -m playwright install chromium

Die Hintergrundentfernung für das Porträt benötigt python -m pip install "rembg[cpu]" (lädt beim ersten Start ein ~1 GB großes Modell herunter). Falls das nicht möglich ist, bitten Sie um ein Porträt mit bereits transparentem Hintergrund und verwenden Sie --no-cutout.

Vereinbaren Sie mit der Person einen Projektordner (Standard: ./portfolio/ im aktuellen Verzeichnis). Layout:

portfolio/
  portfolio.json      # die von Ihnen geschriebene Konfiguration
  photos/             # die Originalfotos (werden nie wie veröffentlicht)
  work/               # Projektbanner und Screenshots
  site/               # Build-Ausgabe: Dieser Ordner wird deployed

2. Interview

Folgen Sie reference/interview.md. Es läuft in zehn kurzen Runden und verwendet AskUserQuestion für jede Wahl mit sinnvollen Optionen (Thema, Maskottchen, welche Repos hervorgehoben werden, welche Links in der Heldensektion platziert werden). Freiform-Material (Biografie-Notizen, Projektbeschreibungen) wird als Klartext angefragt. Fragen Sie eine Runde nach der anderen und bieten Sie an, alles zu entwerfen, was die Person nicht selbst schreiben möchte.

Bereiche, in der Reihenfolge:

1. Identität: vollständiger Name, der Alias oder Handle, unter dem sie bekannt ist, ein kurzer Titel, E-Mail, Stadt und Land (Zeitzone für die Live-Uhr), Sprachen.
2. Fotos: ein Kopf-Schulter-Porträt (der Hero-Ausschnitt) und ein optionales zweites Foto für den About-Bereich.
3. Links: jedes Profil, das aufgelistet werden soll; wählen Sie zwei bis vier für die Heldensektion aus.
4. Hero und About: Was sie in einem Satz tun, dann zwei kurze Absätze darüber, wie sie arbeiten.
5. Was sie bauen: vier Arten von Arbeit, je ein Wort, mit einer Beschreibungszeile und einer Hover-Animation (agents, automation, context, launch, code, data, design).
6. Projekte: bis zu sechs vorgestellte Projekte und bis zu drei Nebenprojekte. Führen Sie zuerst discover_github.mjs aus und schlagen Sie Kandidaten vor.
7. Archiv: ob alle öffentlichen Repos angezeigt werden sollen und welche ausgeblendet werden sollen.
8. Stack: gruppierte Werkzeuglisten und die 12 bis 24 Werkzeuge, die zu Kugeln in der Ball-Pit werden.
9. Prozess, Kontakt, Bänder: drei Prozessschritte, die Kontaktzeile, die zwei scrollenden Bandstreifen.
10. Aussehen und Extras: Themenvorgabe, Maskottchen (Name, Stimme oder aus), Site-URL und wo sie gehostet wird.

3. Projektmaterial sammeln

node scripts/discover_github.mjs --user <github-user> --out portfolio/discovery.json
node scripts/discover_github.mjs --user <github-user> --out portfolio/discovery.json --download portfolio/work --repos RepoA,RepoB

Der erste Durchlauf listet öffentliche Repos mit README-Tagline, Bilder und Live-Links auf. Der zweite speichert das erste README-Bild jedes ausgewählten Repos. Jedes vorgestellte Projekt benötigt mindestens ein Vorschaubild. Gute Quellen, in der Reihenfolge: das README-Banner, ein Screenshot der Live-App (verwenden Sie Playwright bei 1600x900), ein generiertes Banner im Stil von examples/assets/*.svg. Überprüfen Sie jedes Bild: keine Geheimnisse in Screenshots, nichts verschwommen, Breitbildformat (16:9 oder ähnlich).

4. Fotos vorbereiten

python scripts/prepare_photos.py --portrait portfolio/photos/portrait.jpg \
  --about portfolio/photos/about.jpg --about-gray --out portfolio/photos/out

Öffnen Sie das Ergebnis und betrachten Sie es. Der Ausschnitt muss saubere Kanten haben, keine durchsichtigen Stellen und der Kopf nahe der Oberseite. Wenn das About-Foto ein Gesicht schlecht zuschneidet, führen Sie es mit --about-focus x,y erneut aus (0 bis 1 Bruchteile des Bildes). Zeigen Sie im Konfigurationsfeld person.photos.portrait und .about auf die Dateien in out/.

5. Konfiguration schreiben und bauen

Schreiben Sie portfolio/portfolio.json (Schema: reference/config-schema.md; funktionierendes Beispiel: examples/portfolio.example.json). Pfade darin sind relativ zur Konfigurationsdatei. Dann:

node scripts/build.mjs --config portfolio/portfolio.json --out portfolio/site
node scripts/snapshot_github.mjs --user <github-user> --site portfolio/site   # nur wenn das Archiv aktiv ist
python scripts/render_images.py --site portfolio/site

Der Build stoppt mit einer klaren Meldung, wenn ein erforderliches Feld fehlt. Warnungen zu unbekannten Symbolen bedeuten, dass die Kugel ihren Namen als Text anzeigt; wählen Sie einen Slug aus data/simple-icons.json oder lassen Sie es.

6. Vorschau

Stellen Sie die Website im Hintergrund bereit und geben Sie der Person die URL:

python scripts/serve.py --site portfolio/site --port 4321

Verwenden Sie diesen Server und nicht python -m http.server: Der Standard-Server bricht Verbindungen ab, wenn die Seite viele Dateien gleichzeitig anfordert, was als zufällige QA-Fehler erscheint. Er sendet auch No-Cache-Header (ein Neubuild wird beim Aktualisieren angezeigt) und liefert 404.html für unbekannte Pfade wie bei GitHub Pages.

7. Qualitätsprüfungen

python scripts/qa/run_all.py --url http://127.0.0.1:4321/ --out portfolio/qa

Alle Prüfungen müssen bestanden werden (reference/quality-gates.md erklärt jede einzelne und wie die üblichen Fehler behoben werden). Betrachten Sie dann die Screenshots in portfolio/qa/shots/ selbst, Abschnitt für Abschnitt, Desktop und Telefon. Automatisierte Prüfungen erkennen Kollisionen und Überläufe; Ihre Augen erkennen ungünstige Zeilenumbrüche, schwache Bilder und falsch klingende Texte. Korrigieren, neu bauen, erneut prüfen. Führen Sie --full einmal vor dem Deployment aus.

8. Überprüfung mit der Person

Führen Sie sie durch die Vorschau: Hero, About, Reihen, Projekte, Archiv, Pit, Prozess, Kontakt, Maskottchen-Chat. Sammeln Sie Änderungen, wenden Sie sie auf die Konfiguration an (nicht auf die erstellten Dateien), bauen Sie neu und führen Sie die QA erneut aus.

9. Deployment (nur nach einem klaren Ja)

Folgen Sie reference/deploy.md: GitHub Pages (Benutzerseite oder Projektseite), benutzerdefinierte Domain und die relevanten Cloudflare-Einstellungen. Führen Sie nach dem Deployment die Live-Checks durch:

python scripts/qa/run_all.py --url https://ihre-domain/ --only smoke,live --out portfolio/qa-live

Wenn die Prüfung „E-Mail nicht umgeschrieben“ fehlschlägt, ist Cloudflares Email Address Obfuscation aktiv und unterbricht den „Let's talk“-Ring; die Lösung finden Sie in reference/deploy.md.

Spätere Änderungen

Bearbeiten Sie portfolio.json, bauen Sie neu, führen Sie QA erneut aus, deployen Sie erneut. Jeder Build stempelt neue ?v=-Versionsstrings auf jedes Asset, sodass Browser und CDNs die Änderung ohne manuelle Cache-Leerung übernehmen.