[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C5YP8DWQ48WT00FYTPACF6":3,"skill-same:01M6C5YP8DWQ48WT00FYTPACF6":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6C5YP8DWQ48WT00FYTPACF6","git-issue-scoping",null,"Read an issue's full comment thread and re-verify its cited evidence at HEAD. Use when scoping a PR or plan from a GitHub issue, or before filing or reversing one in your own tracker.","laurigates\u002Fclaude-plugins","laurigates","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F13014001?v=4","01M6C59YHWS9C7KMXKSRX1YXNP","Lauri Gates","01M6C59YP2APG9YAM4DWYQYGFJ",59,"MIT","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fgit-plugin\u002Fskills\u002Fgit-issue-scoping\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"git issue scoping","scoping","git","issue","git issue","git log","when","thread","filing","re","log","api","Bash","use","gh","gh pr","pr","evidence","plan","gh issue","2026-11-10 10:12:30",false,"---\nname: git-issue-scoping\ndescription: \"Read an issue's full comment thread and re-verify its cited evidence at HEAD. Use when scoping a PR or plan from a GitHub issue, or before filing or reversing one in your own tracker.\"\nallowed-tools: Read, Grep, Glob, Bash(gh issue *), Bash(gh pr *), Bash(gh api *), Bash(git log *), TodoWrite\ncreated: 2026-08-19\nmodified: 2026-11-06\nreviewed: 2026-08-19\n---\n\n# Git Issue Scoping\n\n## When to Use This Skill\n\n| Use this skill when... | Use the alternative when... |\n|---|---|\n| Scoping a PR, plan, or prototype from one issue's full comment thread | Use `git-triage` to sweep a whole backlog for close\u002Fmerge recommendations |\n| Re-verifying an issue's cited lines and evidence at HEAD before acting on it | Use `workflow-orchestration-plugin:workflow-verify-before-filing` to verify a backlog of bug claims before filing upstream |\n| Searching your own tracker before filing, or reading its history before reversing a decision | Use `github-issue-writing` to draft the issue body and title once filing is decided |\n| Deferring to a design the maintainer converged on in an upstream thread | Use `upstream-pr-contribution` for CONTRIBUTING.md and PR-template gates when opening the PR |\n\nInvoke before building a PR, plan, or prototype off a GitHub issue — including\nissues in repos you own, and before filing or reversing one in your own tracker.\n\nBefore building a PR (or even an approach) off a GitHub issue, **read every\ncomment in the thread** — not a fetched summary, not just the body. Issues that\nlook like simple feature requests are often where the maintainer has already\n**converged on a specific design** with other experts. A summary compresses\nexactly the part that matters: the decided mechanism, the agreed scope, and the\nwork someone has already volunteered to do.\n\n**Applies to repos you own too** (§ *Your own tracker*): the deference part is\nabout upstream, but the load-bearing part is that a tracker records decisions\npast-you made and no longer remembers.\n\n## The trap\n\n`WebFetch` (and any \"summarize this issue\" step) returns a *compressed* view. It\nfaithfully captures the issue **body** and headline asks, but silently drops the\nback-and-forth in the comments where the real decisions live. You then design\nagainst the body's framing, build a prototype, and discover — only if you go\nback and read the comments — that:\n\n- the maintainer picked a **different mechanism** than the obvious one,\n- the **scope** (MUST \u002F WANT \u002F NICE \u002F OUT) was explicitly bounded,\n- a dependency was **already prototyped** by a collaborator (and may be\n  unreleased, so half your plan isn't even buildable yet),\n- your \"open questions\" were **already answered** in the thread — so asking them\n  reads as not having done the homework.\n\nIncident: jnv #114, where a WebFetch summary hid a 33-comment design thread\n([REFERENCE.md](REFERENCE.md#the-trap-jnv-114-a-summary-that-dropped-the-design)).\n\n## The rule\n\nWhen an issue is the basis for a contribution, read the comments **first**:\n\n```sh\ngh issue view \u003Cn> --repo \u003Cowner>\u002F\u003Crepo> --json title,body,author,comments \\\n  --jq '.body, (.comments[] | \"--- \" + .author.login + \" ---\\n\" + .body)'\n```\n\nSpecifically extract, before writing any code:\n\n1. **Decided mechanism** — has the maintainer chosen an implementation approach?\n   Build *that*, or explicitly propose an alternative knowing theirs exists.\n2. **Scope ladder** — MUST \u002F WANT \u002F NICE \u002F OUT. Don't attempt OUT; don't skip MUST.\n3. **Dependencies in flight** — linked PRs\u002Fbranches a collaborator is building.\n   Check their state (`gh pr view` → merged? released?) before depending on them.\n4. **Who's driving** — if the maintainer is mid-collaboration with another expert,\n   a drive-by PR may duplicate their work. Ask whether a contribution is welcome\n   *before* investing, and frame the PR as building on the thread, not restarting it.\n\nIf you only have a summary and a gap has passed, **re-read the live thread** before\nacting — the discussion may have moved.\n\n## A bot's recommendation is not a maintainer decision\n\nPoint 1 of [The rule](#the-rule) asks whether the maintainer chose an approach. The trap is that an\nautomated triage comment **looks like** that choice. A `needs-decision` routine\nposts options A\u002FB\u002FC, adds its own **\"I'd default to B\"**, and closes with \"reply\nhere and the next run will implement the chosen option\". Nothing has been\ndecided. The recommendation is the bot's, and the reply it asks for is what would\nmake it a decision.\n\nRead authorship and look for the reply, in the same call that fetches the thread:\n\n```sh\ngh issue view \u003Cn> --repo \u003Cowner>\u002F\u003Crepo> --json comments --jq '.comments | length, (.[] | .author.login + \" | \" + (.body[0:80]))'\n```\n\nA single comment that is itself the request for a decision means the decision is\n**open**. Implement nothing that depends on it; ask the human, or say in the PR\nthat you picked an option and which one.\n\nIncident: two PRs shipped a bot's default as the maintainer's choice\n([REFERENCE.md](REFERENCE.md#a-bots-recommendation-two-prs-citing-a-decision-nobody-made)).\n\nTwo consequences worth separating:\n\n- **`Closes #N` on an undecided issue** auto-closes the decision when the PR\n  merges. Use `Refs #N` until the option is chosen.\n- **A false attribution is load-bearing.** On #2568 it was the *only* cited\n  grounds for rejecting a reviewer's finding, so the finding had to be\n  re-examined once the attribution collapsed. Never cite a decision you have not\n  read; when you chose the option yourself, say so plainly.\n\n## Your own tracker — search before filing, read before reversing\n\nNo maintainer to defer to is exactly why this gets skipped. Two failures:\n\n1. **Search before filing** — a well-researched duplicate is still a duplicate,\n   and the better write-up makes it *harder* to spot as one.\n   `gh issue list -R \u003Co>\u002F\u003Cr> --state all --search \"\u003Ckw>\" --json number,title,state`\n2. **Read before reversing** — an old issue records not just a problem but a\n   *decision with its reasoning*, including decisions to **defer**. Shipping the\n   deferred option because it is obviously better silently overrides a choice\n   made with context you no longer have.\n\nIncident: a duplicate filed and a deferred migration merged, ten minutes apart\n([REFERENCE.md](REFERENCE.md#your-own-tracker-a-duplicate-and-a-reversed-deferral-ten-minutes-apart)).\n\nThe tell: calling something \"the obvious fix\" on a subsystem broken long enough\nfor someone to have written about it — long-broken means *investigated*. When\nreversing a decision, say so on the PR and issue, quoting the old reasoning, so\nthe next reader sees a decision changed rather than forgotten.\n\n## An issue's cited evidence expires — re-verify every line before acting on it\n\nDistinct from the other sections, which are about *discussion* you failed to\nread. Here you read everything, and the issue is simply **out of date**: it\ncites `file.ts:230` and asserts what is there, and between filing and today\nsome unrelated PR fixed it. A well-written issue makes this worse — precise\nline numbers and quoted snippets read as verified fact, and the better the\nwrite-up, the less anyone re-checks it.\n\nIncident: thelma #1055, whose central claim a later PR had already fixed\n([REFERENCE.md](REFERENCE.md#cited-evidence-expires-thelma-1055-a-control-added-after-filing)).\n\n- **Re-read every file:line the issue cites, at HEAD, before writing anything\n  from it.** The issue is a *claim about the code*, and the code is the\n  authority — same instinct as `diagnose-at-the-failure-point.md`.\n- **Date the gap.** `gh issue view \u003Cn> --json createdAt` against\n  `git log -S'\u003Csymbol>' -- \u003Cpath>` finds the PR that moved it. An issue older\n  than a few weeks on an active file should be assumed stale until checked.\n- **Report the correction in the PR that acts on it**, so the next reader sees\n  the issue's evidence was superseded rather than silently contradicted.\n- Corollary for *filing*: prefer citing behaviour and symbols over line\n  numbers, which rot fastest.\n\n## When it bites\n\n- Any external contribution scoped from an issue, especially a popular repo where\n  maintainers discuss design in comments.\n- **Acting on an issue filed weeks or months ago against a file that has since\n  changed** — the evidence is stale even though the thread is complete.\n- **Your own repo**, when the tracker is the last place you think to look.\n- Resuming work on an issue days later from a cached summary.\n- Letting an early `WebFetch`\u002Fresearch step stand in for the primary source.\n\n## Related\n\n- [REFERENCE.md](REFERENCE.md) — the incident behind each rule in this skill.\n\n- `~\u002F.claude\u002Frules\u002Fverify-upstream-before-patching.md` — same instinct (check\n  the authoritative source before acting) for vendored code; this is the\n  issue-thread analogue.\n- `agent-patterns-plugin:harness-tool-errors` (WebFetch) — a summary is lossy;\n  for a decision that gates real work, go to the full source, not the fetched\n  digest.\n- `git-plugin:git-issue` — the consumer: the end-to-end issue→PR workflow that\n  scopes from the issue thread this skill teaches you to read in full.\n\n## Rationale\n\nThe cost asymmetry is stark: reading the thread is one `gh issue view` and a few\nminutes; skipping it costs a misaligned prototype, a PR that signals you didn't\nread the discussion, and a reframe-or-close under the maintainer's eye. The full\nthread is the spec; the summary is a lossy proxy for it.\n","# Git Issue Scoping\n\n## When to Use This Skill\n\n| Use this skill when... | Use the alternative when... |\n|---|---|\n| Scoping a PR, plan, or prototype from one issue's full comment thread | Use `git-triage` to sweep a whole backlog for close\u002Fmerge recommendations |\n| Re-verifying an issue's cited lines and evidence at HEAD before acting on it | Use `workflow-orchestration-plugin:workflow-verify-before-filing` to verify a backlog of bug claims before filing upstream |\n| Searching your own tracker before filing, or reading its history before reversing a decision | Use `github-issue-writing` to draft the issue body and title once filing is decided |\n| Deferring to a design the maintainer converged on in an upstream thread | Use `upstream-pr-contribution` for CONTRIBUTING.md and PR-template gates when opening the PR |\n\nInvoke before building a PR, plan, or prototype off a GitHub issue — including\nissues in repos you own, and before filing or reversing one in your own tracker.\n\nBefore building a PR (or even an approach) off a GitHub issue, **read every\ncomment in the thread** — not a fetched summary, not just the body. Issues that\nlook like simple feature requests are often where the maintainer has already\n**converged on a specific design** with other experts. A summary compresses\nexactly the part that matters: the decided mechanism, the agreed scope, and the\nwork someone has already volunteered to do.\n\n**Applies to repos you own too** (§ *Your own tracker*): the deference part is\nabout upstream, but the load-bearing part is that a tracker records decisions\npast-you made and no longer remembers.\n\n## The trap\n\n`WebFetch` (and any \"summarize this issue\" step) returns a *compressed* view. It\nfaithfully captures the issue **body** and headline asks, but silently drops the\nback-and-forth in the comments where the real decisions live. You then design\nagainst the body's framing, build a prototype, and discover — only if you go\nback and read the comments — that:\n\n- the maintainer picked a **different mechanism** than the obvious one,\n- the **scope** (MUST \u002F WANT \u002F NICE \u002F OUT) was explicitly bounded,\n- a dependency was **already prototyped** by a collaborator (and may be\n  unreleased, so half your plan isn't even buildable yet),\n- your \"open questions\" were **already answered** in the thread — so asking them\n  reads as not having done the homework.\n\nIncident: jnv #114, where a WebFetch summary hid a 33-comment design thread\n([REFERENCE.md](REFERENCE.md#the-trap-jnv-114-a-summary-that-dropped-the-design)).\n\n## The rule\n\nWhen an issue is the basis for a contribution, read the comments **first**:\n\n```sh\ngh issue view \u003Cn> --repo \u003Cowner>\u002F\u003Crepo> --json title,body,author,comments \\\n  --jq '.body, (.comments[] | \"--- \" + .author.login + \" ---\\n\" + .body)'\n```\n\nSpecifically extract, before writing any code:\n\n1. **Decided mechanism** — has the maintainer chosen an implementation approach?\n   Build *that*, or explicitly propose an alternative knowing theirs exists.\n2. **Scope ladder** — MUST \u002F WANT \u002F NICE \u002F OUT. Don't attempt OUT; don't skip MUST.\n3. **Dependencies in flight** — linked PRs\u002Fbranches a collaborator is building.\n   Check their state (`gh pr view` → merged? released?) before depending on them.\n4. **Who's driving** — if the maintainer is mid-collaboration with another expert,\n   a drive-by PR may duplicate their work. Ask whether a contribution is welcome\n   *before* investing, and frame the PR as building on the thread, not restarting it.\n\nIf you only have a summary and a gap has passed, **re-read the live thread** before\nacting — the discussion may have moved.\n\n## A bot's recommendation is not a maintainer decision\n\nPoint 1 of [The rule](#the-rule) asks whether the maintainer chose an approach. The trap is that an\nautomated triage comment **looks like** that choice. A `needs-decision` routine\nposts options A\u002FB\u002FC, adds its own **\"I'd default to B\"**, and closes with \"reply\nhere and the next run will implement the chosen option\". Nothing has been\ndecided. The recommendation is the bot's, and the reply it asks for is what would\nmake it a decision.\n\nRead authorship and look for the reply, in the same call that fetches the thread:\n\n```sh\ngh issue view \u003Cn> --repo \u003Cowner>\u002F\u003Crepo> --json comments --jq '.comments | length, (.[] | .author.login + \" | \" + (.body[0:80]))'\n```\n\nA single comment that is itself the request for a decision means the decision is\n**open**. Implement nothing that depends on it; ask the human, or say in the PR\nthat you picked an option and which one.\n\nIncident: two PRs shipped a bot's default as the maintainer's choice\n([REFERENCE.md](REFERENCE.md#a-bots-recommendation-two-prs-citing-a-decision-nobody-made)).\n\nTwo consequences worth separating:\n\n- **`Closes #N` on an undecided issue** auto-closes the decision when the PR\n  merges. Use `Refs #N` until the option is chosen.\n- **A false attribution is load-bearing.** On #2568 it was the *only* cited\n  grounds for rejecting a reviewer's finding, so the finding had to be\n  re-examined once the attribution collapsed. Never cite a decision you have not\n  read; when you chose the option yourself, say so plainly.\n\n## Your own tracker — search before filing, read before reversing\n\nNo maintainer to defer to is exactly why this gets skipped. Two failures:\n\n1. **Search before filing** — a well-researched duplicate is still a duplicate,\n   and the better write-up makes it *harder* to spot as one.\n   `gh issue list -R \u003Co>\u002F\u003Cr> --state all --search \"\u003Ckw>\" --json number,title,state`\n2. **Read before reversing** — an old issue records not just a problem but a\n   *decision with its reasoning*, including decisions to **defer**. Shipping the\n   deferred option because it is obviously better silently overrides a choice\n   made with context you no longer have.\n\nIncident: a duplicate filed and a deferred migration merged, ten minutes apart\n([REFERENCE.md](REFERENCE.md#your-own-tracker-a-duplicate-and-a-reversed-deferral-ten-minutes-apart)).\n\nThe tell: calling something \"the obvious fix\" on a subsystem broken long enough\nfor someone to have written about it — long-broken means *investigated*. When\nreversing a decision, say so on the PR and issue, quoting the old reasoning, so\nthe next reader sees a decision changed rather than forgotten.\n\n## An issue's cited evidence expires — re-verify every line before acting on it\n\nDistinct from the other sections, which are about *discussion* you failed to\nread. Here you read everything, and the issue is simply **out of date**: it\ncites `file.ts:230` and asserts what is there, and between filing and today\nsome unrelated PR fixed it. A well-written issue makes this worse — precise\nline numbers and quoted snippets read as verified fact, and the better the\nwrite-up, the less anyone re-checks it.\n\nIncident: thelma #1055, whose central claim a later PR had already fixed\n([REFERENCE.md](REFERENCE.md#cited-evidence-expires-thelma-1055-a-control-added-after-filing)).\n\n- **Re-read every file:line the issue cites, at HEAD, before writing anything\n  from it.** The issue is a *claim about the code*, and the code is the\n  authority — same instinct as `diagnose-at-the-failure-point.md`.\n- **Date the gap.** `gh issue view \u003Cn> --json createdAt` against\n  `git log -S'\u003Csymbol>' -- \u003Cpath>` finds the PR that moved it. An issue older\n  than a few weeks on an active file should be assumed stale until checked.\n- **Report the correction in the PR that acts on it**, so the next reader sees\n  the issue's evidence was superseded rather than silently contradicted.\n- Corollary for *filing*: prefer citing behaviour and symbols over line\n  numbers, which rot fastest.\n\n## When it bites\n\n- Any external contribution scoped from an issue, especially a popular repo where\n  maintainers discuss design in comments.\n- **Acting on an issue filed weeks or months ago against a file that has since\n  changed** — the evidence is stale even though the thread is complete.\n- **Your own repo**, when the tracker is the last place you think to look.\n- Resuming work on an issue days later from a cached summary.\n- Letting an early `WebFetch`\u002Fresearch step stand in for the primary source.\n\n## Related\n\n- [REFERENCE.md](REFERENCE.md) — the incident behind each rule in this skill.\n\n- `~\u002F.claude\u002Frules\u002Fverify-upstream-before-patching.md` — same instinct (check\n  the authoritative source before acting) for vendored code; this is the\n  issue-thread analogue.\n- `agent-patterns-plugin:harness-tool-errors` (WebFetch) — a summary is lossy;\n  for a decision that gates real work, go to the full source, not the fetched\n  digest.\n- `git-plugin:git-issue` — the consumer: the end-to-end issue→PR workflow that\n  scopes from the issue thread this skill teaches you to read in full.\n\n## Rationale\n\nThe cost asymmetry is stark: reading the thread is one `gh issue view` and a few\nminutes; skipping it costs a misaligned prototype, a PR that signals you didn't\nread the discussion, and a reframe-or-close under the maintainer's eye. The full\nthread is the spec; the summary is a lossy proxy for it.\n",{"name":5,"created":44,"modified":45,"reviewed":44,"description":7,"allowed-tools":46},1787097600000,1793923200000,"Read, Grep, Glob, Bash(gh issue *), Bash(gh pr *), Bash(gh api *), Bash(git log *), TodoWrite","main","9d783554148f9c8a9c55a486b480760d3da673e6","git-plugin\u002Fskills\u002Fgit-issue-scoping",6,"https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins","https:\u002F\u002Fgithub.com\u002Flaurigates","Linux enthusiast, cloud engineer, neovim addict, electronics hobbyist.","2026-11-12 03:43:32",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add laurigates\u002Fclaude-plugins --skill git-issue-scoping",{"tool":61,"command":62},"bunx","bunx skills add laurigates\u002Fclaude-plugins --skill git-issue-scoping",{"tool":64,"command":65},"pnpm","pnpm dlx skills add laurigates\u002Fclaude-plugins --skill git-issue-scoping","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fgit-plugin\u002Fskills\u002Fgit-issue-scoping\u002FSKILL.md",true,[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"REFERENCE.md","REFERENCE","参考文档",3186,"https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fgit-plugin\u002Fskills\u002Fgit-issue-scoping\u002FREFERENCE.md",[76,105,126,142,165,194],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":87,"publishedAt":39},"01M70PFHMH9ADY0CRE6047Y4B2","kitty-show-image","Show the user an image with a note on what to judge, via a file send or a labelled kitty tab. Use when the user must see an image, or icat fails with no \u002Fdev\u002Ftty.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fkitty-plugin\u002Fskills\u002Fkitty-show-image\u002FSKILL.md",[82],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[88,89,90,91,92,93,94,95,96,97,32,25,31,98,99,100,101,102,103,104],"show","kitty show image","image","kitty","show image","ls","get","send","open","dev","file","text","with","xdg","via","2026","read",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":39},"01M70PFEN18HKQ4RCQ1VPGMPTB","kitty-session-persistence","Snapshot and restore kitty terminal sessions on macOS. Use when surviving WindowServer hangs without losing tabs, configuring snapshots, or restoring after a force-reboot.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fkitty-plugin\u002Fskills\u002Fkitty-session-persistence\u002FSKILL.md",[],[91,112,113,114,115,116,25,31,117,118,119,103,104,120,121,122,123,124,125,32],"kitty session persistence","session","persistence","false","snapshots","uname","reboot","terminal","write","edit","snapshot","macos","sessions","restore",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":39},"01M70PFC77XGXCVQ1543VGZHYR","kitty-remote-control","Safe kitty remote control from an agent — read panes with kitty @ ls\u002Fget-text, notify, and never mutate the live terminal unasked. Use when running inside kitty.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fkitty-plugin\u002Fskills\u002Fkitty-remote-control\u002FSKILL.md",[],[133,134,91,135,136,93,137,138,94,139,140,32,25,141,31,99,100,119,103,104],"kitty remote control","remote","control","remote control","running","never","panes","notify","query",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":39},"01M70P6WVMCT5JG4SACTM69AF9","docs-reference-check","Dangling doc-reference gate: flag markdown naming repo paths or relative links that no longer exist. Use when docs cite moved\u002Fdeleted files, or wiring a doc-drift lint.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fdocumentation-plugin\u002Fskills\u002Fdocs-reference-check\u002FSKILL.md",[],[149,150,151,152,153,154,155,156,157,158,32,25,31,159,98,160,161,162,163,164],"docs reference check","check","reference check","reference","docs","links","python3","repo","files","auto","drift","lint","wiring","chezmoi","references","cp",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":180,"publishedAt":39},"01M6C6NDE7DAQGNWSF22J5CJ0Z","youtube-upload","Upload a video to YouTube via the Data API v3 and edit its title, description, tags or thumbnail afterwards. Use when publishing or retitling a YouTube video.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fyoutube-plugin\u002Fskills\u002Fyoutube-upload\u002FSKILL.md",[171,174,175],{"categoryNo":172,"categoryName":173,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},{"categoryNo":176,"categoryName":177,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[181,182,183,184,155,185,104,186,121,187,188,189,32,31,98,30,190,25,191,192,193,102,103],"youtube upload","upload","youtube","Video","run","uv run","publishing","data","uv","v3","tags","id","title",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":203,"publishedAt":39},"01M6C6NABWW1X58KJJM4F6GQMQ","youtube-studio-share","Share a private YouTube video with a whole Google Workspace organization by scripting YouTube Studio in the browser. Use when a video must be org-only.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fyoutube-plugin\u002Fskills\u002Fyoutube-studio-share\u002FSKILL.md",[200],{"categoryNo":201,"categoryName":202,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000023","Skill与智能体开发",[204,205,206,207,183,184,208,209,210,211,212,104,213,214,215,216,32,217,25,100,218,103],"youtube studio share","share","youtube studio","studio","browser","javascript","scripting","google workspace","workspace","tool","google","only","MCP","chrome","organization"]