¶

Quick facts

Phase: Develop | Version: 2.0.0 | Category: coordination | License: Apache-2.0

Try it: /spike-summary "Your context here"

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

How to Use¶

Use the /spike-summary slash command:

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

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:

/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:

/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:

/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

Output Format¶

Use the template in references/TEMPLATE.md to structure the output.