About spike
A skill for testing uncertain technical approaches with disposable feasibility experiments before planning a change. It isolates the riskiest question in a minimal runnable prototype, then returns a verdict rather than production code.
Key features
- 01Identify concrete feasibility questions
- 02Prioritize the riskiest unknown
- 03Build a minimal scratch experiment
- 04Capture observable results
- 05Return a feasibility verdict
Use cases
- 01Test an uncertain external API approach
- 02Check whether a proposed change is viable
- 03Resolve technical risks before writing specifications
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/spikein Claude Code to confirm it loaded.
Details
From the project READMEspike
A disposable feasibility experiment. When a change carries unproven technical risk — an untested approach, an external API, an open "is this possible?" — spike it before writing any OpenSpec artifacts. The point is to answer the risky question for the price of a script, so an unviable idea is killed cheaply.
Core principle: the code is throwaway. A spike that needs cleanup was over-built. Only the verdict survives.
When to use
Risk-gated, not mandatory. Spike only when feasibility is genuinely unclear. If the approach is obviously viable, skip straight to planning. Research enough to pick an approach, then spike the riskiest unknown first — there is no point prototyping the easy parts if the hard part does not work.
Process
- Decompose — frame 2–5 concrete feasibility questions (Given/When/Then), ordered by risk. The most dangerous unknown goes first.
- Align — show the questions and the plan; let the user trim before you write code.
- Build minimal — write the smallest runnable thing in a scratch location
(
/tmp, a REPL, a one-offcurl) — never inside the change's worktree. Hardcode everything. No packaging, Docker, config, or build tooling. It is a spike. - Observe — run it and capture the real output. A spike with no observable result proved nothing.
- Verdict — close with exactly one, plus a sentence of why:
- VALIDATED — the approach works; proceed to plan the change.
- PARTIAL — only a subset works; narrow scope to that subset, then plan.
- INVALIDATED — the approach does not work; do not create the change.
After the spike
Discard the scratch code. Hand the verdict back to the caller — in the
spec-driven-tdd Plan phase it gates whether /opsx:propose runs at all.