New: watch your coding agents work, step by step, on a live board. Try the demo, no account

Move your Vibe Kanban, Beads, Backlog.md or Taskmaster tasks into Taskhold

By Jake Marsh, who builds Taskhold. Updated 2026-10-31. Facts about other tools checked 2026-10-31. 9 min read.

Short answer: Your coding agent does the move. Point it at the source (the Vibe Kanban database or export, bd export, the Backlog.md task files or Taskmaster's tasks.json), paste the prompt for that tool, and it calls taskhold_create for each open task and taskhold_plan for its subtasks. Priorities carry over, dependencies become a line in the description, and the source files stay untouched.

Each of these four tools keeps its tasks in a file or database on your machine, so an agent can read them directly. Connect the agent to Taskhold, export or locate the data as shown below, and paste the prompt. Every task lands in To Do on the live board, with its subtasks as steps.

The prompts use two MCP tools: taskhold_create (title, description, priority, project, labels) and taskhold_plan (task_id and an ordered list of steps). For TODO.md, GitHub Issues or Linear, see the other import guide.

The live board, drawn with the same progress bar component the app uses. A working task with five steps, and a blocked task waiting on a reply.

Before you start

  • Connect the agent to Taskhold. Start the 7-day trial, make a setup URL in Settings and paste it into the agent.
  • Run the prompt from the repo's folder, so the folder name becomes the project. Projects are created the first time the agent passes a name.
  • Try five tasks first. Add "only the first five tasks" to the prompt, check them in the web app, then run the rest.
  • Limits per task: titles up to 500 characters, descriptions up to 10,000, 20 labels, and up to 200 steps (50 per taskhold_plan call). Steps don't nest, so a subtask of a subtask goes into the same step list after its parent.

Vibe Kanban

Vibe Kanban kept two kinds of tasks. Tasks in the local app live in a SQLite file: db.v2.sqlite (db.sqlite in older versions) in ~/Library/Application Support/ai.bloop.vibe-kanban on a Mac or ~/.local/share/vibe-kanban on Linux. The tasks table has title, description and a status of todo, inprogress, inreview, done or cancelled, and each row points at a project. This command saves the open ones as JSON without changing the file:

sqlite3 -readonly -json "$HOME/Library/Application Support/ai.bloop.vibe-kanban/db.v2.sqlite" \
  "SELECT p.name AS project, t.title, t.description, t.status
     FROM tasks t JOIN projects p ON p.id = t.project_id
    WHERE t.status NOT IN ('done', 'cancelled')
    ORDER BY t.created_at" > vibe-tasks.json
Move the Vibe Kanban tasks in vibe-tasks.json into Taskhold.

- Each entry is one open task. Call taskhold_create for each:
  - project: the entry's project (the Vibe Kanban project name)
  - title: title
  - description: description, then a last line "From Vibe Kanban, status <status>"
  - labels: ["in-review"] when status is inreview
- Leave priority out (Vibe Kanban's local tasks have none, so they come in as medium).
- Don't start any task.
- When you finish, tell me how many tasks you filed per project.

Kanban issues from Vibe Kanban Cloud weren't in that file. If you downloaded the export ZIP when the cloud service shut down, its issues.csv has the columns Issue ID, Title, Description, Status, Priority (Urgent, High, Medium or Low), Project, Assignee(s), Creator, Created, Updated, Start Date, Due Date, Completed and Parent Issue. Paste this with the CSV in the folder:

Move the open issues in issues.csv (a Vibe Kanban export) into Taskhold.

- Skip issues with a Completed date, and issues whose Status is a done or canceled column.
- An issue with a Parent Issue becomes a step of its parent's task. Every other open issue becomes a task.
- For each task, call taskhold_create:
  - project: the Project column
  - title: Title
  - description: Description, then "Due <Due Date>" if there is one, then a last line "Vibe Kanban <Issue ID>, status <Status>"
  - priority: Urgent = urgent, High = high, Medium = medium, Low = low, empty = medium
- Then, for a task with child issues, call taskhold_plan with task_id (the new task's id) and steps: one {title, description} per child, oldest first.
- Don't start any task.
- When you finish, tell me how many tasks and steps you filed and how many issues you skipped.

Beads

Beads stores issues in Dolt, and bd export writes them as JSONL, one issue per line with its labels, dependencies and comments. Regular issues only by default (no agents, roles, messages or memories). Fields the prompt uses: id, title, description, design, acceptance_criteria, status (open, in_progress, blocked, deferred, closed, pinned or hooked), priority (0 to 4, where 0 is critical), issue_type, labels, and dependencies, each with depends_on_id and a type such as blocks or parent-child.

bd export -o beads.jsonl
Move the open Beads issues in beads.jsonl into Taskhold.

- Project: this repo's folder name. Pass it as project on every call.
- Each line is one issue. Skip issues whose status is closed.
- An issue with a "parent-child" dependency is a child, and depends_on_id is its parent. Children of an open parent become steps of the parent's task. Every other open issue becomes a task.
- For each task, call taskhold_create:
  - title: title
  - description: description, then design and acceptance_criteria under their own headings when present, then "Waits on: <depends_on_id, ...>" for its "blocks" dependencies, then a last line "Beads <id>, status <status>"
  - priority: 0 = urgent, 1 = high, 2 = medium, 3 or 4 = low
  - labels: labels plus issue_type, up to 20
- Then, for a task with children, call taskhold_plan with task_id (the new task's id) and steps: one {title, description} per child in id order (bd-a3f8.1 before bd-a3f8.2), each description being the child's description plus "Beads <id>". Grandchildren go in the same list, after their parent.
- For each comment on an issue, call taskhold_add_note on its task with "<author>: <text>".
- Don't start any task, and don't run bd commands that change anything.
- When you finish, tell me how many tasks and steps you filed and how many issues you skipped.

Taskhold has no dependency graph, so dependencies stay as a line of text and priority sets the order. Keep Beads for a project that needs bd ready and atomic claims, and see Taskhold vs Beads for running both.

Backlog.md

Backlog.md keeps each task as a markdown file in backlog/tasks/ (or .backlog/tasks/, or the folder named by backlog_directory in backlog.config.yml). Each file opens with YAML frontmatter: id, title, status, labels, priority (high, medium or low), dependencies, and parent_task_id on subtasks. The body has Description, Acceptance Criteria (checkboxes) and Implementation Plan sections. Finished tasks move to backlog/completed/.

Move the open Backlog.md tasks into Taskhold.

- Project: this repo's folder name. Pass it as project on every call.
- Read the .md files in backlog/tasks/. Leave out backlog/completed/, backlog/archive/ and backlog/drafts/.
- Skip tasks in the final status (the last entry of statuses in backlog/config.yml, Done by default).
- A file with parent_task_id is a subtask and becomes a step of its parent's task. Every other open file becomes a task.
- For each task, call taskhold_create:
  - title: title
  - description: the Description section, then the unchecked Acceptance Criteria items ("- [ ]"), then the Implementation Plan if there is one, then "Depends on <dependencies>" when that list isn't empty, then a last line "Backlog.md <id>: <file path>". Leave out the <!-- ... --> marker comments.
  - priority: priority (medium if missing)
  - labels: labels, up to 20
- Then, for a task with open subtasks, call taskhold_plan with task_id (the new task's id) and steps: one {title, description} per subtask in id order, each description being its Description section plus "Backlog.md <id>".
- Don't edit, move or archive any file in backlog/.
- When you finish, tell me how many tasks and steps you filed and how many files you skipped, by status.

The files stay in git, so the history of each task is still there. Taskhold vs Backlog.md covers when to keep using it.

Taskmaster AI

Taskmaster AI keeps tasks in .taskmaster/tasks/tasks.json, grouped by tag: the file has one object per tag ("master" is the default), each with a tasks array. Each task has id, title, description, status (pending, in-progress, review, done, deferred or cancelled), dependencies (task ids), priority (high, medium or low), details, testStrategy and subtasks with the same fields.

Move the Taskmaster tasks in .taskmaster/tasks/tasks.json into Taskhold.

- Project: this repo's folder name. Pass it as project on every call.
- The file has one object per tag, each with a tasks array. If tasks sits at the top level instead, treat it as the master tag.
- Skip tasks and subtasks whose status is done or cancelled.
- For each remaining task, call taskhold_create:
  - title: title
  - description: description, then "Details:" with details, then "Test strategy:" with testStrategy, then "Depends on Taskmaster tasks <dependencies>" when that list isn't empty, then a last line "Taskmaster task <id>, tag <tag>, status <status>". 10,000 characters at most.
  - priority: priority (medium if missing)
  - labels: the tag name unless it is master, plus "deferred" or "review" when that is the status
- Then, for a task with remaining subtasks, call taskhold_plan with task_id (the new task's id) and steps: one {title, description} per subtask in id order, each description being its description and details, 5,000 characters at most.
- Don't start any task, and don't edit tasks.json.
- When you finish, tell me how many tasks and steps you filed and how many you skipped, by status.

Taskmaster's dependencies become a line of text, so set priorities for the order you want. Taskhold vs Taskmaster AI compares the two, including tool count and token cost.

Checking the result

  • Compare the counts the agent reports with the source. Each prompt asks for them.
  • Wrong title, priority or project: ask the agent to fix it with taskhold_update or taskhold_set_priority.
  • Tasks that shouldn't exist: delete them in the web app (open the task, Delete Task). The MCP tools have no delete, which is why the five-task trial run helps.
  • In-progress work in the source comes in as To Do. When the agent picks a task up, taskhold_begin with its task_id starts it and its first step.
Share this page:XLinkedInBlueskyHacker News

See how far along your coding agents are.

$12/month or $120/year after the trial. Card up front. Cancel before day 7 and you pay nothing. Every agent you run is included.

Questions

Does Taskhold have a built-in importer for Vibe Kanban, Beads, Backlog.md or Taskmaster?
No. Your coding agent reads the source and calls taskhold_create and taskhold_plan, using the prompts on this page. The move costs nothing beyond your plan, and the agent can adjust the mapping if your files differ.
Do subtasks and dependencies carry over?
Subtasks do: they become the steps of the task, in order. Dependencies don't, because Taskhold has no dependency graph; the prompts write them into the description as a line such as "Waits on: bd-a3f8.1" so you can set priorities to match.
Will the import change my Beads, Backlog.md or Taskmaster files?
No. Each prompt tells the agent to read only: no bd commands that write, no edits in backlog/, no changes to tasks.json, and the Vibe Kanban query opens the database read-only.
Can I keep using the old tool alongside Taskhold?
Yes. Nothing syncs, so both keep working. Some people keep Beads or Taskmaster for one repo's plan and use Taskhold for the work they hand to agents across repos.

Sources

Related

Updated 2026-10-31. Something wrong or out of date? Email hello@greatwork.company.