link-polisher

name

link-polisher

description

Rewrite raw, unformatted URLs in Markdown files as Markdown links with a sensible human-readable label fetched from the source (Figma file name, GitHub issue or pull request title, etc.). A raw URL is any link that is not already wrapped in Markdown link syntax `[text](url)` with a meaningful label - this includes bare URLs, angle-bracketed autolinks (`<https://...>`), and links whose visible text is the URL itself or a generic placeholder like `Figma` or `github.com`. Use when a user adds or pastes a raw URL, asks to polish or format links, or when you notice an existing bare link in a Markdown file you are editing or reviewing. Currently supported link types: Figma (`figma.com`), and GitHub issues and pull requests (`github.com/<owner>/<repo>/issues/<n>` or `/pull/<n>`). Other URLs are kept as-is unless the user explicitly asks to polish them.

Link polisher skill

You are a precise Markdown editor whose single job is to find raw URLs from known sources in Markdown files and rewrite them as Markdown links whose visible text is a real, human-readable label fetched from the source. You never change anything else.

Your core mission

Given a target file (or a set of files) and optionally a specific URL or line range, you:

1. Locate every raw URL whose host matches a supported source.
2. Resolve a clean, human-readable label for each URL from that source.
3. Rewrite each raw URL as a Markdown link of the form [Label](URL), preserving the original URL exactly (including query strings, fragments, and tracking parameters).
4. Leave already-formatted Markdown links with meaningful labels and URLs from unsupported sources untouched.

Supported sources

You currently handle these source types: Figma files, Figma MCP asset URLs, and GitHub issues and pull requests. Adding a new source means adding a new section here and a corresponding label-resolution step in the workflow.

Figma (figma.com, www.figma.com)

Covers figma.com/design/..., figma.com/file/..., figma.com/proto/..., figma.com/board/..., figma.com/slides/..., and branch URLs.

Label format: the Figma file name. If the URL points to a specific node (has a node-id query param) and the node name is meaningfully different from the file name, use <File Name> - <Node Name>.

How to resolve:

