Spike

Que fait Spike ?

Utilisez ce skill lorsque l'utilisateur souhaite tâter le terrain avant de s'engager dans une vraie construction — valider la faisabilité, comparer des approches, ou faire remonter des inconnues qu'aucune recherche ne pourra résoudre. Les spikes sont conçus pour être jetables. Jetez-les dès qu'ils ont rendu leur service.

Chargez ce skill quand l'utilisateur dit des choses comme "laisse-moi essayer ça", "je veux voir si X marche", "fais un spike", "avant de m'engager sur Y", "prototype rapide de Z", "c'est même possible ?", ou "compare A vs B".

Quand NE PAS l'utiliser

• La réponse est trouvable dans la doc ou en lisant le code — faites simplement une recherche, ne construisez pas
• Le travail est en cours de production — utilisez le skill plan à la place
• L'idée est déjà validée — passez directement à l'implémentation

Si l'utilisateur a le système GSD complet installé

Si gsd-spike apparaît comme un skill frère (installé via npx get-shit-done-cc --hermes), préférez gsd-spike lorsque l'utilisateur veut le workflow GSD complet : état persistant dans .planning/spikes/, suivi MANIFEST entre sessions, format de verdict Given/When/Then, et motifs de commit intégrés au reste de GSD. Ce skill est la version autonome légère pour les utilisateurs qui n'ont pas (ou ne veulent pas) le système complet.

Méthode centrale

Quelle que soit l'échelle, chaque spike suit cette boucle :

décomposer  →  rechercher  →  construire  →  verdict
   ↑__________________________________________↓
                  itérer sur les résultats

1. Décomposer

Décomposez l'idée de l'utilisateur en 2 à 5 questions de faisabilité indépendantes. Chaque question est un spike. Présentez-les sous forme de tableau avec le cadre Given/When/Then :

#	Spike	Valide (Given/When/Then)	Risque
001	websocket-streaming	Given une connexion WS, When LLM envoie des tokens, Then le client reçoit des chunks < 100ms	Élevé
002a	pdf-parse-pdfjs	Given un PDF multi-pages, When parsé avec pdfjs, Then un texte structuré est extractible	Moyen
002b	pdf-parse-camelot	Given un PDF multi-pages, When parsé avec camelot, Then un texte structuré est extractible	Moyen

Types de spikes :

• standard — une approche répondant à une question
• comparatif — même question, différentes approches (numéro partagé, suffixe lettre a/b/c)

Bonnes questions de spike : une faisabilité spécifique avec une sortie observable. Mauvaises questions de spike : trop larges, sans sortie observable, ou juste "lire la doc sur X".

Ordonnez par risque. Le spike le plus susceptible de faire échouer l'idée passe en premier. Pas la peine de prototyper les parties faciles si la partie difficile ne marche pas.

Sautez la décomposition seulement si l'utilisateur sait déjà exactement ce qu'il veut comme spike et le dit. Considérez alors son idée comme un spike unique.

2. Aligner (pour les idées multi-spike)

Présentez le tableau des spikes. Demandez : "Construire tout dans cet ordre, ou ajuster ?" Laissez l'utilisateur supprimer, réordonner ou recadrer avant d'écrire du code.

3. Rechercher (par spike, avant de construire)

Les spikes ne sont pas sans recherche — vous recherchez assez pour choisir la bonne approche, puis vous construisez. Par spike :

1. Briefez-le. 2-3 phrases : ce qu'est ce spike, pourquoi il est important, risque clé.

2. Recensez les approches concurrentes s'il y a un vrai choix :

   Approche	Outil/Bibliothèque	Avantages	Inconvénients	Statut
   ...	...	...	...	maintenu / abandonné / bêta

3. Choisissez-en une. Dites pourquoi. Si 2+ sont crédibles, construisez des variantes rapides dans le spike.

4. Sautez la recherche pour la logique pure sans dépendances externes.

Utilisez les outils Hermes pour l'étape de recherche :

• web_search("python websocket streaming libraries 2025") — trouver des candidats
• web_extract(urls=["https://websockets.readthedocs.io/..."]) — lire la doc réelle (renvoie du markdown)
• terminal("pip show websockets | grep Version") — vérifier ce qui est installé dans le venv du projet

