mcpField
S
spike

spike

github.com/taecontrolDevelopment160 installsUpdated 1d ago
Repository

About spike

spike is a skill for answering one empirical technical question with a small runnable experiment. It guides developers from framing uncertainty through evidence-based recommendations, while keeping discovery code separate from production work.

Key features

  1. 01Frame a bounded question and decision
  2. 02Choose a low-cost decisive probe
  3. 03Build a minimal runnable experiment
  4. 04Capture execution evidence and verdicts
  5. 05Keep experimental artifacts out of production

Use cases

  1. 01Test whether a technical hypothesis holds
  2. 02Compare evidence before choosing an implementation
  3. 03Record unresolved uncertainty within a fixed bound

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/taecontrol/skills --skill spike

After installing, type/spikein Claude Code to confirm it loaded.

Bundled filesagents/openai.yaml

Details

From the project README

Spike

Answer one empirical technical question with the smallest runnable experiment that can settle it. A spike is discovery work: its deliverable is evidence, a verdict, and a recommendation—not production code.

Process

  1. Frame the uncertainty. State one observable question, why its answer affects the next decision, the relevant environment and representative conditions, what observations would validate or invalidate the hypothesis, and a cost, time, or scope bound. Inspect existing evidence first; do not build an experiment when the answer is already established.
  2. Choose the decisive probe. Design the cheapest experiment that exercises the real uncertainty. When several probes are plausible, start with the one most likely to invalidate the hypothesis at the lowest cost. Do not broaden the spike to adjacent questions.
  3. Choose the artifact's disposition. Before building, decide whether to delete the experiment after preserving its evidence or retain it in an isolated discovery location that cannot be mistaken for production code.
  4. Build only what the observation requires. Create the smallest runnable setup that exposes the behavior directly under representative conditions. Include important failure or edge cases. Avoid production hardening, reusable abstractions, unrelated cleanup, and scaffolding that does not improve the evidence.
  5. Run and capture. Record the actual commands, inputs, conditions, outputs, measurements, and failures needed to assess the question. Separate observations from interpretation. Investigate surprises only while they fit within the original bound.
  6. Conclude. Return one verdict—Validated, Partial, or Invalidated—with the supporting evidence, material surprises, remaining uncertainty, production constraints, and a recommendation for the decision that motivated the spike.

An invalidated hypothesis is a successful spike when the evidence removes uncertainty. If the bound expires before the question is settled, report Partial; do not silently extend the experiment or overstate the result.

Production boundary

The experiment does not become production code because it worked or was retained. Reusing any part of it is new production work under the project's normal practices, with no quality claim inherited from the spike.

Completion criteria

  • The question, decision relevance, representative conditions, decisive observations, and bound are explicit.
  • The experiment exercised the actual uncertainty, including material failure cases, without expanding into delivery work.
  • The verdict follows from captured execution evidence and distinguishes observation, interpretation, and unresolved uncertainty.
  • The artifact was deleted or retained only in the declared isolated location.
  • The recommendation explains what the evidence means for the next decision without treating experimental code as production-ready.

Comments

Markdown supported