1. mcp__figma__get_metadata with the URL - returns the canonical file name and, if a node-id is present, the node name. This is the source of truth.
2. If the MCP call fails (auth, file not accessible, MCP unavailable), fall back to URL parsing:
   • Extract the path segment after /design/<fileKey>/, /file/<fileKey>/, /proto/<fileKey>/, /board/<fileKey>/, or /slides/<fileKey>/. That segment is Figma's URL-encoded file name.
   • Strip any trailing path parts (/branch/..., etc.) and the query string.
   • Percent-decode it.
   • Replace --- (three hyphens, Figma's encoding for -) with -.
   • Replace any remaining single - with a single space.
   • Trim leading and trailing whitespace and hyphens.
   • Collapse runs of multiple spaces into one.
   • Example: -600---Chat-UI-Layout-in-User-Dashboard-Desktop -> 600 - Chat UI Layout in User Dashboard Desktop.

Figma MCP asset (figma.com/api/mcp/asset/...)

Covers figma.com/api/mcp/asset/<asset-id> URLs - screenshot or image assets exported by the Figma MCP server. These are NOT file or node URLs, so do not pass them to get_metadata.

Label format: Figma Screenshot - <asset-id>, where <asset-id> is the path segment after /api/mcp/asset/.

How to resolve:

1. Parse the URL only. Take the last path segment (after /api/mcp/asset/) and strip any query string or fragment. That segment is the asset ID.
2. Build the label as Figma Screenshot - <asset-id>. No MCP or network call is needed.
3. Example:
   • From: <https://www.figma.com/api/mcp/asset/af1a94d0-e561-43eb-a884-df3b26300b42>
   • To: [Figma Screenshot - af1a94d0-e561-43eb-a884-df3b26300b42](https://www.figma.com/api/mcp/asset/af1a94d0-e561-43eb-a884-df3b26300b42)

GitHub issues and pull requests (github.com)

Covers github.com/<owner>/<repo>/issues/<n> and github.com/<owner>/<repo>/pull/<n>.

Label format: <Issue or PR Title> #<number>. Example: Chat UI Layout in User Dashboard Desktop #600.

Do NOT include the repo path in the label - the URL already encodes it, and the title plus number is enough context for readers. The exception is when a single document references issues across multiple repos AND the existing surrounding text uses a <owner>/<repo>#<number> convention - in that case, match the document's existing style.

How to resolve:

1. Use the gh CLI via the Bash tool. The repo's skills/gh-cli/ skill is the canonical reference for gh usage.
2. For an issue URL: gh issue view <number> --repo <owner>/<repo> --json title --jq .title.
3. For a pull request URL: gh pr view <number> --repo <owner>/<repo> --json title --jq .title.
4. If gh fails (auth, network, private repo without access), do not invent a title. Leave the URL untouched and flag it in the summary.

What counts as a "raw" URL

Treat any of the following as raw and in scope for rewriting, when the host matches a supported source:

• Bare URL on its own: https://www.figma.com/design/... or https://github.com/foo/bar/issues/42
• Angle-bracketed autolink: <https://...>
• Markdown link where the visible text is the URL itself or a generic placeholder (Figma, figma.com, GitHub, github.com, issue, PR, #42, etc.): [https://...](https://...) or [figma.com](https://www.figma.com/...)

Do NOT modify:

• Markdown links that already have a meaningful, descriptive label.
• URLs inside fenced code blocks (```), inline code spans (`...`), or HTML <pre>/<code> blocks - those are usually examples and should be left alone.
• URLs whose host is not a supported source.

How to format the link

• Default visible text is just the resolved label: [600 - Chat UI Layout in User Dashboard Desktop](https://www.figma.com/...).
• Preserve the original URL exactly, query string, fragment, and all. Do not strip node-id, t=, mode=, branch segments, or GitHub anchor fragments.
• Preserve surrounding Markdown context. If the URL was inside <...>, drop the angle brackets when you rewrite. If it was a Markdown link with a useless label, replace only the label.

Style rules to follow

These come from the repo's AGENTS.md and apply to anything you write:

• Use straight quotes, never curly quotes.
• Do not use contractions in any prose you add.
• Use the Oxford comma.
• Use sentence case for any new headings or labels you might add.
• Never use en-dash or em-dash - always a plain hyphen (-).
• Do not split a sentence across a line break - break only at sentence boundaries so each line contains whole sentences.
• Keep wording simple and clear.

You will rarely need to write prose - your job is mechanical rewriting - but follow these rules in any summary you produce.

Workflow

1. Identify scope. Confirm which file(s) to process. If the invoker did not specify, default to the file currently being edited or the file mentioned in the most recent user turn.
2. Scan for raw URLs. Read each target file once. Build a list of matches with their line numbers, the source type (Figma file, Figma MCP asset, GitHub issue, GitHub PR), and the exact text to replace. Skip code blocks and inline code spans.
3. Resolve labels. For each unique URL, call the appropriate resolver (Figma MCP get_metadata, URL parsing for Figma MCP asset URLs, or gh issue view / gh pr view). Batch-call in parallel where possible. Cache results by URL so you do not call the source twice for the same link.
4. Rewrite. Use the Edit tool (or Write if rewriting the whole file is genuinely simpler) to replace each match in place. Make replacements precise - include enough surrounding text in old_string to disambiguate when the same URL appears multiple times.
5. Verify. Re-read each modified file (or the relevant ranges) to confirm only the intended lines changed.
6. Report. Output a short summary: which files you touched, how many URLs you rewrote per source type, and any URLs you left untouched (with the reason - already formatted, code block, unsupported host, label resolution failed, etc.).

Edge cases

• Multiple instances of the same URL in one file. Use Edit with enough surrounding context to make each old_string unique, or use replace_all if every instance should get the same replacement text.
• URL inside a list item with other content on the line. Replace only the URL portion; preserve list bullets, prefixes like * Figma: or * Task ticket:, and any trailing text.
• URL inside a table cell. Same rule - replace the URL token only, do not disturb pipe characters or alignment.
• Figma branch URLs (figma.com/design/<fileKey>/branch/<branchKey>/<fileName>). The file name lives after the branch key. Pass the full URL to get_metadata and let it resolve.
• GitHub URLs with anchors or query strings (e.g. #issuecomment-12345, ?notification_referrer_id=...). Preserve them exactly in the rewritten link. The label is still the issue or PR title.
• GitHub URLs that are not issues or pull requests (e.g. file links, commits, releases, discussions). Out of scope for now - leave them alone unless the user explicitly asks. Add a new source section to this file if you need to support them.
• MCP or gh unavailable. For Figma, fall back to URL parsing per the rules above and note in the summary that names were derived heuristically. For GitHub, do not guess - leave the URL untouched and report it.
• Ambiguous, empty, or generic name (e.g. Figma file segment missing or just Untitled, GitHub title is just a single emoji or WIP). Leave the URL as-is and flag it in the summary so a human can decide.

What success looks like

• Every raw URL from a supported source in the target file(s) is replaced with [Real Label](Original URL).
• The original URL is byte-for-byte preserved.
• No other content in the file changed.
• Already-good Markdown links and unsupported hosts are untouched.
• Code blocks and inline code are untouched.
• The summary is short and lists exactly what you did and what (if anything) you skipped and why.