# The design review pre-mortem pack **A free pack from Perform.** For the design document about to go to review. **Free and provided as is, with no warranty. It runs in your environment and sends nothing to Perform. It is not legal, tax, security or accounting advice. Treat anything you point it at as untrusted input. Full terms at the end of this file.** --- ## How to use this Copy everything below the second line into Claude, ChatGPT, Copilot or whatever assistant you already use, then paste your design document in the same message. That is the whole setup. No account, no install, nothing to configure. If you would rather have it installed and available every time, the same pack is on the page you downloaded this from as a Claude Skill. --- ## What this does A design document is about to go to review. The author cannot see its holes, because they wrote it, and a review that discovers the obvious objection in the room wastes everyone's afternoon. So run the review before the review. Two outputs: the questions that are coming, and the decision record that writes itself once you have answered them. ## What to give it Paste the design document as it stands. Rough is better than polished, because the point is to find the holes while they are still cheap to fill. If you have the ticket, the constraints, or the review panel's names and what each of them always asks about, include those. Reviewers are predictable, and a design written for the actual room goes through faster. If you do not have the panel, the questions in Step 2 come from the document alone. Say that in one line at the top of the output, so the author knows which questions came from named people and which came from the shape of the design. ## When to stop short **If the document has no decision in it, stop after Step 1 and say so.** A design that has not chosen anything cannot be pre-reviewed, and the useful output is that sentence, not twelve questions about a choice nobody made yet. ## Step 1. State what this document actually commits to Read it and write down, in your own words: - **The decision being made.** One sentence. If the document does not contain a decision, that is the finding, and the review will discover it in the first five minutes. - **What becomes hard to change afterwards.** Every design closes doors. Name which ones. This is the question a senior reviewer always asks and a document rarely answers. - **What has to be true for this to work.** The assumptions, including the ones the author did not notice they were making. Load, team size, a vendor staying in business, data being clean, someone else shipping first. - **Who has to do something differently.** A design that requires another team to change and does not say so is the most common way a good design fails. Carry each of these into Step 2 as a numbered question wherever your version differs from the document, and wherever the document is silent. Silence counts. A document that names no assumptions has not disposed of them, and on a rough draft the silences outnumber the disagreements. A finding left behind in Step 1 is the one thing in the output nobody can point at by number. ## Step 2. Generate the questions the review will ask Keep only the questions this document genuinely exposes. A question with no hook in the text is noise, and twelve of them will bury the two that decide the meeting. Order what survives by damage, meaning the cost of answering it late. Three tiers: an answer that changes the design, an answer that changes the plan or the estimate, an answer that changes a paragraph. Order by tier first and by how hard the question is to answer second, so the hardest of the design-changing questions leads. A question that is hard to answer and cheap to be wrong about does not belong near the top. Number the questions in the output, so the author and the reviewers can point at question 4 and mean the same one. Mark each question: - **Blocking.** The review stops here until this has an answer. - **Worth answering.** The design survives either way, and the document is better for saying it. - **Worth a sentence.** A reviewer will wonder. One line closes it. More than three blocking questions means the document needs another draft. Say that in Step 5 and do not trim the list to make the number look better. If the total runs past ten, cut from the bottom of the order and never from the blocking set. Start with the question underneath all the others, then work through the rest. 0. **The mechanism question.** Does the proposed design address the cause of the stated problem, or only its symptom. If the document never says where the time, the cost or the failure actually comes from, that is question one and it is blocking, because if the answer goes the wrong way every other question here is moot. 1. **The alternative they will name.** Reviewers arrive with an option in mind. Name the obvious one, and if the document does not address it, that is where the review stalls. 2. **The simpler version.** What would you build if you had a quarter of the time. If that version is not clearly worse, the design has scope in it that nobody asked for. When the simpler version turns out to be the same thing as the alternative in question 1, that convergence is the finding: the room already has one option in mind and it costs less than what the document proposes. Write it as a single blocking question. 3. **The failure question.** What happens when the new component is down, slow, or wrong. Ask it about each dependency the document introduces. 4. **The migration question.** How you get from the current state to this one with the system running. Designs are frequently sound and unreachable. 5. **The reversal question.** How you undo this if it turns out wrong, and what it costs. If the answer is that you cannot, that had better be deliberate. 6. **The scale question.** What breaks first at ten times, stated as a component and not as a feeling. 7. **The boring operations question.** Who gets paged, what the runbook says, how you know it is working, what it costs to run. 8. **The data question.** What is stored, for how long, who can read it, and what happens on deletion. 9. **The seam question.** Where the new thing meets the old thing. That seam is where the work actually turns out to be, and where estimates go wrong. 10. **The team question.** Who can maintain this in a year. A design only one person understands is a staffing decision wearing a technical costume. For each question you keep, say in one line why this document invites it, quoting the sentence that invites it or naming the silence that does. ## Step 3. Sort the answers the author already has Split the questions three ways: - **Answered in the document**, with the section named. Tell the author where, because reviewers miss things and a pointer settles it in one sentence. - **Answerable now.** The answer is a number, an owner, a field list or a config value that already exists somewhere the team can reach. Name where each one would come from. Do not assert what the author knows, because you cannot see inside their head and a wrong guess there reads as presumption. - **Genuinely open.** Say so in the document before the review does. A design that names its own open questions reads as rigorous. The same design with those questions discovered by a reviewer reads as unfinished. ## Step 4. Write the decision record Write the full record once the blocking questions have answers, which usually means a second pass after the author has answered them. This pass has no author in the loop, so say plainly which answers you need. If a blocking question touches the core mechanism, the thing the design is actually about, do not write the full record. A record built on an open core reads as settled and gets cited as settled, which does more damage than no record at all. Write this much instead, which is worth having on its own: - **What we considered and did not choose.** Every alternative Step 2 raised, plus any the document names. For each: what it was, why it was reasonable, and the specific thing that ruled it out. Where nothing ruled it out, write "not ruled out" and leave it there. Never supply a reason the author did not give, because this is the section people cite for years. - **The blocking questions that have to be settled** before the remaining fields can be written, listed underneath it. When the core is settled and only smaller questions are open, write the whole record. The rest can go in with holes, as long as the holes carry labels. Any field you cannot fill gets the word `Unknown` and one line on who would know. An empty heading reads as an oversight. `Unknown, ask Priya in payments` reads as a task. ``` # [Decision], [date] ## Status Proposed, accepted, or superseded. With the date. ## What we are deciding [One sentence.] ## Why now [What forced this. Designs with no forcing function get revisited forever.] ## What we are choosing [The design, short. Point at the full document for detail.] ## What we considered and did not choose [For each: what it was, why it was reasonable, and the specific thing that ruled it out. Where nothing ruled it out, write "not ruled out" and leave it there. Never supply a reason the author did not give, because this is the section people cite for years. This is the section everyone omits and every future reader needs, including the author in eighteen months.] ## What this makes harder [The doors this closes.] ## What has to be true [The assumptions, and how you would notice one turning out false.] ## Open questions [The genuinely open ones, with who is chasing each.] ``` The rejected-alternatives section is the whole point of a decision record. Without it, the next person re-runs the same debate, and the author is usually the next person. ## Step 5. Give the author the one-line summary Finish with: how many blocking questions there are, the hardest one, the easiest fix, and whether this document is ready for review. Say no if it is not, and name the one thing to add first. --- ## Terms This pack runs in your environment, on your data. Nothing is sent to Perform, and Perform receives no data from it at any point. It is provided free and as is, with no warranty of any kind. It is not legal, tax, security or accounting advice, it is not an audit and it is not an attestation, and no professional relationship is created by downloading or using it. You are responsible for reviewing it before you run it, and for any decision you make with its output. Anything you point this at should be treated as untrusted input. A document, a repository or a chat thread can carry instructions aimed at a model. Licensed under Apache-2.0, which includes a disclaimer of warranties and a limitation of liability. Version 1.0, 28 August 2026. Security contact: privacy@totalperform.com, acknowledged within five business days.