The prompt
Score 10 of 10, Excellent
Use it when You spent time investigating a technical question and need to write up what you found so the team can decide what to do.
- {{audience}}
- {{question}}
- {{timebox}}
- {{options}}
- {{spike_notes}}
- {{constraints}}
Full prompt and why it works
Prompt
Write up the technical spike below for {{audience}}, so that they can make a decision from the findings, see the evidence behind the recommendation, and know what is still unknown. The question the spike set out to answer, and why it matters: {{question}} Time spent, against the time box: {{timebox}} Options we looked at: {{options}} My notes, benchmark output, code snippets and links from the spike: """ {{spike_notes}} """ Constraints the answer must respect (budget, team skills, existing systems, deadlines): {{constraints}} Use these sections, with Markdown headings: 1. Question: one or two sentences. 2. Short answer: the recommendation, and your confidence in it (high, medium or low), with one sentence on why. 3. Options compared: a table with the columns Option, What we tried, Evidence, Strengths, Weaknesses. Evidence means measurements, errors or behavior observed in the spike, with the numbers from my notes. 4. Evidence in detail: each benchmark or test with enough setup (versions, data size, machine) that someone could run it again. 5. Recommendation and next steps, with effort estimates only where my notes give them. 6. Risks and open questions. 7. What we did not test. Keep it under 900 words, not counting the table. Keep what we observed apart from what we expect, for example: "Observed: 120 ms median with 10,000 rows. Expected, not tested: similar at 1 million rows." That example shows the form only. Do not turn a hunch in my notes into evidence, and do not leave out an option that failed; a failed attempt is a finding. Make sure someone who missed the spike could reach the same recommendation from the evidence alone. If the notes do not answer the question, say so plainly in the short answer and suggest a follow-up spike with a narrower question, rather than forcing a recommendation. If a number in my notes has no setup recorded, mark it [SETUP UNKNOWN].
Variables
- {{audience}}
- Who decides, for example "the team at Thursday's planning" or "the tech lead".
- {{question}}
- What the spike was meant to answer, for example "can we replace our search service with Postgres full-text search?".
- {{timebox}}
- For example "planned 3 days, took 4".
- {{options}}
- The approaches you looked at, one line each.
- {{spike_notes}}
- Your raw notes: what you tried, benchmark output, errors, code snippets, links.
- {{constraints}}
- For example "no new managed services this year; the team knows Python, not Go".
Why it works
- What good looks like. Observed results are kept apart from expectations, so a hunch never reads as a measured finding.
- If unsure. Notes that do not answer the question lead to a plain statement and a narrower follow-up spike, not a forced recommendation.
- Format. A comparison table plus benchmark setups that can be rerun let someone who missed the spike check the conclusion.