Projekt-Präsentations-Skill

Was macht Projekt-Präsentations-Skill?

Dieser Skill automatisiert den „letzten Meter“ der Entwicklung: die Präsentation deiner Arbeit für die Welt. Er identifiziert wichtige UI-Komponenten, erfasst diese automatisch und generiert eine professionelle Dokumentation.

Befehle

• /showcase: Die Zauberformel (Standard). Führt UI-Erfassung + Terminal-Aufzeichnung + README-Aktualisierung + GitHub-Release + Metadaten (Über/Labels) aus.
• /select: Öffnet ein interaktives UI zur Auswahl spezifischer Funktionen.
• /capture: Hochauflösende UI-Erfassung mit Playwright auslösen.
• /record: Terminal-Demo mit VHS aufzeichnen.
• /audit: Repo-Gesundheitsprüfung durchführen (Bewertung & Heilungsplan).
• /readme: README gezielt mit visuellen Galerien und Badges aktualisieren.
• /release: Ein offizielles GitHub-Release erstellen (v0.1.0-alpha).
• /metadata: GitHub „Über“ und „Themen“ automatisch erkennen und aktualisieren.
• /socials: Fertige Beiträge für LinkedIn und Reddit generieren.
• /scan: Datenschutzorientierten Sicherheitsscan auf Geheimnisse und .env-Lecks durchführen.
• /license: MIT-Lizenz überprüfen oder hinzufügen.
• /setup: Alle Abhängigkeiten (Playwright, VHS, ffmpeg) installieren sicherstellen.

Kern-Workflows

1. Erste Analyse & Auto-Setup

• Ziel: Projekttyp identifizieren und Umgebungsbereitschaft sicherstellen.
• Autonome Asset-Generierung:
  • Wenn UI-Erfassung oder Terminal-Aufzeichnung fehlen, DARF der Agent diese nicht überspringen oder defekte Links hinterlassen.
  • Schritt 1: Echt-Erfassung mit Playwright/VHS versuchen.
  • Schritt 2: Falls Schritt 1 fehlschlägt, ein hochwertiges „Visuelle Architektur“-Diagramm oder ein stilisiertes SVG generieren, das die Projektlogik repräsentiert.
  • Ergebnis: Jedes präsentierte Repository MUSS ein visuelles Element haben, sei es echt oder generiert.
• Framework-Erkennung & Geheimnisverwaltung:
  • Streamlit-Projekte: Erkennung über streamlit_app.py oder streamlit in requirements.txt.
  • Geheimnis-Migration: Falls erkannt, vorschlagen, .env-Schlüssel nach .streamlit/secrets.toml zu migrieren, um Streamlit Cloud-Standards zu entsprechen.
• Sicherheits- & Datenschutzscan (/scan) :
  • Vor jeder Erfassung soll der Agent das Projekt auf gängige API-Key-Muster (OpenAI, Anthropic, Google, AWS, etc.) scannen.
  • Falls Geheimnisse im Quellcode oder in .env-Dateien gefunden werden, den Benutzer warnen und vorschlagen, sie zur .gitignore hinzuzufügen.
• Lizenzprüfung (/license) :
  • Prüfen, ob das Projekt eine LICENSE-Datei enthält. Falls nicht, vorschlagen, eine MIT-Lizenz hinzuzufügen.
• Abhängigkeitsprüfung (/setup) :
  • Vor jeder Erfassung prüfen, ob playwright (Python), vhs (System) und ffmpeg installiert sind.

2. Automatisierte Erfassung (/capture, /record)

• UI-Erfassung: Nutzt scripts/capture.py. Unterstützt responsives, ganzseitiges, Maskieren und Dark Mode.
• Terminal-Aufzeichnung: Nutzt scripts/record_cli.tape und VHS.
• Verifikation & Auto-Reparatur:
  • Nach der Erfassung die generierten Assets prüfen.
  • Fehlererkennung: Nach 404-Seiten, leeren Bildschirmen oder VHS-Parser-Fehlern suchen.
• Aufräumen:
  • Sobald die Präsentation verifiziert und das README aktualisiert ist, alle temporären Dateien löschen.
  • Sicherstellen, dass nur die endgültigen hochwertigen Assets (z. B. landing.png, demo.gif) im showcase/-Ordner verbleiben.

3. README-Dokumentation & Hygiene (/readme)

• Ziel: Ein professionelles README erstellen, das „Zeigen vor Erzählen“ priorisiert.
• Read the Docs (Optional / Nicht-UI-Fokus) :
  • Erkennung: Falls das Projekt ein CLI-Tool, eine Bibliothek oder eine Backend-API (nicht UI) ist, SOLLTE der Agent vorschlagen, „Read the Docs“ mit MkDocs einzurichten.
  • Aktion: Vorschlagen, eine einfache mkdocs.yml und docs/-Struktur zu erstellen.
  • Benutzerwahl: Immer fragen: „Da dies ein/e [CLI/Bibliothek] ist, möchtest du, dass ich auch eine ‚Read the Docs‘-Dokumentationsseite einrichte?“
