Coming Back to a Project After a Week Away (Without the Dig)

You're back after a long weekend — or a week, or a month. You open the project. The code looks like someone else wrote it. There are uncommitted changes you don't remember. The last chat ends mid-thought.

So you dig: commit log, diffs, three old chats, a notebook page. An hour later you're roughly where you were.

Part 4 of No Process — about leaving projects so you can come back to them.

The short answer#

• After a break, the cost isn't the work you forgot — it's the hour spent rediscovering where you were.
• Leave every project in a state you can re-enter: phase, next step, open questions and the last session, written in the repo.
• On the way back, read the state file first and let the agent summarize recent changes before touching code.
• If a project has no state file, spend the first session writing one instead of coding.

The break isn't the problem#

Breaks are good. The problem is that most projects are left in a state only your short-term memory understood — and that memory is exactly what the break erased.

The cost isn't the forgotten work. It's the re-entry: the time from opening the project to doing something useful.

Leave a re-entry note#

Before any break longer than a day, spend five minutes on the state file:

Phase:    6/9 — edit pass
Next:     apply the edit notes to chapter 4 (notes in edits/ch4.md)
Half-done: chapter 3 tables — reformatted 2 of 5
Open:     keep or cut the appendix? (leaning cut)
Session:  resume 3a9…c07 for the edit pass

Then commit and push. This is just writing the next step, plus the two things breaks destroy most: half-done work and open questions.

Coming back: read before you code#

When you return, don't open the code first. In order:

1. Read the state file. One minute.
2. Ask the agent to summarize what changed since the date of the last entry — commits, uncommitted files.
3. Answer the open questions now, while nothing else is loaded.
4. Start the next step.

The agent does the digging; you do the deciding. It's the same handoff that stops you re-explaining your project to the AI, just across a longer gap.

A project with no notes#

For the old project with nothing written down, don't start by coding. Make the first session a reconstruction:

"Read this repo and its git history. Draft a state file: what it is, which phase it seems to be in, what looks half-done, and what the next step probably is."

Correct the draft, commit it, and code in the next session. From then on, the project has memory in files instead of in you.

Keep reading#

• What Was the Next Step? Write It Down Before You Stop
• Stop Re-Explaining Your Project to the AI Every Session
• Memory Lives in Files, Not Chats: Managing AI Agent Context