Portfolio One Shot

Was macht Portfolio One Shot?

Zweck

Ein Verzeichnis echter Arbeit in ein Portfolio verwandeln, das geöffnet, von Maschinen gelesen und unabhängig überprüft werden kann – ohne dass das Modell eine einzige Zeile erfundenen Projekttextes schreibt.

Die drei Grundsätze, in der Reihenfolge ihrer Priorität:

1. Null Erfindung. Jede angezeigte Tatsache muss auf eine Datei, einen README-Auszug oder einen vom Benutzer gelieferten Wert zurückgehen. Fehlende Felder werden als sichtbare Lücken dargestellt. Erfinde niemals Projektnamen, Rollen, Metriken, Kunden, Zitate, Ergebnisse oder Bilder.
2. Unabhängige Verifikation. Führe den Verifizierer auf der Ausgabe aus, bevor du den Erfolg meldest. Liste zuerst Fehlschläge, dann bestandene Prüfungen. Präsentiere niemals eine grüne Kriterienliste als Beweis dafür, dass das Portfolio gut aussieht – die visuelle Beurteilung gehört dem Benutzer, mit eigenen Augen.
3. Ein Befehl. all führt Scan → Konfiguration → Bau → Verifikation durch. Ein zweiter Befehl ist ein Fehler, kein Workflow.

Wann verwenden

• Der Benutzer sagt „一键生成作品集 / 做个作品集 / 把我的项目做成作品集 / build a portfolio from this folder“.
• Der Benutzer übergibt ein Verzeichnis mit Bildern, Videos oder Projektordnern und möchte diese präsentiert haben.
• Der Benutzer möchte ein Portfolio nach dem Hinzufügen oder Entfernen von Arbeiten neu generieren.
• Der Benutzer möchte prüfen, ob ein existierendes Portfolio fehlende Nachweise enthält.

Nicht verwenden, wenn der Benutzer eine dekorative Demo-Seite mit erfundenen Inhalten, einen bestimmten künstlerischen visuellen Stil oder eine Integration mit einer gehosteten Plattform wünscht. Das sind andere Aufgaben. Wechsle in diesem Fall nicht stillschweigend zu den Null-Erfindungs-Regeln dieses Skills – sprich den Unterschied laut aus.

Der eine Befehl

python scripts/portfolio.py all <QUELLVERZEICHNIS> --out <AUSGABEVERZEICHNIS> --mode <case_study|gallery>

Beispiel:

python scripts/portfolio.py all "C:/work/my-projects" --out "C:/work/portfolio-dist" --mode gallery

Der Befehl schreibt index.html, portfolio.txt, portfolio.md, projects.json, assets/, build-report.json und verify-report.md in das Ausgabeverzeichnis und gibt dann das Verifizierer-Urteil aus. Öffne index.html für den Benutzer mit dem Dateipräsentationstool. Setze das visuelle Ergebnis an die erste Stelle der Liste.

Um nach Bearbeitung von projects.json durch den Benutzer nur build und verify erneut auszuführen:

python scripts/portfolio.py build <AUSGABEVERZEICHNIS>/projects.json --out <AUSGABEVERZEICHNIS> --mode gallery
python scripts/portfolio.py verify <AUSGABEVERZEICHNIS>

Arbeitsablauf

Phase 0 · Entscheide den Modus, nicht stillschweigend raten

Es gibt zwei Modi, weil die Recherche ergeben hat, dass die beiden Bereiche gegensätzliche Anforderungen haben (siehe references/content-spec.md §Domänenaufteilung).

Modus	Für	Textdichte	Layout
case_study	UX, Produkt, Design, Ingenieurwesen, Forschung	Lange Erzählung; sieben erforderliche Feldgruppen	Ein Projekt pro Abschnitt, Bilder eingestreut
gallery	Game Art, Illustration, Concept Art, Fotografie, Animation	Minimale Worte; lass die Arbeit sprechen	Bildorientiertes Raster, Lightbox bei Klick

