Spike – Ideenvalidierung vor dem Build

Spike

Verwende dieses Skill, wenn der Benutzer eine Idee ausloten möchte, bevor er sich auf einen echten Build festlegt – um Machbarkeit zu prüfen, Ansätze zu vergleichen oder Unbekannte aufzudecken, die keine noch so intensive Recherche beantworten wird. Spikes sind von Natur aus Wegwerfartefakte. Wirf sie weg, sobald sie ihren Zweck erfüllt haben.

Lade dieses Skill, wenn der Benutzer Dinge sagt wie „lass mich das mal ausprobieren“, „ich will sehen, ob X funktioniert“, „spike das mal aus“, „bevor ich mich auf Y festlege“, „schneller Prototyp von Z“, „ist das überhaupt möglich?“ oder „vergleiche A vs B“.

Wann NICHT zu verwenden

• Die Antwort ist aus Doku oder Code ablesbar – dann recherchiere einfach, baue nichts
• Die Arbeit ist produktionsrelevant – verwende stattdessen das plan-Skill
• Die Idee ist bereits validiert – springe direkt zur Implementierung

Wenn der Benutzer das vollständige GSD-System installiert hat

Wenn gsd-spike als Schwester-Skill auftaucht (installiert via npx get-shit-done-cc --hermes), bevorzuge gsd-spike, wenn der Benutzer den vollständigen GSD-Workflow möchte: persistenten .planning/spikes/-Status, MANIFEST-Tracking über Sitzungen hinweg, Given/When/Then-Beurteilungsformat und Commit-Muster, die in den Rest von GSD integriert sind. Dieses Skill ist die leichte eigenständige Version für Benutzer, die das vollständige System nicht haben (oder nicht wollen).

Kernmethode

Unabhängig vom Umfang folgt jeder Spike diesem Kreislauf:

zerlegen  →  recherchieren  →  bauen  →  beurteilen
   ↑__________________________________________↓
                  iterieren auf Grundlage der Erkenntnisse

1. Zerlegen

Zerlege die Idee des Benutzers in 2-5 unabhängige Machbarkeitsfragen. Jede Frage ist ein Spike. Präsentiere sie als Tabelle mit Given/When/Then-Rahmen:

#	Spike	Validiert (Given/When/Then)	Risiko
001	websocket-streaming	Given a WS-Verbindung, when LLM streamt Tokens, then Client erhält Chunks < 100ms	Hoch
002a	pdf-parse-pdfjs	Given ein mehrseitiges PDF, when mit pdfjs geparst, then strukturierter Text ist extrahierbar	Mittel
002b	pdf-parse-camelot	Given ein mehrseitiges PDF, when mit camelot geparst, then strukturierter Text ist extrahierbar	Mittel

Spike-Typen:

• standard — ein Ansatz beantwortet eine Frage
• vergleich — gleiche Frage, verschiedene Ansätze (geteilte Nummer, Buchstaben-Suffix a/b/c)

Gute Spike-Fragen: spezifische Machbarkeit mit beobachtbarem Ergebnis. Schlechte Spike-Fragen: zu breit, kein beobachtbares Ergebnis oder nur „lies die Doku über X".

Sortiere nach Risiko. Der Spike, der die Idee am ehesten zum Scheitern bringt, wird zuerst ausgeführt. Es hat keinen Sinn, die einfachen Teile zu prototypisieren, wenn der schwierige Teil nicht funktioniert.

Überspringe die Zerlegung nur, wenn der Benutzer bereits genau weiß, was er spiken will, und das auch so sagt. Dann übernimm seine Idee als einzelnen Spike.

2. Abstimmung (bei Ideen mit mehreren Spikes)

Präsentiere die Spike-Tabelle. Frage: „Alles in dieser Reihenfolge bauen, oder anpassen?" Lass den Benutzer Spikes entfernen, umsortieren oder umformulieren, bevor du Code schreibst.

3. Recherchieren (pro Spike, vor dem Bauen)

Spikes sind nicht recherchefrei – du recherchierst genug, um den richtigen Ansatz auszuwählen, dann baust du. Pro Spike:

1. Kurzbeschreibung. 2-3 Sätze: Was ist dieser Spike, warum ist er wichtig, was ist das Hauptrisiko.

2. Konkurrierende Ansätze auflisten falls es echte Auswahl gibt:

   Ansatz	Werkzeug/Bibliothek	Vorteile	Nachteile	Status
   ...	...	...	...	maintained / abandoned / beta

3. Einen auswählen. Begründe die Wahl. Wenn 2+ glaubwürdig sind, baue schnelle Varianten innerhalb des Spikes.

4. Recherche überspringen für reine Logik ohne externe Abhängigkeiten.

Nutze Hermes-Werkzeuge für den Recherche-Schritt:

• web_search("python websocket streaming libraries 2025") — Kandidaten finden
• web_extract(urls=["https://websockets.readthedocs.io/..."]) — die eigentliche Doku lesen (gibt Markdown zurück)
• terminal("pip show websockets | grep Version") — prüfen, was in der venv des Projekts installiert ist

Für Bibliotheken ohne Doku-Seiten: klone und lies README.md / examples/ via read_file. Context7 MCP (falls vom Benutzer konfiguriert) ist ebenfalls eine gute Quelle – mcp_*_resolve-library-id dann mcp_*_query-docs.

4. Bauen

Ein Verzeichnis pro Spike. Halte es eigenständig.

