[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DEKW9FV7EBJVAPCY862YCD":3,"skill-same:01M6DEKW9FV7EBJVAPCY862YCD":86},{"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":31,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":67,"repositoryHtmlUrl":68,"repositoryHomepageUrl":6,"ownerHtmlUrl":69,"ownerBlogUrl":6,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M6DEKW9FV7EBJVAPCY862YCD","sketch",null,"Throwaway HTML mockups: 2-3 design variants to compare.","zapabob\u002FSkills","zapabob","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F130830376?v=4","01M6DBMYZAGRTFQDSQYW3W764P","峯岸 亮","01M6DBMZ3GKDSJ01NZ9XTZD7JD",2,"MIT","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002F3d\u002F3dd273225322591ff88d4b8ff93da67fb8daeef15712b599fb2eb8d8372aae0c\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[5,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"hermes","get","done","exploration","build","html","wireframe","hermes agent","design","excalidraw","ui","windows","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.1\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, 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`), you can use **`gsd-sketch`** for the fuller 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> **Note:** The upstream GSD project ([gsd-build\u002Fget-shit-done](https:\u002F\u002Fgithub.com\u002Fgsd-build\u002Fget-shit-done)) is **archived \u002F no longer maintained** on GitHub. The npm package (`get-shit-done-cc`) still installs, but treat it as an archived community project — this standalone `sketch` skill is the maintained path and needs nothing extra.\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 upstream GSD repo is now **archived\u002Funmaintained** on GitHub; the `get-shit-done-cc` npm package still installs (`npx get-shit-done-cc --hermes --global`) and ships persistent sketch state, theme\u002Fvariant pattern references, and consistency-audit workflows, but treat it as an archived community project.\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`), you can use **`gsd-sketch`** for the fuller 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> **Note:** The upstream GSD project ([gsd-build\u002Fget-shit-done](https:\u002F\u002Fgithub.com\u002Fgsd-build\u002Fget-shit-done)) is **archived \u002F no longer maintained** on GitHub. The npm package (`get-shit-done-cc`) still installs, but treat it as an archived community project — this standalone `sketch` skill is the maintained path and needs nothing extra.\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 upstream GSD repo is now **archived\u002Funmaintained** on GitHub; the `get-shit-done-cc` npm package still installs (`npx get-shit-done-cc --hermes --global`) and ships persistent sketch state, theme\u002Fvariant pattern references, and consistency-audit workflows, but treat it as an archived community project.\n",{"name":5,"author":53,"license":15,"version":54,"metadata":55,"platforms":63,"description":7},"Hermes Agent (adapted from gsd-build\u002Fget-shit-done)","1.0.1",{"hermes":56},{"tags":57,"related_skills":61},[5,58,40,42,44,37,59,35,38,60],"mockup","variants","comparison",[46,62,41],"claude-design",[45,47,43],"main","0d1434f89f4bc6b07e9d272accd8c1013768820f","archive\u002Fskill-md-reviewed\u002Fsha256\u002F3d\u002F3dd273225322591ff88d4b8ff93da67fb8daeef15712b599fb2eb8d8372aae0c",0,"https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills","https:\u002F\u002Fgithub.com\u002Fzapabob","The Open University of JAPAN　2019-now\r\n\r\nTokyo University of Science　2007-2010","2026-10-26 16:29:01",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add zapabob\u002FSkills --skill sketch",{"tool":78,"command":79},"bunx","bunx skills add zapabob\u002FSkills --skill sketch",{"tool":81,"command":82},"pnpm","pnpm dlx skills add zapabob\u002FSkills --skill sketch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002F3d\u002F3dd273225322591ff88d4b8ff93da67fb8daeef15712b599fb2eb8d8372aae0c\u002FSKILL.md",true,[],[87,116,148,175,202,219],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":102,"publishedAt":48},"01M6GJTE1GESGGF9K028Y7753E","xurl","X\u002FTwitter via xurl CLI: post, search, DM, media, v2 API.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fxurl\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[93,96,99],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":97,"categoryName":98,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":100,"categoryName":101,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师",[89,103,47,104,105,45,43,106,107,108,109,110,111,32,39,112,64,113,114,115],"openclaw","cli","github","official","search","https","social-media","api","Media","twitter","social","via","post",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":131,"publishedAt":48},"01M6GJT8S1PXQ8WPXT1HSNBWH2","writing-plans","Write implementation plans: bite-sized tasks, paths, code.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwriting-plans\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[122,123,126,127,128],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":124,"categoryName":125,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":97,"categoryName":98,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":100,"categoryName":101,"taxonomyType":29,"taxonomyTypeDesc":30},{"categoryNo":129,"categoryName":130,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[132,133,134,40,47,135,45,136,43,137,138,139,140,141,142,143,144,145,146,147],"writing","writing plans","plans","review","workflow","documentation","tasks","development","code","planning","code-review","subagent","write","superpowers","paths","test-driven-development",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":157,"publishedAt":48},"01M6GJST0H5X7WHBJ3BZK0DVKH","whisper","OpenAI's general-purpose speech recognition model. Supports 99 languages, transcription, translation to English, and language identification. Six model sizes from tiny (39M params) to large (1550M params). Use for speech-to-text, podcast transcription, or multilingual audio processing. Best for robust, multilingual ASR.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwhisper\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[150,47,45,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174],"openai","speech","multimodal","Transformers","ASR","Audio","text","model","speech recognition","use","general","multilingual","translation","english","identification","processing","Audio Processing",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":184,"publishedAt":48},"01M6GJSMRQ8EETZTYMG72P70EA","weights-and-biases","W&B: log ML experiments, sweeps, model registry, dashboards.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fweights-and-biases\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[181],{"categoryNo":182,"categoryName":183,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",[185,47,186,187,43,188,189,190,191,192,193,165,194,195,196,197,198,199,200,201],"weights and biases","tensorflow","experiments","pytorch","visualization","registry","real-time","tuning","dashboards","experiment","log","time","Experiment Tracking","Model Registry","Hyperparameter Tuning","WandB","Real-Time Visualization",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":209,"publishedAt":48},"01M6GJS19KDPRY112JTR326S06","watchers","Poll RSS, JSON APIs, and GitHub with watermark dedup.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwatchers\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[208],{"categoryNo":97,"categoryName":98,"taxonomyType":21,"taxonomyTypeDesc":22},[204,47,210,105,45,211,212,213,214,215,216,32,39,217,218],"terminal","automation","http","monitoring","cron","json","rss","devops","with",{"skillNo":220,"name":221,"nameZh":6,"description":222,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":223,"categories":224,"keywords":227,"publishedAt":48},"01M6GJRHJD2A6Q830SWF9W48BC","serving-llms-vllm","vLLM: high-throughput LLM serving, OpenAI API, quantization.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fvllm\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[225,226],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":100,"categoryName":101,"taxonomyType":29,"taxonomyTypeDesc":30},[228,229,230,45,231,158,232,233,234,161,235,110,236,237,238,239,240,241,242,243],"llms","vLLM","serving llms vllm","research","openai api","tensor","Inference Serving","Production","llm serving","High Throughput","PagedAttention","Continuous Batching","Quantization","Tensor Parallelism","high-throughput","throughput"]