[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71T865TKNP3CADJCBQPC6PM":3,"skill-same:01M71T865TKNP3CADJCBQPC6PM":86},{"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":30,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":66,"commitSha":67,"skillDirectory":68,"forksCount":13,"repositoryHtmlUrl":69,"repositoryHomepageUrl":6,"ownerHtmlUrl":70,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":71,"install":72,"resources":85},"01M71T865TKNP3CADJCBQPC6PM","sketch",null,"Throwaway HTML mockups: 2-3 design variants to compare.","eliottbusiness\u002FDeptFlow-Agent","eliottbusiness","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263418316?v=4","01M71T5T608RHFA07W6QVC6TYX","01M71T5T6R98RMYZ53PYH851T1",0,"MIT","https:\u002F\u002Fgithub.com\u002Feliottbusiness\u002FDeptFlow-Agent\u002Fblob\u002Fmain\u002Fprofile\u002Fskills\u002Fcreative\u002Fsketch\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[5,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"compare","hermes agent","hermes","spike","gsd","design variants","excalidraw","build","web","prototype","wireframe","done","comparison","shit","throwaway","variants","design","get","exploration","2026-11-10 13:02:02",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":55,"license":14,"version":56,"metadata":57,"description":7},"Hermes Agent (adapted from gsd-build\u002Fget-shit-done)","1.0.0",{"hermes":58},{"tags":59,"related_skills":63},[5,60,47,61,40,62,46,49,41,43],"mockup","ui","html",[34,64,65,37],"claude-design","popular-web-designs","main","3ffb682eba417bd920665a7146fecc206b3bccf8","profile\u002Fskills\u002Fcreative\u002Fsketch","https:\u002F\u002Fgithub.com\u002Feliottbusiness\u002FDeptFlow-Agent","https:\u002F\u002Fgithub.com\u002Feliottbusiness","2026-05-03 19:19:17",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add eliottbusiness\u002FDeptFlow-Agent --skill sketch",{"tool":78,"command":79},"bunx","bunx skills add eliottbusiness\u002FDeptFlow-Agent --skill sketch",{"tool":81,"command":82},"pnpm","pnpm dlx skills add eliottbusiness\u002FDeptFlow-Agent --skill sketch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Feliottbusiness\u002FDeptFlow-Agent\u002Fblob\u002Fmain\u002Fprofile\u002Fskills\u002Fcreative\u002Fsketch\u002FSKILL.md",true,[],[87,123,148,164,183,198],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":103,"publishedAt":50},"01M71TEDB3XPT9H5R3SH05XWES","writing-plans","Write implementation plans: bite-sized tasks, paths, code.","https:\u002F\u002Fgithub.com\u002Feliottbusiness\u002FDeptFlow-Agent\u002Fblob\u002Fmain\u002Fprofile\u002Fskills\u002Fsoftware-development\u002Fwriting-plans\u002FSKILL.md",[93,94,97,100],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":95,"categoryName":96,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":98,"categoryName":99,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":101,"categoryName":102,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000036","内容创作者",[104,105,106,107,108,109,47,110,111,112,113,114,115,116,117,118,119,120,121,122],"writing","writing plans","plans","test-driven","test-driven-development","superpowers","workflow","code","tasks","subagent","code-review","review","documentation","write","paths","planning","development","test","implementation",{"skillNo":124,"name":108,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":134,"publishedAt":50},"01M71TEB43BNQKKCRMQZDZ7SAQ","TDD: enforce RED-GREEN-REFACTOR, tests before code.","https:\u002F\u002Fgithub.com\u002Feliottbusiness\u002FDeptFlow-Agent\u002Fblob\u002Fmain\u002Fprofile\u002Fskills\u002Fsoftware-development\u002Ftest-driven-development\u002FSKILL.md",[128,131],{"categoryNo":129,"categoryName":130,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":132,"categoryName":133,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",[135,120,121,136,137,138,139,109,104,140,111,113,141,142,143,144,145,106,146,147],"test driven development","driven","green","red-green-refactor","testing","debugging","systematic","refactor","systematic-debugging","enforce","tests","tdd","quality",{"skillNo":149,"name":143,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":50},"01M71TE76KV9R1WY1V5XQXMMTJ","4-phase root cause debugging: understand bugs before fixing.","https:\u002F\u002Fgithub.com\u002Feliottbusiness\u002FDeptFlow-Agent\u002Fblob\u002Fmain\u002Fprofile\u002Fskills\u002Fsoftware-development\u002Fsystematic-debugging\u002FSKILL.md",[153],{"categoryNo":132,"categoryName":133,"taxonomyType":20,"taxonomyTypeDesc":21},[155,140,141,107,156,157,108,109,104,113,158,159,120,160,106,161,121,162,163,33],"systematic debugging","problem","problem-solving","phase","bugs","root cause","root-cause","investigation","understand",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":175,"publishedAt":50},"01M71TE2Y2TRFZNT6YRPKQA33R","subagent-driven-development","Execute plans via delegate_task subagents (2-stage review).","https:\u002F\u002Fgithub.com\u002Feliottbusiness\u002FDeptFlow-Agent\u002Fblob\u002Fmain\u002Fprofile\u002Fskills\u002Fsoftware-development\u002Fsubagent-driven-development\u002FSKILL.md",[170,171,174],{"categoryNo":95,"categoryName":96,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":172,"categoryName":173,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":101,"categoryName":102,"taxonomyType":28,"taxonomyTypeDesc":29},[176,113,120,136,107,108,177,178,109,104,110,111,114,115,179,180,106,181,182,121],"subagent driven development","delegate","delegation","subagents","parallel","stage","task",{"skillNo":184,"name":34,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":191,"publishedAt":50},"01M71TE0E7WRGXY6N0WTMDXY23","Throwaway experiments to validate an idea before build.","https:\u002F\u002Fgithub.com\u002Feliottbusiness\u002FDeptFlow-Agent\u002Fblob\u002Fmain\u002Fprofile\u002Fskills\u002Fsoftware-development\u002Fspike\u002FSKILL.md",[188],{"categoryNo":189,"categoryName":190,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000021","资料检索与研究",[34,192,49,48,119,120,106,45,44,104,193,42,113,40,194,195,38,5,196,197],"concept","proof-of-concept","plan","research","mvp","validate",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":206,"publishedAt":50},"01M71TDY3JXZHWSYNF3AZ2XM2D","requesting-code-review","Pre-commit review: security scan, quality gates, auto-fix.","https:\u002F\u002Fgithub.com\u002Feliottbusiness\u002FDeptFlow-Agent\u002Fblob\u002Fmain\u002Fprofile\u002Fskills\u002Fsoftware-development\u002Frequesting-code-review\u002FSKILL.md",[204,205],{"categoryNo":129,"categoryName":130,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":98,"categoryName":99,"taxonomyType":28,"taxonomyTypeDesc":29},[207,208,111,115,107,108,209,210,109,211,104,212,213,113,114,214,215,120,216,106],"code review","requesting code review","fix","auto-fix","auto","security scan","commit","verification","security","scan"]