spike

Build throwaway prototype experiments to validate technical feasibility before committing to a real build.

Updated Jun 30, 2026
One-click install
npx skills add https://github.com/zhoulingxiao1216/testworkspace --skill spike-zhoulingxiao1216
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spike
Source: https://github.com/zhoulingxiao1216/testworkspace/tree/main/all_Skills/software-development/spike
Command: npx skills add https://github.com/zhoulingxiao1216/testworkspace --skill spike-zhoulingxiao1216

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It answers feasibility questions that research alone cannot resolve by building small, disposable prototypes, so you avoid committing to a full implementation before knowing whether an approach actually works. ## Core Features & Use Cases - Structured Spike Decomposition: Breaks an idea into 2-5 independent feasibility questions framed as Given/When/Then statements, ordered by risk so the idea-killing question runs first. - Comparison Spikes: Builds competing approaches side by side (e.g., pdfjs vs camelot for PDF parsing) and produces a head-to-head verdict table with a clear winner recommendation. - Evidence-Based Verdicts: Each spike directory closes with a VALIDATED, PARTIAL, or INVALIDATED verdict documenting what worked, what failed, and recommendations for the real build. - Use Case: Before building a real-time chat feature, spike whether WebSocket streaming delivers LLM tokens to the client under 100ms, then throw the prototype away once the question is answered. ## Quick Start Ask the agent to spike whether your chosen approach is feasible, for example: "Spike whether I can stream LLM responses over WebSockets with under 100ms latency before I commit to this architecture."

Frequently Asked Questions about spike

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

FAQPage Schema
How do I validate a technical idea before building it?▼

Decompose the idea into 2-5 independent feasibility questions, order them by risk, then build a small throwaway prototype for each in its own directory. Close each spike with a VALIDATED, PARTIAL, or INVALIDATED verdict documenting evidence and recommendations.

What is a spike in software development?▼

A spike is a disposable experiment built to answer a specific feasibility question, such as whether a library performs adequately or an integration works. Spikes are thrown away after producing a verdict and are never cleaned up for production.

How do I compare two libraries or approaches for the same task?▼

Build comparison spikes with a shared number and letter suffixes (e.g., 002a and 002b), one per approach, then write a head-to-head table covering dimensions like output quality, setup complexity, and performance, ending with a winner recommendation.

When should I not use a spike?▼

Skip spiking when the answer is knowable from documentation or reading existing code, when the work is on the production path and needs real planning, or when the idea is already validated and you can jump straight to implementation.

What makes a good spike question?▼

A good spike question targets specific feasibility with observable output, such as whether streamed tokens arrive under 100ms. Bad questions are too broad, produce no observable output, or amount to just reading documentation.