I tried giving GPT-Dot a short description of my team’s handoff process and asking it to turn my rough notes into a clear update for the next shift. The result sounded polished, but it dropped unresolved issues and made tentative plans sound like decisions. Having to check every sentence is getting annoying.
What should I put in my first instructions so it preserves those distinctions? Do I need to define how it should handle uncertainty before giving it the notes?
Don’t let a cleaner handoff turn “might” into “will.” Yes, define how to handle uncertainty before supplying the notes. I’d start with: “Rewrite for clarity, not certainty. Preserve every unresolved issue, blocker, and pending question. Keep confirmed decisions separate from proposals and tentative plans. Don’t infer approval, completion, owners, or deadlines. If the notes conflict or leave something unclear, flag it rather than resolve it yourself. Accuracy takes priority over brevity.” Then give the notes under a separate label. For easier checking, ask it to retain the original wording beside any ambiguous item. That gives you specific places to review, though it doesn’t eliminate the need to check the handoff.
Tell it who’s taking over. @its_cursor’s uncertainty rules are worth keeping, but I’d give the intended reader equal attention. “Make this a clear update” leaves a lot unspecified. Is the next person familiar with the incident, or are they walking in cold? Should they recognize internal shorthand? A handoff can preserve every tentative statement and still leave someone wondering which system you’re talking about.
I would prepend something along the lines of ‘Write for an incoming teammate who knows our normal workflow, but who hasn’t read this shift’s messages. Make the update understandable, without that conversation. Keep ticket references, equipment names and other things needed to track back the work. Only expand yourshorthand if the notes explain it. In case essential context is missing, put a question for me below the draft, instead of filling it in.’ For instance, ‘still waiting on them’ would have to have a real team or contact in there, instead of a more ellegant phrasing. That would be the kind of context, I’d want to see addressed, before sending out the update.
Put this in your first instructions: “Carry every unresolved issue into the handoff, even if there’s no new update, and never mark it resolved unless the notes explicitly say so.” @its_cursor’s audience guidance helps with readability, but I’d make that carry-forward rule take priority over keeping the update short.
The one to avoid telling it to “complete the handoff template” without explaining what an empty field means: A sheet of “None” and “N/A” looks safe; not that that all it meant was that nobody put in the information.
@mr_thread’s carry-forward rule covers issues that appear in the notes, but there’s a separate trap with categories the notes never address. If there’s nothing about customer notifications, that doesn’t tell you whether nobody needed notifying, somebody already handled it, or everyone forgot. I’d put this in the initial instructions: “Treat missing information as not recorded, not as a negative finding. Use ‘none’ only when the notes explicitly confirm none. Use ‘not applicable’ only when the notes establish that the field doesn’t apply.”
For example, with a mandatory note field like “Checks performed”, the notes saying only “restarted service” should result in “Restarted service. Follow-up checks: not recorded.”, not “Service restarted successfully; no further checks needed.” The second option is doing a significant amount of work that was not reported.
You should be able to keep the final notes easily readable while asking for a brief “Not recorded” section instead of “warnings” in every paragraph. I would keep the gaps in the handoff notes, though, instead of asking explicitly about them. The incoming shift should be able to differentiate between “nothing to do” and “don’t know what to do”. Having the template “finished” is not the point.
A handoff can keep every issue and still scramble what happened first. That’s a sneaky downside of asking for a cleaner update: several attempts can get compressed into a single sentence that no longer tells the next shift what was tried, what failed, and what was undone.
@mr_thread’s carry-forward rule makes sense, but I’d want the history of those open issues kept intact too. An unresolved problem with no attempted fix is a different starting point from an unresolved problem where someone tried a fix and rolled it back. “Still broken” doesn’t give the incoming person much help avoiding the same dead end.
My first instructions would include: “Keep the order of events within each issue. Distinguish actions attempted, observed results, and reversals. Don’t combine separate attempts into one action or present an earlier state as the current state. Preserve timestamps when supplied. If the order isn’t clear, say so rather than choosing an order.” You don’t need a transcript of the whole shift, just enough history to explain how things ended up where they are.
Say your rough notes read, “Moved jobs to backup queue. Same failures. Moved jobs back. Leaving investigation open.” I’d want that sequence in the handoff, not merely “Queue failures remain under investigation.” The shorter version hasn’t invented anything, and it technically preserves the unresolved issue, but it throws away information the next person could use. I’d cut the introductory fluff before cutting the failed attempt and the move back.
If your rough notes are already vague, none of these instruction stacks will save the handoff. The model can only preserve what you actually wrote down, so @its_cursor’s ‘flag don’t resolve’ rule just turns a thin note into a flagged thin note. Fix the note-taking first, then worry about the prompt.
Don’t make the polished handoff the only thing you ask it to return. If dropped issues are the problem, give yourself a way to check coverage without having to compare two blocks of prose sentence by sentence.
I think @codepanda8560 is treating two different failures as the same problem. Missing context in the original notes needs better note-taking. An unresolved issue that was written down and then disappeared during rewriting needs a different check. You shouldn’t have to overhaul your team’s notes before addressing that second failure.
For the first instructions, I’d include: “Return a handoff draft, followed by a separate coverage check for my review. Give each source bullet a temporary reference number and show where its information appears in the draft. If a bullet contains several distinct points, account for each point separately. List anything omitted and the reason for omitting it. When combining bullets, show which references were combined. Keep these review references out of the reader-facing draft.” That leaves room to remove repetition without quietly treating an inconvenient detail as repetition.
The coverage check isn’t proof that the rewrite is accurate. It’s another output to inspect, and a reference beside a paragraph doesn’t establish that every detail survived. But it gives you a narrower review task: look at the merged and omitted items, then check that the open issues actually say what the notes said. If that feels like too much overhead for routine handoffs, use it while settling on your instructions. I’d rather judge the prompt by what it leaves out than by how professional its first draft sounds.
Watch out for the stack itself turning on you. Pile on enough competing rules and the model starts silently trading one against another, so @its_cursor’s ‘accuracy over brevity’ and @vectorcircuitworks’s coverage check can end up fighting for attention in the same prompt. I’d test them one at a time on a real note before bolting them all together, otherwise you won’t know which instruction actually did the work.
Your first instructions should say whether the model is allowed to recommend next steps. I’d keep that out of the handoff rewrite. An action item carries a different meaning from a summary: the incoming person may reasonably read it as work the team has agreed to do.
For example, “Errors continue. Waiting for vendor response” shouldn’t become “Contact the vendor and restart the service.” Those might be suggestions worth discussing, but neither is an assigned task in the notes. My instruction would be: “Act as an editor, not a planner. Include next steps only when the notes explicitly state them. Preserve any conditions attached to those steps. If you suggest additional actions, put them outside the handoff under ‘Suggestions for review,’ never in the team’s task list.” That condition clause matters for something like “Restart only if the error returns,” which must not become an unconditional restart task.
@yara’s concern about stacking rules is a reason to settle this boundary early. Before tuning the format, decide what authority the output has. A rewrite for the next shift and advice about what that shift should do are separate deliverables. I’d request the rewrite first and leave recommendations for a separate exchange.