Was macht Spike?
Verwende diese Skill, wenn der Benutzer eine Idee testen möchte, bevor er sich auf einen echten Build festlegt: „Spike das“, „schneller Prototyp“, „ist das möglich?“, „A/B vergleichen“, „bevor wir bauen“.
Nicht verwenden, wenn die Frage durch Lesen von Doku/Code beantwortet werden kann oder wenn der Benutzer explizit nach einer Produktionsimplementierung gefragt hat.
Ablauf
- Frage: Formuliere die konkrete Machbarkeitsfrage.
- Recherche: Lese genügend Dokumentation/Quellcode, um einen glaubwürdigen Ansatz zu wählen.
- Bau: Erstelle das kleinste lauffähige Artefakt, das die Idee bestätigt oder widerlegt.
- Belastung: Teste einen Randfall oder Fehlermodus.
- Urteil:
VALIDATED,PARTIALoderINVALIDATED.
Ausgabeform
- Standard-Arbeitsbereich:
.tmp/openclaw-spikes/<slug>, es sei denn, der Benutzer wünscht einen repo-lokalen Pfad. - Repo-lokale Option:
spikes/<NNN-slug>/mitREADME.mdund minimalem Code. - Bevorzuge ausführbare CLI, winziges HTML, einen Endpunkt oder einen fokussierten Test.
- Vermeide Paketwucher, Docker, Env-Dateien, App-Frameworks und Produktionsaufräumarbeiten.
Multi-Spike-Ideen
- Teile in 2–5 unabhängige Fragen auf.
- Bearbeite zuerst die riskanteste Frage.
- Für A/B-Vergleiche halte die Eingaben gleich und messe dieselben Dimensionen.
- Frage vor dem Bau aller Varianten, wenn der Aufwand mehr als ein kleiner Prototyp ist.
Urteilsformat
## Urteil: VALIDATED | PARTIAL | INVALIDATED
Frage: ...
Belege: exakter Befehl/Ausgabe/Messung.
Was funktioniert hat: ...
Was fehlgeschlagen oder überraschend war: ...
Empfehlung: ausliefern / anpassen / vermeiden, mit dem nächsten Produktionsschritt.
Regeln
- Ein invalidiertes Spike ist nützlich, wenn es einen Pfad mit Belegen ausschließt.
- Spike-Code nicht ohne normales Umschreiben in die Produktion übernehmen.
- Wenn externe Abhängigkeiten bewertet werden, prüfe deren Zustand: aktuelles Release/Commit, Doku, Lizenz, Installationsaufwand.