| name | spike |
| description | Use when the right approach is genuinely unknown and reality will teach faster than planning — a risky unvalidated assumption, an unfamiliar integration, "will this even work", "try something quick". The result is explicitly throwaway and does not ship. |
MasterMind — Prototype
Tight feedback loops beat big plans when the path is unclear (~/.mastermind/engineering/core/agent-loop.md, mindset.md →
design it twice). A spike buys knowledge cheaply — the discipline is keeping it knowledge, not product.
Method
- Name the question — the ONE risky unknown this spike will answer ("can the Worker stream a >20 MB
file?", "does this library handle X?"). One named question is the entry price — find it first.
- Build the smallest thing that answers it — hard-code, skip error handling, skip tests, skip
polish. Speed over quality; it's throwaway.
- Extract the learning — what did reality teach? Write down the answer and any surprises.
- Throw it away and rebuild to standard — the real version gets the full loop (design, rigor,
tests, review). Ship the rebuild; the spike gets discarded.
Rules
Time-box: 5 build-and-run attempts, roughly 30 minutes — one question needs a handful of tries, not a
day; proportionality over ceremony. An attempt is one edit → run → observe cycle against the named
question; count them out loud as you go, so the box is observable and not a vibe. Attempt 5 finished
without an answer = the box is spent, whatever the clock says.
When it expires, stop — that's a result, not a failure. Report: what you learned, what is still
unknown, and one recommendation — proceed (answer is yes, build it properly) / different approach
(this path is wrong, here's the next one) / needs more investigation (name what a second spike would
target). Then discard the code: it stays throwaway and does not ship, same as a spike that succeeded.
Extending the box is a decision, not drift. Only extend when the attempts narrowed the question
rather than wandering — say so explicitly, state the new bound (e.g. "3 more attempts"), and stop there.
Keep it isolated (a scratch branch/dir) so it can't leak into production. The deliverable is
the learning, not the code.
Output
The answer to the question + the surprises, and a clear "now build it properly" recommendation (or a
"don't build it — here's why").
