[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M755J8H8MNH3CFF13S3BNJSF":3,"skill-same:01M755J8H8MNH3CFF13S3BNJSF":45},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":28,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M755J8H8MNH3CFF13S3BNJSF","dependency-upgrade",null,"Plan, batch, and verify dependency upgrades safely. Triages outdated packages into risk tiers, upgrades in order (dev\u002Fminor\u002Fpatch first, runtime majors last), verifies each batch, and produces an auditable commit sequence. Use when asked to \"upgrade deps\", \"bump packages\", \"update node_modules\", \"fix vulnerabilities\", \"upgrade React\u002FNode\u002FTypeScript\", or after `\u002Fgsd start dep-upgrade`.","eagle27272\u002Fgsd-pi","eagle27272","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F89469515?v=4","01M755FHJ96F4TC1WYYSGJ8D93","Mike","01M755FHKBQK52KMR81J0HEVR2",0,"MIT","https:\u002F\u002Fgithub.com\u002Feagle27272\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fdependency-upgrade\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: dependency-upgrade\ndescription: Plan, batch, and verify dependency upgrades safely. Triages outdated packages into risk tiers, upgrades in order (dev\u002Fminor\u002Fpatch first, runtime majors last), verifies each batch, and produces an auditable commit sequence. Use when asked to \"upgrade deps\", \"bump packages\", \"update node_modules\", \"fix vulnerabilities\", \"upgrade React\u002FNode\u002FTypeScript\", or after `\u002Fgsd start dep-upgrade`.\n---\n\n\u003Cobjective>\nTurn a pile of outdated packages into a series of small, verifiable upgrades with clean commits. The deliverable is an ordered upgrade plan, executed with verification between batches, and a summary that flags anything risky for follow-up. No big-bang upgrades.\n\u003C\u002Fobjective>\n\n\u003Ccontext>\ngsd-pi ships a `\u002Fgsd start dep-upgrade` workflow template (`src\u002Fresources\u002Fextensions\u002Fgsd\u002Fworkflow-templates\u002Fdep-upgrade.md`) that structures the phases: assess → upgrade → fix breaks → verify. This skill is the execution-level detail inside the upgrade phase — how to batch, how to verify, how to recover from a breaking upgrade without losing the good ones.\n\nInvocation points:\n- `\u002Fgsd start dep-upgrade` workflow is running\n- Ad-hoc \"bump the deps\" request\n- Security advisory response (CVE in a direct dep)\n- Framework major-version update (React 18 → 19, Node LTS bump)\n- Monthly hygiene pass\n\u003C\u002Fcontext>\n\n\u003Ccore_principle>\n**BATCH BY RISK, NOT BY LAZINESS.** `npm update` is a shortcut that blends safe and risky changes into one commit. When something breaks, you can't tell which dep caused it. Always separate: patches and dev-deps first, minors next, majors individually.\n\n**VERIFY BETWEEN BATCHES.** Run the test suite after every batch. Don't stack five batches and hope. If a batch breaks something, you need to know which one.\n\n**ONE MAJOR PER COMMIT.** Major version bumps are where real breakage lives. Keep them isolated so the commit history tells the truth.\n\u003C\u002Fcore_principle>\n\n\u003Cprocess>\n\n## Step 1: Take inventory\n\nRun the ecosystem's outdated check. Capture output, don't act on it yet:\n- Node: `npm outdated` or `pnpm outdated` or `yarn outdated`\n- Python: `pip list --outdated` or `uv pip list --outdated`\n- Rust: `cargo outdated`\n- Ruby: `bundle outdated`\n- Go: `go list -m -u all`\n\nAlso capture:\n- `npm audit` (or equivalent) — security advisories\n- Current versions of language runtime, build tool, test runner\n\n## Step 2: Classify each outdated package\n\nFor each outdated package, note:\n\n- **Type:** direct dep \u002F dev-dep \u002F transitive\n- **Kind of bump:** patch (1.2.3 → 1.2.4), minor (1.2.3 → 1.3.0), major (1.2.3 → 2.0.0)\n- **Risk:** Low (dev-dep, patch), Medium (runtime minor, dev-dep major), High (runtime major, framework, TypeScript compiler)\n- **Blast radius:** How many files in the repo import it? (Rough count via `rg`.)\n- **Has known breaking changes:** Check the CHANGELOG or release notes for any major bumps — do NOT skip this, and do NOT infer \"probably fine.\"\n\n## Step 3: Build the batch plan\n\nOrder:\n\n1. **Batch 1 — Dev dep patches and minors.** Lowest risk, fastest feedback. Includes linters, formatters, type definitions, test runners.\n2. **Batch 2 — Runtime patches.** All patch bumps to runtime deps together.\n3. **Batch 3 — Runtime minors.** One batch per semantic group if any minor carries risk notes; otherwise one batch for the rest.\n4. **Batch 4+ — Each major, individually.** One commit per major. Framework bumps (React, Next.js, Vue, TypeScript) each get their own commit.\n5. **Batch N — Language runtime.** If bumping Node\u002FPython\u002FRust, last — it changes the compile\u002Frun env for everything.\n\nSkip (for now):\n- Anything with \"unreleased\", \"pre\", \"beta\", \"rc\" tags unless the user explicitly wants pre-release tracking\n- Deps you know are blocked by another dep (e.g., can't bump X until Y supports it)\n\nPresent the plan to the user. One round of adjustment. Then execute.\n\n## Step 4: Execute a batch\n\nFor each batch:\n\n1. **Start from a clean working tree.** `git status` — no uncommitted changes.\n2. **Apply the upgrades** using the ecosystem command (`npm install package@version ...`, `uv add …`, `cargo update -p …`).\n3. **Regenerate the lockfile** fully if necessary.\n4. **Build.** Run the project's real build — not just typecheck.\n5. **Test.** Run the full suite. Not a scoped subset.\n6. **Lint.** `lsp diagnostics` on changed files + the project linter.\n7. **Smoke-test the app** if it has a running surface (dev server, CLI command).\n\nIf any step fails:\n- Investigate before moving on. Don't skip the batch.\n- If the failure is trivial (a rename, a deprecated import), fix it in the same commit — the upgrade broke it, the upgrade commit fixes it.\n- If the failure is non-trivial (an API you heavily depend on was removed), either pin back or split: upgrade the other deps in the batch in this commit, and handle the problem dep separately in Step 5.\n\n**Commit with a precise message:**\n\n```\ndeps: bump \u003Cscope> — \u003Cwhat changed in one line>\n\n- package-a: 1.2.3 → 1.2.9 (patch)\n- package-b: 2.1.0 → 2.4.0 (minor — no breaking changes in CHANGELOG)\n- package-c: 3.0.1 → 3.0.2 (patch)\n\nVerified: npm test (84\u002F84 pass), npm run build exit 0, lsp diagnostics clean.\n```\n\n## Step 5: Handle stuck majors\n\nFor each major that breaks something:\n\n1. **Read the migration guide** — do not guess at the API changes.\n2. **Scope the blast radius** — `rg` for the symbols that changed.\n3. **Decide: upgrade now or defer?** If the migration is a weekend's work and not urgent, file a `\u002Fgsd start refactor` follow-up and pin the current major for now.\n4. **If upgrading now:** branch the work as its own slice (`S##`). The dep upgrade is only one task; the migration is the rest of the slice.\n5. **Verify end-to-end after migration.** The test suite alone may miss behavior changes.\n\n## Step 6: Summary\n\nAfter all batches, produce a rollup:\n\n```markdown\n## Dependency Upgrade — \u003Cdate>\n\n### Completed\n- Batch 1 (dev patches): 12 packages — commit abc1234\n- Batch 2 (runtime patches): 5 packages — commit def5678\n- Batch 3 (runtime minors): 3 packages — commit ...\n- Batch 4 (React 18 → 19): commit ... — required refactors in \u003Cfiles>\n\n### Deferred\n- typescript 5.3 → 5.7 — requires updating 40+ decorator usages. Filed as M005.\n- vite 4 → 5 — config shape changed. Owner assigned: \u003Cuser>.\n\n### Still outdated (intentional)\n- \u003Cpackage> — pinned because \u003Creason>\n\n### Security advisories\n- \u003CCVE> resolved by \u003Cpackage upgrade>\n- \u003CCVE> still open — not exploitable in our usage (see comment in package.json)\n```\n\nAppend to `.gsd\u002FKNOWLEDGE.md` any non-obvious gotcha from the upgrade (API changes that tripped you up, migration rituals for this codebase).\n\n\u003C\u002Fprocess>\n\n\u003Canti_patterns>\n\n- **`npm update` blindly.** Mixes safe and risky in one undiagnosable commit.\n- **Multiple majors in one commit.** When it breaks, you don't know which.\n- **No verification between batches.** You stack failures until nothing works.\n- **Skipping the CHANGELOG.** \"It's just a minor\" — until it isn't.\n- **Force-merging a failing batch with `--force`.** Leave it broken or roll back; don't lie to git.\n- **Ignoring `--legacy-peer-deps` warnings.** They're telling you the dep graph is incoherent.\n\n\u003C\u002Fanti_patterns>\n\n\u003Csuccess_criteria>\n\n- [ ] Each batch is in its own commit with a precise message.\n- [ ] Majors are one-per-commit.\n- [ ] Test suite, build, and lint passed after every batch (per `verify-before-complete`).\n- [ ] Stuck upgrades are documented with a concrete next step (filed as slice\u002Fmilestone, or pinned with a reason).\n- [ ] Security advisories are addressed or explicitly triaged.\n- [ ] Summary report exists for the user to review.\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nTurn a pile of outdated packages into a series of small, verifiable upgrades with clean commits. The deliverable is an ordered upgrade plan, executed with verification between batches, and a summary that flags anything risky for follow-up. No big-bang upgrades.\n\u003C\u002Fobjective>\n\n\u003Ccontext>\ngsd-pi ships a `\u002Fgsd start dep-upgrade` workflow template (`src\u002Fresources\u002Fextensions\u002Fgsd\u002Fworkflow-templates\u002Fdep-upgrade.md`) that structures the phases: assess → upgrade → fix breaks → verify. This skill is the execution-level detail inside the upgrade phase — how to batch, how to verify, how to recover from a breaking upgrade without losing the good ones.\n\nInvocation points:\n- `\u002Fgsd start dep-upgrade` workflow is running\n- Ad-hoc \"bump the deps\" request\n- Security advisory response (CVE in a direct dep)\n- Framework major-version update (React 18 → 19, Node LTS bump)\n- Monthly hygiene pass\n\u003C\u002Fcontext>\n\n\u003Ccore_principle>\n**BATCH BY RISK, NOT BY LAZINESS.** `npm update` is a shortcut that blends safe and risky changes into one commit. When something breaks, you can't tell which dep caused it. Always separate: patches and dev-deps first, minors next, majors individually.\n\n**VERIFY BETWEEN BATCHES.** Run the test suite after every batch. Don't stack five batches and hope. If a batch breaks something, you need to know which one.\n\n**ONE MAJOR PER COMMIT.** Major version bumps are where real breakage lives. Keep them isolated so the commit history tells the truth.\n\u003C\u002Fcore_principle>\n\n\u003Cprocess>\n\n## Step 1: Take inventory\n\nRun the ecosystem's outdated check. Capture output, don't act on it yet:\n- Node: `npm outdated` or `pnpm outdated` or `yarn outdated`\n- Python: `pip list --outdated` or `uv pip list --outdated`\n- Rust: `cargo outdated`\n- Ruby: `bundle outdated`\n- Go: `go list -m -u all`\n\nAlso capture:\n- `npm audit` (or equivalent) — security advisories\n- Current versions of language runtime, build tool, test runner\n\n## Step 2: Classify each outdated package\n\nFor each outdated package, note:\n\n- **Type:** direct dep \u002F dev-dep \u002F transitive\n- **Kind of bump:** patch (1.2.3 → 1.2.4), minor (1.2.3 → 1.3.0), major (1.2.3 → 2.0.0)\n- **Risk:** Low (dev-dep, patch), Medium (runtime minor, dev-dep major), High (runtime major, framework, TypeScript compiler)\n- **Blast radius:** How many files in the repo import it? (Rough count via `rg`.)\n- **Has known breaking changes:** Check the CHANGELOG or release notes for any major bumps — do NOT skip this, and do NOT infer \"probably fine.\"\n\n## Step 3: Build the batch plan\n\nOrder:\n\n1. **Batch 1 — Dev dep patches and minors.** Lowest risk, fastest feedback. Includes linters, formatters, type definitions, test runners.\n2. **Batch 2 — Runtime patches.** All patch bumps to runtime deps together.\n3. **Batch 3 — Runtime minors.** One batch per semantic group if any minor carries risk notes; otherwise one batch for the rest.\n4. **Batch 4+ — Each major, individually.** One commit per major. Framework bumps (React, Next.js, Vue, TypeScript) each get their own commit.\n5. **Batch N — Language runtime.** If bumping Node\u002FPython\u002FRust, last — it changes the compile\u002Frun env for everything.\n\nSkip (for now):\n- Anything with \"unreleased\", \"pre\", \"beta\", \"rc\" tags unless the user explicitly wants pre-release tracking\n- Deps you know are blocked by another dep (e.g., can't bump X until Y supports it)\n\nPresent the plan to the user. One round of adjustment. Then execute.\n\n## Step 4: Execute a batch\n\nFor each batch:\n\n1. **Start from a clean working tree.** `git status` — no uncommitted changes.\n2. **Apply the upgrades** using the ecosystem command (`npm install package@version ...`, `uv add …`, `cargo update -p …`).\n3. **Regenerate the lockfile** fully if necessary.\n4. **Build.** Run the project's real build — not just typecheck.\n5. **Test.** Run the full suite. Not a scoped subset.\n6. **Lint.** `lsp diagnostics` on changed files + the project linter.\n7. **Smoke-test the app** if it has a running surface (dev server, CLI command).\n\nIf any step fails:\n- Investigate before moving on. Don't skip the batch.\n- If the failure is trivial (a rename, a deprecated import), fix it in the same commit — the upgrade broke it, the upgrade commit fixes it.\n- If the failure is non-trivial (an API you heavily depend on was removed), either pin back or split: upgrade the other deps in the batch in this commit, and handle the problem dep separately in Step 5.\n\n**Commit with a precise message:**\n\n```\ndeps: bump \u003Cscope> — \u003Cwhat changed in one line>\n\n- package-a: 1.2.3 → 1.2.9 (patch)\n- package-b: 2.1.0 → 2.4.0 (minor — no breaking changes in CHANGELOG)\n- package-c: 3.0.1 → 3.0.2 (patch)\n\nVerified: npm test (84\u002F84 pass), npm run build exit 0, lsp diagnostics clean.\n```\n\n## Step 5: Handle stuck majors\n\nFor each major that breaks something:\n\n1. **Read the migration guide** — do not guess at the API changes.\n2. **Scope the blast radius** — `rg` for the symbols that changed.\n3. **Decide: upgrade now or defer?** If the migration is a weekend's work and not urgent, file a `\u002Fgsd start refactor` follow-up and pin the current major for now.\n4. **If upgrading now:** branch the work as its own slice (`S##`). The dep upgrade is only one task; the migration is the rest of the slice.\n5. **Verify end-to-end after migration.** The test suite alone may miss behavior changes.\n\n## Step 6: Summary\n\nAfter all batches, produce a rollup:\n\n```markdown\n## Dependency Upgrade — \u003Cdate>\n\n### Completed\n- Batch 1 (dev patches): 12 packages — commit abc1234\n- Batch 2 (runtime patches): 5 packages — commit def5678\n- Batch 3 (runtime minors): 3 packages — commit ...\n- Batch 4 (React 18 → 19): commit ... — required refactors in \u003Cfiles>\n\n### Deferred\n- typescript 5.3 → 5.7 — requires updating 40+ decorator usages. Filed as M005.\n- vite 4 → 5 — config shape changed. Owner assigned: \u003Cuser>.\n\n### Still outdated (intentional)\n- \u003Cpackage> — pinned because \u003Creason>\n\n### Security advisories\n- \u003CCVE> resolved by \u003Cpackage upgrade>\n- \u003CCVE> still open — not exploitable in our usage (see comment in package.json)\n```\n\nAppend to `.gsd\u002FKNOWLEDGE.md` any non-obvious gotcha from the upgrade (API changes that tripped you up, migration rituals for this codebase).\n\n\u003C\u002Fprocess>\n\n\u003Canti_patterns>\n\n- **`npm update` blindly.** Mixes safe and risky in one undiagnosable commit.\n- **Multiple majors in one commit.** When it breaks, you don't know which.\n- **No verification between batches.** You stack failures until nothing works.\n- **Skipping the CHANGELOG.** \"It's just a minor\" — until it isn't.\n- **Force-merging a failing batch with `--force`.** Leave it broken or roll back; don't lie to git.\n- **Ignoring `--legacy-peer-deps` warnings.** They're telling you the dep graph is incoherent.\n\n\u003C\u002Fanti_patterns>\n\n\u003Csuccess_criteria>\n\n- [ ] Each batch is in its own commit with a precise message.\n- [ ] Majors are one-per-commit.\n- [ ] Test suite, build, and lint passed after every batch (per `verify-before-complete`).\n- [ ] Stuck upgrades are documented with a concrete next step (filed as slice\u002Fmilestone, or pinned with a reason).\n- [ ] Security advisories are addressed or explicitly triaged.\n- [ ] Summary report exists for the user to review.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7},"main","a034c670a76777c39345ad63706b280ea0774427","src\u002Fresources\u002Fskills\u002Fdependency-upgrade","https:\u002F\u002Fgithub.com\u002Feagle27272\u002Fgsd-pi","https:\u002F\u002Fwww.opengsd.net","https:\u002F\u002Fgithub.com\u002Feagle27272","2026-11-06 03:33:29",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add eagle27272\u002Fgsd-pi --skill dependency-upgrade",{"tool":37,"command":38},"bunx","bunx skills add eagle27272\u002Fgsd-pi --skill dependency-upgrade",{"tool":40,"command":41},"pnpm","pnpm dlx skills add eagle27272\u002Fgsd-pi --skill dependency-upgrade","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Feagle27272\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fdependency-upgrade\u002FSKILL.md",true,[],[46,53,60,67,74,81],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M755N4XASRYTGDBP3257N9XY","write-milestone-brief","Synthesize the current conversation into a milestone brief (PRD). Writes to `M###-CONTEXT.md` by default, or files a GitHub issue only with explicit user confirmation. Use when asked to \"turn this into a PRD\", \"draft a milestone brief\", \"capture this context\", \"write it up\", or when enough has been discussed to commit the plan to paper. Does not interview — it synthesizes what is already known.","https:\u002F\u002Fgithub.com\u002Feagle27272\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fwrite-milestone-brief\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M755N0HQG5WDJM1Q1DM86G8R","write-docs","Collaborative authoring workflow for proposals, technical specs, decision docs, READMEs, ADRs, and long-form prose that must work for fresh readers. Three stages: gather context, iterate on structure, reader-test for a stranger. Use when asked to \"write the docs\", \"draft a proposal\", \"write a spec\", \"write an RFC\", \"write the README\", or when a doc must be understandable without this session's context.","https:\u002F\u002Fgithub.com\u002Feagle27272\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fwrite-docs\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M755MWPJ6T2YJBTX2XYGSHJ6","web-quality-audit","Comprehensive web quality audit covering performance, accessibility, SEO, and best practices. Use when asked to \"audit my site\", \"review web quality\", \"run lighthouse audit\", \"check page quality\", or \"optimize my website\".","https:\u002F\u002Fgithub.com\u002Feagle27272\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fweb-quality-audit\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":19},"01M755MS2TPG3DTXM0SD5Y19CG","web-design-guidelines","Review UI code for Web Interface Guidelines compliance. Use when asked to \"review my UI\", \"check accessibility\", \"audit design\", \"review UX\", or \"check my site against best practices\".","https:\u002F\u002Fgithub.com\u002Feagle27272\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fweb-design-guidelines\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M755MMK6Q58TXHJ8T5NSSNWK","verify-before-complete","Block completion claims until verification evidence has been produced in the current message. Use before marking a task\u002Fslice\u002Fmilestone complete, before creating a commit or PR, before saying \"it works\" or \"tests pass\", and any time you are about to claim work is done. The rule is: evidence before claims, always — running the verification must happen now, not \"earlier in the session\". Fresh output or no claim.","https:\u002F\u002Fgithub.com\u002Feagle27272\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fverify-before-complete\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M755MDN11JJKSW1HV7TQZ7VC","userinterface-wiki","UI\u002FUX best practices for web interfaces. Use when reviewing animations, CSS, audio, typography, UX patterns, prefetching, or icon implementations. Covers 11 categories from animation principles to typography. Outputs file:line findings.","https:\u002F\u002Fgithub.com\u002Feagle27272\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fuserinterface-wiki\u002FSKILL.md",[],[]]