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

> After a break, every project looks unfamiliar and you start by digging through commits and chats. How to leave a project so coming back takes five minutes.

- URL: https://shotmatic.app/blog/returning-to-a-project-after-a-break
- Category: Agent Context
- Published: 2026-10-12
- Author: Tu Nguyen

## Key takeaways

- 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.

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 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:

```markdown
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](https://shotmatic.app/blog/always-write-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](https://shotmatic.app/blog/stop-re-explaining-your-project-to-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](https://shotmatic.app/blog/memory-lives-in-files) instead of in you.

## Where ShotMatic fits

When you open ShotMatic after a break, every project is still there as one line — phase, next step, stuck or
not — read from the files in your repos. ✦ resumes the session you left, or starts a new one with the task's
context already written.

## FAQ

**How do I get back into a coding project after time off?**

Start with the written state: phase, next step, open questions. Then ask the agent to summarize commits since that date. Only then open the code.

**What should I do before leaving a project for a while?**

Spend five minutes updating the state file: where it is, the next step, anything half-done, and which session to resume. Commit and push.

**My old project has no notes at all. Where do I start?**

Make the first session a reconstruction: ask the agent to read the repo and history and draft a state file, then correct it. Code in the next session.