Pour les bibliothèques sans pages de doc, clonez et lisez leur README.md / examples/ via read_file. Context7 MCP (si l'utilisateur l'a configuré) est aussi une bonne source — mcp_*_resolve-library-id puis mcp_*_query-docs.

4. Construire

Un répertoire par spike. Gardez-le autonome.

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

Privilégiez quelque chose avec lequel l'utilisateur peut interagir. Les spikes échouent quand la seule sortie est une ligne de log qui dit "ça marche". L'utilisateur veut sentir le spike fonctionner. Choix par défaut, par ordre de préférence :

1. Une CLI exécutable qui prend une entrée et affiche une sortie observable
2. Une page HTML minimale qui démontre le comportement
3. Un petit serveur web avec un seul endpoint
4. Un test unitaire qui exerce la question avec des assertions reconnaissables

La profondeur plutôt que la rapidité. Ne déclarez jamais "ça marche" après un seul chemin heureux. Testez les cas limites. Suivez les découvertes surprenantes. Le verdict n'est digne de confiance que si l'investigation était honnête.

Évitez sauf si le spike le nécessite spécifiquement : gestion de paquets complexe, outils de construction/bundlers, Docker, fichiers env, systèmes de configuration. Hardcodez tout — c'est un spike.

Construire un spike — une séquence d'outils typique :

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")
# Observez la sortie, itérez.

Spikes comparatifs parallèles (002a / 002b) — délégation. Lorsque deux approches peuvent être exécutées en parallèle et que les deux nécessitent une véritable ingénierie (pas des prototypes de 10 lignes), répartissez avec delegate_task :

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

Chaque sous-agent renvoie son propre verdict ; vous rédigez la comparaison.

5. Verdict

Le README.md de chaque spike se termine par :

## Verdict : VALIDÉ | PARTIEL | INVALIDÉ

### Ce qui a fonctionné
- ...

### Ce qui n'a pas fonctionné
- ...

### Surprises
- ...

### Recommandation pour la vraie construction
- ...

VALIDÉ = la question centrale a reçu une réponse positive, avec preuve. PARTIEL = ça marche sous les contraintes X, Y, Z — documentez-les. INVALIDÉ = ça ne marche pas, pour cette raison. C'est un spike réussi.

Spikes comparatifs

Lorsque deux approches répondent à la même question (002a / 002b), construisez-les dos à dos, puis faites une comparaison directe à la fin :

## Comparaison directe : pdfjs vs camelot

| Dimension | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| Qualité d'extraction | 9/10 structuré | 7/10 tableaux uniquement |
| Complexité d'installation | npm install, 1 ligne | pip + ghostscript |
| Perf sur PDF de 100 pages | 3s | 18s |
| Gère le texte pivoté | non | oui |

**Gagnant :** pdfjs pour notre cas d'usage. Camelot si nous avons besoin d'une extraction tableau-first plus tard.

Mode Frontier (choisir le prochain spike à faire)

Si des spikes existent déjà et que l'utilisateur dit "quel spike devrais-je faire ensuite ?", parcourez les répertoires existants et cherchez :

• Risques d'intégration — deux spikes validés qui touchent la même ressource mais ont été testés indépendamment
• Transferts de données — la sortie du spike A était supposée compatible avec l'entrée du spike B ; jamais prouvé
• Lacunes dans la vision — capacités supposées mais non prouvées
• Approches alternatives — angles différents pour les spikes PARTIEL ou INVALIDÉ

Proposez 2 à 4 candidats en format Given/When/Then. Laissez l'utilisateur choisir.

Sortie

• Créez spikes/ (ou .planning/spikes/ si l'utilisateur utilise les conventions GSD) à la racine du dépôt
• Un répertoire par spike : NNN-nom-descriptif/
• README.md par spike capture la question, l'approche, les résultats, le verdict
• Gardez le code jetable — un spike qui nécessite 2 jours de "nettoyage pour la production" était un mauvais spike

Attribution

Adapté du workflow /gsd-spike du projet GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Le système GSD complet offre un état de spike persistant, un suivi MANIFEST et une intégration avec un pipeline de développement plus large piloté par spécifications ; installez avec npx get-shit-done-cc --hermes --global.