Field guide
The Brain-Dump Inbox
Ideas don't wait until you're at a desk. A single no-structure capture box, plus an assistant that reads it before anything else each run, turns a half-formed thought into a properly filed, prioritised task — without you doing the filing.
2 prompts · one Lovable table · about 15 minutes

Why this exists
Most task-capture tools ask you to do the annoying part up front — pick a list, set a priority, guess a due date — right when you have the least patience for it. A thought that occurs to you mid-conversation, or while you're stood in a warehouse, doesn't arrive pre-sorted. If capturing it takes more than typing it, it doesn't get captured at all.
So the fix is to remove the sorting from the capture step entirely, and give it to the assistant instead. One box. Type anything. No fields, no categories, no format. The assistant reads it before it does anything else, works out what it actually means, and files it properly — then clears the box so it never becomes a graveyard of half-read notes.
What you'll need
- A Lovable companion app your assistant already talks to — this builds on the same pattern as a receipts or replies feed, so if you've built either of those, this reuses infrastructure you already have.
- An assistant instructions file it reads at the start of every run (a CLAUDE.md-style file, or equivalent).
- About 15 minutes — most of it is one Lovable prompt and one instructions update.
The one design decision that makes this work
The assistant is told explicitly never to invent urgency or a date that isn't actually there. "Sort this by Friday" gets a real deadline. "sort labels at some point" gets filed with no date at all, rather than a guessed one. Get this backwards — let it assume urgency to seem more useful — and the whole list stops meaning anything within a week.
The walkthrough
Add the capture surface
in Lovable
One field. A text box, a submit button, done. No title field, no category picker, no priority dropdown — the entire point is that adding friction here defeats the purpose. This is the one part of the whole feature a human touches, so it should take about three seconds.
Give it a pending/processed API
in Lovable
Same shape as a replies feed: the assistant fetches what's pending, acts on it, then marks it processed so it isn't re-read next run.
GET /api/public/notes?status=pending
Header: Authorization: Bearer <token>
→ [{ "id": 1, "text": "...", "created_at": "..." }, ...]
POST /api/public/notes/mark-processed
Header: Authorization: Bearer <token>
Body: { "ids": [1, 2, 3] }Teach the assistant to read it first
in your instructions file
Not "read it eventually" — first, before it processes anything else that run. A thought captured hours ago and still sitting unfiled defeats the purpose just as thoroughly as a capture box with too many fields.
## Brain-dump inbox
At the start of every run, before anything else: fetch pending notes.
Dan types anything here whenever it occurs to him — no structure,
no format required, could be a task, a reminder, a half-formed thought.
For each new entry:
1. Work out what it actually means as a task — infer a name, a
priority only if the content suggests one, and a due date only
if one is actually stated or clearly implied. Don't invent
urgency or dates that aren't there.
2. File it into the standing to-do list in the standard format.
3. Mark it processed once filed.
If an entry is genuinely too ambiguous to turn into a task, leave it
pending and flag it directly rather than guess at what it meant.Teach it how to file, not just capture
in your instructions file
Capturing without filing well just moves the mess from your head to a database. Two rules do most of the work: infer a priority from what's actually written (a stated deadline reads as more urgent than a vague someday), and route each entry to the right list — a task that ends in an email to someone goes somewhere different from a task that's purely internal, if your setup makes that distinction.
"sort labels at some point" → filed, no date, low priority — nothing invented that wasn't said.
"chase the Henderson quote by Friday" → filed with Friday as the actual due date, flagged higher priority — the deadline was stated, so it's used.
Close the loop — mark it processed
every run, without exception
The moment an entry is filed, mark it processed via the API in the same run. An inbox that never empties trains you to stop trusting it — the whole value of "type it and forget it" depends on it actually being gone once it's handled.
Field notes — what actually mattered in practice
The build is simple. These are the two ways it goes wrong anyway.
An assistant that always finds a task is worse than one that asks. Pushed hard enough, a model will turn almost any fragment into something plausible-sounding — a date, a priority, a next step. That's exactly the failure mode to guard against. A genuinely ambiguous entry left pending with a question is more useful than a confidently wrong task silently added to the list.
Test with real fragments, not clean examples. "Order more bike labels" is easy. The real test is a half-sentence typed one-handed while doing something else — no punctuation, no full context, maybe a name with no explanation of who they are. If the filing logic only works on tidy input, it doesn't actually solve the problem this was built for.
Security note
Same considerations as any other bearer-token integration into a companion app: treat it as a real credential, never commit it to a repo, and if the environment running your assistant has no dedicated secrets store, only use it somewhere you're the sole user of that environment.
The two prompts
One for Lovable to build the capture surface, one for your assistant to read and file it.
Prompt 1 — For Lovable
Add a quick-capture "brain dump" feature to the app. A single text input and submit button — no other fields, this needs to take about three seconds to use. Store each submission with an id, the text, a created_at timestamp, and a processed flag (default false).
Add two API endpoints, using the same bearer-token authentication as the app's existing endpoints:
- GET /api/public/notes?status=pending — returns unprocessed notes, oldest first.
- POST /api/public/notes/mark-processed — body {"ids": [...]}, marks the given notes as processed.
Keep the capture form itself completely unstructured — no title, category, or priority field. The whole point is zero friction at the point of capture.
Prompt 2 — For your assistant's instructions file
I want my assistant to read a "brain dump" inbox at the start of every run, before processing anything else. Add a section to my instructions file that:
- Fetches pending notes from GET /api/public/notes?status=pending as the very first step of every run.
- For each note, works out what it means as a task: infers a name, a priority only if the content actually suggests urgency, and a due date only if one is stated or clearly implied. Explicitly never invents urgency or a date that isn't there.
- Files it into my standing to-do list in the standard format already used elsewhere in my instructions.
- Marks it processed via POST /api/public/notes/mark-processed in the same run it was filed.
- If an entry is genuinely too ambiguous to turn into a task, leaves it pending and flags it to me directly rather than guessing.
Test it against a handful of realistic, messy fragments before treating it as done — not just clean, obvious examples.
This is exactly the kind of small-but-fiddly integration work Dan's Systems helps businesses get right the first time. If you'd rather have it set up for you than do it yourself, get in touch.