BUILD IT ONCE. USE IT AGAIN. A project handoff by Matt Klein Start a new AI project with this handoff and a small example of a recurring task. The goal is a useful first tool and a teammate who can improve it, without depending on the conversation that produced it. YOUR ASSIGNMENT Build around the work the person actually does. A spreadsheet can be the right architecture. A new application earns its place only if it makes the decision or workflow easier. 1. Define the first result. Name the user, recurring question, decision, and current process. Establish what a successful first use looks like. Choose one ordinary case, the exception most likely to mislead the user, and one small rule the teammate should be able to change. Write the expected answer or independent checking method before implementation. Keep the scope small enough to try in one session. If information is missing, prepare the parts that do not depend on it and ask one focused question. 2. Establish the source contract. Inspect the supplied files and permitted connections. For every necessary input, record its meaning, unit, identifier, source, date, and expected coverage. Expose conflicts rather than choosing the most convenient value. Define how missing, stale, duplicated, or incompatible inputs should behave. An unknown value is not zero. Preserve the raw input, place generated output separately, and label demonstration data as fictional. Keep one editable home for each business rule. Do not copy a threshold into a formula, a script, and a guide that can drift apart. 3. Deliver a working first version. Choose the simplest useful form, explain the choice briefly, then create the artifact. Put the answer, its basis, and the next action where the user can find them. Keep dates and limits inside the artifact so they travel with it. Separate the calculation from the business rule and the presentation. Make the agreed rule easy to inspect and change. Preserve an original or recoverable version. Include a refresh path: which inputs to replace, how to run, where the result appears, and how to tell the latest run is complete. If your environment cannot create or run a required file, provide the closest usable draft and state the exact limitation. 4. Check it independently. Trace the ordinary case from source through to output. Recompute the decisive value using a method that does not simply repeat the implementation. Feed it the misleading exception and watch the check reject or expose it. Check the actual delivered file in its intended format. Test a refresh with changed input. Verify that the result changes where expected, and that untouched inputs remain untouched. 5. Transfer capability. Prepare a three-part teammate trial: - Run the ordinary case and explain the answer. - Diagnose the exception and recover. - Change the agreed rule, predict the new answer, and check it. Give the teammate only the artifact and its short guide. Record whether they completed each task without the builder, what confused them, and what they changed. If no person has tried it, provide the trial script and leave its result unverified. A simulation is not adoption. Save the useful correction once, in the rule or guide where the next run will use it. Compare against the recipient's actual version before replacing their work. 6. Decide what deserves a second version. Identify the owner, refresh trigger, and response to a failed check. Measure a baseline and an actual trial before claiming time saved, better decisions, or adoption. Name one feature to defer or remove. Expand only when another real task or user justifies it. RETURN The working artifact and a concise guide covering inputs, run or refresh, interpretation, exceptions, editable rule, and recovery. Include the independent check record and teammate trial script. Finish with three separate statements: built, checked, and used, each supported by actual evidence. ACCEPTANCE CHECK The ordinary case is correct, the exception cannot quietly produce a misleading answer, and another person has enough information to make the small change. Only call capability transferred after a real person completes the trial. SMALL EXAMPLE, FICTIONAL Build a reorder worksheet from stock, committed units, daily demand, lead time, and buffer days. Suggested order is max(0, target - net available). For one item: stock 20, committed 6, demand 5 per day, lead time 3 days, buffer 1 day. Net available is 14; target is 5 × (3 + 1) = 20; the suggestion is 6 units. This simple example has no incoming stock or minimum order constraint. With stock 30 and the other inputs unchanged, net available is 24 and the suggestion must be 0, not a negative order. An item with unknown demand must show "Needs review." The teammate changes buffer days from 1 to 2 on the original item, predicts 11 units, and verifies the result. The worksheet suggests an order; it does not place one. WORKING BOUNDARY Use the agreed draft destination. Existing authorization governs actions; preparing a tool does not by itself authorize new external messages, live data changes, access grants, or publication. Keep credentials and restricted material out of the handoff. MY STARTING CONTEXT The recurring task: Who will use it: What they need to decide: What happens today: Files or sources: One good example, if available: Constraints: If a field is blank, help work it out. Filling in the form is not the project.