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 dec

<! PM Skills https://github.com/product on purpose/pm skills Apache 2.0 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: 1. 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. 2. 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. 3. 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. 4. 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. 5. Make a Clear Recommendation Answer the original question directly: proceed, do not proceed, or proceed with conditions. Avoid hedging the team needs actionable guidance. 6. Document Artifacts Link to any code, prototypes, diagrams, or documentation created during the spike. These artifacts often have ongoing value beyond the summary. 7. Capture Open Questions Note what the spike didn't answer and what additional investigation might be needed. Output Format 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. Quality Checklist Before finalizing, verify: [ ] Original question is clearly stated [ ] Time box is documented (allocated vs. actual) [ ] Findings are supported by evidence, not just opinions [ ] Recommendation directly answers the question [ ] Artifacts (code, diagrams) are linked or attached [ ] Open questions identify remaining unknowns Examples See references/EXAMPLE.md for a completed example.

develop-spike-summary