Prototype Spike
Build only enough to answer a specific question, then make the result and disposition explicit.
Preconditions
Confirm the question, success and failure evidence, time or cost bound, allowed environment, authorized writes, and whether the work must be isolated. If the question cannot change a decision, do not build a prototype.
Workflow
- Record the hypothesis, alternatives, constraints, and decision the evidence will inform.
- Isolate the work from production state and unrelated changes. Use fixtures, fakes, local data, or a worktree when appropriate and authorized.
- Choose the smallest implementation that can falsify the important assumption.
- Add focused checks that make the result repeatable. A prototype may use lighter coverage, but it cannot invent success or bypass safety controls.
- Run the experiment and record inputs, environment, observations, failures, and uncertainty.
- Compare the result with the predefined threshold and decide
discard, extend, adopt as a proposal, or inconclusive.
- Stop at the authorized boundary and list production work that would still be required.
Boundaries
- A successful spike is evidence about the tested question, not production readiness.
- Do not commit, merge, deploy, migrate, publish, or promote the prototype unless separately authorized.
- Do not use real sensitive data or production credentials merely because the implementation is temporary.
- Preserve an abort path and remove temporary state only when cleanup is authorized and the target is exact.
Output
Return Question, Hypothesis, Bounds, Prototype, Evidence, Result, Limitations, Disposition, and Production gaps.
1---2name: prototype-spike3description: Run a bounded prototype or technical spike to answer a named uncertainty with disposable or isolated work and explicit evidence. Invoke explicitly when the user authorizes implementation for learning but has not authorized production adoption, merge, or release.4license: MIT5---67# Prototype Spike89Build only enough to answer a specific question, then make the result and disposition explicit.1011## Preconditions1213Confirm the question, success and failure evidence, time or cost bound, allowed environment, authorized writes, and whether the work must be isolated. If the question cannot change a decision, do not build a prototype.1415## Workflow16171. Record the hypothesis, alternatives, constraints, and decision the evidence will inform.182. Isolate the work from production state and unrelated changes. Use fixtures, fakes, local data, or a worktree when appropriate and authorized.193. Choose the smallest implementation that can falsify the important assumption.204. Add focused checks that make the result repeatable. A prototype may use lighter coverage, but it cannot invent success or bypass safety controls.215. Run the experiment and record inputs, environment, observations, failures, and uncertainty.226. Compare the result with the predefined threshold and decide `discard`, `extend`, `adopt as a proposal`, or `inconclusive`.237. Stop at the authorized boundary and list production work that would still be required.2425## Boundaries2627- A successful spike is evidence about the tested question, not production readiness.28- Do not commit, merge, deploy, migrate, publish, or promote the prototype unless separately authorized.29- Do not use real sensitive data or production credentials merely because the implementation is temporary.30- Preserve an abort path and remove temporary state only when cleanup is authorized and the target is exact.3132## Output3334Return `Question`, `Hypothesis`, `Bounds`, `Prototype`, `Evidence`, `Result`, `Limitations`, `Disposition`, and `Production gaps`.
JovaniPink