[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GFS29FSYDG4EV2PP1DT7CV":3,"skill-same:01M6GFS29FSYDG4EV2PP1DT7CV":83},{"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":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":6,"ownerHtmlUrl":66,"ownerBlogUrl":6,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M6GFS29FSYDG4EV2PP1DT7CV","spike",null,"Throwaway experiments to validate an idea before build.","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\u002Fdf\u002Fdf4a3da742ecb7cd7365d43a41beddbcc5261faa5aa561bb4aa222bfbf13edba\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"subagent","gsd","mvp","proof","get","done","exploration","build","sketch","hermes","plan","planning","development","windows","validate","experiments","research","prototype","linux","2026-11-10 10:12:30",false,"---\r\nname: spike\r\ndescription: \"Throwaway experiments to validate an idea before build.\"\r\nversion: 1.0.0\r\nauthor: Hermes Agent (adapted from gsd-build\u002Fget-shit-done)\r\nlicense: MIT\r\nplatforms: [linux, macos, windows]\r\nmetadata:\r\n  hermes:\r\n    tags: [spike, prototype, experiment, feasibility, throwaway, exploration, research, planning, mvp, proof-of-concept]\r\n    related_skills: [sketch, subagent-driven-development, plan]\r\n---\r\n\r\n# Spike\r\n\r\nUse this skill when the user wants to **feel out an idea** before committing to a real build — validating feasibility, comparing approaches, or surfacing unknowns that no amount of research will answer. Spikes are disposable by design. Throw them away once they've paid their debt.\r\n\r\nLoad this when the user says things like \"let me try this\", \"I want to see if X works\", \"spike this out\", \"before I commit to Y\", \"quick prototype of Z\", \"is this even possible?\", or \"compare A vs B\".\r\n\r\n## When NOT to use this\r\n\r\n- The answer is knowable from docs or reading code — just do research, don't build\r\n- The work is production path — use the `plan` skill instead\r\n- The idea is already validated — jump straight to implementation\r\n\r\n## If the user has the full GSD system installed\r\n\r\nIf `gsd-spike` shows up as a sibling skill (installed via `npx get-shit-done-cc --hermes`), prefer **`gsd-spike`** when the user wants the full GSD workflow: persistent `.planning\u002Fspikes\u002F` state, MANIFEST tracking across sessions, Given\u002FWhen\u002FThen verdict format, and commit patterns that integrate with the rest of GSD. This skill is the lightweight standalone version for users who don't have (or don't want) the full system.\r\n\r\n## Core method\r\n\r\nRegardless of scale, every spike follows this loop:\r\n\r\n```\r\ndecompose  →  research  →  build  →  verdict\r\n   ↑__________________________________________↓\r\n                  iterate on findings\r\n```\r\n\r\n### 1. Decompose\r\n\r\nBreak the user's idea into **2-5 independent feasibility questions**. Each question is one spike. Present them as a table with Given\u002FWhen\u002FThen framing:\r\n\r\n| # | Spike | Validates (Given\u002FWhen\u002FThen) | Risk |\r\n|---|-------|----------------------------|------|\r\n| 001 | websocket-streaming | Given a WS connection, when LLM streams tokens, then client receives chunks \u003C 100ms | High |\r\n| 002a | pdf-parse-pdfjs | Given a multi-page PDF, when parsed with pdfjs, then structured text is extractable | Medium |\r\n| 002b | pdf-parse-camelot | Given a multi-page PDF, when parsed with camelot, then structured text is extractable | Medium |\r\n\r\n**Spike types:**\r\n- **standard** — one approach answering one question\r\n- **comparison** — same question, different approaches (shared number, letter suffix `a`\u002F`b`\u002F`c`)\r\n\r\n**Good spike questions:** specific feasibility with observable output.\r\n**Bad spike questions:** too broad, no observable output, or just \"read the docs about X\".\r\n\r\n**Order by risk.** The spike most likely to kill the idea runs first. No point prototyping the easy parts if the hard part doesn't work.\r\n\r\n**Skip decomposition** only if the user already knows exactly what they want to spike and says so. Then take their idea as a single spike.\r\n\r\n### 2. Align (for multi-spike ideas)\r\n\r\nPresent the spike table. Ask: \"Build all in this order, or adjust?\" Let the user drop, reorder, or re-frame before you write any code.\r\n\r\n### 3. Research (per spike, before building)\r\n\r\nSpikes are not research-free — you research enough to pick the right approach, then you build. Per spike:\r\n\r\n1. **Brief it.** 2-3 sentences: what this spike is, why it matters, key risk.\r\n2. **Surface competing approaches** if there's real choice:\r\n\r\n   | Approach | Tool\u002FLibrary | Pros | Cons | Status |\r\n   |----------|-------------|------|------|--------|\r\n   | ... | ... | ... | ... | maintained \u002F abandoned \u002F beta |\r\n\r\n3. **Pick one.** State why. If 2+ are credible, build quick variants within the spike.\r\n4. **Skip research** for pure logic with no external dependencies.\r\n\r\nUse Hermes tools for the research step:\r\n\r\n- `web_search(\"python websocket streaming libraries 2025\")` — find candidates\r\n- `web_extract(urls=[\"https:\u002F\u002Fwebsockets.readthedocs.io\u002F...\"])` — read the actual docs (returns markdown)\r\n- `terminal(\"pip show websockets | grep Version\")` — check what's installed in the project's venv\r\n\r\nFor libraries without docs pages, clone and read their `README.md` \u002F `examples\u002F` via `read_file`. Context7 MCP (if the user has it configured) is also a good source — `mcp_*_resolve-library-id` then `mcp_*_query-docs`.\r\n\r\n### 4. Build\r\n\r\nOne directory per spike. Keep it standalone.\r\n\r\n```\r\nspikes\u002F\r\n├── 001-websocket-streaming\u002F\r\n│   ├── README.md\r\n│   └── main.py\r\n├── 002a-pdf-parse-pdfjs\u002F\r\n│   ├── README.md\r\n│   └── parse.js\r\n└── 002b-pdf-parse-camelot\u002F\r\n    ├── README.md\r\n    └── parse.py\r\n```\r\n\r\n**Bias toward something the user can interact with.** Spikes fail when the only output is a log line that says \"it works.\" The user wants to *feel* the spike working. Default choices, in order of preference:\r\n\r\n1. A runnable CLI that takes input and prints observable output\r\n2. A minimal HTML page that demonstrates the behavior\r\n3. A small web server with one endpoint\r\n4. A unit test that exercises the question with recognizable assertions\r\n\r\n**Depth over speed.** Never declare \"it works\" after one happy-path run. Test edge cases. Follow surprising findings. The verdict is only trustworthy when the investigation was honest.\r\n\r\n**Avoid** unless the spike specifically requires it: complex package management, build tools\u002Fbundlers, Docker, env files, config systems. Hardcode everything — it's a spike.\r\n\r\n**Building one spike** — a typical tool sequence:\r\n\r\n```\r\nterminal(\"mkdir -p spikes\u002F001-websocket-streaming\")\r\nwrite_file(\"spikes\u002F001-websocket-streaming\u002FREADME.md\", \"# 001: websocket-streaming\\n\\n...\")\r\nwrite_file(\"spikes\u002F001-websocket-streaming\u002Fmain.py\", \"...\")\r\nterminal(\"cd spikes\u002F001-websocket-streaming && python3 main.py\")\r\n# Observe output, iterate.\r\n```\r\n\r\n**Parallel comparison spikes (002a \u002F 002b) — delegate.** When two approaches can run in parallel and both need real engineering (not 10-line prototypes), fan out with `delegate_task`:\r\n\r\n```\r\ndelegate_task(tasks=[\r\n    {\"goal\": \"Build 002a-pdf-parse-pdfjs: ...\", \"toolsets\": [\"terminal\", \"file\", \"web\"]},\r\n    {\"goal\": \"Build 002b-pdf-parse-camelot: ...\", \"toolsets\": [\"terminal\", \"file\", \"web\"]},\r\n])\r\n```\r\n\r\nEach subagent returns its own verdict; you write the head-to-head.\r\n\r\n### 5. Verdict\r\n\r\nEach spike's `README.md` closes with:\r\n\r\n```markdown\r\n## Verdict: VALIDATED | PARTIAL | INVALIDATED\r\n\r\n### What worked\r\n- ...\r\n\r\n### What didn't\r\n- ...\r\n\r\n### Surprises\r\n- ...\r\n\r\n### Recommendation for the real build\r\n- ...\r\n```\r\n\r\n**VALIDATED** = the core question was answered yes, with evidence.\r\n**PARTIAL** = it works under constraints X, Y, Z — document them.\r\n**INVALIDATED** = doesn't work, for this reason. This is a successful spike.\r\n\r\n## Comparison spikes\r\n\r\nWhen two approaches answer the same question (002a \u002F 002b), build them **back to back**, then do a head-to-head comparison at the end:\r\n\r\n```markdown\r\n## Head-to-head: pdfjs vs camelot\r\n\r\n| Dimension | pdfjs (002a) | camelot (002b) |\r\n|-----------|--------------|----------------|\r\n| Extraction quality | 9\u002F10 structured | 7\u002F10 table-only |\r\n| Setup complexity | npm install, 1 line | pip + ghostscript |\r\n| Perf on 100-page PDF | 3s | 18s |\r\n| Handles rotated text | no | yes |\r\n\r\n**Winner:** pdfjs for our use case. Camelot if we need table-first extraction later.\r\n```\r\n\r\n## Frontier mode (picking what to spike next)\r\n\r\nIf spikes already exist and the user says \"what should I spike next?\", walk the existing directories and look for:\r\n\r\n- **Integration risks** — two validated spikes that touch the same resource but were tested independently\r\n- **Data handoffs** — spike A's output was assumed compatible with spike B's input; never proven\r\n- **Gaps in the vision** — capabilities assumed but unproven\r\n- **Alternative approaches** — different angles for PARTIAL or INVALIDATED spikes\r\n\r\nPropose 2-4 candidates as Given\u002FWhen\u002FThen. Let the user pick.\r\n\r\n## Output\r\n\r\n- Create `spikes\u002F` (or `.planning\u002Fspikes\u002F` if the user is using GSD conventions) in the repo root\r\n- One dir per spike: `NNN-descriptive-name\u002F`\r\n- `README.md` per spike captures question, approach, results, verdict\r\n- Keep the code throwaway — a spike that takes 2 days to \"clean up for production\" was a bad spike\r\n\r\n## Attribution\r\n\r\nAdapted from the GSD (Get Shit Done) project's `\u002Fgsd-spike` workflow — MIT © 2025 Lex Christopherson ([gsd-build\u002Fget-shit-done](https:\u002F\u002Fgithub.com\u002Fgsd-build\u002Fget-shit-done)). The full GSD system offers persistent spike state, MANIFEST tracking, and integration with a broader spec-driven development pipeline; install with `npx get-shit-done-cc --hermes --global`.\r\n","# Spike\r\n\r\nUse this skill when the user wants to **feel out an idea** before committing to a real build — validating feasibility, comparing approaches, or surfacing unknowns that no amount of research will answer. Spikes are disposable by design. Throw them away once they've paid their debt.\r\n\r\nLoad this when the user says things like \"let me try this\", \"I want to see if X works\", \"spike this out\", \"before I commit to Y\", \"quick prototype of Z\", \"is this even possible?\", or \"compare A vs B\".\r\n\r\n## When NOT to use this\r\n\r\n- The answer is knowable from docs or reading code — just do research, don't build\r\n- The work is production path — use the `plan` skill instead\r\n- The idea is already validated — jump straight to implementation\r\n\r\n## If the user has the full GSD system installed\r\n\r\nIf `gsd-spike` shows up as a sibling skill (installed via `npx get-shit-done-cc --hermes`), prefer **`gsd-spike`** when the user wants the full GSD workflow: persistent `.planning\u002Fspikes\u002F` state, MANIFEST tracking across sessions, Given\u002FWhen\u002FThen verdict format, and commit patterns that integrate with the rest of GSD. This skill is the lightweight standalone version for users who don't have (or don't want) the full system.\r\n\r\n## Core method\r\n\r\nRegardless of scale, every spike follows this loop:\r\n\r\n```\r\ndecompose  →  research  →  build  →  verdict\r\n   ↑__________________________________________↓\r\n                  iterate on findings\r\n```\r\n\r\n### 1. Decompose\r\n\r\nBreak the user's idea into **2-5 independent feasibility questions**. Each question is one spike. Present them as a table with Given\u002FWhen\u002FThen framing:\r\n\r\n| # | Spike | Validates (Given\u002FWhen\u002FThen) | Risk |\r\n|---|-------|----------------------------|------|\r\n| 001 | websocket-streaming | Given a WS connection, when LLM streams tokens, then client receives chunks \u003C 100ms | High |\r\n| 002a | pdf-parse-pdfjs | Given a multi-page PDF, when parsed with pdfjs, then structured text is extractable | Medium |\r\n| 002b | pdf-parse-camelot | Given a multi-page PDF, when parsed with camelot, then structured text is extractable | Medium |\r\n\r\n**Spike types:**\r\n- **standard** — one approach answering one question\r\n- **comparison** — same question, different approaches (shared number, letter suffix `a`\u002F`b`\u002F`c`)\r\n\r\n**Good spike questions:** specific feasibility with observable output.\r\n**Bad spike questions:** too broad, no observable output, or just \"read the docs about X\".\r\n\r\n**Order by risk.** The spike most likely to kill the idea runs first. No point prototyping the easy parts if the hard part doesn't work.\r\n\r\n**Skip decomposition** only if the user already knows exactly what they want to spike and says so. Then take their idea as a single spike.\r\n\r\n### 2. Align (for multi-spike ideas)\r\n\r\nPresent the spike table. Ask: \"Build all in this order, or adjust?\" Let the user drop, reorder, or re-frame before you write any code.\r\n\r\n### 3. Research (per spike, before building)\r\n\r\nSpikes are not research-free — you research enough to pick the right approach, then you build. Per spike:\r\n\r\n1. **Brief it.** 2-3 sentences: what this spike is, why it matters, key risk.\r\n2. **Surface competing approaches** if there's real choice:\r\n\r\n   | Approach | Tool\u002FLibrary | Pros | Cons | Status |\r\n   |----------|-------------|------|------|--------|\r\n   | ... | ... | ... | ... | maintained \u002F abandoned \u002F beta |\r\n\r\n3. **Pick one.** State why. If 2+ are credible, build quick variants within the spike.\r\n4. **Skip research** for pure logic with no external dependencies.\r\n\r\nUse Hermes tools for the research step:\r\n\r\n- `web_search(\"python websocket streaming libraries 2025\")` — find candidates\r\n- `web_extract(urls=[\"https:\u002F\u002Fwebsockets.readthedocs.io\u002F...\"])` — read the actual docs (returns markdown)\r\n- `terminal(\"pip show websockets | grep Version\")` — check what's installed in the project's venv\r\n\r\nFor libraries without docs pages, clone and read their `README.md` \u002F `examples\u002F` via `read_file`. Context7 MCP (if the user has it configured) is also a good source — `mcp_*_resolve-library-id` then `mcp_*_query-docs`.\r\n\r\n### 4. Build\r\n\r\nOne directory per spike. Keep it standalone.\r\n\r\n```\r\nspikes\u002F\r\n├── 001-websocket-streaming\u002F\r\n│   ├── README.md\r\n│   └── main.py\r\n├── 002a-pdf-parse-pdfjs\u002F\r\n│   ├── README.md\r\n│   └── parse.js\r\n└── 002b-pdf-parse-camelot\u002F\r\n    ├── README.md\r\n    └── parse.py\r\n```\r\n\r\n**Bias toward something the user can interact with.** Spikes fail when the only output is a log line that says \"it works.\" The user wants to *feel* the spike working. Default choices, in order of preference:\r\n\r\n1. A runnable CLI that takes input and prints observable output\r\n2. A minimal HTML page that demonstrates the behavior\r\n3. A small web server with one endpoint\r\n4. A unit test that exercises the question with recognizable assertions\r\n\r\n**Depth over speed.** Never declare \"it works\" after one happy-path run. Test edge cases. Follow surprising findings. The verdict is only trustworthy when the investigation was honest.\r\n\r\n**Avoid** unless the spike specifically requires it: complex package management, build tools\u002Fbundlers, Docker, env files, config systems. Hardcode everything — it's a spike.\r\n\r\n**Building one spike** — a typical tool sequence:\r\n\r\n```\r\nterminal(\"mkdir -p spikes\u002F001-websocket-streaming\")\r\nwrite_file(\"spikes\u002F001-websocket-streaming\u002FREADME.md\", \"# 001: websocket-streaming\\n\\n...\")\r\nwrite_file(\"spikes\u002F001-websocket-streaming\u002Fmain.py\", \"...\")\r\nterminal(\"cd spikes\u002F001-websocket-streaming && python3 main.py\")\r\n# Observe output, iterate.\r\n```\r\n\r\n**Parallel comparison spikes (002a \u002F 002b) — delegate.** When two approaches can run in parallel and both need real engineering (not 10-line prototypes), fan out with `delegate_task`:\r\n\r\n```\r\ndelegate_task(tasks=[\r\n    {\"goal\": \"Build 002a-pdf-parse-pdfjs: ...\", \"toolsets\": [\"terminal\", \"file\", \"web\"]},\r\n    {\"goal\": \"Build 002b-pdf-parse-camelot: ...\", \"toolsets\": [\"terminal\", \"file\", \"web\"]},\r\n])\r\n```\r\n\r\nEach subagent returns its own verdict; you write the head-to-head.\r\n\r\n### 5. Verdict\r\n\r\nEach spike's `README.md` closes with:\r\n\r\n```markdown\r\n## Verdict: VALIDATED | PARTIAL | INVALIDATED\r\n\r\n### What worked\r\n- ...\r\n\r\n### What didn't\r\n- ...\r\n\r\n### Surprises\r\n- ...\r\n\r\n### Recommendation for the real build\r\n- ...\r\n```\r\n\r\n**VALIDATED** = the core question was answered yes, with evidence.\r\n**PARTIAL** = it works under constraints X, Y, Z — document them.\r\n**INVALIDATED** = doesn't work, for this reason. This is a successful spike.\r\n\r\n## Comparison spikes\r\n\r\nWhen two approaches answer the same question (002a \u002F 002b), build them **back to back**, then do a head-to-head comparison at the end:\r\n\r\n```markdown\r\n## Head-to-head: pdfjs vs camelot\r\n\r\n| Dimension | pdfjs (002a) | camelot (002b) |\r\n|-----------|--------------|----------------|\r\n| Extraction quality | 9\u002F10 structured | 7\u002F10 table-only |\r\n| Setup complexity | npm install, 1 line | pip + ghostscript |\r\n| Perf on 100-page PDF | 3s | 18s |\r\n| Handles rotated text | no | yes |\r\n\r\n**Winner:** pdfjs for our use case. Camelot if we need table-first extraction later.\r\n```\r\n\r\n## Frontier mode (picking what to spike next)\r\n\r\nIf spikes already exist and the user says \"what should I spike next?\", walk the existing directories and look for:\r\n\r\n- **Integration risks** — two validated spikes that touch the same resource but were tested independently\r\n- **Data handoffs** — spike A's output was assumed compatible with spike B's input; never proven\r\n- **Gaps in the vision** — capabilities assumed but unproven\r\n- **Alternative approaches** — different angles for PARTIAL or INVALIDATED spikes\r\n\r\nPropose 2-4 candidates as Given\u002FWhen\u002FThen. Let the user pick.\r\n\r\n## Output\r\n\r\n- Create `spikes\u002F` (or `.planning\u002Fspikes\u002F` if the user is using GSD conventions) in the repo root\r\n- One dir per spike: `NNN-descriptive-name\u002F`\r\n- `README.md` per spike captures question, approach, results, verdict\r\n- Keep the code throwaway — a spike that takes 2 days to \"clean up for production\" was a bad spike\r\n\r\n## Attribution\r\n\r\nAdapted from the GSD (Get Shit Done) project's `\u002Fgsd-spike` workflow — MIT © 2025 Lex Christopherson ([gsd-build\u002Fget-shit-done](https:\u002F\u002Fgithub.com\u002Fgsd-build\u002Fget-shit-done)). The full GSD system offers persistent spike state, MANIFEST tracking, and integration with a broader spec-driven development pipeline; install with `npx get-shit-done-cc --hermes --global`.\r\n",{"name":5,"author":48,"license":15,"version":49,"metadata":50,"platforms":59,"description":7},"Hermes Agent (adapted from gsd-build\u002Fget-shit-done)","1.0.0",{"hermes":51},{"tags":52,"related_skills":57},[5,41,53,54,55,30,40,35,26,56],"experiment","feasibility","throwaway","proof-of-concept",[32,58,34],"subagent-driven-development",[42,60,37],"macos","main","0d1434f89f4bc6b07e9d272accd8c1013768820f","archive\u002Fskill-md-reviewed\u002Fsha256\u002Fdf\u002Fdf4a3da742ecb7cd7365d43a41beddbcc5261faa5aa561bb4aa222bfbf13edba",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":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add zapabob\u002FSkills --skill spike",{"tool":75,"command":76},"bunx","bunx skills add zapabob\u002FSkills --skill spike",{"tool":78,"command":79},"pnpm","pnpm dlx skills add zapabob\u002FSkills --skill spike","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002Fdf\u002Fdf4a3da742ecb7cd7365d43a41beddbcc5261faa5aa561bb4aa222bfbf13edba\u002FSKILL.md",true,[],[84,116,148,175,200,217],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":101,"publishedAt":43},"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",[90,93,96],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[86,102,60,103,104,42,37,105,106,107,108,109,110,33,111,112,61,113,114,115],"openclaw","cli","github","official","search","https","social-media","api","Media","hermes agent","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":133,"publishedAt":43},"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,125,128,129,130],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},{"categoryNo":131,"categoryName":132,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000036","内容创作者",[134,135,136,137,60,138,42,139,37,140,141,36,142,35,143,24,144,145,146,147],"writing","writing plans","plans","design","review","workflow","documentation","tasks","code","code-review","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":43},"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,60,42,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":43},"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,60,186,39,37,187,188,189,190,191,192,165,53,193,194,195,196,197,198,199],"weights and biases","tensorflow","pytorch","visualization","registry","real-time","tuning","dashboards","log","time","Experiment Tracking","Model Registry","Hyperparameter Tuning","WandB","Real-Time Visualization",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":207,"publishedAt":43},"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",[206],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},[202,60,208,104,42,209,210,211,212,213,214,33,111,215,216],"terminal","automation","http","monitoring","cron","json","rss","devops","with",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":225,"publishedAt":43},"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",[223,224],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},[226,227,228,42,40,158,229,230,231,161,232,109,233,234,235,236,237,238,239,240],"llms","vLLM","serving llms vllm","openai api","tensor","Inference Serving","Production","llm serving","High Throughput","PagedAttention","Continuous Batching","Quantization","Tensor Parallelism","high-throughput","throughput"]