kktbur/VibeCoding-Start

VibeCoding Start

Verwende diesen Skill, um Codex ab der ersten Projektsession bis zur Veröffentlichung und Beobachtung mit einem leichten Engineering-System auszustatten. Das gewünschte Ergebnis ist ein Projekt, das eine spätere Session verstehen, überprüfen, verifizieren, akzeptieren und sicher fortsetzen kann, ohne den gesamten Chat wiederholen zu müssen.

Erste Aktion

Lies die AGENTS.md des Projekts und befolge dann diese Hot-Context-Reihenfolge:

1. docs/INDEX.md
2. docs/CURRENT.md
3. docs/PRODUCT.md
4. docs/PRD.md
5. docs/ACCEPTANCE.md

Lies docs/CODEMAP.md, aktive ADRs, Pläne, Arbeitsprotokolle, Standards und lokale Rohdaten nur dann, wenn die Aufgabe sie benötigt. Wenn das Sechs-Dokumenten-Gerüst fehlt, verwende vor der Implementierung den INIT-Modus des begleitenden Skills vibecoding-project-knowledge.

Nicht verhandelbare Projektgrenzen

• Jedes Projekt erhält das gleiche Mindestgerüst: AGENTS.md, docs/INDEX.md, PRODUCT.md, PRD.md, ACCEPTANCE.md, CURRENT.md und CODEMAP.md.
• Die Komplexität ändert die Dokumentationstiefe und die Stärke der Prüfpfosten, entfernt aber nicht das Gerüst.
• PRODUCT.md erklärt das Warum, PRD.md erklärt das Was und ACCEPTANCE.md erklärt den Nachweis. Diese Verantwortlichkeiten nicht stillschweigend zusammenführen.
• Aktualisiere PRD.md, wenn die Session eine Anforderung, ein Feature, ein Nicht-Ziel, eine Einschränkung oder ein sinnvolles Benutzerszenario ändert.
• Halte rohe Sessions, Protokolle, fehlgeschlagene Versuche, Untersuchungen und Beweise standardmäßig lokal unter .project-memory/. Überführe nur redigierte, bewusst kuratierte Beispiele in docs/examples/.
• Bevorzuge vorhandene Projektfähigkeiten, die Standardbibliothek, offizielle SDKs/APIs/Tools, ausgereifte Open-Source-Projekte, Pakete, Adapter oder Komposition vor benutzerdefinierter Infrastruktur.
• Baue keine Speicherdatenbank, Vektordatenbank, Suchmaschine, Testframework, Bereitstellungsframework, CI-Dienst oder Observability-Backend als Teil dieses Workflows.

Engineering-Tore

Verwende für jedes Projekt das gleiche Vokabular, während die Tiefe an das Risiko angepasst wird:

G0 Umfang
→ G1 Absicht
→ G2 Wiederverwendung
→ G3 Plan
→ G4 Bauen
→ G5 Adversarial Review
→ G6 Verifikation
→ G7 Menschliche Abnahme
→ G8 Veröffentlichung
→ G9 Beobachtung

G0 Umfang

Klassifiziere die Arbeit als Anwendung/Produkt, Integration/Adapter oder Infrastruktur/Sicherheit/Laufzeit. Je näher an der Infrastruktur, desto stärker müssen die Nachweise für Wiederverwendung, Überprüfung und Wiederherstellung sein.

G1 Absicht

Mache die Kette explizit:

PRODUCT (Warum) → PRD (Was) → ACCEPTANCE (Wie nachweisen)

Halte das Problem, die Benutzer, den aktuellen und den gewünschten Zustand, funktionale Anforderungen, Nicht-Ziele, Einschränkungen, die Abnahme und Risiken vor der Implementierung fest.

G2 Wiederverwendung

Für jede nicht-triviale allgemeine Fähigkeit suche vor dem Bauen und entscheide in dieser Reihenfolge:

