kb-link - SKILL.md Agent Skill

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