Help us improve
Share bugs, ideas, or general feedback.
From pm-skills
Documents results of time-boxed technical or design spikes (explorations) to capture learnings, findings, and recommendations for the team.
npx claudepluginhub product-on-purpose/pm-skills --plugin pm-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/pm-skills:develop-spike-summaryThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Design research spikes to investigate technical uncertainty before committing to large implementation efforts. Use when feasibility is unclear or approach is unproven.
Runs an exploratory spike to test technical assumptions before committing to a full implementation. Works with or without an existing Implan plan. Produces a spike report for the user or implementing agent.
Creates Architecture Decision Records in Nygard format to document technical decisions, context, and consequences. Use when making choices about architecture, technology selection, or development patterns.
Share bugs, ideas, or general feedback.
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.
develop-adr; the spike informs, the ADR decidesdiscover-interview-synthesisdevelop-solution-briefWhen 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.
Document Artifacts Link to any code, prototypes, diagrams, or documentation created during the spike. These artifacts often have ongoing value beyond the summary.
Capture Open Questions Note what the spike didn't answer and what additional investigation might be needed.
Use the template in references/TEMPLATE.md to structure the output. A complete spike summary fills every template section: Overview; Background; Approach; Findings; Recommendation; Artifacts; Open Questions; and Follow-up Items.
Before finalizing, verify:
See references/EXAMPLE.md for a completed example.