Two task lists, one assistant
This post started as a task. I asked Claude to add two blog ideas to my ToDo list. It looked through my projects, found one called “Outbox”, put both ideas in there and told me what it had done. I didn't open the app once, and I didn't have to tell it where things go. One of those two ideas was this post.
I have two task systems. At home I run tududi, a self-hosted task manager on my homelab server. At work there's Jira, because in big companies there is always Jira. For years the problem wasn't the tools. The problem was me: switching between them, forgetting which list something lived on, and filling in the same fields the same way over and over again.
These days Claude handles both, and in both cases the trick is the same: a skill.
Tududi at home
Claude talks to tududi through an MCP connector, so it can list projects and create, update and complete tasks. That part is plumbing. What makes it useful is the skill on top: a short markdown file that describes how I use tududi.
It triggers on phrases like “put it on my list” or “task: ...“. The first sentence becomes the title, the rest becomes the description. Then it matches the task against my existing projects. If there's a clear match, it just creates the task. If there isn't, it stops and proposes a project, or a new one, and waits for me to pick. A due date only gets set when I actually mention one. Tududi's due dates cover a whole day, though. When I add a specific time, a different skill turns it into a reminder instead. And when I say “remind me” without a time, Claude asks which of the two I meant.
The rules I care about most are the ones about what it must not do. It never rewrites a task's description. When I say “add to that task that...”, it appends a dated line at the bottom and leaves the rest alone. When I tell it I'm starting on something, it sets the task to in progress. When I close a task, it first writes down what was done, again as a dated line. And it never completes a task on its own initiative. Ticking things off is my job, and frankly the only fun part.
Some rules even live inside tududi itself. My readinglist project has a description that reads like an instruction, because it is one: only add a book when I explicitly ask, not the moment I mention buying one. Claude reads project descriptions when it matches a task, so the rule sits right next to the data it governs.
For the non-interactive stuff, a small bash script still does the job. A cron job that creates tasks from action dates on scanned documents doesn't need a language model. It needs a curl call.
Jira at work
The Jira skill works the same way but was built differently. I didn't write its rules from memory. Claude derived them from a sample of around 800 existing tickets in our team project, so the conventions reflect how the team actually works rather than how we think we work.
Some of what came out of that was surprisingly specific. Almost everything is a plain Task, including bugs. Other issue types exist but are effectively dead, so Claude never picks one unless I name it. All ticket content is in English, even when I'm asking in Dutch. Labels are never used, so it doesn't use them. There's a mandatory team field that people used to forget, and now nobody forgets it, because Claude never does. Four optional fields for rationale, stakeholders, risks and acceptance criteria are all or nothing: filled in for real decisions or anything over a day of work, left empty for a quick operational item. Status changes always go through Jira's transitions instead of setting the field directly.
So “log this: script X uses a non-unique temp file, which causes a race when two cron jobs run at once” turns into a properly structured ticket with the mechanism, impact, workaround and structural fix. “Make a ticket to update tool Z” turns into a one-line Task with nothing else filled in. Both look like a colleague wrote them, which is the point.
Same rules, different house
Here's what I didn't expect. These two skills were written months apart, for different tools, in different contexts. And yet they ended up with nearly the same rules.
Act on your own when it's clear, ask when it isn't. In tududi that's the project match, in Jira it's assigning a ticket to someone. Never overwrite what's already there, only add to it. Never claim something is done when it isn't: Claude doesn't complete my tududi tasks, and it doesn't mark a Jira ticket resolved when the structural fix is still pending.
The tool underneath barely matters. Tududi and Jira have nothing in common except that they store tasks. What matters is the layer of rules on top. Without it, an assistant with access to your task list is an eager intern with admin rights. With it, it's a colleague who knows how you work. Writing those rules down also forced me to decide how I actually want my lists to work, which I had somehow never done before.
Written with assistance from Claude.
Want to reach out? Contact me.