Spike

O que Spike faz?

Use este skill quando o usuário quiser sentir uma ideia antes de se comprometer com uma implementação real — validando viabilidade, comparando abordagens ou revelando incógnitas que nenhuma quantidade de pesquisa responderá. Spikes são descartáveis por natureza. Jogue-os fora assim que pagarem sua dívida.

Carregue isto quando o usuário disser coisas como "deixa eu tentar isso", "quero ver se X funciona", "faz um spike disso", "antes de me comprometer com Y", "protótipo rápido de Z", "isso é sequer possível?", ou "compare A vs B".

Quando NÃO usar

• A resposta é conhecível a partir de documentação ou leitura de código — apenas pesquise, não construa
• O trabalho é caminho de produção — use o skill plan
• A ideia já está validada — vá direto para a implementação

Se o usuário tiver o sistema GSD completo instalado

Se gsd-spike aparecer como um skill irmão (instalado via npx get-shit-done-cc --hermes), prefira gsd-spike quando o usuário quiser o fluxo de trabalho GSD completo: estado persistente em .planning/spikes/, rastreamento MANIFEST entre sessões, formato de veredito Dado/Quando/Então e padrões de commit que se integram com o resto do GSD. Este skill é a versão autônoma leve para usuários que não têm (ou não querem) o sistema completo.

Método principal

Independentemente da escala, cada spike segue este loop:

decompor  →  pesquisar  →  construir  →  veredito
   ↑__________________________________________↓
                  iterar sobre descobertas

1. Decompor

Divida a ideia do usuário em 2-5 perguntas de viabilidade independentes. Cada pergunta é um spike. Apresente-as como uma tabela com formatação Dado/Quando/Então:

#	Spike	Valida (Dado/Quando/Então)	Risco
001	websocket-streaming	Dada uma conexão WS, quando LLM transmite tokens, então o cliente recebe blocos < 100ms	Alto
002a	pdf-parse-pdfjs	Dado um PDF de várias páginas, quando analisado com pdfjs, então texto estruturado é extraível	Médio
002b	pdf-parse-camelot	Dado um PDF de várias páginas, quando analisado com camelot, então texto estruturado é extraível	Médio

Tipos de spike:

• padrão — uma abordagem respondendo a uma pergunta
• comparação — mesma pergunta, abordagens diferentes (número compartilhado, sufixo de letra a/b/c)

Boas perguntas de spike: viabilidade específica com saída observável. Más perguntas de spike: muito amplas, sem saída observável, ou apenas "leia a documentação sobre X".

Ordene por risco. O spike com maior probabilidade de invalidar a ideia é executado primeiro. Não adianta prototipar as partes fáceis se a parte difícil não funcionar.

Pule a decomposição apenas se o usuário já souber exatamente o que quer testar e disser isso. Então aceite a ideia como um único spike.

2. Alinhar (para ideias com múltiplos spikes)

Apresente a tabela de spikes. Pergunte: "Construir tudo nesta ordem, ou ajustar?" Deixe o usuário remover, reordenar ou reformular antes de escrever qualquer código.

3. Pesquisar (por spike, antes de construir)

Spikes não são livres de pesquisa — você pesquisa o suficiente para escolher a abordagem certa, depois constrói. Por spike:

1. Resuma. 2-3 frases: o que é este spike, por que é importante, risco principal.

2. Apresente abordagens concorrentes se houver escolha real:

   Abordagem	Ferramenta/Biblioteca	Prós	Contras	Status
   ...	...	...	...	mantida / abandonada / beta

3. Escolha uma. Justifique. Se 2+ forem viáveis, construa variantes rápidas dentro do spike.

4. Pule pesquisa para lógica pura sem dependências externas.

Use ferramentas Hermes para a etapa de pesquisa:

• web_search("python websocket streaming libraries 2025") — encontre candidatos
• web_extract(urls=["https://websockets.readthedocs.io/..."]) — leia a documentação real (retorna markdown)
• terminal("pip show websockets | grep Version") — verifique o que está instalado no ambiente virtual do projeto

