Help me plan a bug bash before a major release. Keep it productive — not 5 hours of 'I clicked around and nothing seems broken'.
WHAT'S RELEASING: {feature_or_version_summary}
RISK AREAS — be honest about which parts you don't fully trust: {paste}
TEAM SIZE for the bash: {how_many_people}
ROLES participating: {eng / pm / design / cs / others}
TIME ALLOTTED: {hours}
WHAT EXISTING TESTS COVER: {unit_e2e_summary — to avoid duplicating}
USER PERSONAS we care about: {list}
KNOWN FRAGILE FLOWS from past releases: {list}
WHEN THE RELEASE GOES OUT: {date}
DESIGN:
1. **Scope sheet** — what's IN-scope for the bash + what's OUT. Bug bashes get derailed by people fixing the wrong things.
2. **Test charters** — 4-6 explicit charters, each assigned to 1-2 people. Each charter has a goal, a persona, a 1-hour box, and an artifact to produce.
3. **Per-persona walkthroughs** — what to actually try as each persona.
4. **Cross-cutting checks** — accessibility, mobile, slow network, locale, edge data.
5. **Bug intake template** — exactly what info every bug needs (so triage doesn't take 3 hours).
6. **Severity rubric** — block-release / fix-during-rollout / next-sprint / nope.
7. **The 'last 15 minutes' protocol** — what everyone does to wind down (file remaining bugs, vote on must-fix).
8. **Post-bash decision meeting** — 30 min to triage what was found.
No 'have fun!' — actual operational doc.0 copies·0 saves·5 views
227 words·1,400 chars
Sample output
Releasing: new pricing page + checkout flow. Risk: discount-code logic + tax calculation. Team: 6 (3 eng, 1 PM, 1 design, 1 CS). Time: 3 hours. Existing tests: unit + 8 Playwright happy-paths. Personas: new visitor, returning logged-in, paid customer. Known fragile: Safari iOS payment flow. Release: Thursday.
Scope sheet:
IN scope:
OUT of scope:
Parameters
Text generation parameters
FAQ
Charter the bug bash. People who 'click around and look for bugs' produce 60% noise. People given a 1-hour charter with a specific persona and artifact produce 5-10 real bugs each. Same hour, ten times the value. The prompt targets ChatGPT (GPT-4) and lives in the Coding & Development category on mycopyprompt.
This prompt is written for ChatGPT (GPT-4). It's a text/chat prompt — paste it into ChatGPT (GPT-4) (or compatible LLMs like Claude or GPT-4) to get the expected output.
1. Click the Copy button on this page to copy the full prompt. 2. Open ChatGPT (GPT-4). 3. Paste the prompt into a new conversation. 4. Replace any {placeholders} with your specifics, then send. Most prompts produce the right output on the first try; complex ones may need 1-2 iterations.
Yes — every prompt on mycopyprompt is free forever. No paywall, no signup wall for browsing or copying. You can use it for personal or commercial work, just don't redistribute the entire mycopyprompt library.
Absolutely — most prompts are templates. Look for {placeholders} (curly braces) and swap them with your own values. You can also reword sections, add constraints, or chain it with other prompts.
See the "Sample output" panel above — that's a real example of what ChatGPT (GPT-4) returns when this prompt runs. Your output will vary in wording but should follow the same structure and depth.
Similar prompts
Matched against every prompt in the catalog by title.
No new feature requests during the bash. Only bugs.
Test charters (1 hour each, 2 people each):
Charter 1: Discount code stacking — Erin + Mei
Charter 2: Tax calculation cross-region — Adam + James
Charter 3: Safari iOS mobile end-to-end — Devon + design lead Lin
Charter 4: Edge data — solo (Mei after Charter 1)
Charter 5: Slow network + payment timeouts — Erin (after Charter 1)
Charter 6: Email confirmation — CS lead Sasha
Per-persona walkthroughs:
New visitor: arrive at pricing → no account → enter info → checkout → confirm. Returning logged-in: logged in to existing account → check current plan → upgrade. Paid customer: current paying user → switch plan → handle prorating.
Cross-cutting checks (everyone):
Bug intake template:
Title: [short — 'Discount code stacks twice on returning user upgrade']
Severity: [block / fix-during-rollout / next-sprint / nope]
Where: [URL + browser + device]
Repro steps:
1. ...
2. ...
3. ...
Expected: [what should happen]
Observed: [what actually happened]
Screenshots/video: [link]
Logs (if any): [paste relevant lines]
Found during charter: [#]
All bugs go in a single Notion / Linear board with this exact template.
Severity rubric:
Decision authority: PM has final call on severity; eng owns whether 'fix during rollout' is feasible.
Last 15 minutes protocol:
Post-bash 30-min triage meeting (same day):
Verdict at end: ship-ready or delay. Send a 4-line summary to the broader team that same evening.