prp-spike

Arguments: $ARGUMENTS (and $1, $2, ...) refer to the arguments given when this skill was invoked. Take them from the user's request; if absent, infer them from the conversation.

PRP Spike — Prove or Disprove

Settle an open question by building the smallest thing that could prove it wrong. The deliverable is a verdict backed by evidence, not shippable code.

Input: $ARGUMENTS (if absent, take the question from the conversation).

When to use

• Feasibility — can this be built at all, here, with what we have?
• Fit — does this sit naturally in our stack, or fight it the whole way?
• Cost of admission — what would have to change (a primitive, an abstraction, a product constraint) to make it possible, and is that trade worth it?
• Choice — which of several approaches survives contact with the real constraints?

Not for work whose feasibility is already settled — that is prp-plan then prp-implement. Not for something already broken — that is prp-debug.

The contract

1. A spike answers one falsifiable question — or several sub-claims that share a single falsifier. No falsifiable question, no spike.
2. Kill criteria are written before the build. Deciding what counts as failure after seeing results turns a spike into a rationalization.
3. DISPROVEN is a success. It bought a decision with evidence and closed a path that would otherwise have cost weeks.
4. Spike code is throwaway by construction and never opens a PR.

Phase 1 — Frame

Convert the request into a claim that can fail, and fix the kill criteria before touching code.

Reconnaissance before framing is allowed, and usually required. A hypothesis that names a version, a field, a threshold, or a mechanism cannot be written cold — read the issue, the source, and the environment until the claim can be stated precisely. The line is the falsifier: never let findings produced by the thing built to test the claim reshape the claim. Recon sharpens the question; results must only answer it.