Para bibliotecas sem páginas de documentação, clone e leia o arquivo README.md / examples/ via read_file. Context7 MCP (se o usuário o tiver configurado) também é uma boa fonte — mcp_*_resolve-library-id depois mcp_*_query-docs.

4. Construir

Um diretório por spike. Mantenha-o autônomo.

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

Tendência para algo com que o usuário possa interagir. Spikes falham quando a única saída é uma linha de log que diz "funciona". O usuário quer sentir o spike funcionando. Opções padrão, em ordem de preferência:

1. Uma CLI executável que recebe entrada e imprime saída observável
2. Uma página HTML mínima que demonstra o comportamento
3. Um pequeno servidor web com um endpoint
4. Um teste unitário que exercita a pergunta com asserções reconhecíveis

Profundidade sobre velocidade. Nunca declare "funciona" após uma única execução de caminho feliz. Teste casos de borda. Siga descobertas surpreendentes. O veredito é confiável apenas quando a investigação foi honesta.

Evite a menos que o spike especificamente exija: gerenciamento complexo de pacotes, ferramentas de build/bundlers, Docker, arquivos de ambiente, sistemas de configuração. Codifique tudo na raça — é um spike.

Construindo um spike — uma sequência típica de ferramentas:

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")
# Observe a saída, itere.

Spikes de comparação paralela (002a / 002b) — delegue. Quando duas abordagens podem rodar em paralelo e ambas precisam de engenharia real (não protótipos de 10 linhas), distribua com delegate_task:

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

Cada subagente retorna seu próprio veredito; você escreve o confronto direto.

5. Veredito

O README.md de cada spike fecha com:

## Veredito: VALIDADO | PARCIAL | INVALIDADO

### O que funcionou
- ...

### O que não funcionou
- ...

### Surpresas
- ...

### Recomendação para a implementação real
- ...

VALIDADO = a pergunta central foi respondida sim, com evidências. PARCIAL = funciona sob as restrições X, Y, Z — documente-as. INVALIDADO = não funciona, por esta razão. Este é um spike bem-sucedido.

Spikes de comparação

Quando duas abordagens respondem à mesma pergunta (002a / 002b), construa-as em sequência, depois faça um confronto direto ao final:

## Confronto direto: pdfjs vs camelot

| Dimensão | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| Qualidade da extração | 9/10 estruturado | 7/10 apenas tabelas |
| Complexidade de setup | npm install, 1 linha | pip + ghostscript |
| Desempenho em PDF de 100 páginas | 3s | 18s |
| Lida com texto rotacionado | não | sim |

**Vencedor:** pdfjs para nosso caso de uso. camelot se precisarmos de extração focada em tabelas depois.

Modo Frontier (escolhendo o próximo spike)

Se spikes já existem e o usuário diz "qual deve ser o próximo spike?", percorra os diretórios existentes e procure por:

• Riscos de integração — dois spikes validados que tocam no mesmo recurso, mas foram testados independentemente
• Transferências de dados — a saída do spike A foi assumida compatível com a entrada do spike B, nunca provada
• Lacunas na visão — capacidades assumidas, mas não comprovadas
• Abordagens alternativas — ângulos diferentes para spikes PARCIAL ou INVALIDADO

Proponha 2-4 candidatos como Dado/Quando/Então. Deixe o usuário escolher.

Saída

• Crie spikes/ (ou .planning/spikes/ se o usuário estiver usando convenções GSD) na raiz do repositório
• Um diretório por spike: NNN-nome-descritivo/
• README.md por spike captura pergunta, abordagem, resultados, veredito
• Mantenha o código descartável — um spike que leva 2 dias para "limpar para produção" foi um spike ruim

Atribuição

Adaptado do fluxo de trabalho /gsd-spike do projeto GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). O sistema GSD completo oferece estado persistente de spikes, rastreamento MANIFEST e integração com um pipeline de desenvolvimento orientado a especificações mais amplo; instale com npx get-shit-done-cc --hermes --global.