How do I install the Link skill?

Run npx skillmds@latest add iankiku/link in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Link?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

iankiku (@iankiku) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Link by iankiku — Agent Skill

Name: Link
Author: iankiku

Link

(forwward) Keeps every PR linked to a tracker issue — detects the project's tracker (Linear, Jira, or GitHub Issues), validates the PR body has a closing keyword, and if it's missing, creates the issue and adds the reference. Triggers on "link this PR to a ticket", "make an issue for this", "does this PR have a ticket", or before merging work that has none.

iankiku 0a83f8c 3.3 KB Updated Sep 17, 2026

File contents

Link — Every PR Traces to an Issue

No work should merge untracked. This enforces the convention — a PR links to a tracker issue via a closing keyword — and closes the gap when one's missing by creating the issue and wiring the reference.

North star: every PR body carries a valid Closes|Refs <ISSUE-KEY> for the project's actual tracker, and the issue exists — done with one command, not a manual hunt.

Step 0 — Detect the tracker (never assume)

Resolve which tracker this repo uses, in order:

The repo's PR template or contributing doc, if it states a convention.
Config or references in the repo pointing at a Linear team, a Jira project key, or GitHub Issues.
If genuinely ambiguous, ask once rather than guessing — creating a ticket in the wrong system is worse than asking.

Key formats: Linear uses a team prefix (TEAM-123), Jira uses a project key (PROJ-123), GitHub Issues uses #123 in the same repo or owner/repo#123 cross-repo.

Step 1 — Check the PR for a valid link

gh pr view <num> --json body,title,headRefName

Present and the issue exists (verify against the tracker) → nothing to do, report it.
Present but the issue doesn't exist or is in the wrong project → flag it, treat as missing.
Absent → Step 2.

Step 2 — Create the issue (when missing)

Draft from the PR, then create it in the detected tracker:

Title — the PR title, tightened to an imperative.
Description — a 2-3 line what/why from the PR body, plus a link back to the PR.
Team/project — the repo's mapped destination; confirm rather than guess if there's more than one.
Status/labels — sensible defaults only (e.g. "In Progress" since a PR already exists) — don't over-set fields the team doesn't use.

Capture the returned key.

Step 3 — Wire the reference back

Add the closing keyword to the PR body so the link is bidirectional and the merge can auto-close the issue:

gh pr edit <num> --body "<updated body with 'Closes TEAM-456' appended>"

Prefer Closes/Fixes when the PR fully resolves the issue (auto-closes on merge); use Refs when it's partial. Confirm the tracker now shows the PR linked.

Optional: retro sweep

To backfill a whole repo: list open PRs, run Steps 1-3 per unlinked PR. Skip drafts and already-linked PRs.

Anti-patterns

Guessing the tracker instead of detecting it from the repo's own convention.
Creating a duplicate issue when a valid one is already referenced — verify existence first.
Inventing an issue key instead of creating a real one.
Over-populating tracker fields; set the minimum that makes it useful.
Using Closes on a PR that only partially addresses the issue (it wrongly auto-closes) — use Refs.

---name: linkdescription: (forwward) Keeps every PR linked to a tracker issue — detects the project's tracker (Linear, Jira, or GitHub Issues), validates the PR body has a closing keyword, and if it's missing, creates the issue and adds the reference. Triggers on "link this PR to a ticket", "make an issue for this", "does this PR have a ticket", or before merging work that has none.---# Link — Every PR Traces to an IssueNo work should merge untracked. This enforces the convention — a PR links to a tracker issue via aclosing keyword — and closes the gap when one's missing by creating the issue and wiring the reference.**North star:** every PR body carries a valid `Closes|Refs <ISSUE-KEY>` for the project's actual tracker,and the issue exists — done with one command, not a manual hunt.## Step 0 — Detect the tracker (never assume)Resolve which tracker this repo uses, in order:- The repo's PR template or contributing doc, if it states a convention.- Config or references in the repo pointing at a Linear team, a Jira project key, or GitHub Issues.- If genuinely ambiguous, ask once rather than guessing — creating a ticket in the wrong system is worse than asking.Key formats: Linear uses a team prefix (`TEAM-123`), Jira uses a project key (`PROJ-123`), GitHub Issuesuses `#123` in the same repo or `owner/repo#123` cross-repo.## Step 1 — Check the PR for a valid link```bashgh pr view <num> --json body,title,headRefName```Look in the body (and the branch name as a fallback) for a closing keyword + a real issue key:`Closes|Close|Closed|Fixes|Fix|Fixed|Resolves|Resolve|Resolved|Refs|Ref <KEY>`.- **Present and the issue exists** (verify against the tracker) → nothing to do, report it.- **Present but the issue doesn't exist or is in the wrong project** → flag it, treat as missing.- **Absent** → Step 2.## Step 2 — Create the issue (when missing)Draft from the PR, then create it in the detected tracker:- **Title** — the PR title, tightened to an imperative.- **Description** — a 2-3 line what/why from the PR body, plus a link back to the PR.- **Team/project** — the repo's mapped destination; confirm rather than guess if there's more than one.- **Status/labels** — sensible defaults only (e.g. "In Progress" since a PR already exists) — don't over-set fields the team doesn't use.Capture the returned key.## Step 3 — Wire the reference backAdd the closing keyword to the PR body so the link is bidirectional and the merge can auto-close theissue:```bashgh pr edit <num> --body "<updated body with 'Closes TEAM-456' appended>"```Prefer `Closes`/`Fixes` when the PR fully resolves the issue (auto-closes on merge); use `Refs` whenit's partial. Confirm the tracker now shows the PR linked.## Optional: retro sweepTo backfill a whole repo: list open PRs, run Steps 1-3 per unlinked PR. Skip drafts and already-linkedPRs.## Anti-patterns- Guessing the tracker instead of detecting it from the repo's own convention.- Creating a duplicate issue when a valid one is already referenced — verify existence first.- Inventing an issue key instead of creating a real one.- Over-populating tracker fields; set the minimum that makes it useful.- Using `Closes` on a PR that only partially addresses the issue (it wrongly auto-closes) — use `Refs`.

Frequently asked questions