If you'd rather try it first than read about it, there's a demo video and a quick tutorial that walk you through the entire workflow in just a few minutes.
By the end of it, you'll have an agent:
- picking up issues automatically
- implementing changes in isolated worktrees
- creating pull requests
- updating issue states as work progresses
This article explains why I built tasq and the problems it tries to solve.
I spend most of my time building software with AI coding agents.
My workflow usually looks like this:
- Use Claude Code and custom skills to explore a problem and generate a plan.
- Ask Codex to implement the plan.
- Let the agent create a pull request.
At first, it felt magical.
Then I started running multiple agents in parallel.
While one agent was investigating a bug, another was implementing a feature. While waiting for CI to finish, I would ask yet another agent to work on a different task.
A few days later I noticed a problem:
- Which tasks are currently running?
- Which tasks are blocked by dependencies?
- Which tasks are already finished?
- Which conversation thread belongs to which implementation?
Sometimes an agent would finish a task and I wouldn't notice for days.
Sometimes I would discover an unfinished implementation a week later and wonder why it had stopped in the first place.
AI made software development massively parallel.
But my task management workflow was still designed for humans.
That's why I built tasq.
tasq
AI coding agent task manager.
tasq helps you turn implementation work into a visible queue, start local services for that queue, and inspect progress from both the tq CLI and the Web UI.
intro_v2.mp4
Watch the Tasq introduction video.
Japanese counterpart: README.ja.md.
Problem
AI coding agents make it possible to work on multiple implementation tasks at the same time. The bottleneck moves from writing code to managing parallel work.
Human Context Switching
Agents can run in parallel, but humans still need to track which tasks were assigned, which agents are running, how far each task has progressed, and what should be reviewed next.
Workspace Conflicts
Running multiple agents in one repository checkout can create branch switching issues, unfinished-change conflicts, and overlapping file edits.
Repeated Setup Work
Each agent task often needs the same preparation steps: create a branch, create a worktree, verify dependencies, and run the right…
An AI-native task orchestrator designed for coding agents.
Why not GitHub Issues or Linear?
The obvious answer is to create more issues.
The problem is that not all tasks belong in a shared project management system.
I don't want to publish every tiny implementation detail, development experiment, or dotfiles improvement to a team-wide Linear workspace.
Many of these tasks are personal implementation notes or intermediate steps that only exist to help me finish larger work.
They also have dependencies.
For example:
- Create database schema
- Implement repository layer
- Add API endpoints
- Update frontend integration
I don't want to manually copy and paste these tasks into agents in the correct order.
I want the system to understand the dependency graph and schedule the work automatically.
What I needed was:
Run multiple agents and automatically consume tasks while respecting dependencies.
What is tasq?
tasq combines three ideas:
- A local issue tracker
- A dependency-aware task queue
- An orchestrator for coding agents
Issues are stored locally in a database rather than in GitHub or Linear.
The orchestrator continuously watches the queue and dispatches executable tasks to coding agents.
Each task runs in its own Git worktree and branch, so multiple implementations can happen in parallel without conflicts.
tasq was heavily inspired by Codex Symphony and its orchestration model, while focusing on local-first and personal workflows.
Workflow Customization
The default implementation loop looks like this:
- Create a worktree and branch.
- Move the issue to
in_progress. - Implement the requested changes.
- Run agent-based review.
- Create a pull request.
However, these steps are not hardcoded.
tasq uses WORKFLOW.md files inspired by Symphony's workflow specification.
This means users can customize:
- review strategies
- branching models
- required checks
- skill selection
- pull request behavior
tasq only cares about:
- issue dependencies
- issue states
- orchestration
Everything else belongs to the user.
Autonomous agents still need humans
In an ideal world, agents would continuously fetch tasks and finish them without interruption.
Reality is messier.
Agents may require permissions.
CI pipelines fail.
Implementations sometimes diverge from expectations.
For these situations, tasq intentionally stays lightweight.
Each issue stores the execution session identifier of the underlying coding agent.
If something goes wrong, you can simply continue from the existing session:
codex resume <thread_id>
You don't need to create another issue just to fix CI failures or tweak a generated implementation.
You simply resume the conversation and continue from where the agent stopped.
Typical Workflow
A typical tasq workflow looks like this:
- Create a plan using Claude Code, Codex, or your preferred tools.
- Convert the plan into issues with
tq issue create. - Review the generated issues and mark them as
ready. - Let the orchestrator dispatch work automatically.
- Review the generated pull requests.
In practice, this often means your work becomes:
Review issues and move them to ready.
Everything else happens automatically.
tasq provides both a web interface and a CLI interface.
The CLI is primarily intended for coding agents, while the web interface focuses on issue management and orchestration visibility.
There is also a dedicated tasq skill package for coding agents so they can interact with the issue tracker without additional prompting.
What's Next?
There is still a lot to improve.
Current ideas include:
- TUI support
- Seamless recovery of blocked tasks
- Better onboarding and startup configuration
- Claude Code integration
I personally spend most of my time inside tmux and Vim, so a TUI feels inevitable.
I also want blocked tasks to recover automatically whenever possible.
For example, if CI fails, users shouldn't need to manually resume an agent and type:
fix ci
Finally, tasq currently depends on Codex App Server and does not yet support direct execution through Claude Code.
Long term, I would like planning and implementation workflows to work seamlessly across both ecosystems.
If any of this sounds interesting, I'd love for you to try the tutorial and share your feedback.
Top comments (0)