Task dependencies

Chain tasks together so one starts automatically when another finishes.

Dependencies let you build fully autonomous pipelines. One task finishes, commits, and kicks off the next — without you having to watch the board.

How dependencies work

When you link two tasks, the waiting task sits in backlog until its prerequisite finishes. The moment the prerequisite is trashed (meaning it has completed its work and been committed or otherwise resolved), Kanban automatically starts the waiting task.

Combine dependencies with auto-commit and you get end-to-end automation: one task completes → commits → triggers the next → repeats until the whole chain is done.

Linking tasks in the UI

Hold Cmd (macOS) or Ctrl (Windows / Linux) and click a card to enter link mode, then click the second card to create the dependency. An arrow appears on the board connecting the two cards.

Dependency direction:

• If both tasks are in backlog, the order you click sets the direction: the first card you click waits on the second.
• If one task is already running or in review, Kanban automatically orients the link so the backlog task is the waiting dependent.

To remove a link, open the task detail view and delete the dependency from the connections panel.

CLI

You can also manage dependencies from the command line.

# Link two tasks: the first waits on the second
kanban task link \
  --task-id <waiting-task-id> \
  --linked-task-id <prerequisite-task-id>

# Remove a dependency by its ID
kanban task unlink --dependency-id <dep-id>

When both tasks are in backlog, Kanban preserves the order you pass: --task-id waits on --linked-task-id. Once only one task remains in backlog (because the other has started or moved to review), Kanban reorients the link automatically so the backlog task is always the waiting dependent.

To find dependency IDs, run kanban task list — the output includes a dependencies array with each dependency’s ID and the task IDs it connects.

Example: autonomous auth system

Here is a real workflow showing how an agent can decompose a large feature into a dependency chain that runs without supervision.

1. Ask the sidebar agent to decompose the work

   Open the sidebar and say:

   “Break down adding an auth system into tasks. Each task should auto-commit when done, and link them in order so they run sequentially.”

   The agent creates the cards and the dependency links for you.

2. Review the plan

   You end up with three linked cards in backlog:

   1. Add database schema for users and sessions — auto-commit enabled
   2. Implement JWT login and refresh endpoints — auto-commit enabled, waits on task 1
   3. Add auth middleware and protect routes — auto-commit enabled, waits on task 2
3. Start the first task

   Click play on the first card. The rest of the chain runs on its own.

   • Task 1 finishes → auto-commits to the base branch → moves to trash
   • Task 2 starts automatically → finishes → auto-commits → moves to trash
   • Task 3 starts automatically → finishes → auto-commits → done

When you ask an agent to decompose work, it will often choose an order that maximizes parallelism — for example, running independent subtasks at the same time and only serializing the ones that genuinely depend on each other.

Constraints

• A task must be in backlog to be the waiting dependent in a link. Tasks in in_progress, review, or trash cannot wait on a prerequisite.
• A trashed task cannot participate in a new link.
• A task cannot depend on itself.
• Duplicate links between the same two tasks are not allowed.