| name | kb-link |
| description | Link two Cline Kanban tasks so one waits on the other (auto-cascade pipeline). When a task in review is trashed, any linked backlog task auto-starts. Use when the user says "kb-link", "link these tasks", "make X depend on Y", "chain these tickets", or wants to wire up a sequential pipeline of work. Project-agnostic. |
| category | execution |
| runtimes | ["claude"] |
| pii_safe | true |
Cline Kanban Link Skill
Wire two tasks with a dependency relationship. The "waiting" task auto-starts when the "prerequisite" task is trashed (typically after passing review).
When to use
Triggers: /kb-link, "kb-link", "link these tasks", "make X wait on Y", "chain ticket A after B", "set up auto-cascade".
Often called right after creating a sequence of tickets with /kb-do or /kb-plan to chain them.
Inputs
- Required: two task IDs
--project <path> — defaults to cwd
The order matters when both are in backlog: first ID waits on second ID. Once one moves out of backlog, Cline Kanban reorients automatically (the remaining backlog task becomes the dependent).
Usage forms:
/kb-link <waiting-id> <prereq-id> — explicit ordering/kb-link --task-id <waiting> --linked-task-id <prereq> — full flag form
How linking works (important)
Cline Kanban's link semantics:
- Both tasks in backlog: the order you pass is preserved.
--task-id A --linked-task-id B means A waits on B. Board arrow: A → B.
- One task moves to in_progress / review: Kanban reorients the saved dependency so the remaining backlog task is the waiting dependent. The user can ignore reordering — it's automatic.
- The prerequisite task is trashed (typically after review): the waiting backlog task auto-starts.
Combined with --auto-review-mode commit|pr|move_to_trash on the prerequisite, you get a fully autonomous pipeline:
- Task A finishes → auto-commits → moves to review → auto-trashes → task B auto-starts.
Procedure
-
Resolve project path. --project <path> if given, else pwd.
-
Validate task IDs exist by calling task list first. Filter to the two IDs and confirm they're in the project.
-
Create the link:
'/usr/bin/node' '<LOCAL_PATH>/.local/bin/kanban' task link \
--task-id <waiting> \
--linked-task-id <prereq> \
--project-path <project>
-
Capture the dependency ID from the response. Echo it so the user can unlink later if needed.
-
Confirm with a simple visualization:
Linked: [b8920] Audit session token handling
↓ (waits on)
[c526a] BIN Enrichment Service
Auto-cascade: when c526a is trashed, b8920 will start.
Dependency ID: 47edcd69 (use with /kanban task unlink to remove)
Pipeline patterns
Linear chain
A → B → C → D (each step starts when the previous trashes):
/kb-link B A
/kb-link C B
/kb-link D C
Fan-out (multiple tasks all wait on one prereq)
B, C, D all wait on A:
/kb-link B A
/kb-link C A
/kb-link D A
When A trashes, B/C/D all start in parallel.
Fan-in (one task waits on multiple prereqs)
D waits on both B and C:
/kb-link D B
/kb-link D C
D won't auto-start until BOTH B and C are trashed.
Anti-patterns
- Do NOT link tasks across different projects — Cline Kanban scopes links to a single workspace.
- Do NOT link a task to itself.
- Do NOT link a task that's already in
trash — the link will be silently ignored (or rejected, depending on Kanban version).
- Do NOT rely on a specific arrow direction without testing — if uncertain, run
/kb-status after linking and confirm the dependency renders correctly.
Companion skills
/kb-do, /kb-plan — create the tasks before linking/kb-trash — trash a prerequisite task to fire the cascade/kb-status — visualize the current dependency graph
