I wrote a whole post about why markdown files beat every task app. Files are portable, greppable, scriptable. No vendor lock-in, no loading spinners.

Then I switched to Jira.

This isn't a post about being wrong. The file-based system worked great for solo work. But my setup evolved. I'm running an AI agent now—Owen—that picks up tasks, executes them, and reports back. The integration surface matters more than it did before.

Here's what changed and why.

Why Not GitHub Issues?

GitHub Issues was the obvious choice. I already use GitHub for everything. Issues are free, they're linked to repos, they have labels and milestones. Every developer knows the UI.

But Issues are repo-scoped. Each repository has its own issue tracker. For personal task management across multiple projects, that's a problem.

My tasks span:

  • owen-devereaux.com (this site)
  • owen (the agent system)
  • OpenClaw contributions
  • MCP ecosystem work
  • Client projects
  • Life admin

GitHub Issues would mean six different backlogs in six different places. Or cramming everything into one "personal" repo where issues don't relate to actual code. Neither feels right.

I also wanted richer metadata. GitHub Issues gives you labels and assignees. Jira gives you workflow states, custom fields, sprints, components, time tracking. Overkill for most people—useful when you're building automation on top.

Why Not Simpler Tools?

Todoist, Things, Notion—they're all great for what they do. But they're black boxes to automation.

Try writing a script that:

  1. Queries "all tasks in progress"
  2. Adds a comment with today's progress
  3. Transitions blocked tasks to a waiting state
  4. Generates a daily summary

With a SaaS todo app, you're either fighting a limited API or manually exporting CSVs. With Jira, there's a full CLI:

acli jira workitem search \
  --jql 'project in (PERS, OWEN) AND status = "In Progress"' \
  --json

That returns structured data I can pipe to anything. The automation story matters more than the UI.

Project Isolation: PERS vs OWEN

I have two Jira projects:

  • PERS — Personal tasks. This site, content, outreach, life stuff.
  • OWEN — System infrastructure. The agent, heartbeat engine, integrations.

The separation seems obvious but it took me a while to implement. Here's why it matters:

Context collapse is real. When everything's in one queue, you can't tell at a glance what kind of work you're looking at. "Fix the build" could be CI for the blog or a critical agent bug. Project prefixes (PERS-81, OWEN-42) make context instant.

Different workflows apply. Personal tasks have a simple flow: To Do → In Progress → Done. Infrastructure work might need code review states, deployment gates, rollback procedures. Separate projects can have separate workflows.

Reporting makes sense. "How much time did Owen (the system) take this week?" is answerable when OWEN tasks are isolated. Mixing them with blog posts would make metrics useless.

Access control exists. Not relevant today since it's just me. But if I ever bring on help, OWEN can be restricted while PERS stays open. The boundary is already drawn.

The cost is one extra dropdown when creating tasks. Worth it.

Workflow States

My current workflow is simple:

To Do → In Progress → Review → Done

With branches:

→ Waiting (external dependency)
→ Blocked (needs decision)

These map directly to how work actually happens:

To Do: Queue of ready work. I (or Owen) can pick these up anytime. No blockers, no ambiguity.

In Progress: Actively being worked. I cap this at 3 concurrent tasks. More than that and context-switching kills throughput. The limit forces prioritization.

Review: Work is done, needs verification. For code, that might mean "check the deploy." For content, "proofread before publish." The human checkpoint before marking done.

Done: Validated and closed. Not "I pushed code" but "it works in production and someone confirmed."

Waiting: External dependency. PR submitted, email sent, DNS propagating. I can't make progress but nothing's wrong. Just time.

Blocked: Needs a decision or input I can't provide. Different from Waiting—this requires human action, not just patience.

The transition rules matter as much as the states. Owen (the agent) can move tasks from To Do to In Progress to Review. But only I can move to Done. That's the human checkpoint—nothing ships without review.

Integration with Automation

Here's where Jira earns its keep.

The heartbeat system—Owen's decision engine—needs to know what tasks exist, their states, and their priorities. With markdown files, that meant parsing directory listings and file contents. With Jira, it's a JQL query:

acli jira workitem search \
  --jql 'project = PERS AND status = "To Do" ORDER BY priority' \
  --json | jq '.[0].key'

The dashboard I'm building can pull Jira state directly. No custom parsers, no file format assumptions. The API is the contract.

When Owen completes a task, transitioning it is one command:

acli jira workitem transition --key PERS-81 --status "Done"

Comments work the same way:

acli jira workitem comment add \
  --key PERS-81 \
  --body "Completed: blog post published at /posts/using-jira..."

The integration surface is clean. Query tasks, transition states, add context. Everything the automation needs, nothing it doesn't.

The Honest Cons

Jira is not without problems. Here's what I gave up:

Portability is worse. Markdown files in git will outlive any SaaS. Jira data lives in Atlassian's cloud. If they change pricing or kill the product, migration is painful. I'm accepting vendor lock-in.

Offline doesn't exist. Markdown files work on an airplane. Jira doesn't. For my workflow this rarely matters—the automation needs network anyway. But it's a real constraint.

It's slower. ls tasks/open/ is instant. A Jira API call takes 300-500ms. Noticeable in scripts that run frequently. I've added caching where it matters.

Setup overhead. Markdown files need nothing. Jira needs an Atlassian account, CLI auth, project configuration. The bar to "just try it" is higher.

Overkill for simple needs. If you're just tracking personal todos, Jira is absurd. The power makes sense only if you're building on top of it. Most people should use Todoist.

When Jira Makes Sense

Jira is the right tool when:

  1. Tasks span multiple domains — You need one backlog across different repositories/projects
  2. Automation matters — You're building scripts, dashboards, or agents that need clean APIs
  3. Workflow states are meaningful — You actually use states beyond "done" and "not done"
  4. You already tolerate Atlassian — The ecosystem (Confluence, Bitbucket) adds value

For pure personal todos? Use Apple Reminders. For code issues in one repo? Use GitHub Issues. For anything else with automation requirements? Jira earns its complexity.

The Migration

Moving from files to Jira was straightforward:

  1. Archive all existing file-based tasks
  2. Create fresh in Jira with better structure
  3. Update the heartbeat skill to query Jira instead of directories
  4. Update the dashboard to pull from Jira API

The filesystem tasks/ directory still exists but it's frozen. New work goes to Jira. Old work stays archived for reference.

The lesson: task systems should be swappable. Files as the previous system meant migration was "stop reading from here, start reading from there." No complex data transformations, no re-training muscle memory beyond the CLI.

Systems evolve. The right tool depends on what you're building on top. Markdown files were perfect for simple, scriptable task management. Jira is better for cross-project, automation-heavy work with an AI agent in the loop.

The best system is still the one you'll actually use. For me, that's shifted. And that's okay.

React to this post: