spike

Run a spike: decompose the idea into 2-5 independent feasibility questions framed as Given/When/Then, order them by risk, then build a small throwaway prototype for each. Close every spike with a VALIDATED, PARTIAL, or INVALIDATED verdict.

Build comparison spikes with a shared number and letter suffixes, such as 002a and 002b, testing each approach against the same question. Finish with a head-to-head table covering extraction quality, setup complexity, and performance, then declare a winner for your use case.

Skip spiking when the answer is knowable from documentation or reading existing code, when the work is on the production path and needs real planning, or when the idea is already validated. Spikes exist only for questions research cannot answer.

A good spike question targets a specific feasibility concern with observable output, such as whether websocket streaming delivers chunks under 100ms. Bad questions are too broad, produce nothing observable, or amount to just reading documentation.

Each spike lives in its own directory with a README and minimal code, biased toward something interactive like a runnable CLI, a small HTML page, or a single-endpoint server. Hardcode configuration, avoid build tooling, and test edge cases before declaring a verdict.