Skip to content

How to log

Write one note per day in this folder. Plain English, whatever length suits the day. /parselogs reads these, updates Progress against Timeline, and files anything else you mention into the right place in the workspace.

That second part matters for what's worth writing down. If you mention a PCB revision, it can update the firmware spec's hardware section. A disproved hypothesis goes to vault/docs/agent-notes.md. A pricing decision ticks the open question in the launch plan. So engineering notes are as welcome here as launch notes — this is the inbox for the whole project, not just the marketing side.

Filename: YYYY-MM-DD.md (e.g. 2026-08-08.md). The date in the filename is what everything is ordered by, so it's the one piece of structure worth keeping.

Just write normally

You do not need to reference milestone IDs, use tags, or follow a template. This is meant to be a diary, not a form. /parselogs is expected to do the interpretive work.

Filmed four Sunrise Lock clips this morning — the pillow-muffle one is by far the best, the servo lock reads really clearly on camera. Set up the email capture on the site, tested it, works. Still haven't heard back from the second module vendor about the integration guidance.

That's a perfectly good log. It's enough to mark two milestones done, note one waiting on someone else, and record which hook looked strongest.

Three habits that make the parse much better

  1. Say numbers when you have them. "up to 340 emails" or "that clip did 22k views, 61% completion" get trended. "Did well" doesn't.
  2. Say when something is finished, versus started or attempted. "Posted the Show HN" and "drafted the Show HN" are very different states, and the difference is invisible to a parser that has to guess.

  3. Write down what went wrong and what you decided. Blockers, dead ends, and decisions are the most valuable content here and the least recoverable from anywhere else. A dropped thread that nobody logged just quietly disappears.

  4. Say "done" when it's done. The parser will only write a hardware or firmware change into a spec if the log states it as fact — "the new boards came in, ring is on GPIO 8" gets filed; "I'm going to move the ring to GPIO 8" doesn't, and shouldn't.

What not to bother with

Don't summarise the plan back to yourself, and don't log what you intend to do tomorrow as though it happened. The parser is explicitly instructed to treat intent as not-done, so aspirational logging just produces a Progress file that lies to you.

Skipping days

Fine. Gaps are expected and /parselogs notes them without judgement. A gap is only interesting when it's long enough to suggest the cadence itself has lapsed — which is exactly the signal the launch plan says to watch for.