Wenn der Benutzer keine Wahl getroffen hat, leite aus dem Material ab und teile die Ableitung in einem Satz vor der Ausführung mit – lass dann ein Wort des Benutzers die Entscheidung überschreiben. Entscheide niemals automatisch über das Portfolio eines anderen.

Phase 1 · Echtes Material scannen

scan zählt Unterverzeichnisse als Projekte auf. Für jedes Projekt zeichnet es auf:

• Verzeichnisname als Projekt-Titel-Kandidat (eine Tatsache, keine Erfindung).
• Jede Bild- und Videodatei mit Byte-Größe, SHA-256-Präfix und Pixeldimensionen.
• Den ersten Absatz von README.md / project.md / about.md als wörtlichen summary-Kandidaten, mit einem _sources-Eintrag, der Datei und Zeilenbereich nennt.
• Eine missing-Liste der Felder, die keine Datei liefern konnte.

Dateien mit unbekannten Erweiterungen bleiben in manifest.json als unclassified erhalten, anstatt verworfen zu werden. Lösche, benenne um, verschiebe oder verändere niemals Quelldateien. Schreibe nur in das Ausgabeverzeichnis.

Phase 2 · Bauen

build liest projects.json (Schema in references/config-schema.md) und erzeugt:

• index.html – Helles Design, responsive, System-Schriftstapel, keine CDN-Abhängigkeiten, keine blitzenden Vorlagen. Jedes <img> trägt alt, width, height, loading="lazy". Bilder verwenden relative Pfade unter assets/.
• portfolio.txt – Klartext-Projektzusammenfassung zur ATS-Analyse und zum Kopieren/Einfügen in einen Lebenslauf.
• portfolio.md – Dieselben Fakten als Markdown für README oder E-Mail.
• Ein sichtbares Warnbanner, das genau angibt, wie viele Felder fehlen, sodass ein Gerüst niemals mit einem fertigen Portfolio verwechselt werden kann.

Wenn --embed gesetzt ist, binde nur Bilder unter 10 KB als Base64 ein und behalte größere extern; gib eine Warnung für jede Datei aus, die den Schwellenwert überschritten hätte. Base64 vergrößert die Nutzlast um etwa 33 Prozent und kann nicht lazy-geladen werden – siehe references/content-spec.md §Bildrichtlinie.

Phase 3 · Vor der Meldung verifizieren

verify prüft Feldvollständigkeit, Bild-Existenz und Dekodierbarkeit, sinnvollen Alt-Text, Abwesenheit von Platzhalter-Bild-Hosts, Link-Form, HTML-Struktur und Klartext-Parität. Es schreibt verify-report.md mit Fehlschlägen zuerst, Bestandenen danach, dann Einschränkungen / Nicht verifiziert.

Exit-Code 1 bedeutet, dass rote Einträge existieren. Melde dies ehrlich. Bearbeite die Kriterien nicht, um sie bestehen zu lassen, wiederhole keinen fehlschlagenden Generierungskanal und verstecke keine Einschränkung.

Für eine Positiv-/Negativkontrolle führe python scripts/portfolio.py verify <verz> --self-test aus – es erstellt ein absichtlich defektes Projekt und ein vollständiges Projekt im Speicher und bestätigt, dass der Verifizierer das erste markiert und das zweite durchlässt. Wenn die Negativkontrolle grün besteht, ist der Verifizierer defekt; repariere den Verifizierer, nicht die Testdaten.

Phase 4 · Übergeben

Präsentiere zuerst index.html, damit der Benutzer es öffnen kann, dann verify-report.md, dann projects.json. Gib in der Textantwort das Urteil, die genaue Anzahl fehlender Felder und den nächsten einzelnen Schritt an (befülle projects.json). Behaupte nicht, dass das Portfolio gut aussieht. Behaupte nicht, dass es versandbereit ist, solange das Warnbanner vorhanden ist.

Null-Erfindungs-Vertrag

Harte Regeln, alle abgeleitet von dokumentierten Fehlermodi in references/content-spec.md:

