[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GC6FPDN6T3SMKGDQ705TED":3,"skill-same:01M6GC6FPDN6T3SMKGDQ705TED":77},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6GC6FPDN6T3SMKGDQ705TED","fork-upstream-sync",null,"Sync a fork to upstream, keeping custom features.","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\u002Fa5\u002Fa52f1522e68e3b748949b2bba2a2896765a975141ffb945edfcac2c2e4b5b25d\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"upstream sync","fork upstream sync","upstream","sync","merge","workflow","windows","pr","routing","git","macos","hermes","hermes agent","repo","management","schema","drift","linux","conflict","github","2026-11-10 10:12:30",false,"---\r\nname: fork-upstream-sync\r\ndescription: \"Sync a fork to upstream, keeping custom features.\"\r\nversion: 1.0.0\r\nauthor: Hermes Agent\r\nlicense: MIT\r\nplatforms: [linux, macos, windows]\r\nmetadata:\r\n  hermes:\r\n    tags: [git, github, fork, upstream, merge, conflict, schema, drift]\r\n    related_skills: [git-pr-fork-routing, github-repo-management, github-pr-workflow]\r\n---\r\n\r\n# Fork ↔ Upstream Sync (customizations preserved)\r\n\r\nUse when the user says any of: \"取り込んで \u002F 追従 \u002F pull in upstream's latest features, security updates and bugfixes while keeping my custom features\", \"sync my fork\", \"rebase my fork on upstream\", \"keep my custom API in step with upstream's latest\".\r\n\r\nThis is a **class of task**, not a one-off: fork is N commits behind, has a small set of fork-only files, and the user wants (a) upstream's fixes, (b) their customizations intact, and (c) their custom data\u002Fconfig still valid against upstream's *current* schema\u002FAPI.\r\n\r\n## Step 0 — Verify the checkout is actually the fork (non-skippable)\r\n\r\nA local directory named after the repo is frequently **not** the fork. Check before touching anything:\r\n\r\n```bash\r\ngit remote -v            # origin must be the FORK, not upstream\r\ngit branch -a            # \"* (no branch)\" == detached\r\ncat .git\u002Fshallow         # non-empty == shallow clone, cannot merge history\r\n```\r\n\r\nCommon trap seen in practice: the local dir was a **shallow, detached tag checkout of upstream** (`origin` = upstream URL, `HEAD` = a release tag, `.git\u002Fshallow` present, 1 commit of history). Merging there is impossible and silently wrong.\r\n\r\n**Fix: clone the fork fresh into a scratch dir and work there.** Do not try to repair the broken checkout. Tell the user plainly that the local dir was not the fork — it changes their mental model of the task.\r\n\r\n```bash\r\ngit clone https:\u002F\u002Fgithub.com\u002F\u003CYOU>\u002F\u003Crepo>.git \u002Ftmp\u002F\u003Crepo>-merge\r\ncd \u002Ftmp\u002F\u003Crepo>-merge\r\ngit remote add upstream https:\u002F\u002Fgithub.com\u002F\u003CUPSTREAM>\u002F\u003Crepo>.git\r\ngit fetch upstream\r\ngit rev-list --left-right --count HEAD...upstream\u002Fmain   # ahead \u003CTAB> behind\r\n```\r\n\r\n## Step 1 — Survey before merging\r\n\r\nTwo numbers decide the strategy:\r\n\r\n- `git log --oneline upstream\u002Fmain..HEAD` — the **fork-only commits**. If this is 1–3 commits of config\u002Fdocs, a merge is trivially safe. If it's a divergent feature branch, expect real conflicts.\r\n- `git diff --stat upstream\u002Fmain...HEAD` — the exact fork-only file set. **This list IS the protection policy** for step 2.\r\n- Overlap of `diff --name-only upstream\u002Fmain...HEAD` and `diff --name-only HEAD...upstream\u002Fmain` = the only files that can conflict. Usually it's just lockfiles.\r\n\r\n## Step 2 — Merge with an explicit ours\u002Ftheirs policy\r\n\r\nWrite the policy down as code, don't resolve by hand. Use `scripts\u002Fmerge_upstream.py` in this skill (edit the constants at the top):\r\n\r\n- `OURS_PATHS` — fork-only config\u002Fstate dirs (`.akari\u002F`, `.claude\u002F`, custom reports). Always `--ours`.\r\n- `THEIRS_PATHS` — **generated** artifacts (`package-lock.json`, `poetry.lock`, `uv.lock`). Always `--theirs`; the fork's lockfile is stale by definition and regenerating from upstream's manifest is correct.\r\n- Anything else conflicting → stop and surface to the user.\r\n\r\n```bash\r\npython scripts\u002Fmerge_upstream.py --report    # triage: security \u002F fix \u002F feature \u002F other\r\npython scripts\u002Fmerge_upstream.py --merge     # branch merge\u002Fupstream-YYYY-MM-DD\r\n```\r\n\r\nUse `--no-ff` onto a dated branch (`merge\u002Fupstream-YYYY-MM-DD`), **never** merge straight into `main`. Push the branch; let the user open the PR.\r\n\r\nClassify the incoming commits into security \u002F fix \u002F feature \u002F other and report the counts. When the user asks for \"脆弱性更新\" \u002F security updates specifically and the security bucket is 0, **say so explicitly** rather than letting the reader assume security work was included.\r\n\r\n## Step 3 — Verify the custom API still tracks upstream (the part people skip)\r\n\r\nMerging cleanly does **not** mean the fork's custom data still matches upstream's contract. Upstream may have changed a JSON Schema or a TS interface that the fork's config files must satisfy. Validate mechanically with `scripts\u002Fverify_custom_api.py`:\r\n\r\n- Pair each fork-only data file with upstream's current schema (`packages\u002Fschemas\u002F*.schema.json` or equivalent) and validate with `jsonschema`.\r\n- For custom files with **no** upstream schema, locate the governing TS\u002Fpy interface and diff the key set by hand. Check whether upstream parses it as `Partial\u003CT>` \u002F with defaults — if so, extra fork-only keys are a **safe extension**, not drift. If upstream does a strict parse, extra keys are a break.\r\n- The script falls back to a structural check (required keys, types, enums, `additionalProperties`) when `jsonschema` is unavailable, so it always yields a verdict.\r\n\r\n## Step 4 — Report honestly what was NOT verified\r\n\r\nA merge that compiles in your head is not a verified merge. State the residual risk explicitly:\r\n\r\n- `npm ci` \u002F `build` \u002F `lint` \u002F tests **not run** (e.g. no `node_modules`) → runtime regression unverified.\r\n- Lockfile taken from upstream → fork-specific deps may need reinstall.\r\n- Branch pushed, **not** merged to main.\r\n\r\nThen offer to run the build. Do not describe the merge as \"done\" when only the git operation is done.\r\n\r\n## Step 5 — Generic Harness Independence (Phase 2-4: after sync is stable)\r\n\r\nWhen the fork's goal shifts from \"track upstream\" to \"grow as an independent generic harness\" (e.g. `zapabob\u002Fhermes-agent-windows` as Windows AI workstation base, zero runtime dependency on `NousResearch\u002Fhermes-agent`), extend the lifecycle:\r\n\r\n### 5a. Brand-separation audit (Phase 2)\r\n\r\nBefore declaring independence, audit hard-coded upstream brand strings so future merges stay clean:\r\n\r\n```bash\r\n# Find residual brand references that would re-entangle merges\r\nrg -n \"NousResearch|nous-research|hermes-agent.*upstream\" --glob '!uv.lock' --glob '!*.bak'\r\n# Classify each hit: attribution (keep) vs. runtime dependency (remove)\r\n# Attribution stays in README\u002FLICENSE\u002FCARRY.yaml; runtime deps must be zero\r\npy -3 -c \"import tomllib; d=tomllib.load(open('pyproject.toml','rb')); print([x for x in d['project']['dependencies'] if 'nous' in x.lower()])\"\r\n# Expect [] — no PyPI dep on nous\r\n```\r\n\r\nRecord the result in `_docs\u002FYYYY-MM-DD_generic-harness-independence.md` and `fork\u002Fharness\u002FGENERIC_HARNESS.md` (the permanent harness definition). Patch `fork\u002FREADME.md` with an Identity block declaring `upstream = fetch-only, zero runtime dependency`.\r\n\r\n### 5b. Harness growth policy (Phase 3-4)\r\n\r\n- **Narrow waist**: keep `run_agent.py` \u002F `gateway\u002F` \u002F `tool registry` thin; new capability goes to `plugins\u002F` \u002F `skills\u002F` \u002F `downstream\u002F` (Footprint Ladder).\r\n- **Windows Tier-1**: any new feature touching paths\u002Fprocesses\u002FIPC must have a `WINDOWS_PLATFORM_CONTRACT.md` regression.\r\n- **Freeze gate**: when upstream stalls (90 days no `main` activity or architectural deadlock), freeze `UPSTREAM_SNAPSHOT.json` at the last SHA and archive `scripts\u002Fsync_all.py` — thereafter the fork owns its release cycle.\r\n- **A2A decision meetings**: when Phase 2 vs. expansion priority is contested, run a 4-perspective `delegate_task` batch (conservative \u002F expansion \u002F risk-CI \u002F operations) to force explicit trade-offs before committing. See `references\u002Fgeneric-harness-independence.md`.\r\n\r\n## Pitfalls\r\n\r\n- **A repo dir with the upstream URL in `origin` is not your fork.** Always `git remote -v` first; re-clone rather than repair.\r\n- **Shallow clones cannot merge** (`.git\u002Fshallow` present, no merge base). Re-clone with full history.\r\n- **Don't hand-resolve lockfile conflicts.** Take theirs and regenerate.\r\n- **Don't merge into `main` directly** on a 100+ commit catch-up. Dated merge branch + PR.\r\n- **Don't claim security fixes were pulled in** unless the commit classification actually found some.\r\n- **Windows:** the real interpreter is `py -3`; bare `python` may be the Microsoft Store stub. Invoke as `py -3 scripts\u002Fmerge_upstream.py`.\r\n- Write the implementation log to the **project's** `_docs\u002FYYYY-MM-DD_\u003Ctopic>_\u003CAI>.md` per the PC-wide AGENTS.md baseline, even when the merge itself happened in a scratch clone.\r\n- Committing the two scripts into the fork itself is a good outcome — it makes the next catch-up a one-command operation.\r\n\r\n## Bundled files\r\n\r\n- `scripts\u002Fmerge_upstream.py` — survey + policy-guarded merge + fork-file survival assertion.\r\n- `scripts\u002Fverify_custom_api.py` — validate fork-only JSON against upstream's current schemas; reports drift.\r\n","# Fork ↔ Upstream Sync (customizations preserved)\r\n\r\nUse when the user says any of: \"取り込んで \u002F 追従 \u002F pull in upstream's latest features, security updates and bugfixes while keeping my custom features\", \"sync my fork\", \"rebase my fork on upstream\", \"keep my custom API in step with upstream's latest\".\r\n\r\nThis is a **class of task**, not a one-off: fork is N commits behind, has a small set of fork-only files, and the user wants (a) upstream's fixes, (b) their customizations intact, and (c) their custom data\u002Fconfig still valid against upstream's *current* schema\u002FAPI.\r\n\r\n## Step 0 — Verify the checkout is actually the fork (non-skippable)\r\n\r\nA local directory named after the repo is frequently **not** the fork. Check before touching anything:\r\n\r\n```bash\r\ngit remote -v            # origin must be the FORK, not upstream\r\ngit branch -a            # \"* (no branch)\" == detached\r\ncat .git\u002Fshallow         # non-empty == shallow clone, cannot merge history\r\n```\r\n\r\nCommon trap seen in practice: the local dir was a **shallow, detached tag checkout of upstream** (`origin` = upstream URL, `HEAD` = a release tag, `.git\u002Fshallow` present, 1 commit of history). Merging there is impossible and silently wrong.\r\n\r\n**Fix: clone the fork fresh into a scratch dir and work there.** Do not try to repair the broken checkout. Tell the user plainly that the local dir was not the fork — it changes their mental model of the task.\r\n\r\n```bash\r\ngit clone https:\u002F\u002Fgithub.com\u002F\u003CYOU>\u002F\u003Crepo>.git \u002Ftmp\u002F\u003Crepo>-merge\r\ncd \u002Ftmp\u002F\u003Crepo>-merge\r\ngit remote add upstream https:\u002F\u002Fgithub.com\u002F\u003CUPSTREAM>\u002F\u003Crepo>.git\r\ngit fetch upstream\r\ngit rev-list --left-right --count HEAD...upstream\u002Fmain   # ahead \u003CTAB> behind\r\n```\r\n\r\n## Step 1 — Survey before merging\r\n\r\nTwo numbers decide the strategy:\r\n\r\n- `git log --oneline upstream\u002Fmain..HEAD` — the **fork-only commits**. If this is 1–3 commits of config\u002Fdocs, a merge is trivially safe. If it's a divergent feature branch, expect real conflicts.\r\n- `git diff --stat upstream\u002Fmain...HEAD` — the exact fork-only file set. **This list IS the protection policy** for step 2.\r\n- Overlap of `diff --name-only upstream\u002Fmain...HEAD` and `diff --name-only HEAD...upstream\u002Fmain` = the only files that can conflict. Usually it's just lockfiles.\r\n\r\n## Step 2 — Merge with an explicit ours\u002Ftheirs policy\r\n\r\nWrite the policy down as code, don't resolve by hand. Use `scripts\u002Fmerge_upstream.py` in this skill (edit the constants at the top):\r\n\r\n- `OURS_PATHS` — fork-only config\u002Fstate dirs (`.akari\u002F`, `.claude\u002F`, custom reports). Always `--ours`.\r\n- `THEIRS_PATHS` — **generated** artifacts (`package-lock.json`, `poetry.lock`, `uv.lock`). Always `--theirs`; the fork's lockfile is stale by definition and regenerating from upstream's manifest is correct.\r\n- Anything else conflicting → stop and surface to the user.\r\n\r\n```bash\r\npython scripts\u002Fmerge_upstream.py --report    # triage: security \u002F fix \u002F feature \u002F other\r\npython scripts\u002Fmerge_upstream.py --merge     # branch merge\u002Fupstream-YYYY-MM-DD\r\n```\r\n\r\nUse `--no-ff` onto a dated branch (`merge\u002Fupstream-YYYY-MM-DD`), **never** merge straight into `main`. Push the branch; let the user open the PR.\r\n\r\nClassify the incoming commits into security \u002F fix \u002F feature \u002F other and report the counts. When the user asks for \"脆弱性更新\" \u002F security updates specifically and the security bucket is 0, **say so explicitly** rather than letting the reader assume security work was included.\r\n\r\n## Step 3 — Verify the custom API still tracks upstream (the part people skip)\r\n\r\nMerging cleanly does **not** mean the fork's custom data still matches upstream's contract. Upstream may have changed a JSON Schema or a TS interface that the fork's config files must satisfy. Validate mechanically with `scripts\u002Fverify_custom_api.py`:\r\n\r\n- Pair each fork-only data file with upstream's current schema (`packages\u002Fschemas\u002F*.schema.json` or equivalent) and validate with `jsonschema`.\r\n- For custom files with **no** upstream schema, locate the governing TS\u002Fpy interface and diff the key set by hand. Check whether upstream parses it as `Partial\u003CT>` \u002F with defaults — if so, extra fork-only keys are a **safe extension**, not drift. If upstream does a strict parse, extra keys are a break.\r\n- The script falls back to a structural check (required keys, types, enums, `additionalProperties`) when `jsonschema` is unavailable, so it always yields a verdict.\r\n\r\n## Step 4 — Report honestly what was NOT verified\r\n\r\nA merge that compiles in your head is not a verified merge. State the residual risk explicitly:\r\n\r\n- `npm ci` \u002F `build` \u002F `lint` \u002F tests **not run** (e.g. no `node_modules`) → runtime regression unverified.\r\n- Lockfile taken from upstream → fork-specific deps may need reinstall.\r\n- Branch pushed, **not** merged to main.\r\n\r\nThen offer to run the build. Do not describe the merge as \"done\" when only the git operation is done.\r\n\r\n## Step 5 — Generic Harness Independence (Phase 2-4: after sync is stable)\r\n\r\nWhen the fork's goal shifts from \"track upstream\" to \"grow as an independent generic harness\" (e.g. `zapabob\u002Fhermes-agent-windows` as Windows AI workstation base, zero runtime dependency on `NousResearch\u002Fhermes-agent`), extend the lifecycle:\r\n\r\n### 5a. Brand-separation audit (Phase 2)\r\n\r\nBefore declaring independence, audit hard-coded upstream brand strings so future merges stay clean:\r\n\r\n```bash\r\n# Find residual brand references that would re-entangle merges\r\nrg -n \"NousResearch|nous-research|hermes-agent.*upstream\" --glob '!uv.lock' --glob '!*.bak'\r\n# Classify each hit: attribution (keep) vs. runtime dependency (remove)\r\n# Attribution stays in README\u002FLICENSE\u002FCARRY.yaml; runtime deps must be zero\r\npy -3 -c \"import tomllib; d=tomllib.load(open('pyproject.toml','rb')); print([x for x in d['project']['dependencies'] if 'nous' in x.lower()])\"\r\n# Expect [] — no PyPI dep on nous\r\n```\r\n\r\nRecord the result in `_docs\u002FYYYY-MM-DD_generic-harness-independence.md` and `fork\u002Fharness\u002FGENERIC_HARNESS.md` (the permanent harness definition). Patch `fork\u002FREADME.md` with an Identity block declaring `upstream = fetch-only, zero runtime dependency`.\r\n\r\n### 5b. Harness growth policy (Phase 3-4)\r\n\r\n- **Narrow waist**: keep `run_agent.py` \u002F `gateway\u002F` \u002F `tool registry` thin; new capability goes to `plugins\u002F` \u002F `skills\u002F` \u002F `downstream\u002F` (Footprint Ladder).\r\n- **Windows Tier-1**: any new feature touching paths\u002Fprocesses\u002FIPC must have a `WINDOWS_PLATFORM_CONTRACT.md` regression.\r\n- **Freeze gate**: when upstream stalls (90 days no `main` activity or architectural deadlock), freeze `UPSTREAM_SNAPSHOT.json` at the last SHA and archive `scripts\u002Fsync_all.py` — thereafter the fork owns its release cycle.\r\n- **A2A decision meetings**: when Phase 2 vs. expansion priority is contested, run a 4-perspective `delegate_task` batch (conservative \u002F expansion \u002F risk-CI \u002F operations) to force explicit trade-offs before committing. See `references\u002Fgeneric-harness-independence.md`.\r\n\r\n## Pitfalls\r\n\r\n- **A repo dir with the upstream URL in `origin` is not your fork.** Always `git remote -v` first; re-clone rather than repair.\r\n- **Shallow clones cannot merge** (`.git\u002Fshallow` present, no merge base). Re-clone with full history.\r\n- **Don't hand-resolve lockfile conflicts.** Take theirs and regenerate.\r\n- **Don't merge into `main` directly** on a 100+ commit catch-up. Dated merge branch + PR.\r\n- **Don't claim security fixes were pulled in** unless the commit classification actually found some.\r\n- **Windows:** the real interpreter is `py -3`; bare `python` may be the Microsoft Store stub. Invoke as `py -3 scripts\u002Fmerge_upstream.py`.\r\n- Write the implementation log to the **project's** `_docs\u002FYYYY-MM-DD_\u003Ctopic>_\u003CAI>.md` per the PC-wide AGENTS.md baseline, even when the merge itself happened in a scratch clone.\r\n- Committing the two scripts into the fork itself is a good outcome — it makes the next catch-up a one-command operation.\r\n\r\n## Bundled files\r\n\r\n- `scripts\u002Fmerge_upstream.py` — survey + policy-guarded merge + fork-file survival assertion.\r\n- `scripts\u002Fverify_custom_api.py` — validate fork-only JSON against upstream's current schemas; reports drift.\r\n",{"name":5,"author":44,"license":15,"version":45,"metadata":46,"platforms":54,"description":7},"Hermes Agent","1.0.0",{"hermes":47},{"tags":48,"related_skills":50},[28,38,49,21,23,37,34,35],"fork",[51,52,53],"git-pr-fork-routing","github-repo-management","github-pr-workflow",[36,29,25],"main","0d1434f89f4bc6b07e9d272accd8c1013768820f","archive\u002Fskill-md-reviewed\u002Fsha256\u002Fa5\u002Fa52f1522e68e3b748949b2bba2a2896765a975141ffb945edfcac2c2e4b5b25d",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":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add zapabob\u002FSkills --skill fork-upstream-sync",{"tool":69,"command":70},"bunx","bunx skills add zapabob\u002FSkills --skill fork-upstream-sync",{"tool":72,"command":73},"pnpm","pnpm dlx skills add zapabob\u002FSkills --skill fork-upstream-sync","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002Fa5\u002Fa52f1522e68e3b748949b2bba2a2896765a975141ffb945edfcac2c2e4b5b25d\u002FSKILL.md",true,[],[78,110,144,171,198,215],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":97,"publishedAt":39},"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",[84,89,92],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":90,"categoryName":91,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[80,98,29,99,38,36,25,100,101,102,103,104,105,30,31,106,55,107,108,109],"openclaw","cli","official","search","https","social-media","api","Media","twitter","social","via","post",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":127,"publishedAt":39},"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",[116,119,122,123,124],{"categoryNo":117,"categoryName":118,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":120,"categoryName":121,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":90,"categoryName":91,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},{"categoryNo":125,"categoryName":126,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000036","内容创作者",[128,129,130,131,29,132,36,24,25,133,134,135,136,137,138,139,140,141,142,143],"writing","writing plans","plans","design","review","documentation","tasks","development","code","planning","code-review","subagent","write","superpowers","paths","test-driven-development",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":153,"publishedAt":39},"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",[150],{"categoryNo":151,"categoryName":152,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000016","图像与多媒体",[146,29,36,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170],"openai","speech","multimodal","Transformers","ASR","Audio","text","model","speech recognition","use","general","multilingual","translation","english","identification","processing","Audio Processing",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":180,"publishedAt":39},"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",[177],{"categoryNo":178,"categoryName":179,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000013","分析与可视化",[181,29,182,183,25,184,185,186,187,188,189,161,190,191,192,193,194,195,196,197],"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":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":205,"publishedAt":39},"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",[204],{"categoryNo":90,"categoryName":91,"taxonomyType":87,"taxonomyTypeDesc":88},[200,29,206,38,36,207,208,209,210,211,212,30,31,213,214],"terminal","automation","http","monitoring","cron","json","rss","devops","with",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":223,"publishedAt":39},"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",[221,222],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},[224,225,226,36,227,154,228,229,230,157,231,104,232,233,234,235,236,237,238,239],"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"]