[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JDRABJD4YWSGP6Z88VF9PW":3,"skill-same:01M6JDRABJD4YWSGP6Z88VF9PW":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":33,"publishedAt":53,"linkOnly":54,"markdownContent":55,"markdownBody":56,"frontMatter":57,"refName":68,"commitSha":69,"skillDirectory":70,"forksCount":71,"repositoryHtmlUrl":72,"repositoryHomepageUrl":73,"ownerHtmlUrl":74,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":75,"install":76,"resources":89},"01M6JDRABJD4YWSGP6Z88VF9PW","sketch",null,"Throwaway HTML mockups: 2-3 design variants to compare.","S3YED\u002Fappie-kit","S3YED","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F62743867?v=4","01M6JBKBRRVP6KMS0VWZ27T3R6","01M6JBKBX0KG30284PW1DBYJT1",14,"MIT","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Ffleet\u002Fsketch-absorbed-into-claude-design\u002FSKILL.md",[17,22,25,28],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[5,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52],"html","design variants","mockup","comparison","compare","get","done","exploration","build","design","wireframe","excalidraw","ui","windows","web","prototype","linux","spike","macos","2026-11-10 10:12:30",false,"---\nname: sketch\ndescription: \"Throwaway HTML mockups: 2-3 design variants to compare.\"\nversion: 1.0.0\nauthor: Hermes Agent (adapted from gsd-build\u002Fget-shit-done)\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [sketch, mockup, design, ui, prototype, html, variants, exploration, wireframe, comparison]\n    related_skills: [spike, claude-design, popular-web-designs, excalidraw]\n---\n\n# Sketch\n\nUse this skill when the user wants to **see a design direction before committing** to one — exploring a UI\u002FUX idea as disposable HTML mockups. The point is to generate 2-3 interactive variants so the user can compare visual directions side-by-side, not to produce shippable code.\n\nLoad this when the user says things like \"sketch this screen\", \"show me what X could look like\", \"compare layout A vs B\", \"give me 2-3 takes on this UI\", \"let me see some variants\", \"mockup this before I build\".\n\n## When NOT to use this\n\n- User wants a production component — use `claude-design` or build it properly\n- User wants a polished one-off HTML artifact (landing page, deck) — `claude-design`\n- User wants a diagram — `excalidraw`, `architecture-diagram`\n- The design is already locked — just build it\n\n## If the user has the full GSD system installed\n\nIf `gsd-sketch` shows up as a sibling skill (installed via `npx get-shit-done-cc --hermes`), prefer **`gsd-sketch`** for the full workflow: persistent `.planning\u002Fsketches\u002F` with MANIFEST, frontier mode analysis, consistency audits across past sketches, and integration with the rest of GSD. This skill is the lightweight standalone version — one-off sketching without the state machinery.\n\n## Core method\n\n```\nintake  →  variants  →  head-to-head  →  pick winner (or iterate)\n```\n\n### 1. Intake (skip if the user already gave you enough)\n\nBefore generating variants, get three things — one question at a time, not all at once:\n\n1. **Feel.** \"What should this feel like? Adjectives, emotions, a vibe.\" — *\"calm, editorial, like Linear\"* tells you more than *\"minimal\"*.\n2. **References.** \"What apps, sites, or products capture the feel you're imagining?\" — actual references beat abstract descriptions.\n3. **Core action.** \"What's the single most important thing a user does on this screen?\" — the variants should all serve this well; if they don't, they're just decoration.\n\nReflect each answer briefly before the next question. If the user already gave you all three upfront, skip straight to variants.\n\n### 2. Variants (2-3, never 1, rarely 4+)\n\nProduce **2-3 variants** in one go. Each variant is a complete, standalone HTML file. Don't describe variants — build them. The point is comparison.\n\nEach variant should take a **different design stance**, not different pixel values. Three good variant axes:\n\n- **Density:** compact \u002F airy \u002F ultra-dense (pick two contrasting poles)\n- **Emphasis:** content-first \u002F action-first \u002F tool-first\n- **Aesthetic:** editorial \u002F utilitarian \u002F playful\n- **Layout:** single-column \u002F sidebar \u002F split-pane\n- **Grounding:** card-based \u002F bare-content \u002F document-style\n\nPick one axis and pull apart from it. Two variants that differ only in accent color are wasted effort — the user can't distinguish them.\n\n**Variant naming:** describe the stance, not the number.\n\n```\nsketches\u002F\n├── 001-calm-editorial\u002F\n│   ├── index.html\n│   └── README.md\n├── 001-utilitarian-dense\u002F\n│   ├── index.html\n│   └── README.md\n└── 001-playful-split\u002F\n    ├── index.html\n    └── README.md\n```\n\n### 3. Make them real HTML\n\nEach variant is a **single self-contained HTML file**:\n\n- Inline `\u003Cstyle>` — no build step, no external CSS\n- System fonts or one Google Font via `\u003Clink>`\n- Tailwind via CDN (`\u003Cscript src=\"https:\u002F\u002Fcdn.tailwindcss.com\">\u003C\u002Fscript>`) is fine\n- Realistic fake content — actual sentences, actual names, not \"Lorem ipsum\"\n- **Interactive**: links clickable, hovers real, at least one state transition (open\u002Fclose, filter, toggle). A frozen static image is a worse spike than a sloppy animated one.\n\nOpen it in a browser. If it looks broken, fix it before showing the user.\n\n**Verify variants visually — use Hermes' browser tools.** Don't just write HTML and hope it renders; load each variant and look at it:\n\n```\nbrowser_navigate(url=\"file:\u002F\u002F\u002Fabsolute\u002Fpath\u002Fto\u002Fsketches\u002F001-calm-editorial\u002Findex.html\")\nbrowser_vision(question=\"Does this layout look clean and readable? Any visible bugs (overlapping text, unstyled elements, broken images)?\")\n```\n\n`browser_vision` returns an AI description of what's actually on the page plus a screenshot path — catches layout bugs that pure source inspection misses (e.g. a font import that silently failed, a flex container that collapsed). Fix and re-navigate until each variant looks right.\n\n**Default CSS reset + system font stack** for fast starts:\n\n```html\n\u003Cstyle>\n  * { box-sizing: border-box; margin: 0; padding: 0; }\n  body {\n    font-family: -apple-system, BlinkMacSystemFont, \"Segoe UI\", Roboto,\n                 \"Helvetica Neue\", Arial, sans-serif;\n    -webkit-font-smoothing: antialiased;\n    color: #1a1a1a;\n    background: #fafafa;\n    line-height: 1.5;\n  }\n\u003C\u002Fstyle>\n```\n\n### 4. Variant README\n\nEach variant's `README.md` answers:\n\n```markdown\n## Variant: {stance name}\n\n### Design stance\nOne sentence on the principle driving this variant.\n\n### Key choices\n- Layout: ...\n- Typography: ...\n- Color: ...\n- Interaction: ...\n\n### Trade-offs\n- Strong at: ...\n- Weak at: ...\n\n### Best for\n- The kind of user or use case this variant actually serves\n```\n\n### 5. Head-to-head\n\nAfter all variants are built, present them as a comparison. Don't just list — **opinionate**:\n\n```markdown\n## Three takes on the home screen\n\n| Dimension | Calm editorial | Utilitarian dense | Playful split |\n|-----------|----------------|-------------------|---------------|\n| Density   | Low            | High              | Medium        |\n| Primary action visibility | Low | High | Medium |\n| Scan-ability | High | Medium | Low |\n| Feel | Calm, trusted | Sharp, tool-like | Inviting, energetic |\n\n**My take:** Utilitarian dense for power users, calm editorial for content-forward audiences. Playful split is weakest — tries to do both and commits to neither.\n```\n\nLet the user pick a winner, or combine two into a hybrid, or ask for another round.\n\n## Theming (when the project has a visual identity)\n\nIf the user has an existing theme (colors, fonts, tokens), put shared tokens in `sketches\u002Fthemes\u002Ftokens.css` and `@import` them in each variant. Keep tokens minimal:\n\n```css\n\u002F* sketches\u002Fthemes\u002Ftokens.css *\u002F\n:root {\n  --color-bg: #fafafa;\n  --color-fg: #1a1a1a;\n  --color-accent: #0066ff;\n  --color-muted: #666;\n  --radius: 8px;\n  --font-display: \"Inter\", sans-serif;\n  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;\n}\n```\n\nDon't over-tokenize a throwaway sketch — three colors and one font is usually enough.\n\n## Interactivity bar\n\nA sketch is interactive enough when the user can:\n\n1. **Click a primary action** and something visible happens (state change, modal, toast, navigation feint)\n2. **See one meaningful state transition** (filter a list, toggle a mode, open\u002Fclose a panel)\n3. **Hover recognizable affordances** (buttons, rows, tabs)\n\nMore than that is over-engineering a throwaway. Less than that is a screenshot.\n\n## Frontier mode (picking what to sketch next)\n\nIf sketches already exist and the user says \"what should I sketch next?\":\n\n- **Consistency gaps** — two winning variants from different sketches made independent choices that haven't been composed together yet\n- **Unsketched screens** — referenced but never explored\n- **State coverage** — happy path sketched, but not empty \u002F loading \u002F error \u002F 1000-items\n- **Responsive gaps** — validated at one viewport; does it hold at mobile \u002F ultrawide?\n- **Interaction patterns** — static layouts exist; transitions, drag, scroll behavior don't\n\nPropose 2-4 named candidates. Let the user pick.\n\n## Output\n\n- Create `sketches\u002F` (or `.planning\u002Fsketches\u002F` if the user is using GSD conventions) in the repo root\n- One subdir per variant: `NNN-stance-name\u002Findex.html` + `README.md`\n- Tell the user how to open them: `open sketches\u002F001-calm-editorial\u002Findex.html` on macOS, `xdg-open` on Linux, `start` on Windows\n- Keep variants disposable — a sketch that you felt the need to preserve should be promoted into real project code, not curated as an asset\n\n**Typical tool sequence for one variant:**\n\n```\nterminal(\"mkdir -p sketches\u002F001-calm-editorial\")\nwrite_file(\"sketches\u002F001-calm-editorial\u002Findex.html\", \"\u003C!doctype html>...\")\nwrite_file(\"sketches\u002F001-calm-editorial\u002FREADME.md\", \"## Variant: Calm editorial\\n...\")\nbrowser_navigate(url=\"file:\u002F\u002F$(pwd)\u002Fsketches\u002F001-calm-editorial\u002Findex.html\")\nbrowser_vision(question=\"How does this look? Any obvious layout issues?\")\n```\n\nRepeat for each variant, then present the comparison table.\n\n## Attribution\n\nAdapted from the GSD (Get Shit Done) project's `\u002Fgsd-sketch` workflow — MIT © 2025 Lex Christopherson ([gsd-build\u002Fget-shit-done](https:\u002F\u002Fgithub.com\u002Fgsd-build\u002Fget-shit-done)). The full GSD system ships persistent sketch state, theme\u002Fvariant pattern references, and consistency-audit workflows; install with `npx get-shit-done-cc --hermes --global`.\n","# Sketch\n\nUse this skill when the user wants to **see a design direction before committing** to one — exploring a UI\u002FUX idea as disposable HTML mockups. The point is to generate 2-3 interactive variants so the user can compare visual directions side-by-side, not to produce shippable code.\n\nLoad this when the user says things like \"sketch this screen\", \"show me what X could look like\", \"compare layout A vs B\", \"give me 2-3 takes on this UI\", \"let me see some variants\", \"mockup this before I build\".\n\n## When NOT to use this\n\n- User wants a production component — use `claude-design` or build it properly\n- User wants a polished one-off HTML artifact (landing page, deck) — `claude-design`\n- User wants a diagram — `excalidraw`, `architecture-diagram`\n- The design is already locked — just build it\n\n## If the user has the full GSD system installed\n\nIf `gsd-sketch` shows up as a sibling skill (installed via `npx get-shit-done-cc --hermes`), prefer **`gsd-sketch`** for the full workflow: persistent `.planning\u002Fsketches\u002F` with MANIFEST, frontier mode analysis, consistency audits across past sketches, and integration with the rest of GSD. This skill is the lightweight standalone version — one-off sketching without the state machinery.\n\n## Core method\n\n```\nintake  →  variants  →  head-to-head  →  pick winner (or iterate)\n```\n\n### 1. Intake (skip if the user already gave you enough)\n\nBefore generating variants, get three things — one question at a time, not all at once:\n\n1. **Feel.** \"What should this feel like? Adjectives, emotions, a vibe.\" — *\"calm, editorial, like Linear\"* tells you more than *\"minimal\"*.\n2. **References.** \"What apps, sites, or products capture the feel you're imagining?\" — actual references beat abstract descriptions.\n3. **Core action.** \"What's the single most important thing a user does on this screen?\" — the variants should all serve this well; if they don't, they're just decoration.\n\nReflect each answer briefly before the next question. If the user already gave you all three upfront, skip straight to variants.\n\n### 2. Variants (2-3, never 1, rarely 4+)\n\nProduce **2-3 variants** in one go. Each variant is a complete, standalone HTML file. Don't describe variants — build them. The point is comparison.\n\nEach variant should take a **different design stance**, not different pixel values. Three good variant axes:\n\n- **Density:** compact \u002F airy \u002F ultra-dense (pick two contrasting poles)\n- **Emphasis:** content-first \u002F action-first \u002F tool-first\n- **Aesthetic:** editorial \u002F utilitarian \u002F playful\n- **Layout:** single-column \u002F sidebar \u002F split-pane\n- **Grounding:** card-based \u002F bare-content \u002F document-style\n\nPick one axis and pull apart from it. Two variants that differ only in accent color are wasted effort — the user can't distinguish them.\n\n**Variant naming:** describe the stance, not the number.\n\n```\nsketches\u002F\n├── 001-calm-editorial\u002F\n│   ├── index.html\n│   └── README.md\n├── 001-utilitarian-dense\u002F\n│   ├── index.html\n│   └── README.md\n└── 001-playful-split\u002F\n    ├── index.html\n    └── README.md\n```\n\n### 3. Make them real HTML\n\nEach variant is a **single self-contained HTML file**:\n\n- Inline `\u003Cstyle>` — no build step, no external CSS\n- System fonts or one Google Font via `\u003Clink>`\n- Tailwind via CDN (`\u003Cscript src=\"https:\u002F\u002Fcdn.tailwindcss.com\">\u003C\u002Fscript>`) is fine\n- Realistic fake content — actual sentences, actual names, not \"Lorem ipsum\"\n- **Interactive**: links clickable, hovers real, at least one state transition (open\u002Fclose, filter, toggle). A frozen static image is a worse spike than a sloppy animated one.\n\nOpen it in a browser. If it looks broken, fix it before showing the user.\n\n**Verify variants visually — use Hermes' browser tools.** Don't just write HTML and hope it renders; load each variant and look at it:\n\n```\nbrowser_navigate(url=\"file:\u002F\u002F\u002Fabsolute\u002Fpath\u002Fto\u002Fsketches\u002F001-calm-editorial\u002Findex.html\")\nbrowser_vision(question=\"Does this layout look clean and readable? Any visible bugs (overlapping text, unstyled elements, broken images)?\")\n```\n\n`browser_vision` returns an AI description of what's actually on the page plus a screenshot path — catches layout bugs that pure source inspection misses (e.g. a font import that silently failed, a flex container that collapsed). Fix and re-navigate until each variant looks right.\n\n**Default CSS reset + system font stack** for fast starts:\n\n```html\n\u003Cstyle>\n  * { box-sizing: border-box; margin: 0; padding: 0; }\n  body {\n    font-family: -apple-system, BlinkMacSystemFont, \"Segoe UI\", Roboto,\n                 \"Helvetica Neue\", Arial, sans-serif;\n    -webkit-font-smoothing: antialiased;\n    color: #1a1a1a;\n    background: #fafafa;\n    line-height: 1.5;\n  }\n\u003C\u002Fstyle>\n```\n\n### 4. Variant README\n\nEach variant's `README.md` answers:\n\n```markdown\n## Variant: {stance name}\n\n### Design stance\nOne sentence on the principle driving this variant.\n\n### Key choices\n- Layout: ...\n- Typography: ...\n- Color: ...\n- Interaction: ...\n\n### Trade-offs\n- Strong at: ...\n- Weak at: ...\n\n### Best for\n- The kind of user or use case this variant actually serves\n```\n\n### 5. Head-to-head\n\nAfter all variants are built, present them as a comparison. Don't just list — **opinionate**:\n\n```markdown\n## Three takes on the home screen\n\n| Dimension | Calm editorial | Utilitarian dense | Playful split |\n|-----------|----------------|-------------------|---------------|\n| Density   | Low            | High              | Medium        |\n| Primary action visibility | Low | High | Medium |\n| Scan-ability | High | Medium | Low |\n| Feel | Calm, trusted | Sharp, tool-like | Inviting, energetic |\n\n**My take:** Utilitarian dense for power users, calm editorial for content-forward audiences. Playful split is weakest — tries to do both and commits to neither.\n```\n\nLet the user pick a winner, or combine two into a hybrid, or ask for another round.\n\n## Theming (when the project has a visual identity)\n\nIf the user has an existing theme (colors, fonts, tokens), put shared tokens in `sketches\u002Fthemes\u002Ftokens.css` and `@import` them in each variant. Keep tokens minimal:\n\n```css\n\u002F* sketches\u002Fthemes\u002Ftokens.css *\u002F\n:root {\n  --color-bg: #fafafa;\n  --color-fg: #1a1a1a;\n  --color-accent: #0066ff;\n  --color-muted: #666;\n  --radius: 8px;\n  --font-display: \"Inter\", sans-serif;\n  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;\n}\n```\n\nDon't over-tokenize a throwaway sketch — three colors and one font is usually enough.\n\n## Interactivity bar\n\nA sketch is interactive enough when the user can:\n\n1. **Click a primary action** and something visible happens (state change, modal, toast, navigation feint)\n2. **See one meaningful state transition** (filter a list, toggle a mode, open\u002Fclose a panel)\n3. **Hover recognizable affordances** (buttons, rows, tabs)\n\nMore than that is over-engineering a throwaway. Less than that is a screenshot.\n\n## Frontier mode (picking what to sketch next)\n\nIf sketches already exist and the user says \"what should I sketch next?\":\n\n- **Consistency gaps** — two winning variants from different sketches made independent choices that haven't been composed together yet\n- **Unsketched screens** — referenced but never explored\n- **State coverage** — happy path sketched, but not empty \u002F loading \u002F error \u002F 1000-items\n- **Responsive gaps** — validated at one viewport; does it hold at mobile \u002F ultrawide?\n- **Interaction patterns** — static layouts exist; transitions, drag, scroll behavior don't\n\nPropose 2-4 named candidates. Let the user pick.\n\n## Output\n\n- Create `sketches\u002F` (or `.planning\u002Fsketches\u002F` if the user is using GSD conventions) in the repo root\n- One subdir per variant: `NNN-stance-name\u002Findex.html` + `README.md`\n- Tell the user how to open them: `open sketches\u002F001-calm-editorial\u002Findex.html` on macOS, `xdg-open` on Linux, `start` on Windows\n- Keep variants disposable — a sketch that you felt the need to preserve should be promoted into real project code, not curated as an asset\n\n**Typical tool sequence for one variant:**\n\n```\nterminal(\"mkdir -p sketches\u002F001-calm-editorial\")\nwrite_file(\"sketches\u002F001-calm-editorial\u002Findex.html\", \"\u003C!doctype html>...\")\nwrite_file(\"sketches\u002F001-calm-editorial\u002FREADME.md\", \"## Variant: Calm editorial\\n...\")\nbrowser_navigate(url=\"file:\u002F\u002F$(pwd)\u002Fsketches\u002F001-calm-editorial\u002Findex.html\")\nbrowser_vision(question=\"How does this look? Any obvious layout issues?\")\n```\n\nRepeat for each variant, then present the comparison table.\n\n## Attribution\n\nAdapted from the GSD (Get Shit Done) project's `\u002Fgsd-sketch` workflow — MIT © 2025 Lex Christopherson ([gsd-build\u002Fget-shit-done](https:\u002F\u002Fgithub.com\u002Fgsd-build\u002Fget-shit-done)). The full GSD system ships persistent sketch state, theme\u002Fvariant pattern references, and consistency-audit workflows; install with `npx get-shit-done-cc --hermes --global`.\n",{"name":5,"author":58,"license":14,"version":59,"metadata":60,"platforms":67,"description":7},"Hermes Agent (adapted from gsd-build\u002Fget-shit-done)","1.0.0",{"hermes":61},{"tags":62,"related_skills":64},[5,36,43,46,49,34,63,41,44,37],"variants",[51,65,66,45],"claude-design","popular-web-designs",[50,52,47],"master","8ec37df6d71fb664ea19d32c079e7d3ff931a8e0","skills\u002Ffleet\u002Fsketch-absorbed-into-claude-design",3,"https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit","https:\u002F\u002Fweblyfe.ai","https:\u002F\u002Fgithub.com\u002FS3YED","2026-08-27 01:54:02",{"source":8,"skillName":5,"commands":77,"prompt":87,"zipAvailable":88},[78,81,84],{"tool":79,"command":80},"npx","npx skills add S3YED\u002Fappie-kit --skill sketch",{"tool":82,"command":83},"bunx","bunx skills add S3YED\u002Fappie-kit --skill sketch",{"tool":85,"command":86},"pnpm","pnpm dlx skills add S3YED\u002Fappie-kit --skill sketch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Ffleet\u002Fsketch-absorbed-into-claude-design\u002FSKILL.md",true,[],[91,123,150,176,204,229],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":104,"publishedAt":53},"01M6JFD4M6N4DSGC7TXEJ5R3J2","ai-music","AI music generation and audio tools: HeartMuLa lyrics-to-music generation, songwriting craft (+ Suno prompts), and audio spectrogram\u002Ffeature visualization.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fwethlete\u002Fai-music\u002FSKILL.md",[97,100,103],{"categoryNo":98,"categoryName":99,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":101,"categoryName":102,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},[105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122],"music","ai music","humanizer","visualization","Tools","Audio","hermes","hermes agent","songwriting","suno","lyrics","prompts","heartmula","craft","generation","feature","ai music generation","music generation",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":131,"publishedAt":53},"01M6JFCZE4XNFQFMNZDHKHT5V5","agentic-webdesign-design-system-ingestion","Use v0 Design Systems 2.0, Bolt Design System Agents, or Lovable to generate production UI from a client's real design system components — not generic Tailwind. Use when building a client website where brand consistency matters.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fweb-design\u002Fagentic-webdesign-design-system-ingestion\u002FSKILL.md",[129,130],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},[43,132,133,134,135,136,137,138,139,140,141,46,142,143,144,145,146,147,148,149],"agentic","design system","system","ingestion","webdesign","agentic webdesign design system ingestion","components","generate","design systems","website","Tailwind","bolt","lovable","v0","design-system","wed","design system components","appie",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":158,"publishedAt":53},"01M6JFCVPX3913CFAS6QQJ33ZB","agentic-webdesign-agent-elements","Use 21st.dev Agent Elements — 25 shadcn\u002Fui components purpose-built for AI agent UIs. Tool cards (Bash, Edit, Search, Plan, Subagent, MCP), chat, input, streaming. Open source, shadcn-registry install, no runtime lock-in.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fweb-design\u002Fagentic-webdesign-agent-elements\u002FSKILL.md",[156,157],{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},[132,159,136,160,161,162,138,163,164,165,166,167,168,169,170,171,172,173,174,175],"elements","agentic webdesign agent elements","MCP","ai agent","registry","search","streaming","open source","open","Bash","plan","subagent","edit","install","input","lock","source",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":186,"publishedAt":53},"01M6JFCQC7H65M9QJ6TRE71BS1","vercel-deployment","Deploy static sites and frontends to Vercel — handles both CLI and REST API paths, including the CLI token sanitization workaround.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Fvercel-deployment\u002FSKILL.md",[182,185],{"categoryNo":183,"categoryName":184,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},[187,188,189,52,190,50,47,191,192,193,194,195,196,197,198,199,200,201,202,203],"deployment","vercel deployment","vercel","cli","deploy","vercel deploy","REST","api","site","deploy to vercel","token","rest api","host","sites","paths","sanitization","static site",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":211,"publishedAt":53},"01M6JFCM4SMTXBM5A01BK2YQG1","software-quality-workflows","Umbrella workflow for TDD, debugging, code simplification, spikes, pre-commit review, and debugger-assisted investigation.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Fsoftware-quality-workflows\u002FSKILL.md",[210],{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},[212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228],"workflows","quality","software","software quality workflows","review","tdd","workflow","commit","debugging","code","debugger","pre-commit","investigation","code simplification","user","simplification","for",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":233,"categories":234,"keywords":240,"publishedAt":53},"01M6JFCGD0M6CEATY01W7YN6DB","react-component-refactoring","Safely refactor large React components into smaller, maintainable pieces using proven patterns","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Freact-component-refactoring\u002FSKILL.md",[235,238,239],{"categoryNo":236,"categoryName":237,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},[241,242,243,244,245,246,247,248,52,249,250,138,251,47,252,221,253,254,255,256],"react","component","refactoring","component refactoring","react component","react component refactoring","frontend","writing","safe","typescript","react components","modular","refactor","simplify","patterns","test-driven-development"]