Spike Summary

Try it: /pm-skills:develop-spike-summary "Your context here"

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

How to Use

Invoke the skill by name (/pm-skills:develop-spike-summary on Claude Code, $develop-spike-summary on Codex):

/pm-skills:develop-spike-summary "Your context here"

Or reference the skill file directly: skills/develop-spike-summary/SKILL.md

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.
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.

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.

Examples

See references/EXAMPLE.md for a completed example.

Output Template

Spike Summary: [Spike Title]

Overview

Field	Value
Question to Answer	[The specific question this spike investigated]
Time-Box	[Allocated time, e.g., 3 days]
Actual Time Spent	[Actual time, e.g., 2.5 days]
Spike Lead	[Name/role]
Date Completed	[YYYY-MM-DD]

Background

[Brief context explaining why this question needed investigation]

Approach

What We Tried

[Approach 1: description and rationale]
[Approach 2: description and rationale]
[Approach 3: description and rationale]

Technologies/Tools Evaluated

[Technology/Tool 1]
[Technology/Tool 2]

Findings

Finding 1: [Title]

[Description of what was discovered]

Evidence:

[Specific data point, benchmark, or observation]
[Code sample, API response, or screenshot reference]

Finding 2: [Title]

[Description of what was discovered]

Evidence:

[Specific data point, benchmark, or observation]

Finding 3: [Title]

[Description of what was discovered]

Evidence:

[Specific data point, benchmark, or observation]

Recommendation

Decision: [Proceed / Do Not Proceed / Proceed with Conditions]

[Clear rationale for the recommendation, referencing findings above]

If Proceeding

[Key consideration or condition 1]
[Key consideration or condition 2]
[Estimated effort for implementation]

If Not Proceeding

[Why this path is not recommended]
[Alternative approaches to consider]

Artifacts

Artifact	Location	Description
[POC Code]	[Link]	[Brief description]
[Architecture Diagram]	[Link]	[Brief description]
[Vendor Documentation]	[Link]	[Brief description]

Open Questions

[Open question 1]
[Open question 2]
[Open question 3]

Follow-up Items

Action	Owner	Timeline
[Next step 1]	[Who]	[When]
[Next step 2]	[Who]	[When]

Example Output

Spike Summary: Payment Processor Evaluation

Overview

Field	Value
Question to Answer	Should we use Stripe or Adyen for payment processing on our new platform?
Time-Box	3 days
Actual Time Spent	2.5 days
Spike Lead	Chen Wei, Senior Backend Engineer
Date Completed	2026-01-12

Background

Our new e-commerce platform needs payment processing capabilities. We currently process $2M/month through a legacy system and expect to scale to $10M/month within 18 months. The decision between Stripe and Adyen will affect our transaction costs, integration timeline, and ability to expand internationally.

Approach

What We Tried

Stripe Sandbox Integration: Built a complete checkout flow using Stripe Elements. Created test webhooks and simulated various payment scenarios including 3D Secure, declined cards, and refunds.
Adyen Test Integration: Implemented Adyen’s Drop-in Components in a parallel branch. Tested the same scenarios as Stripe for direct comparison.
Fee Analysis: Modeled transaction costs at current volume ($2M/month) and projected volume ($10M/month) using published pricing and obtained quotes from both vendors.
International Capability Review: Researched multi-currency support, local payment methods, and regulatory compliance for our target markets (US, EU, UK, Canada).

Technologies/Tools Evaluated

Stripe API v2024-12-18, Stripe Elements, Stripe Webhooks
Adyen API v68, Drop-in Components, Adyen Webhooks
Both tested with React 18 frontend, Node.js 20 backend

Findings

Finding 1: Stripe has significantly better developer experience

Stripe’s documentation is more comprehensive and includes more working examples. The sandbox environment required no setup - we were processing test payments within 15 minutes. Adyen required account manager approval and took 2 days to get sandbox access.

Evidence:

Time to first successful test payment: Stripe (15 min), Adyen (2 days including access wait)
Documentation score (internal rating): Stripe 9/10, Adyen 6/10
Stack Overflow questions with accepted answers: Stripe (47,000+), Adyen (3,200)

Finding 2: Adyen has lower fees at scale

At our projected $10M/month volume, Adyen’s interchange++ pricing results in meaningful savings. However, at current volume, the difference is marginal.

Evidence:

Current volume ($2M/month): Stripe $58K/year, Adyen $54K/year (7% savings)
Projected volume ($10M/month): Stripe $290K/year, Adyen $245K/year (16% savings)
Stripe’s 2.9% + $0.30 vs. Adyen’s interchange++ (avg 2.4% + $0.20 at volume)

Finding 3: Both meet international requirements, but Adyen has edge in Europe

Both processors support our target markets. Adyen has more local payment method integrations in Europe (iDEAL, Bancontact, SEPA Direct Debit) which could improve conversion for EU customers.

Evidence:

Local EU payment methods: Stripe (8), Adyen (15)
Both support Apple Pay, Google Pay, PayPal
Both are PCI Level 1 compliant

Finding 4: Stripe’s subscription billing is more mature

If we add subscription products in the future, Stripe Billing is significantly more capable than Adyen’s recurring payment features. Adyen would require a third-party subscription management tool.

Evidence:

Stripe Billing: Proration, trial periods, usage-based billing, revenue recovery
Adyen: Basic recurring only, no built-in subscription management

Recommendation