spikes/
├── 001-websocket-streaming/
│   ├── README.md
│   └── main.py
├── 002a-pdf-parse-pdfjs/
│   ├── README.md
│   └── parse.js
└── 002b-pdf-parse-camelot/
│   ├── README.md
│   └── parse.py

Bevorzuge etwas, mit dem der Benutzer interagieren kann. Spikes schlagen fehl, wenn die einzige Ausgabe eine Logzeile ist, die „es funktioniert" sagt. Der Benutzer möchte den Spike spüren. Standardwahl, in der Reihenfolge der Bevorzugung:

1. Ein ausführbares CLI, das Eingaben nimmt und beobachtbare Ausgaben liefert
2. Eine minimale HTML-Seite, die das Verhalten demonstriert
3. Ein kleiner Webserver mit einem Endpunkt
4. Ein Unit-Test, der die Frage mit erkennbaren Assertions prüft

Tiefe vor Geschwindigkeit. Erkläre niemals „es funktioniert" nach einem einzigen Happy-Path-Durchlauf. Teste Randfälle. Folge überraschenden Erkenntnissen. Das Urteil ist nur vertrauenswürdig, wenn die Untersuchung ehrlich war.

Vermeide – sofern der Spike es nicht spezifisch erfordert – komplexes Paketmanagement, Build-Tools/Bundler, Docker, Env-Dateien, Konfigurationssysteme. Hardcode alles – es ist ein Spike.

Einen Spike bauen – eine typische Werkzeugsequenz:

terminal("mkdir -p spikes/001-websocket-streaming")
write_file("spikes/001-websocket-streaming/README.md", "# 001: websocket-streaming\n\n...")
write_file("spikes/001-websocket-streaming/main.py", "...")
terminal("cd spikes/001-websocket-streaming && python3 main.py")
# Ausgabe beobachten, iterieren.

Parallele Vergleichs-Spikes (002a / 002b) – delegieren. Wenn zwei Ansätze parallel laufen können und beide echte Entwicklung erfordern (keine 10-Zeilen-Prototypen), auslagern mit delegate_task:

delegate_task(tasks=[
    {"goal": "Baue 002a-pdf-parse-pdfjs: ...", "toolsets": ["terminal", "file", "web"]},
    {"goal": "Baue 002b-pdf-parse-camelot: ...", "toolsets": ["terminal", "file", "web"]},
])

Jeder Sub-Agent gibt sein eigenes Urteil ab; du schreibst den direkten Vergleich.

5. Beurteilung

Die README.md jedes Spikes endet mit:

## Urteil: VALIDIERT | TEILWEISE VALIDIERT | NICHT VALIDIERT

### Was funktioniert hat
- ...

### Was nicht funktioniert hat
- ...

### Überraschungen
- ...

### Empfehlung für den echten Build
- ...

VALIDIERT = die Kernfrage wurde mit Ja beantwortet, mit Belegen. TEILWEISE VALIDIERT = es funktioniert unter den Einschränkungen X, Y, Z – dokumentiere sie. NICHT VALIDIERT = funktioniert nicht, aus diesem Grund. Dies ist ein erfolgreicher Spike.

Vergleichs-Spikes

Wenn zwei Ansätze dieselbe Frage beantworten (002a / 002b), baue sie hintereinander, mache dann am Ende einen direkten Vergleich:

## Direkter Vergleich: pdfjs vs camelot

| Dimension | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| Extraktionsqualität | 9/10 strukturiert | 7/10 nur Tabellen |
| Einrichtungsaufwand | npm install, 1 Zeile | pip + ghostscript |
| Performance bei 100 Seiten PDF | 3s | 18s |
| Unterstützt gedrehten Text | nein | ja |

**Gewinner:** pdfjs für unseren Anwendungsfall. Camelot, wenn später tabellenbasierte Extraktion benötigt wird.

Fortgeschrittener Modus (Auswahl des nächsten Spikes)

Wenn bereits Spikes existieren und der Benutzer fragt „was soll ich als nächstes spiken?", durchsuche die vorhandenen Verzeichnisse und suche nach:

• Integrationsrisiken – zwei validierte Spikes, die dieselbe Ressource berühren, aber unabhängig getestet wurden
• Datenübergaben – Spike A's Ausgabe wurde als kompatibel mit Spike B's Eingabe angenommen; nie bewiesen
• Lücken in der Vision – angenommene, aber unbewiesene Fähigkeiten
• Alternative Ansätze – andere Blickwinkel für TEILWEISE VALIDIERTE oder NICHT VALIDIERTE Spikes

Schlage 2-4 Kandidaten als Given/When/Then vor. Lass den Benutzer wählen.

Ausgabe

• Erstelle spikes/ (oder .planning/spikes/ wenn der Benutzer GSD-Konventionen verwendet) im Repository-Stammverzeichnis
• Ein Verzeichnis pro Spike: NNN-beschreibender-name/
• README.md pro Spike enthält Frage, Ansatz, Ergebnisse, Urteil
• Halte den Code wegwerfbar – ein Spike, der 2 Tage braucht, um „für die Produktion aufgeräumt zu werden", war ein schlechter Spike

Quellenangabe

Adaptiert aus dem GSD (Get Shit Done) Projekt-Workflow /gsd-spike — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Das vollständige GSD-System bietet persistenten Spike-Status, MANIFEST-Tracking und Integration in eine breitere, spezifikationsgetriebene Entwicklungspipeline; Installation mit npx get-shit-done-cc --hermes --global.