I’m back in the same GPT-Dot conversation about cleaning up a parts spreadsheet, and it’s asking me to explain the column labels again. We had already settled on keeping blank rows between categories, so repeating the basics is getting annoying. What’s the recommended way to get it to pick up an old task without explaining everything again? I pointed it to the earlier messages, but it still asked what the finished sheet should look like.
“Look back at our messages” is a broad request; I’d try asking for a specific task checkpoint instead: “Before editing, reconstruct our agreed column meanings, formatting rules, and remaining work from the messages you can access. Keep blank rows between categories. Flag anything you can’t recover rather than guessing.” Check that summary, then save the corrected version alongside the latest spreadsheet to reuse when resuming. If it still can’t recover the details, paste only the relevant earlier decisions, not the whole conversation. I’d include a small approved sample of the finished layout in that checkpoint, too.
Even if I were to give a correct recap, it still might require editing an old spreadsheet. A checkpoint is a good thing, but I’d want to make sure the file you’re actually working on is pinned down before I waste my time explaining recapping all the labels. I’ll ask you to attach your most recent save and tell me that this is the working file. Tell me what tab you think you need to work on and what you think your next step should be to change before making any changes. That way you have something concrete to check off of rather than you telling me yes I remember the last time we stopped and it’s ready to go.
If the next job is adjusting column widths, you shouldn’t need to explain what every parts code means. If it’s merging entries that might represent different parts, then yes, those definitions matter. I’d push back on restarting the entire explanation before finding out which missing detail actually blocks the next edit.
Pinning down the working file makes sense. But a correct file and a tidy recap still leave room for “cleaning up” to mean something you never authorized. Stop using that broad instruction once you resume. Give it a specific change and make everything else off-limits. Your category spacing is a good example of something that should stay untouched, regardless of whether it thinks removing empty rows would look cleaner.
I’d send something like: “We’re continuing, not starting a new cleanup. Leave row order, category spacing, headers, and cell values unchanged unless the next requested edit specifically requires changing them. If you need a column definition, name the column and explain which decision depends on it. Don’t ask me to redefine the whole sheet.” Then state the actual next edit. If that edit involves interpreting the data, answer the relevant question. If it doesn’t, there’s no reason to spend another round rebuilding the glossary.
I’d change the stopping rule, too: an unclear column should block changes to that column, not trigger a fresh interview about the entire workbook. Tell it to leave uncertain items alone and report what it skipped. That gives you a smaller problem to resolve instead of another round of explaining settled decisions. The goal isn’t to get it to say it remembers. It’s to keep missing context from turning into unnecessary work or unwanted edits.
You haven’t indicated whether the issue is with changing the sheet incorrectly or asking the same question multiple times. I would treat these two cases differently because an annoying question is a waste of time, whereas a plausible yet wrong spreadsheet change is a task to be redone.
I will say upfront that I am not interested in a general recap of my requirements. If possible, let’s test the edited version of the spreadsheet on the next requested change and a limited portion of the sheet, including a category boundary. This way, I can see the changes without asking you to redo the whole sheet again in case of an error.
You can check if the changes have been made correctly in the excerpt of the spreadsheet according to your previous instructions. For your sheet, that would include checking if the separating rows were left untouched; for my sheet, checking if the changes made are those that were requested. If both are correct, I can take your suggestion as a basis for further editing.
Alternatively, if I wanted to go through the entire spreadsheet, I would ask you to apply the suggested changes to a copy of the sheet and make a list of the cells changed or left unedited. So you can see my edits as a reference sheet for checking other cells rather than a guarantee that nothing else has been changed.
If the limited editing sample is to my liking, I can ask you to proceed to the next stage of editing. If not, I will show you what exactly was done incorrectly rather than asking you to try to remember the whole conversation.
By suggesting a checkpoint, you describe the task well enough. Checking an excerpt of the spreadsheet shows me that the changes made were correct, and the changes left unmade are the ones that should be done next.
If this is a long-running chat that’s been going for weeks, the asking-again problem probably isn’t the model being lazy. It’s the conversation outgrowing what it can actually read. Older turns fall out of reach, so when it says ‘remind me what the columns mean,’ it may genuinely no longer see where you agreed on that. No amount of ‘look back at our messages’ fixes a window it can’t reach.
That changes how I’d treat the whole thing. @novawizard7308 is right that a checkpoint beats a vague ‘remember our chat,’ but I’d stop storing the rules inside the chat at all. Put the column glossary, the blank-row rule, and the remaining steps in the spreadsheet itself, like a small notes tab or a header block. Then every resume starts with you attaching the file and it reading its own instructions off the sheet. The context lives with the data instead of in a thread that keeps eroding.
Where I’d push back a little is @hyperscript_86’s idea of testing a small edited sample across a category boundary. Good in theory, but a tiny excerpt loses the surrounding structure, and these models are weirdly prone to ‘tidying’ what looks like a stray empty row when they only see a fragment. If you test on a slice, keep enough rows above and below the boundary that the spacing clearly reads as intentional, otherwise you’re inviting the exact edit @0xserver6 warned about.
Honestly the blunt version is this: assume it remembers nothing between sessions and build your workflow around that. One canonical file, rules written into it, and a single named edit per round. If it still asks you to redefine everything, that’s your cue it lost the context, not a reason to re-teach the sheet by hand.
Do not follow up on everything you have talked about so far, if some of that discussion was about testing ideas. What puzzles me about ‘look back through the chat’ is how it would be able to differentiate between a suggestion and something you have actually approved of. Say you considered deleting empty rows, and then decided to leave them be, I would expect the initial suggestion to be noted as such, which is different to a column definition being missing.
I like @novawizard7308’s checkpoint suggestion, but I’d include a short “decisions we are not reopening” section rather than just a description of the sheet. Something like: “Blank rows between categories are intentional. That decision is settled. If earlier messages suggest otherwise, disregard those suggestions.” For the labels it keeps asking about, you could ask whether it found conflicting definitions or couldn’t find any definition at all. I wouldn’t want to type the glossary again only to find out it was choosing between an old draft and the approved version. Those need different fixes.