# Sort changes into keep, fix or drop: prompt chain Turn feedback on a current plan or service into a short list of what to keep, what to fix, what to drop, and what needs a decision, with a quote behind each move. **Made for:** A team member preparing a revision list from feedback on a form, service, event or draft plan. ## Before you start Have these ready: - **Current version** (required): List the parts of the current version, with names you can recognize in the feedback. - **Feedback to sort** (required): Paste comments with a label for each speaker or source. Remove personal details first. - **What the version must achieve** (required): Say what successful use looks like and any part that must stay. **How to use this chain** 1. Open a new chat in any AI assistant. 2. Copy the Step 1 prompt, replace every [PASTE HERE: ...] slot with your material, and send it. 3. Keep each answer: later steps ask you to paste it in. Run each step in the same chat or a new one; a new chat keeps steps from blurring together. 4. After a step that has a check, run the check before you move on. ## Step 1: Capture each feedback point Put each distinct comment beside its source before proposing a change. Copy this prompt: ````text You are a careful feedback reader. Your task is to extract each distinct point in the feedback about the current version. Current version: [PASTE HERE: Current version] Feedback: [PASTE HERE: Feedback to sort] Rules: - Give each point its speaker or source label and quote the relevant words exactly. - If one comment makes two points, use two rows. Keep praise as well as problems. - Do not infer a cause or suggest a fix yet. Do not add a comment that is not in the feedback. Return one markdown table: | Source | Feedback (quote) | Current part | ```` **You get back:** A feedback table with exact quotes and the current part each one concerns. **Check after Step 1: Each feedback quote appears in the supplied comments** Check by eye: Every quote in the Feedback (quote) column appears word for word in the feedback to sort. If it does not pass: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it. ## Step 2: Sort each part into an action Make an evidence-linked keep, fix, drop or ask decision for each current part. Copy this prompt: ````text You are a service editor who makes practical changes from evidence. Your task is to sort the current parts into keep, fix, drop or ask. Goal: [PASTE HERE: What the version must achieve] Current version: [PASTE HERE: Current version] Feedback points: [PASTE HERE: the answer from Step 1 (Capture each feedback point)] Rules: - Keep means the part serves the goal and no supplied evidence calls for changing it. - Fix means the feedback shows a specific problem and a bounded change could address it. - Drop means the part is unnecessary for the stated goal and its removal follows from the current version and feedback. One dislike alone is not enough. - Ask means the feedback conflicts or the evidence is too thin to make a safe choice. - Give a short reason citing a feedback source or the stated goal. Do not treat silence as proof that a part works. Return one markdown table: | Current part | Action | Evidence and reason | The Action column must say exactly keep, fix, drop or ask. ```` **You get back:** A decision table with a bounded reason for each current part. **Check after Step 2: Every part has one allowed action** Check by eye: Every row of the table has one of "keep", "fix", "drop" or "ask" in the Action column. If it does not pass: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it. ## Step 3: Write the revision list Translate fix and drop rows into concrete edits while protecting kept parts. Copy this prompt: ````text You are an editor writing a revision list another person can carry out. Your task is to turn the sorted actions into concrete changes. Goal: [PASTE HERE: What the version must achieve] Sorted parts: [PASTE HERE: the answer from Step 2 (Sort each part into an action)] Feedback evidence: [PASTE HERE: the answer from Step 1 (Capture each feedback point)] Rules: - For fix, name the smallest visible change and how a person can check it. - For drop, name the part to remove and any effect the removal could have. - For keep, name what should remain visible. For ask, write a specific question and who can answer it if the feedback identifies someone. - Keep proposed changes inside the current version and the supplied feedback. Do not promise improved outcomes without another test. Return one markdown table: | Part | Action | Next change or question | How to check | ```` **You get back:** A revision list and checks tied to the sorted evidence. **Check after Step 3: Every revision row gives a next move** Check by eye: Every row of the table has something written in "Part", "Action", "Next change or question" and "How to check" (a blank or a dash does not count). If it does not pass: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it. ## Step 4: Make a short change brief Put the edit list and open decisions in a short handoff. Copy this prompt: ````text You are a project coordinator writing a clear change brief. Your task is to summarize what should change and what still needs a decision. Revision list: [PASTE HERE: the answer from Step 3 (Write the revision list)] Original goal: [PASTE HERE: What the version must achieve] Rules: - Name the keep, fix, drop and ask items, or say None under an empty heading. - Put ask items under Open questions. State the check that would show a fix was made, not an outcome the evidence cannot prove. - Do not claim the changes have been tested. Do not invent an owner or deadline. Return markdown with headings Keep, Fix, Drop, Open questions and Check after editing. ```` **You get back:** A concise handoff that distinguishes edits from questions and follow-up checks. **Check after Step 4: The brief keeps open questions visible** Check by eye: The answer includes the words "Open questions". If it does not pass: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it. ## Final checks Run these on the finished result. **Final check 1: Each proposed change follows the feedback and goal** Open a new chat (so the check is not swayed by the work) and paste this check prompt: ````text You are a careful reviewer. You do not fix or rewrite the work; you only decide whether it passes one check. The check: Each proposed change follows the feedback and goal Compare the brief with [PASTE HERE: the answer from Step 1 (Capture each feedback point)] and [PASTE HERE: the answer from Step 2 (Sort each part into an action)]. Is each fix or drop justified by a quote or the stated goal, are ask items still open, and did a keep item survive? Answer FAIL and quote any unsupported change. The work to check (the answer from Step 4 (Make a short change brief)): [PASTE HERE: the answer from Step 4 (Make a short change brief)] Reply with exactly PASS or FAIL on the first line. On the second line, say in one sentence why. If it fails, name the exact item or line that fails. Do not add anything else. ```` If it does not pass: Run the step once more, and add what was wrong to the end of the prompt. If it still does not pass, fix it by hand and make a note of it. **Final check 2: You approve drops and unresolved choices** Ask yourself: Read each proposed drop against the goal and check that it will not remove needed information. Resolve or assign each open question before the revision is published. If it does not pass: Carry on, but write down the problem so whoever uses the result knows about it. ## What you end up with - A keep, fix, drop and ask table with feedback behind each action. - A short change brief with visible open questions and checks for the edits. ## Changing this chain - This sorts supplied feedback about the current version. It does not measure how common a problem is unless the feedback includes counts. - If readers disagree, use ask and name the specific decision instead of letting the loudest comment win. - Run the revised version past users again before claiming it solved a problem. --- From Logic Lab (logiclabhq.com). Free to use and adapt, with credit.