[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M74DZ829BNVMT385JTAPB6FS":3,"skill-same:01M74DZ829BNVMT385JTAPB6FS":62},{"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":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":13,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M74DZ829BNVMT385JTAPB6FS","sketch",null,"Throwaway HTML mockups: 2-3 design variants to compare.","LyrikNilpferd71\u002FHermes-Backup","LyrikNilpferd71","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F187173780?v=4","01M727S8GPB77P0S9ECRRMZT58","01M727S8HF63B0MD53F496MK1V",0,"MIT","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-05-12T12-00-32Z\u002Fskills\u002Fcreative\u002Fsketch\u002FSKILL.md",[],[],"2026-11-11 15:11:14",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\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":23,"license":14,"version":24,"metadata":25,"description":7},"Hermes Agent (adapted from gsd-build\u002Fget-shit-done)","1.0.0",{"hermes":26},{"tags":27,"related_skills":37},[5,28,29,30,31,32,33,34,35,36],"mockup","design","ui","prototype","html","variants","exploration","wireframe","comparison",[38,39,40,41],"spike","claude-design","popular-web-designs","excalidraw","main","404fd33aabef3b6bc1cc913117ba2160ade62625","snapshots\u002F2026-05-12T12-00-32Z\u002Fskills\u002Fcreative\u002Fsketch","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71","2026-11-08 20:00:57",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add LyrikNilpferd71\u002FHermes-Backup --skill sketch",{"tool":54,"command":55},"bunx","bunx skills add LyrikNilpferd71\u002FHermes-Backup --skill sketch",{"tool":57,"command":58},"pnpm","pnpm dlx skills add LyrikNilpferd71\u002FHermes-Backup --skill sketch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-05-12T12-00-32Z\u002Fskills\u002Fcreative\u002Fsketch\u002FSKILL.md",true,[],[63,71,78,85,92,99],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":70},"01M76BBCCNA7WQ82Q8QNZH8PBK","writing-plans","Write implementation plans: bite-sized tasks, paths, code.","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fwriting-plans\u002FSKILL.md",[],[],"2026-11-12 13:55:43",{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":70},"01M76BB8YS41CA3NKW0YMSSB88","systematic-debugging","4-phase root cause debugging: understand bugs before fixing.","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fsystematic-debugging\u002FSKILL.md",[],[],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":70},"01M76BB680FPNT998E1GM2QW10","subagent-driven-development","Execute plans via delegate_task subagents (2-stage review).","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fsubagent-driven-development\u002FSKILL.md",[],[],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":70},"01M76BB3C4ZB9S4RWPMM8MX0YB","plan","Write a markdown plan to .hermes\u002Fplans\u002F; no execution.","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fplan\u002FSKILL.md",[],[],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":70},"01M76BB0NK28KMP51YDB5R3EXA","hermes-agent-skill-authoring","Author in-repo SKILL.md files: frontmatter and structure.","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fhermes-agent-skill-authoring\u002FSKILL.md",[],[],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":70},"01M76BAYV58H0CKNSTZE3ZH4NY","debugging-hermes-tui-commands","Debug Hermes TUI slash commands: Python, gateway, Ink UI.","https:\u002F\u002Fgithub.com\u002FLyrikNilpferd71\u002FHermes-Backup\u002Fblob\u002Fmain\u002Fsnapshots\u002F2026-11-08T13-00-51+0100\u002Fskills\u002Fsoftware-development\u002Fdebugging-hermes-tui-commands\u002FSKILL.md",[],[]]