Question | Alternative task tracking solutions?

[Nopik]

Currently Maister is using markdown files with - [ ] to track tasks. I would love to see this part more swappable. In my projects I'm using Beads a lot (https://github.com/steveyegge/beads), is there any chance that Maister will be able to use that instead?

[mkaluzny]

Thanks for bringing this up!

We ran /maister:research on this topic recently. The tricky part is that beads and maister's checkboxes operate at very different levels - the - [ ] items are throwaway micro-steps within a single workflow run ("1.1 Create User model", "2.3 Add validation"), while beads is really a project-level issue tracker meant for persistent cross-session tracking.

Swapping one for the other doesn't quite work, but syncing at the right granularity could. We're thinking something like:

• Whole task groups ("Database layer", "API endpoints") → beads issues with dependency links
• Workflow-level tasks ("Implement user auth") → beads epics
• Discovered issues during implementation → beads issues linked to parent

This way beads handles project-wide visibility and maister keeps doing the micro-step orchestration internally.

Before we go further - how are you actually using beads day to day? Would task-group level sync (rather than individual checkboxes) cover your needs? Curious whether you're mainly after the cross-session persistence, the dependency graph, or the bd ready queue.

If this moves forward, we're looking at an optional hook-based sync approach - if beads is installed it works automatically, otherwise nothing changes. Still exploring the options though.

[Nopik]

Right, it depends on how you use Beads. I do not think it is good enough to be a project-level tracker, actually. I'm using it to keep small working set at any point of time. I.e. my list of open beads is almost always at zero. When I start working on some big feature where I write PRD (basically a folder in .maister/development), I eventually come up with a plan file and split plan file into beads tasks. Typically each PRD has few epics, they have children, blocks each other etc. So, e.g. PRD can result in 20-50 beads easily. That is the only moment where I have non-zero list of beads. Then I run orchestrator loop which implements beads on a 'first free' basis, starting literally from scratch, i.e. completely new claude session. Beads are described like "Your task is to implement step 4.7 out of this plan: PLAN.md for this feature: PRD.md, here is the task description: [.. description for step 4.7 of the plan ...]". Each individual worker actually does git commit + git push, then quits. I have some custom scripts around it, so the work is not done as a subagent, it is actually a separate claude process which exits at the end. And the loop continues until there is zero beads opened. Then this zero beads situation is kept until I write another PRD for something else. For the rare occasions when I work on several things simultaneously this workflow can work with labels, i.e. plan-to-beads script creates beads with some label, and then orchestrator lists only the tasks with given label, so I can have several worktrees being worked on separately.

I did measurements and it definitely produces better output than a single claude doing the whole plan in one go, 100% of the time. Maister is doing something in between - 3-5 tasks (or so, I don't remember your threshold) can be done by a single subagent, but big lists are split into more subagents. That is actually another bit which I do not like about Maister - I'd prefer each task to be completely isolated, never let any subagent do 2 tasks or more. I did not conducted any comparison of the outputs, though, maybe 2-3 tasks at a time wont result in output quality degradation. Maybe even it will result in improvements, that would mean that Maister approach is better than mine. But without actual data it is impossible to tell more.

There is some author info on it, though his description is fuzzy at best: https://steve-yegge.medium.com/beads-best-practices-2db636b9760c