Features
Tasks
A task is the unit of work in Modula: a ticket with a title and description that agents turn into reviewed code. Tasks either come from an external tracker (like Jira) or are created directly in the app.
Every task gets an ID. Internal tasks get an auto-generated one (like MOD-001); synced tasks keep their tracker key (like ENG-1234) and link back to the original issue.
Create a task
From the Tasks page, click +, give the task a title, and add a markdown description. The description is what agents work from, so the same advice applies as for a good ticket: state the outcome you want and any constraints, and let the Researcher figure out the how.
Tasks can also arrive from an external tracker. Default scan agents mirror issues from Jira, Linear, and GitHub into your workspace; see tracker sync for setup. Synced tasks keep their external status and URL, and stay in sync on each scan.
Approval is the gate
New tasks start as Pending. Agents never touch a task until you set its approval to Approved in the task’s Workflow panel. Set it to Rejected to dismiss a task without deleting it.
Approving a task is what starts the pipeline: the Project Manager agent picks it up, sequences it onto the roadmap, and hands it to the Researcher.
The pipeline
The Roadmap page shows every active task on a column-per-status board. A task moves through these stages:
| Status | What it means |
|---|---|
| Planning | Project Manager is evaluating the task and its dependencies |
| Ready for research / Researching | Researcher is investigating the codebase and writing specs |
| Needs clarification | Researcher hit ambiguity and asked you a question in the task thread |
| Ready for workers / In progress | Workers are implementing, Code-Reviewers are reviewing |
| Ready for review / In review | Reviewer is judging the finished variants as a whole |
| Ready for acceptance | Approved by the Reviewer, waiting on you |
| Accepted | You merged the winner. Done |
| Blocked | Stuck, needs manual attention |
You can move a task manually at any time with the Roadmap dropdown in the task’s Workflow panel. Setting a status re-emits the matching event, so the right agent picks the task up again.
Variants
A variant is one complete attempt at a task: its own spec, its own branch, its own worktree per project. By default a task has one variant. Raise Max variants (up to 10) in the task’s Execution panel to have the Researcher spec several approaches and run a Worker on each in parallel. When they all finish, you compare and pick the best one.
Each variant moves through its own smaller cycle: implemented by a Worker, reviewed by a Code-Reviewer, sent back for rework as many rounds as needed, then accepted.
Worktree mode and direct mode
By default each variant works on its own branch (feature/<task-slug>-v1) in an isolated worktree under <project>/.worktrees/, so parallel attempts never collide and your checkout is never touched.
Set Worktree to No for direct mode: the Worker commits straight onto the project’s base branch with no new branch and no worktree. Direct mode forces max variants to 1. Use it for rapid prototyping when you don’t want PR overhead.
Inside a task
Opening a task shows everything about it in one place:
- Variants with their current status, a Changes button that opens the full diff, and PR links once a branch has an open pull request.
- Thread tabs, one for the task and one per variant. This is where agents talk: the Researcher asks clarifying questions, the Code-Reviewer posts findings with file references, the Reviewer posts its verdict. You can reply in any thread.
- Runs, the history of every agent run on this task, each with a live-streaming log.
- Workflow, the approval and roadmap status controls.
- Execution, the worktree toggle and max variants.
- Branches, every branch the task created per project, with commit counts.
- Agent settings, per-task overrides like agent looping.
Answering a clarification
When a task sits at Needs clarification, open it, read the Researcher’s question in the task thread, post your answer, then set the roadmap status back to Ready for research. The Researcher resumes with your answer in hand.
Review and ship
When a task reaches Ready for acceptance:
- Read the Reviewer’s verdict in the task thread, and each variant’s thread for the Code-Reviewer’s findings.
- Open each variant’s Changes diff and pick the winner.
- Push the winning branch to your remote. Agents commit locally but never push; that stays in your hands.
- Use the Create PR button next to the project diff. It opens a prefilled GitHub compare page for the branch. Once a PR is open, the button becomes a link to it.
- Merge, then set the task’s roadmap status to Accepted.
If you’re not happy with the result, set the variant’s status to Rework instead and leave feedback in its thread. The Worker picks it back up.
Reset and delete
The Danger Zone at the bottom of a task offers two cleanups:
- Reset task clears the task’s variants, branches, worktrees, spec files, threads, and runs, but keeps the task itself, ready for a fresh start.
- Delete task removes the task entirely.