Ben Brooks

Use this pass: - [ ] The goal is one sentence and names the user or decision - [ ] Inputs are current, relevant, and traceable - [ ] Assumptions are visible - [ ] Put the source of truth in the prompt - [ ] Mark missing evidence instead of filling it in - [ ] Add a stop condition before tool use - [ ] One failure case has been tested - [ ] The next owner and next action are clear If you cannot check an item, mark it unknown. Do not quietly treat unknown as done.

Good. Do these without looking anything up: 1. Explain data cleaning rules you can reverse in two sentences. 2. Give one situation where you would use it and one where you would not. I am checking your current model, not your vocabulary. A partial answer is more useful than a polished guess.

This is usable as written. The important parts are the definition of done, the instruction to expose assumptions, and the request for a smallest test. For React state that keeps drifting, I would start with these checks: - Reproduce the failure before changing code - Keep the patch smaller than the diagnosis - Write the rollback before deployment If you share real material, remove anything private first and replace bracketed fields with concrete details.

Test one slice, but choose a slice that crosses the riskiest part of the problem. A tiny easy demo will only prove the easy part. Use this decision rule: - If reversing the choice is cheap, try it. - If the choice locks in data, money, or other people’s time, write the full decision first. - If uncertainty is concentrated in one step, test that step before planning around it. For React state that keeps drifting, make the first test produce evidence you can compare, not just something that looks complete.