Decision: Proceed with Stripe for MVP, plan migration path to Adyen

Rationale

Stripe is the right choice for our current stage. The superior developer experience will accelerate our launch timeline by approximately 2-3 weeks. At our current volume, fee differences are minimal ($4K/year). Once we reach $10M/month and validate product-market fit, we should reevaluate migration to Adyen for cost savings.

If Proceeding

Use Stripe Elements for checkout (fastest integration)
Implement webhook handlers for payment lifecycle events
Estimated integration effort: 2 weeks for full production deployment
Build payment abstraction layer to facilitate future processor migration

Migration Trigger

Consider Adyen migration when:

Monthly transaction volume exceeds $5M consistently for 3 months
EU revenue exceeds 30% of total (local payment methods become important)
Fee savings would exceed $50K/year (pays for migration effort)

Artifacts

Artifact	Location	Description
Stripe POC	/spikes/payment-processor/stripe-poc	Working checkout flow with webhooks
Adyen POC	/spikes/payment-processor/adyen-poc	Comparable checkout for benchmarking
Fee Model	/spikes/payment-processor/fee-analysis.xlsx	Volume-based fee comparison
Architecture Diagram	/spikes/payment-processor/payment-arch.png	Proposed payment system design

Open Questions

What is the exact timeline for Stripe’s pricing negotiation at higher volumes? (Sales said “competitive” but no specifics)
How does PSD2 Strong Customer Authentication affect conversion in EU? Need production data.
Should we implement payment abstraction from day one or wait until migration is certain?

Follow-up Items

Action	Owner	Timeline
Begin Stripe production integration	Chen Wei	Week of Jan 20
Set up Stripe Radar for fraud prevention	DevOps	Week of Jan 20
Document payment abstraction interface	Chen Wei	Feb 1
Schedule Adyen volume pricing call for Q3	PM	Q3 2026

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce platform . revenue attribution feasibility spike for Campaigns v1

Prompt:

develop-spike-summary

Spike: Revenue attribution feasibility . can SendGrid open/click webhooks
be linked to Storevine purchase events within v1 timeline?

Context:
- Revenue attribution is a launch-gate requirement (confirmed in interview
  synthesis and opportunity tree)
- Engineering ADR selected SendGrid for Campaigns email delivery
- Engineering Lead asked for a 1-week spike before sprint planning

What we investigated:
- SendGrid Event Webhook payload structure and custom data fields
- Whether Storevine's customer_id can survive the email→purchase journey
- POC: send a test campaign, receive webhook, match to staging order
- Attribution window design: real-time vs. deferred (7-day)

Need: full spike summary with findings, recommendation, and follow-up
items. Will share with PM and Engineering Lead to unblock sprint planning.

Output:

Spike Summary: Revenue Attribution via SendGrid Event Webhooks

Brainshelf (Consumer): Brainshelf consumer PKM app . topic-matching algorithm spike for the Resurface digest

Prompt:

develop-spike-summary

topic matching spike for resurface. alex spent 3 days on it last
week. question: can we build something that picks saved items relevant
to what the user has been reading recently, accurate enough to not
annoy people?

three approaches tested:
1. tag-based . use OG tags, domain, URL patterns. simplest, no ML.
2. tfidf . extract article text, vectorize, cosine similarity. no
   external api. medium complexity.
3. openai embeddings . text-embedding-3-small. highest accuracy but
   adds external dependency and per-call cost.

benchmark: 3 real user libraries (anonymized), 50 items each,
manually rated as "relevant" or "not relevant" to recent reading.

results: tags = ~55% [fictional], tfidf = ~72% [fictional],
embeddings = ~84% [fictional].

recommendation: go with tfidf for mvp. meets the 70% bar we set,
no external dependency. plan to migrate to embeddings later if the
feature sticks.

Output:

Spike Summary: Topic-Matching Algorithm for Resurface Digest

Workbench (Enterprise): "Workbench enterprise collaboration platform: CRDT library evaluation for Blueprint co-editing"

Prompt:

develop-spike-summary

Spike: CRDT library evaluation for Blueprints real-time co-editing
Product: Workbench (enterprise collaboration platform)
Engineer: Nate P. (Backend Engineer)
Duration: 5 days (Dec 1-5, 2025)

Background:
- Blueprints requires real-time co-editing (20+ concurrent editors per document [fictional])
- Our editor is ProseMirror-based; no current collaboration layer
- Enterprise requirements: offline-first, conflict resolution, per-user audit trail
- Target: 20+ concurrent editors, <100ms merge latency [fictional]

Libraries evaluated:
1. Yjs (CRDT, MIT) -- y-prosemirror binding; offline-first; sub-document support
2. Automerge (CRDT, MIT) -- Rust/WASM; strong offline; no ProseMirror binding
3. ShareDB (OT, MIT) -- central server model; mature; no offline support

Findings from prototype:
- Yjs: integrated in 2 days; 45ms merge latency at 20 users [fictional]; +38KB gzipped [fictional]; offline works out of box
- Automerge: no ProseMirror binding (3-4 week custom build [fictional]); +120KB gzipped [fictional]; excellent offline
- ShareDB: integrated in 1.5 days; 62ms merge latency [fictional]; +22KB gzipped [fictional]; NO offline (disqualified)

Stakeholders: Karen L. (Eng Lead), James W. (VP Engineering)

Output:

Spike Summary: CRDT Library Evaluation for Blueprints Co-Editing

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