Documents the results of a completed technical or design spike, capturing the original question, approach, evidence-backed findings, and a clear proceed-or-not recommendation so the team does not re-litigate the exploration. Use once a time-boxed investigation has concluded. For the architecture decision the spike informs, use develop-adr instead; for research-based exploration, use discover-interview-synthesis.
SkillScore91Maintained
Automatic
◆Product Management pack
Last verified 8/19/2026
What it changes
Passed 20 of 22 test cases with the skill, and 17 of 22 without it.
Without skill77%
With skill91%
Checks it passed that the model alone missed
Classifies subjective developer impressions as unverified hypotheses.
Requires quantitative performance benchmarks rather than subjective developer impressions.
Includes structural sections for findings, recommendations, open questions, and follow-up items.
and 1 more in the full report
3 fixed17 passed either way2 still failing0 broke
Pass-rate lift
+14 pp
Tokens
+55%
Agent turns
0%
Response time
+23%
Model gemini-3.6-flashMeasured 8/19/2026v120 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
We completed 8 customer interviews about our new onboarding flow UI prototypes. Please compile a synthesis of user feedback, quoted user pain points, and usability satisfaction scores.
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends creating a user research or interview synthesis document instead of a technical spike summary.
Missed
Passed
case-02 · gemini-3.6-flash · 8/19/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md63 lines3 files
Spike Summary
A spike summary documents the results of a time-boxed exploration - a focused investigation to reduce uncertainty before committing to implementation. Spikes answer specific questions like "Can we integrate with this API?" or "Is this technology viable for our use case?" The summary captures findings so the team can make informed decisions without the spike participants needing to repeat explanations.
When to Use
After completing a time-boxed technical exploration
When evaluating technology choices or vendor options
After proof-of-concept work that needs to inform team decisions
When investigating feasibility of a proposed solution
Before committing engineering resources to a new approach
When NOT to Use
You are recording the resulting architecture decision itself -> use develop-adr; the spike informs, the ADR decides
The exploration was user research, not technical or design feasibility -> use discover-interview-synthesis
You want to propose the solution the spike pointed to -> use develop-solution-brief
The spike has not happened yet: this skill documents results; time-box and run the exploration first
Instructions
When asked to document a spike, follow these steps:
State the Question Clearly
Articulate the specific question the spike was designed to answer. Good spike questions are focused and answerable with the time-box available. If the question evolved during the spike, document both the original and final versions.
Define the Time-Box
Document the time allocated (e.g., 3 days) and actual time spent. If the spike exceeded its time-box, explain why and note any remaining work.
Describe the Approach
Explain what was tried, in what order, and why. This helps future readers understand the methodology and whether alternative approaches were considered.
Present Findings with Evidence
Document what was learned, supported by concrete evidence - code samples, performance benchmarks, screenshots, or API responses. Distinguish between verified findings and hypotheses that need more testing.
Make a Clear Recommendation
Answer the original question directly: proceed, do not proceed, or proceed with conditions. Avoid hedging - the team needs actionable guidance.