spike

Run a time-boxed spike workflow with research, prototyping, and evaluation phases.

10|5|Updated Jan 5, 2026
One-click install
npx skills add https://github.com/phuthuycoding/moicle --skill spike-phuthuycoding
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spike
Source: https://github.com/phuthuycoding/moicle/tree/main/assets/skills/spike
Command: npx skills add https://github.com/phuthuycoding/moicle --skill spike-phuthuycoding

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Spike/Research workflow provides a structured, time-boxed approach to exploring unknowns before committing to implementation, reducing risk and guiding decision-making early.

Core Features & Use Cases

  • Time-boxed phases (DEFINE, RESEARCH, PROTOTYPE, EVALUATE) with clear gates and artifacts like ADRs.
  • Architecture-aware exploration: prompts investigators to consult architecture references before proposing solutions.
  • Documentation outputs: produces decisions, ADRs, and learnings to inform project direction.
  • Use cases: prototyping proof-of-concepts, validating assumptions, and de-risking before full-scale development.

Quick Start

To begin a spike, create a new spike doc, define a specific research question within a timebox (2–7 days), identify relevant architecture docs, log findings as you go, and conclude with a recommended path and required artifacts (ADR/decision record).

Frequently Asked Questions about spike

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

FAQPage Schema
What is a timeboxed spike workflow for software research?

A timeboxed spike workflow is a structured approach to exploring technical unknowns before committing to implementation, reducing risk by guiding decision-making early through defined research, prototyping, and evaluation phases.

How do I create an architecture decision record after a proof of concept?

To create an architecture decision record after a proof of concept, conclude your timeboxed research by logging findings and outputting a recommended path with required artifacts like an ADR to inform project direction.

When do I need to use a spike for validating technical assumptions?

You need to use a spike for validating technical assumptions when you must prototype proof-of-concepts and de-risk unknowns before full-scale development, typically within a defined 2 to 7 day timebox.

What is the best way to structure a spike investigation across cross-stack contexts?

The best way to structure a spike investigation across cross-stack contexts is to enforce architecture read-throughs, define specific research questions within a timebox, and log findings continuously to produce decision records.

What are the limitations of using timeboxed research for architecture exploration?

A key limitation of timeboxed research is the strict 2 to 7 day boundary, meaning complex architecture exploration may require multiple sequential spikes rather than a single extended evaluation phase to thoroughly resolve unknowns.