From devboy
Links issues with typed relationships (blocks, blocked-by, related, duplicates, parent/subtask) in GitHub, GitLab, Jira, ClickUp. Checks existing relations to avoid duplicates.
npx claudepluginhub meteora-pro/devboy-tools --plugin devboyThis skill uses the workspace's default tool permissions.
Create a typed relationship between two issues so the tracker's dependency graph reflects the real one. The skill covers the four canonical link types plus the special case of parent/subtask, and it inspects existing links first to avoid duplicates.
Manages GitHub issue hierarchies: add/remove/create sub-issues, check completion status/progress, list deps, set blocking/blocked-by relationships.
Manages GitHub Issues workflows with parent-child hierarchies, sub-issues, closing keywords, branch creation via gh issue develop, and cross-repo coordination for issue tracking strategies.
Manage GitHub Issues and Linear tasks: list, create, update, close, comment via ralph_task tool. Auto-detects platform from ID format.
Share bugs, ideas, or general feedback.
Create a typed relationship between two issues so the tracker's dependency graph reflects the real one. The skill covers the four canonical link types plus the special case of parent/subtask, and it inspects existing links first to avoid duplicates.
IssueRelations (the shape returned by get_issue_relations) groups links into five buckets:
| Bucket | linkType to pass | Meaning |
|---|---|---|
blocked_by | blocked_by | The source cannot progress until the target is done |
blocks | blocks | The source must be done before the target can progress |
related_to | relates_to | Soft relationship — "see also" |
duplicates | duplicates | The source is a duplicate of the target |
parent / subtasks | subtask | Source is a subtask of target (ClickUp / Jira) |
Provider support varies:
relates_to, blocks, blocked_by.relates_to (dependency-free by default; Projects v2 adds more).update_issue parentId in addition to link_issues.If a given relationship is not supported by the active provider, link_issues returns ProviderUnsupported — fall back to an explanatory comment instead.
Before adding a link, list the existing ones so you do not create a duplicate edge:
devboy tools call get_issue_relations '{"key": "DEV-200"}'
# or in aggregate via get_issue
devboy tools call get_issue '{"key": "DEV-200", "includeRelations": true}'
Look at blocked_by, blocks, related_to, duplicates, parent, subtasks. If the edge you are about to add already exists, stop — the tracker is already correct.
One link_issues call per edge. All three fields are required:
# "DEV-200 is blocked by DEV-100"
devboy tools call link_issues '{
"sourceIssueKey": "DEV-200",
"targetIssueKey": "DEV-100",
"linkType": "blocked_by"
}'
# "DEV-55 duplicates DEV-40"
devboy tools call link_issues '{
"sourceIssueKey": "DEV-55",
"targetIssueKey": "DEV-40",
"linkType": "duplicates"
}'
# "DEV-42 is related to DEV-17"
devboy tools call link_issues '{
"sourceIssueKey": "DEV-42",
"targetIssueKey": "DEV-17",
"linkType": "relates_to"
}'
Where the provider supports it, prefer update_issue with parentId — it moves the issue under the parent in one call and most trackers render the hierarchy natively:
devboy tools call update_issue '{"key": "CU-child", "parentId": "CU-epic"}'
Fall back to link_issues with "linkType": "subtask" if the provider expects that shape.
A real request usually needs more than one edge. Walk them one at a time — the tool is not batched:
"This MR fixes DEV-123 and is blocked by DEV-100."
# DEV-<current> blocks? no — DEV-<current> is blocked by DEV-100
devboy tools call link_issues '{
"sourceIssueKey": "DEV-<current>",
"targetIssueKey": "DEV-100",
"linkType": "blocked_by"
}'
# "fixes" on most trackers is just a related link + automation on merge
devboy tools call link_issues '{
"sourceIssueKey": "DEV-<current>",
"targetIssueKey": "DEV-123",
"linkType": "relates_to"
}'
unlink_issues takes the same three fields:
devboy tools call unlink_issues '{
"sourceIssueKey": "DEV-55",
"targetIssueKey": "DEV-40",
"linkType": "duplicates"
}'
get_issue_relations after the operation shows the new edge in the correct bucket.create-issue and then link.