link

name	link
description	Link skill — create same-backend relationships between tickets
risk_class	hard
confirm_action	link.create

Link

Create a same-backend relationship between two tickets and reflect the link in both wiki task pages.

Arguments

$ARGUMENTS — Two task references and a relationship type: <ref-a> <ref-b> <relationship>

Examples:

• wiki/tasks/fix-login-bug.md wiki/tasks/auth-rewrite.md blocks
• GEORGE-288 GEORGE-291 blocks
• owner/repo#12 owner/repo#15 relates-to

Supported relationship types: blocks, blocked-by, relates-to, duplicates, duplicated-by

If $ARGUMENTS is empty, ask the user to provide two task references and a relationship type.

Behavior

Step 1 — Parse arguments

Extract the two task references and the relationship type from $ARGUMENTS. If any are missing, prompt the user.

Step 2 — Resolve wiki task pages

For each reference, find the corresponding wiki task page:

• If the reference is a wiki path (e.g., wiki/tasks/foo.md), read it directly.
• If the reference is a backend key (e.g., GEORGE-288 or owner/repo#12), scan wiki/tasks/ for a task page with a matching jira_ref, gh_ref, or asana_ref in frontmatter.

If a wiki page cannot be found for a reference, inform the user and stop.

Step 3 — Identify the backend

Both tasks must share the same backend. Read the backend reference from each wiki task page (gh_ref, jira_ref, or asana_ref).

If the tasks use different backends or have no backend reference, inform the user: "Both tasks must have a backend reference in the same system to create a link."

Read workspace.md to confirm the backend is configured.

Step 4 — Create the relationship via the gated primitives

This skill is risk_class: hard and composes two primitive writes — one on each side of the link. Each write goes through the CLI gate (rubber-ducky comment for GitHub-style cross-reference comments; rubber-ducky link is not a v1 primitive yet for Jira / Asana, see "Linking on Jira and Asana" below for the documented gap).

Build the preview as plain text:

Action:  link
Backend: <backend-name>
Source:  <ref-a>
Target:  <ref-b>
Type:    <relationship>

GitHub

The link is two cross-reference comments. Each comment is its own hard write — issue a fresh confirm-token and invoke rubber-ducky comment twice:

TOKEN_A=$(rubber-ducky --no-json confirm request \
  --action github.comment \
  --preview "Link comment on $REF_A: Related: $RELATIONSHIP $REF_B")
rubber-ducky --json comment <wiki-task-a> \
  --backend github \
  --text "Related: $RELATIONSHIP #$REF_B_NUMBER" \
  --confirm-token "$TOKEN_A"

TOKEN_B=$(rubber-ducky --no-json confirm request \
  --action github.comment \
  --preview "Link comment on $REF_B: Related: $INVERSE_RELATIONSHIP $REF_A")
rubber-ducky --json comment <wiki-task-b> \
  --backend github \
  --text "Related: $INVERSE_RELATIONSHIP #$REF_A_NUMBER" \
  --confirm-token "$TOKEN_B"

Both writes are CLI-enforced; an unconfirmed call cannot land a comment.

Linking on Jira and Asana (acknowledged gap)

Native issue-link types (Jira "Blocks", Asana dependencies, etc.) do not have a v1 rubber-ducky link primitive. For these backends, fall back to two rubber-ducky comment calls that note the relationship in body text — losing the native typed link in exchange for keeping every external write under the CLI gate. Surface this explicitly to the user before proceeding so they can choose: "Jira/Asana don't have a CLI-gated typed-link primitive yet. I can mark the relationship via comments on both tickets, or you can run the native link manually through the UI. Which?"

Step 6 — Update both wiki task pages

Add a ## Relationships section (or append to it if it already exists) on both task pages:

For ref-a:

- <relationship> [[wiki/tasks/<ref-b-slug>.md|<ref-b-title>]]

For ref-b (inverse relationship):

- <inverse-relationship> [[wiki/tasks/<ref-a-slug>.md|<ref-a-title>]]

Inverse mapping:

• blocks ↔ blocked-by
• relates-to ↔ relates-to
• duplicates ↔ duplicated-by

Step 7 — Summary audit log + rebuild

Each underlying rubber-ducky comment already wrote its own [write-back] comment → ... line. Append a summary that ties the pair together, then rebuild the index:

rubber-ducky log append "[link] <backend> (<ref-a> <relationship> <ref-b>) — created via 2 gated comments"
rubber-ducky index rebuild