A Project Log Template for AI-Assisted Builds

September 27, 2026

A project log is a plain text file where you write a few lines after each work session: what you wanted, what you asked the assistant, what worked, what broke and what comes next. It takes about three minutes per session, and it saves far more time later when you return to a project after a break and cannot remember where you stopped.

Here is a template you can copy, with notes on how to use it.

Why a log helps more than your memory

AI-assisted projects move quickly, and the details blur. A week later you may not recall which prompt produced a feature, why you chose one approach over another, or which version of the file was the last good one. The assistant cannot help you remember, since it does not see earlier conversations unless you paste them.

A log fixes this. It gives you a short history in your own words, and it gives the assistant a summary to work from when you start a new chat. It also shows progress, which is motivating on days when a bug feels endless.

The template

Create a text file called LOG.md or log.txt in the project folder. Add an entry like this after each session:

Date: 2026-09-16
Version: v4 (file: tracker-v4.html)
Goal today: add a CSV export button
Prompt summary: asked for a button that downloads all expenses as CSV, with a header row
Result: worked on first try; dates exported in the wrong order
Fix: asked to sort by date before export; now correct
Tests run: added 3 expenses, exported, opened in a spreadsheet, reloaded page
Problems left: none
Next: month selector
Notes: do not change the cents storage format

Not every field needs an entry each time. If a field would be blank, skip it. The aim is to capture enough that a stranger, or you in a month, can understand what happened.

What each field is for

Date and version. These tie the entry to a saved file. When something breaks, you can tell which version introduced it.

Goal today. One sentence about what you wanted, written before you start. It keeps the session focused and makes it easy to tell whether you finished.

Prompt summary. You do not need to save the whole prompt, only the idea. If a prompt worked unusually well, paste it into a separate prompts file.

Result and fix. Record what happened, including surprises. A failed attempt is useful information, because it prevents you from repeating it.

Tests run. Write which checks you did, so you know what has been verified and what has not.

Problems left and next. These two lines make the next session easy to start. Open the log, read them and go.

Notes. Decisions and rules for the project, such as “single file only” or “amounts stored in cents.”

Keep it small

The log works only if you keep it. If it takes ten minutes, you will skip it. Set a rule: three minutes at the end of every session, using the template, with short phrases. Bullet points and fragments are fine. Nobody else needs to read it.

Put the newest entry at the top, so the latest state is the first thing you see when you open the file.

Use it with your assistant

When you start a new chat, paste the latest entry’s Next and Notes lines plus the project summary. This gives the assistant the context it needs without a long explanation. When you report a bug, you can include the relevant entries to show what changed recently.

You can also ask the assistant to help you tidy the log: “Here are my last five entries. Write a five-line summary of the project’s current state and the open problems.” That summary is handy for a new conversation.

Add a short section at the top

Beyond entries, keep a fixed header at the top of the file with items that rarely change:

• What the project is, in two sentences.
• The files and what each does.
• Where it is published, if anywhere.
• Rules and decisions.
• The test checklist.

When these change, update the header and leave the old text out. The entries below it record the history.

Common mistakes

Writing the log only when things go well. Failures are the most useful entries.

Making entries too detailed. If you copy whole conversations, you will not read them later.

Not saving versions. An entry that mentions v4 is useless if v4 no longer exists. Save numbered copies.

Losing the file. Keep the log in the same folder as the project so it travels with it, and back up the folder.

A week in the life of a log

Imagine three entries in a week. On Monday you built the first version and noted that saving failed on reload. On Wednesday you fixed it and recorded the prompt that worked. On Saturday you added an export button, found a sorting bug and noted the fix. Reading those lines on the following Monday takes thirty seconds and tells you exactly where you stand.

Without the log, you would reopen the file, scan the code, guess what changed, and probably repeat Wednesday’s investigation. The log turns a half-hour of reconstruction into half a minute of reading. That trade is the whole reason to keep one, and it only works if the entries stay short enough that you actually write them.

Next steps

Create the log file for your current project and write one entry now, covering where the project stands today. Use the template at the end of your next session, even if the session was short. After a week, reread the entries and note which fields you found useful, and trim the template to match.