Keep track of your project's progress

If you keep your project history in notes rather than in git, the notes will drift. They're written at a moment in time, the work keeps moving, and nothing ever checks them against what's actually true. I learned this the expensive way. My Luma project lost its git history back in July, which left an Obsidian vault as the only record of what happened. In late August I discovered four claims in that vault were stale, and two of them had sent me down paths I later had to abandon. One had blocked a task for three days on the strength of a sentence that was no longer true.

The fix was a nightly routine that reads the notes back against reality and corrects what has drifted. It took an evening to build, it contains no code, and the pattern works for any project where notes carry real weight. Here's how to build one.

Step 1: Write the routine as a prompt, in plain English

The entire automation is one markdown file. Mine is 61 lines. It has a short header naming the task, and then the body is just instructions, written the way you'd brief a colleague who's covering for you tonight. A scheduler hands that file to a fresh AI agent session every evening, and the agent follows it.

This matters because it lowers the bar enormously. You aren't writing a script that has to handle every edge case in code. You're writing down how to do a job you already know how to do. If you can explain the task to a person, you can write this file.

Give the routine a clear sequence. Mine runs six steps: figure out what changed since the last note was written, verify the facts the notes claim, run the tests if it's safe to, write up what landed in the vault's own voice, audit the standing task notes and correct drift, and finish with a score in the form "N claims confirmed, N stale, N uncheckable."

Add one rule up front that will save the whole thing from becoming noise: if nothing changed, the routine should say so in one line and touch nothing. An automation that edits something on every run teaches you to stop reading its output.

Step 2: Verify against reality, and check where reality lives

Decide, for each fact your notes tend to claim, what the authoritative source is, and write that into the prompt. For me, the notes claim things like "this fix is deployed" and "there are 47 test files." The authoritative answer to the first lives in production, so the routine checks what's actually serving traffic rather than what's sitting in the working folder. I once had a two-week-old build serving users while my notes described the fix as done, and nothing surfaced it.

Rank your sources and put the ranking in the file. Mine goes: production first, then actually running the thing, then reading the whole relevant file, then text search last. Search sits at the bottom because it misled me twice. A note about a fragile pattern survived for days because searching found the pattern in the code, and it really was there. It just wasn't the one that was running.

Step 3: Schedule it locally, where your data is

This is the decision people get wrong first. Cloud automation sounds like the natural home for a nightly job, and for this job it's useless, because a cloud agent can't see a folder on your laptop. If your notes and your project live on your machine, the automation has to run on your machine. Pick a scheduler that runs locally and persists to disk, so the task survives restarts and simply runs on next launch if your computer was off at the appointed hour.

You don't need to pick an odd time. Mine is set for 21:00 and the scheduler adds a few minutes of jitter of its own, so it fires nearer 21:06 without my choosing that. Expect the schedule to be approximate, which doesn't matter for a daily habit.

Step 4: Assume the routine remembers nothing

Each nightly run starts with zero memory of every previous run. Treat that as the feature it is. It forces you to write every piece of operating knowledge into the file, because nothing else will carry it forward.

In practice this means your prompt file becomes a collection of scars. Every time a run goes wrong, you add a line so it can't go wrong the same way again. My file tells the agent to scope its file scans, because an unscoped search once walked through hundreds of dependency folders and timed out, and a truncated result looks exactly like a complete one. It names a network quirk on my machine that disguises itself as a login failure. It warns that I sometimes edit the project during the day, so a changed count is something to investigate before it's treated as a problem. None of those lines could have been written on day one. That's fine. The file is meant to grow.

Step 5: Bake in the audit rules

Four rules keep the routine honest, and they're worth copying verbatim into your own version.

Check in both directions. You'll assume stale notes over-claim, saying something is done when it isn't. In my vault the opposite dominated. Three of my four stale claims were too pessimistic, describing problems that had already been solved, and those are the expensive ones because they make you re-solve solved problems. An audit that only hunts for over-claiming would have caught one of the four.

Strike through, never delete. Have the routine correct a wrong claim by striking through the original text and writing what disproved it, with a date. Delete it silently and future-you re-derives the wrong claim from scratch, with no idea it was already investigated.

Don't fix things during the audit. A pass that edits what it's measuring stops being a measurement. Findings get recorded and become their own separate piece of work the next day.

Report the confirmed count, always. "Nine claims stale" reads like rot. "Nine stale out of a hundred and six" describes what your notes probably are, which is mostly right, drifting at the edges.

What to expect

The first version of your prompt will be naive, and the first few runs will teach you what it was missing. Budget for that. The value shows up as a compounding habit: every morning you get a one-line answer to "can I trust my notes today," and every failure makes the file smarter.

Mine has only just started running. This whole routine exists because of the gap between what's written down and what's actually true, so I'm going to let it work before I call it working. I'll follow up with what the first week of scores looks like.