• Schreibe niemals Projektprosa, Bildunterschriften, Rollen, Metriken, Ergebnisse, Gutschriften oder Kundennamen, die in der Eingabe fehlen. Ein fehlendes Feld wird als [FEHLT: Feld] dargestellt – auffällig, niemals stillschweigend leer, niemals in einen plausiblen Satz umschrieben.
• Verwende niemals Platzhalter-Bild-Hosts (picsum.photos, placehold.co, lorem, Stock-URLs) als Ersatz für echte Arbeit. Ein Projekt ohne Bilder zeigt einen expliziten leeren Medienblock.
• Zitiere niemals eine Metrik ohne einen _sources-Eintrag. Wenn der Benutzer eine Metrik liefert, zeichne source: "user-supplied" auf; mache sie nicht zu „verifiziert“.
• Erfinde niemals einen Studionamen, eine persönliche Biografie oder Kontaktdaten. Lasse sie leer und liste sie als Fehlschläge auf.
• Wenn eine README verwendet wird, kopiere den Absatz wörtlich und zeichne seine Datei und seinen Zeilenbereich auf. Poliere, kürze oder schreibe ihn nicht um.
• Präsentiere KI-gestützte Formulierungen nicht als eigene Entscheidungsfindung des Benutzers. „Prozess“- und „Reflexions“-Felder bleiben leer, bis der Benutzer sie liefert.

Multi-Versions-Ausgabe

Dieselbe projects.json unterstützt zielgerichtete Versionen. Füge eine select-Liste mit Projekt-IDs hinzu oder übergib --only id1,id2 an build, um eine Version zu erstellen, die auf ein Publikum ausgerichtet ist. Eine Neuanordnung ist eine Konfigurationsänderung, niemals eine automatische Umschreibung. Dies folgt der dokumentierten Aufteilung zwischen einer Website zur Entdeckung und einem PDF oder Deck für Bewerbungen.

Fallstricke

• Beurteile nicht anhand eines Fragments. Lies die gesamte README, das gesamte projects.json und den gesamten Verifiziererbericht, bevor du etwas als vollständig oder defekt einstufst.
• Bestandene Kriterien sind keine Qualität. Ein grüner Verifizierer bedeutet, dass die Dateistruktur in Ordnung ist. Ästhetik erfordert die Augen des Benutzers.
• Fülle keine Lücken, um die Seite fertig aussehen zu lassen. Eine sichtbar unvollständige Seite ist die korrekte Ausgabe, wenn der Benutzer die Fakten nicht geliefert hat.
• Berühre keine persönlichen Verzeichnisse. Scan ist auf der Quelle schreibgeschützt. Alle Schreibvorgänge gehen in das Ausgabeverzeichnis.
• Wachse nicht in die PDF-Generierung, das Hosting oder den GitHub-API-Zugriff hinein. Diese benötigen eine explizite Entscheidung des Benutzers.
• Bildabmessungen sind wichtig. Das Ausgeben von width und height verhindert Layout-Verschiebungen. Wenn Pillow nicht verfügbar ist, falle auf Header-Parsing zurück und gib eine sichtbare Warnung aus; verschlechtere niemals stillschweigend die Qualität.
• Ein Ordner ist ein Projekt. Wenn das Material des Benutzers flach ist, frage nach einer Gruppierung oder verwende --flat, um ein Projekt zu erstellen, das alle Medien enthält. Erfinde keine Gruppierungen.

Ressourcen

Pfad	Rolle
scripts/portfolio.py	Einzelnes CLI: scan, build, verify, all, --self-test. Standardbibliothek plus optionales Pillow.
references/content-spec.md	Forschungsgestützte Inhaltsregeln, Domänenaufteilung, Bildrichtlinie und Quell-URLs. Lade, bevor du Felddefinitionen oder Vorlagen änderst.
references/config-schema.md	Vollständiges projects.json Schema, Feldbedeutungen und was als Quelle zählt.
assets/template.html	Helles, responsives Template mit beiden Modi. Ersetze nur {{TOKEN}}-Platzhalter; schreibe das CSS nicht um, um ein bestimmtes Aussehen zu erzielen.
assets/projects.sample.json	Eine klar gekennzeichnete DEMO-Konfiguration. Versende sie niemals als das echte Portfolio des Benutzers.