Every working day · running on real work
There is no shortage of task managers. Records go missing not for lack of will but because of when the question is asked — ask hours after the fact and nobody answers.
Terminal · work chat · a kanban board on your phone — the same rules and the same tools across all three
WHAT IT DOES
The assistant does the rest by itself. However it arrives, it lands in the same single markdown file, goes through the same arithmetic, and shows up on the same screen.
Work chat, the board's prompt field, the terminal. Drop a sentence the way you would say it out loud and it lands on the matching one among your open tasks as a new task, a postponement or a log entry. You never pick which task; it asks back only when two or more have similar names. No form, no syntax. The raw text is saved before anything tries to read it, so a failed reading loses nothing.
Raw text saved first · a failure leaves it sitting in the queue
Point a task at a working directory and that folder's commits are attached to its progress log every evening. It does not care which tool made them — a commit typed by hand is caught the same way. A commit says "worked on it", not "finished it", so the status is left alone.
Tool-agnostic · a hand-typed commit is caught the same way
Two weeks of mail is cut to roughly a quarter by a filter, then sorted five ways: create, update, reply, drop, or ask. Calendar entries with no task behind them are held up against the list too. Creating a task is approved by a person.
95.0% accuracy on that sorting · scored by hand over 140 items
Estimated hours and a buffer are subtracted back from the deadline to give a latest start date. Nobody works out dates in their head, and a card you should have started today but have not touched blinks on its own.
Open tasks sort themselves into seven columns
It drafts the week's 40 hours out of the progress logs and spreads them across issue-tracker tickets, and it sends the data and the design documents off the machine at a fixed time every day. Posting to the issue tracker is approved by a person.
Hours by the week · backup at a fixed time every day
One file is one task: the front matter holds its fields, the body holds its progress log. Any markdown editor opens it as it is. One write is one commit, so a task's history is its version history.
One write, one commit · task history is version history
THE PROBLEM
The task list was always there. But it does not answer the questions you ask every morning.
What should I start on today?
The list holds the due date and nothing else. Whether the work has to start today is written nowhere.
What did I work on last week?
The work happened in repositories, documents and meetings. The list looks at none of them.
How many hours did this take?
Asked a few hours after the work ends, the memory is already gone. That field stays empty.
How many days have I been waiting for that reply?
The list does not separate their turn from mine, so waiting work looks the same as late work.
Where do this week's hours go?
On Friday you rebuild the whole week from memory, and that number becomes the input for the next plan.
Not one of the five has an answer in the list. What is missing is not a list — it is the record that should have been left between the list and where the work happens.
THE STRONGEST EVIDENCE
Every finished task has a field for how many hours it actually took. A check-in asked for it every day, and for 15 days not one was filled in. Not a matter of willpower — the question came hours after the work ended, when the memory had already gone soft.
First only the timing moved: the question now came the moment you press Done. For four days it produced nothing — completions were arriving through the prompt field rather than the button, so the question never appeared.
So the finished tasks still missing the figure were laid out in a row across the top of the board to be cleared one at a time. The backlog — 25 of them — filled the day that row went up, and all 8 finished since were filled in too. It now stands at 35 of 35.
Nothing was asked more often. The asking moved, and what was left was put in front of you.
WHERE THE MODEL IS USED
Counting and arithmetic are all done in code. What the model is handed is judgement, which is why all five of these fit inside $30 a month.
In technical terms
The same thing said in industry terms.
Before you adopt it
Task notes are among the most sensitive text a company holds. Here is what leaves and what does not.
THE SAME ANYWHERE
Tap a card and an edit sheet rises; a value changed there lands on the board in 3.3 seconds. Tap several cards and they still travel together in one batch, so there is a single round trip.
Anything a button cannot express goes into the prompt field as it is — "push this to next week and note that I handed it over" arrives in the work-chat conversation and is handled there.
What comes back is one line naming what changed — and if it did exactly what you asked, not even that.
HOW
Three steps, and no new procedure to learn.
In work chat or in the board's input field, in the words you would normally use. The raw text is saved before anything reads it, so a failed reading loses nothing.
Estimated hours and a buffer are subtracted back from the deadline to give a latest start date. Open tasks fall into seven columns by themselves, and a card that needs attention today blinks.
Point a task at a working directory and that folder's commits are attached to its progress log every evening. It does not care which tool made them — a commit typed by hand is caught the same way.
NOT THERE YET
These do not work today. None of them needs a new rule — each one reuses "propose a candidate, let a person approve it", which already runs on mail.
| What is missing | Today | How it would attach |
|---|---|---|
| Task candidates from the issue tracker | The issue-tracker link runs one way only — it posts weekly hours | Sort five ways as mail does, and take the same approval |
| Task candidates from chat channels | Direct messages go both ways, but channels are not read | One more way in, feeding the same candidate list |
| Merging two tasks into one | Say "merge these two" and it asks back; a person tidies it by hand | One command to join the progress logs and close one side |
A path that turns those candidates into tasks automatically still will not be built. A wrong candidate costs one line of annoyance; a wrongly created task is one nobody ever deletes, and the list only grows heavier. What gets added is places candidates come from, not places approval is skipped.
MEASURED, THEN DROPPED
These were built, measured, and then taken back out. What we measured and why we dropped it is written down, so you need not measure the same things again.
| What was measured | Result | What was decided |
|---|---|---|
| Matching calendar events to tasks | Of 19 word-overlap matches, 6 to 8 were right | Dropped — a wrong value that lands on a card never gets corrected |
| Daily capacity with meetings subtracted | Swung two-fold, 3.0 to 6.2 hours | Not used — a meeting's length leaves out its preparation and follow-up |
| A check-in pushed twice a day | A question attached itself the moment you said anything, blocking the conversation | Removed — seeing it on the board and fixing it there is more natural |
| Publishing the same screen in two places | One of them was always stale | Down to one — only the screen the product itself renders |
| Keeping the store in a hosted service | An outage stopped every lookup at once | Moved to local files — one git commit per write |
WHAT TRANSFERS
What changes
The same day written twice — a task list on its own, then this, set side by side at each stage.
A list on its own
Now
When work comes in
A list on its own
Now
When work is done
A list on its own
Now
The next morning
A list on its own
Now
Eight steps became three. What shrank is not the work but the trips you make to record it.
Which column a card sits in, "N working days late", the capacity overrun — every one of them is computed back from a deadline. The only thing a person set is the single line at the top.