spike

Validate build feasibility with disposable prototypes and structured verdicts.

Updated May 16, 2026
One-click install
npx skills add https://github.com/jaredcroxton/hermes-mirror --skill spike-jaredcroxton
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spike
Source: https://github.com/jaredcroxton/hermes-mirror/tree/main/agents/skills/software-development/spike
Command: npx skills add https://github.com/jaredcroxton/hermes-mirror --skill spike-jaredcroxton

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Spike helps you de-risk a proposed build by turning vague “can we do this?” into concrete feasibility evidence you can act on.

Core Features & Use Cases

  • Feasibility decomposition: Breaks the idea into 2–5 independent, observable feasibility questions with explicit Given/When/Then framing.
  • Evidence-driven build: Builds the smallest, most interactive artifact possible (CLI, small HTML, tiny server, or tests) to produce real outputs rather than “it works” logs.
  • Comparable verdicts: Produces a structured verdict for each spike (VALIDATED | PARTIAL | INVALIDATED) and recommends what to do next for the real build.

Quick Start

Ask the AI to run a spike to test whether your approach is feasible before committing to the full implementation.

Frequently Asked Questions about spike

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate the feasibility of an engineering idea before committing code?▼

Validate feasibility by decomposing the idea into 2–5 independent Given/When/Then questions and building minimal disposable prototypes that produce real observable outputs. This method yields a structured VALIDATED, PARTIAL, or INVALIDATED verdict to guide your next steps.

What is a spike in software engineering and when should I use one?▼

A spike is a disposable prototype used to de-risk proposed builds when research alone is insufficient. Use a spike for multi-approach exploration, unknown integration risks, and uncertainty-heavy features to generate concrete feasibility evidence before committing to full implementation.

How do I de-risk unknown integration issues during feature planning?▼

De-risk integration issues by building the smallest interactive artifact possible, such as a CLI, small HTML page, or tiny server, to test specific feasibility questions. This evidence-producing approach replaces guesswork with observable results and a structured recommendation.

Can I test multiple technical approaches without building the full features?▼

You can test multiple approaches by framing each as an independent, observable feasibility question with explicit Given/When/Then criteria. The process builds minimal targeted artifacts per question, producing comparable verdicts to recommend what to do for the real build.

Does feasibility validation require extensive research before prototyping?▼

Feasibility validation requires only minimal targeted research before building a spike. The focus shifts quickly to creating an observable artifact that produces real outputs, ensuring you gather concrete evidence efficiently rather than relying solely on preliminary research.

Why use disposable prototypes instead of standard research for uncertainty-heavy features?▼

Use disposable prototypes because research alone is often insufficient for uncertainty-heavy features. Prototypes produce real observable outputs and evidence rather than assumptions, yielding a structured verdict that directly recommends the next action for your real build.