toolkit

Scenario · The bigger jobs

Log what I did today

End of the day, or end of the week, with a rough note of what got done.

A rough end-of-day note of what got done is only useful if it turns into something that can actually be reported on later — and doing that from memory a week later is where the accuracy disappears. This reads an informal note and turns it into structured entries against the right client and category, but always shows what it's about to create first, because a wrongly attributed entry looks exactly as plausible as a correct one until someone checks.

What to ask for

Activity log clientClient for the team's internal Activity Logs work-log tool.Task board (monday.com)monday.com task board — board overview (open/done/overdue, by-status, who it sits with) via REST or an agent-captured MCP payload; verdict always INFO.

See it work

A real run of Activity log client:

$ node scripts/activity-log-client.mjs log "fixed 3 broken links on the site ... rewrote the homepage meta description ... client call about the September campaign"

parsed 3 entries
  <date>  technical  example.com  fixed 3 broken links on the site
  <date>  technical  example.com  rewrote the homepage meta description
  <date>  technical  example.com  client call about the September campaign

DRY RUN — nothing was created.
To create: --apply

$ node scripts/activity-log-client.mjs log "..." --apply

parsed 3 entries
  <date>  technical  example.com  fixed 3 broken links on the site
  <date>  technical  example.com  rewrote the homepage meta description
  <date>  technical  example.com  client call about the September campaign

created 3 entries
  rollback: ./out/rollback.json

$ node scripts/activity-log-client.mjs mine

3 total — showing 3
  <date>  example.com  client call about the September campaign
  <date>  example.com  rewrote the homepage meta description
  <date>  example.com  fixed 3 broken links on the site

  report: ./out/activity-log-client-activity-log-client.html

The paste-your-day flow. Its value is that it turns a rough note into structured entries against the right domains, which is the difference between a log that can be reported on and a list of sentences.

  1. Write the raw note first, however roughly. Domains, what was done, roughly how long. Doing this from memory at the end of the week is where the accuracy goes, so it is worth doing daily even when the note is three lines.
  2. Parse it into entries as a dry run. The activity log client AI-parses the text into structured entries and shows what it would create without creating anything. This is the default and it should stay the default.
  3. Read the preview against what you actually did. Domain, category, description. A misattributed entry is worse than a missing one — it puts one client’s time against another, and that surfaces later in reporting nobody thinks to question.
  4. [manual] Apply it once the preview is right. The write happens only on explicit approval, per the toolkit’s write-approval rules, and every apply appends to the shared write log.
  5. Close the loop on the board. Where logged work corresponds to board items, move them. Work logged but left open on the board is the most common reason a status meeting disagrees with reality.
  6. Read back the log for the period to confirm the entries landed as intended, which is also the fastest way to spot a day nobody logged.

Dry run is the feature

The parse is a language model reading an informal note, so it is right most of the time and confidently wrong occasionally. Step 2 and step 3 exist because the failure is silent: a plausible entry against the wrong domain looks exactly like a correct one a week later.

What this does not cover

Knowing what you did. It parses a description into structured entries and creates them; it cannot recover work nobody wrote down, and it will happily record a wrong domain or category if that is what the text implies. Writes are dry-run by default for exactly that reason — the preview is the point, not a formality.

← All scenarios