• Asset-Integrität:
  • NIEMALS defekte Bildlinks oder Platzhalter (wie landing.png, falls nicht vorhanden) einfügen.
  • Falls eine echte Erfassung unmöglich ist, MUSS der Agent eine hochwertige Alternative generieren (z. B. ein Mermaid-Diagramm).
• Das „Vibe-First“-README:
  • Kein Metadaten-Overkill: Die diagnostische Gesundheitstabelle und die Haken/Prozentzeilen (z. B. ✅ Sicher | ✅ 92/100) entfernen. Diese wirken roboterhaft und überladen.
  • Natürlicher Kontextsatz: Statt Keywords einen einzigen, aussagekräftigen Satz generieren, der die Essenz, den Tech-Stack und den Zweck des Projekts harmonisch verbindet.
    • Beispiel: „Ein datenschutzorientierter KI-Agent, erstellt mit React und TypeScript für automatisiertes UI-Auditing.“
    • Regel: Dieser Satz sollte sich wie ein von einem Menschen geschriebener Untertitel anfühlen, nicht wie ein Prüfbericht.
  • Externer Gesundheits-Check: Alle detaillierten Bewertungen, Gesundheitstabellen und Diagnosedaten MÜSSEN in ein dediziertes externes Repository/eine externe Datei (z. B. ayush-repos-health) oder ganz unten in eine separate REPO_HEALTH.md verschoben werden. Das Haupt-README bleibt streng auf das Produkt und den „Vibe“ fokussiert.
• Gezielte Injektion & Deduplizierung:
  • Nie duplizieren: Falls ein Abschnitt bereits existiert (z. B. „Architektur“, „Funktionen“, „Installation“), DARF der Agent keine zweite Version hinzufügen.
  • Überlegenheitswahl: Vorhandenen Inhalt mit generiertem Inhalt vergleichen. Falls die generierte Version besser ist (klarer, visueller), die alte ersetzen.
  • Hybride Fusion: Falls beide einen einzigartigen Wert enthalten, zu einem einzigen kohärenten Abschnitt zusammenführen.
  • Null Redundanz: Eine einzige, optimierte Wahrheitsquelle für jeden Projektaspekt. Keine überflüssigen Überschriften.
• Positionierung oben: Die visuelle Galerie immer direkt nach dem Elevator Pitch platzieren, um die erste Wirkung zu maximieren.

4. Professionelle Bereitstellung & Veröffentlichung (/release, /metadata)

• Ziel: Das Projekt für die offizielle Distribution verpacken.
• Professionelles GitHub-Release (/release) :
  • Nach Abschluss der Präsentation ein automatisiertes Release (z. B. v0.1.0-alpha/beta/stable) erstellen.
• GitHub-Metadaten (/metadata) :
  • Die „Über“-Beschreibung und „Themen“ (Labels) mit scripts/manage_metadata.py erkennen und aktualisieren.
• Verifikation & Validierung:
  • Live-Repository-Prüfung:
    • Vor dem Abschluss visuell bestätigen, dass das README, die Badges, die Visuelle Galerie und die GitHub-Themen korrekt dargestellt werden.
  • Sauberer Zustand: Falls ein Force-Push nötig war, um Geheimnisse zu bereinigen, sicherstellen, dass das Release mit dem neuesten bereinigten Commit-Hash verknüpft wird.

5. Repo-Gesundheit & Heilung (/audit)

• Ziel: Die „Bereitschaft“ des Projekts diagnostizieren und gezielte Verbesserungen anbieten.
• Bewertung: Eine gewichtete Punktzahl auf einer 0-100-Skala vergeben.
• Checkliste:
  • Dokumentation (README, LICENSE).
  • Sicherheit (Geheimnisse, .gitignore).
  • Automatisierung (setup.sh, Tests).
  • Präsentation (Screenshots, VHS).
  • Bonus (+5 Punkte): Erweiterte Dokumentation (MkDocs/Read the Docs) – Besonders empfohlen für Nicht-UI-Apps.
• Durchdachte Verschreibung: Vor der Reparatur soll der Agent einen „Heilungsplan“ präsentieren.
• Die Heilung: Erst nach Benutzerfreigabe die Korrekturen gezielt anwenden und erneut prüfen, um die verbesserte Punktzahl zu zeigen.

6. Soziale Medien & PR (/socials)

• Ziel: Das Projekt für die externe Kommunikation zusammenfassen.
• Formate:
  • LinkedIn: Professionell, wertorientiert und badgefokussiert.
  • Reddit: Technisch, von Entwickler zu Entwickler und GIF-zentriert.

Best Practices

• Auf Laden warten: Immer page.wait_for_selector() oder time.sleep() einfügen, um sicherzustellen, dass Diagramme und LLM-Antworten gerendert werden.
• Verifizierte Qualität: python3 tests/test_readme_injection.py ausführen, um zu bestätigen, dass die Injektionslogik noch einwandfrei ist.
• Dokumentationshygiene: Niemals die README-Schönheit für Diagnosedaten opfern. Das README für den „Vibe“ behalten und den „Audit“ in REPO_HEALTH.md verschieben.

---

Erstellt mit ❤️ für Vibe-Coder überall.