NUTZEN → ANPASSEN → KOMPONIEREN → BAUEN → STOPP

Wenn BAUEN ausgewählt wird, halte die durchsuchten Alternativen, abgelehnten Wiederverwendungspfade, die Wartungsverantwortung und die Abnahmemethode des Eigentümers in einem ADR fest. Die Fähigkeit eines Modells, Code zu schreiben, ist kein Beweis dafür, dass benutzerdefinierter Code die richtige Wahl ist.

G3 Plan

Zerlege komplexe Arbeit in kleine Meilensteine mit einem Verifikationspunkt nach jedem Meilenstein. Stoppe und plane neu, wenn sich Umfang, Architektur oder Risiko wesentlich ändern.

G4 Bauen

Halte die Implementierung klein und umkehrbar. Verwende die vorhandene Toolchain und vermeide spekulative Abstraktionen, Abhängigkeiten und Infrastruktur.

G5 Adversarial Review

Ein unabhängiger Prüfer untersucht PRODUCT.md, PRD.md, ACCEPTANCE.md, aktive Entscheidungen, die relevante Struktur, den Diff und die Tests. Achte auf Auslassungen, falsche Annahmen, Regressionen, doppelte Fähigkeiten, Überdesign, Sicherheits-/Datenrisiken, Testlücken und Rollback-Fehler. Der Autor darf bei einer wichtigen Änderung nicht der letzte Prüfer sein.

G6 Verifikation

Decke normale, Fehler-, Grenz-, Ungültig-Eingabe-, Regressions- und Wiederherstellungspfade im Verhältnis zum Risiko ab. Berichte maschinelle Beweise und eine für den Eigentümer lesbare Erklärung; ein grüner Haken beweist nur die Invariante, die er tatsächlich prüft.

G7 Menschliche Abnahme

Der Eigentümer bestätigt, dass das Ergebnis das beabsichtigte Produkt ist und dass sein beobachtbares Verhalten verständlich ist. Automatisierte Prüfungen und unabhängige Überprüfungen ersetzen diesen Schritt nicht.

G8 Veröffentlichung

Halte vor der tatsächlichen Nutzung die Version, den letzten bekannten guten Zustand, die Versionshinweise, das Backup, die Rollback-Methode, das Migrationsrisiko und das genaue Veröffentlichungsziel fest.

G9 Beobachtung

Beobachte nach der Veröffentlichung die Gesundheit und die Hinweise der Benutzer. Fahre nur fort, wenn der Zustand gesund ist; stoppe und rolle zurück oder rolle vorwärts, wenn Hinweise auf ein Problem zeigen. Führe das Ergebnis nach Bedarf in Tests, Arbeitsprotokoll, ADR, Produktabsicht, Abnahme oder ein Postmortem zurück.

Wissensabschluss

Am Ende jeder substanziellen Session verwende den UPDATE-Modus des begleitenden Skills vibecoding-project-knowledge:

1. Bewahre rohe Sessionsdetails und große Ausgaben im lokalen Verzeichnis .project-memory/ auf.
2. Kuratiere CURRENT.md und die relevanten aktiven Dokumente.
3. Aktualisiere CODEMAP.md, wenn sich die Struktur ändert.
4. Aktualisiere PRD.md, wenn sich Anforderungen, Features, Nicht-Ziele, Einschränkungen oder Benutzerszenarien ändern.
5. Halte materielle Entscheidungen in einem ADR fest.
6. Aktualisiere die Indizes und das Arbeitsprotokoll.
7. Führe die relevanten deterministischen Audits durch.

Behaupte keinen Abschluss ohne maschinelle Beweise, eine für Menschen lesbare Erklärung und eine Abnahmemethode des Eigentümers.

Referenzen

• Lies Standard v1.3 für die normativen Regeln und die Veröffentlichungsgrenze.
• Lies den begleitenden Skill vibecoding-project-knowledge für die INIT-, UPDATE- oder AUDIT-Verfahren.