maumoya/pro-portfolio-dev

PRO Portfolio DEV

GitHub-Nutzer rein, Live-Portfolio raus. Die Skripte übernehmen das Abrufen, Bauen, Prüfen und Veröffentlichen; Du machst das Eine, was sie nicht können: Wähle die Projekte aus und schreibe ehrliche, einprägsame Texte. Pfade sind relativ zum Ordner dieses Skills. Arbeite in einem temporären Ordner, z.B. portfolio/.

1 · Abrufen (nur Fakten)

python3 scripts/fetch.py USER --out portfolio/repos.json (2 öffentliche API-Aufrufe, kein Token). Es gibt die wichtigsten Repos aus. Dies sind die einzigen Fakten, die du verwenden darfst; erfinde niemals Sterne, Benutzer oder Ergebnisse.

2 · Planen (fragen, dann portfolio/plan.json schreiben)

Frage in einer Nachricht, mit Standardwerten, die der Nutzer durch Sagen von "los" akzeptieren kann:

• Wer und für wen: Name, Rolle, Zielgruppe (Personalvermittler, Kunden, Kollegen). Standard: GitHub-Name und Bio.
• Projekte: Schlage die 4-9 stärksten vor (Sterne, letzte Updates, eine Homepage, eine klare Beschreibung); sie wählen aus.
• Fähigkeiten und Erfahrungen zur Suchbarkeit (optional) und Kontaktlinks.
• Wo es lebt: USER.github.io (Wurzelverzeichnis) oder der docs/-Ordner eines Repos. Die URL muss endgültig sein.

Dann schreibe plan.json (Schema und Textregeln: references/plan.md). Textregeln in Kürze: Überschrift ≤8 Wörter, Tagline sagt was + für wen, jedes Projekt bekommt einen einzeiligen Pitch (den Nutzen, nicht den Stack) und eine optionale proof-Zeile, die eine Zahl aus der README oder den GitHub-Daten dieses Repos zitiert, niemals eine selbst erfundene.

Sprachen: UI-Zeichenketten für 10 Sprachen sind in scripts/ui.json enthalten. Um den eigenen Text des Nutzers zu übersetzen, füge plan.t.<lang> hinzu und übersetze sinngemäß, so wie ein Muttersprachler es in dieser Sprache sagen würde, nicht Wort für Wort (siehe references/plan.md, "Übersetzen"). Lies dann jede Sprache einmal als Muttersprachler und korrigiere alles, was wörtlich klingt.

3 · Bauen und prüfen

python3 scripts/build.py portfolio/repos.json portfolio/plan.json --out portfolio/site
python3 scripts/check.py portfolio/site

check.py muss PASS ausgeben. Öffne portfolio/site/index.html im Browser und sieh es dir an, bevor du veröffentlichst: Probiere die Suche mit einem Tippfehler, wechsle zu Arabisch (von rechts nach links) und einem dunklen Design.

4 · Veröffentlichen (nach außen: vorher fragen)

Zeige dem Nutzer die Seite und das Ziel und hole ein Ja ein. Dann: bash scripts/publish.sh portfolio/site REPO_CLONE URL [--folder root|docs] --yes Es comittet, pusht, aktiviert Pages bei Bedarf und fragt ab, bis der neue Build live ist, und gibt LIVE … in N s aus.

5 · Messen und berichten

Berichte in ≤4 Zeilen: die Live-URL, die LIVE-Zeit, das check.py-Ergebnis und Lighthouse SEO / Barrierefreiheit / Performance von PageSpeed Insights (pagespeed.web.dev, kostenlos) oder einem lokalen lighthouse, falls installiert.

Fertig, wenn

• check.py PASS auf der gebauten Seite ausgibt.
• Jedes Projekt auf der Seite ein echtes Repo des Nutzers ist und jede darin enthaltene Zahl auf GitHub-Daten oder eine README zurückgeht.
• Die Live-URL den neuen Build zurückgibt (publish.sh hat LIVE ausgegeben) oder der Nutzer sich gegen eine Veröffentlichung entschieden hat.

Niemals

• Projekte, Kennzahlen, Arbeitgeber oder Testimonials erfinden. Stattdessen fragen.
• Pushen, veröffentlichen oder Pages aktivieren ohne das Ja des Nutzers.
• Tracker, Analytics, Cookies oder externe Skripte hinzufügen. Die Seite stellt keine Drittanbieter-Anfragen.
• Eine bestehende Seite überschreiben, ohne zu zeigen, was sich ändert (publish.sh ohne --yes ist der Trockenlauf).