A system that knows who it's for
Nothing here is built for its own sake, and none of it assumes an ideal user. Every piece has to earn its place — and the guardrails are shaped around how I actually work, including the ways I get it wrong.
Two rules run underneath everything. First: nothing gets built for the feeling of building — every piece has to produce something useful or it doesn't get made. Second: the system is tuned to its operator, not a fantasy version — it plans for low energy, counters my tendency to over-build, holds big decisions when I'm in a bad state to make them, and talks to me in plain English because that's how I think.
Most personal productivity systems quietly assume two things: that everything worth doing is worth building, and that the person running it is rested, disciplined and consistent. Both are false, and designing around them is how these systems end up abandoned. So underneath everything here are two rules that point the other way.
Nothing gets built for its own sake
The first rule is purpose. New ideas are parked by default — capturing one creates a memory, not a commitment. An idea only becomes active work by displacing something already active or unblocking the current goal; "it's interesting" doesn't qualify. And every deliberate build has to answer one question before it starts: what useful thing comes out of this? The bias is shipped proof over interesting complexity.
That sounds obvious until you notice how much work is really done for the feeling of working — the motion, the new project, the clever tool you didn't need. A system that rewards motion over outcome fills up with half-finished cleverness; this one is designed to resist that.
It plans for the real operator, not an ideal one
The second rule is that the guardrails are built around how I actually work — including my failure modes, treated as design inputs rather than flaws to will away.
- It assumes low energy by default. Unless I say otherwise, the day's scope is set for a tired version of me, not an optimistic one, so plans stay finishable instead of becoming a backlog of good intentions.
- It counters my tendency to over-build. Left unchecked I keep polishing and adding "just one more thing," then stall at the finish line. So a "good enough" bar gets set before the work starts, and the system flags when I'm quietly expanding scope mid-task — which is how things actually ship.
- It knows when not to trust my judgement. There are states — restless, over-stimulated, chasing the next shiny thing — where I make strategic bets I regret by morning. The system recognises those and holds the big decisions for a clearer day rather than letting me commit on a bad one.
- It raises a concern once, then respects the override. If it flags something and I overrule it, that's the end of it — no nagging. The judgement stays mine; the guardrail isn't a scold.
It talks to me in the register I think in
The clearest example is small and load-bearing. I'm a systems thinker, not a developer — so when the work goes deep into technical detail, the right report for me is concepts, outcomes and trade-offs, not scoring maths and code internals. There's a dedicated command, /simplify, that re-renders any stretch of deep technical conversation straight back into plain English: same content, less mechanism. It exists for exactly one reason — that the person running this system reasons in plain language, not code — and that's the whole principle in miniature. The tools bend to how the operator thinks, not the other way round.
Why this is the point, not a footnote
Anyone can assemble a stack of productivity tools. The harder, more useful thing is building one that's honest about its operator — that treats my worst tendencies as facts to design around, and my way of thinking as the spec rather than an inconvenience. Optimise for an ideal user and you've built something for no one in particular. This is built for a specific person, failure modes and all, and it works better precisely because it doesn't pretend otherwise.