The prompt
Score 10 of 10, Excellent
Use it when You need every step, owner, check and rollback point for a launch or switchover.
- {{launch_description}}
- {{go_live_window}}
- {{affected_users}}
- {{teams}}
- {{rollback_options}}
- {{plan_notes}}
Full prompt and why it works
Prompt
What is going live: {{launch_description}} Go-live date and time window: {{go_live_window}} Who is affected: {{affected_users}} Teams and roles involved: {{teams}} How we could go back if it fails: {{rollback_options}} Plan and notes so far: """ {{plan_notes}} """ Task: Build a go-live checklist for this launch, for the launch lead and the teams involved to work through and sign off. A good result means nothing depends on someone remembering a step, every step has an owner and a check, and we know in advance when and how we would roll back. Format: numbered tables with the columns #, Step, Owner (role), When, Done check (how we know it worked), If it fails. Use these sections: 1. Readiness, from two weeks to one day before: testing signed off, data and backups, access and permissions, support staffed, training done, communications sent, and a freeze on other changes. 2. Go or no-go: the meeting time, who decides, and the criteria, written as measurable conditions agreed in advance, for example "all critical test cases passed" or "backup restored successfully in rehearsal". 3. Cutover: the steps in order, with times relative to the start (T+0, T+30 minutes), a check after each critical step, and the point of no return clearly marked, after which rolling back costs more than fixing forward. 4. Rollback: the conditions that trigger it, who decides, the steps, and how long it takes. 5. After go-live: checks in the first hour, the first day and the first week; who watches what; how users report problems; and when the extra support ends. 6. Communications: who is told what, and when, before, during and after. Then a contact list with roles, and a sign-off line for each team. Requirements: - Use only systems, teams and dates from my notes. Where a step needs something I have not given, do not guess: write "[to confirm]". - Write each step as an action someone can tick off, starting with a verb. - Up to 60 steps in total. Group small steps rather than dropping them. If my notes do not describe a way to roll back, put that at the top as the first open issue, because a launch without a tested way back should not get a "go".
Variables
- {{launch_description}}
- For example "new payroll system replacing the old one for all staff".
- {{go_live_window}}
- For example "Saturday, 8 a.m. to 2 p.m.".
- {{affected_users}}
- Who will notice the change, and roughly how many people.
- {{teams}}
- Teams and roles taking part, for example "IT, payroll, the vendor's support team".
- {{rollback_options}}
- How you could return to the old state, or "not worked out yet".
- {{plan_notes}}
- Your launch plan, test status, dependencies and anything already agreed.
Why it works
- What good looks like. Go or no-go criteria are measurable conditions agreed in advance, so the decision on the day is a check, not a debate under pressure.
- Format. Every step has an owner, a timing, a done check and a fallback, with the point of no return marked, which makes the checklist usable in the middle of a cutover.
- If unsure. A missing rollback plan is raised as the first open issue, because a launch without a tested way back should not go ahead.