[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GH9TPBFDGS67DFF6QH4PE8":3,"skill-same:01M6GH9TPBFDGS67DFF6QH4PE8":79},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6GH9TPBFDGS67DFF6QH4PE8","agent-merge-conflict-arbiter",null,"Neutral arbiter for merge conflicts between two agents.","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\u002Ff8\u002Ff8b1a0cf2392a1da0d3890e1ebc6429b1edb83a8f076e104b8f7c8cb7465d1be\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"merge","Arbiter","conflict","agent merge conflict arbiter","macos","linux","windows","git","multi-agent","hermes","hermes agent","merge conflicts","kanban","conflicts","multi","hermes-agent","2026-11-10 10:12:30",false,"---\nname: agent-merge-conflict-arbiter\ndescription: \"Neutral arbiter for merge conflicts between two agents.\"\nversion: 1.0.0\nauthor: Hermes Agent\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [Multi-Agent, Git, Merge-Conflict, Kanban, Arbitration]\n    related_skills: [hermes-agent]\n---\n\n# Agent Merge-Conflict Arbiter\n\nResolve a git merge conflict between two AGENTS' branches as an impartial third\nparty. Agents resolving conflicts against a peer's work reliably either\noverwrite the peer or abandon their own change — they lack the peer's context\nand are biased toward their own side. This skill is the fix: a neutral\nreconciler that receives both diffs plus both sides' stated intents and\nproduces a merged result, like a merge-queue arbiter.\n\n## When to Use\n\n- Two agent branches\u002Fworktrees collide during a parallel campaign (kanban\n  engineering pipeline, parallel-PR wave, multi-worktree refactor).\n- `git merge` or `git rebase` halts on conflicts between two agents' work and\n  neither original agent should self-adjudicate.\n- Do NOT use for conflicts within a single agent's own work, or for trivial\n  lockfile\u002Fgenerated-file conflicts (regenerate those instead).\n\n## Prerequisites\n\n- A repo checkout containing the halted merge, or the two branch names plus\n  permission to run the merge yourself.\n- Both sides' intent sources: kanban completion summaries (`terminal` running\n  `hermes kanban show \u003Ctask-id>`), PR bodies, or at minimum each branch's\n  commit messages.\n- The project's build\u002Ftest command, if one exists.\n\n## How to Run\n\n**Standalone** — a human (or agent) invokes this skill inside the conflicted\nrepo: load the skill, then follow the Procedure top to bottom.\n\n**Spawned neutral agent** — the preferred shape in multi-agent campaigns:\n\n- `delegate_task`: spawn a subagent whose task message contains the repo path,\n  both branch names, and both sides' intent summaries verbatim, plus an\n  instruction to follow this skill.\n- Kanban-native: create a reconciliation card assigned to a **third profile**\n  (not either worker's profile) with BOTH conflicted cards linked as parents —\n  `kanban_create(title=\"reconcile branch-a x branch-b\", assignee=\"reconciler\",\n  parents=[\"t_a\", \"t_b\"])`. The parent links carry both sides' completion\n  summaries into the reconciler's context automatically; the card body should\n  name the repo path and the two branches.\n\n## Quick Reference\n\n| Hunk class | Definition | Resolution |\n|---|---|---|\n| disjoint-intent | The two changes serve different goals and can coexist | Combine both |\n| same-question-different-answer | Both sides answered one design question differently | Pick ONE per stated intents; surface the decision |\n| superseded | One side's premise no longer holds after the other's change | Keep the surviving side; note why |\n\nImpartiality contract: never favor the side that spawned you; touch ONLY\nconflicted regions (no drive-by edits); every design-question pick must appear\nexplicitly in the hand-back summary.\n\n## Procedure\n\n### 1. Gather both sides\n\n- Run via `terminal`: `git status` (confirm the conflicted state and list\n  conflicted files), `git merge-base \u003CA> \u003CB>`, then for each side\n  `git log --oneline \u003Cbase>..\u003Cside>` and `git diff \u003Cbase>..\u003Cside> -- \u003Cfile>`\n  for every conflicted file. In a halted merge, `HEAD` is one side and\n  `MERGE_HEAD` is the other.\n- Collect each side's intent: `hermes kanban show \u003Ctask-id>` for completion\n  summaries\u002Fmetadata, or the PR body, or the commit messages from the log\n  above. Write down one sentence of intent per side before touching any file.\n- Done when: you can state both intents in your own words and have both diffs\n  for every conflicted file.\n\n### 2. Classify every conflicted hunk\n\n- Open each conflicted file with `read_file` and locate each\n  `\u003C\u003C\u003C\u003C\u003C\u003C\u003C`\u002F`=======`\u002F`>>>>>>>` block.\n- Assign each hunk exactly one class from the Quick Reference table, judging\n  by the stated intents — not by which change looks nicer.\n- If a single hunk contains multiple independent decisions (e.g., new logic\n  that combines cleanly PLUS a styling\u002Frounding choice both sides answered\n  differently), decompose it into sub-decisions and classify each one.\n- A single file often mixes classes: one hunk may be a design collision while\n  a neighboring hunk is disjoint. Classify per hunk, not per file.\n- Done when: every hunk has a written class and a one-line rationale.\n\n### 3. Resolve under the impartiality contract\n\n- Edit each hunk with `patch` (or `write_file` for whole-file rewrites):\n  - disjoint-intent → merge both changes so each intent is fully served.\n  - same-question-different-answer → pick the answer that best serves the\n    STATED intents (e.g., an intent of \"strict validation\" beats \"quick\n    default\" if the task required correctness). Never split the difference\n    into a hybrid neither side asked for.\n  - superseded → keep the surviving side; delete the dead premise.\n- Never favor the side that spawned you. If intents genuinely tie, escalate\n  (block the kanban card \u002F report back) rather than guess.\n- Change nothing outside conflict markers — no formatting, renames, or\n  opportunistic fixes.\n- `git add` each resolved file via `terminal`.\n- Done when: `search_files` finds no `\u003C\u003C\u003C\u003C\u003C\u003C\u003C` markers in the repo and every\n  resolved file is staged.\n\n### 4. Verify\n\n- Run the project's build\u002Ftests via `terminal`; at minimum import\u002Fexecute the\n  touched modules. Both intents must be observable in the merged behavior\n  (e.g., side A's new semantics AND side B's disjoint addition both present).\n- Complete the merge: `git commit` (the default merge message plus a body\n  listing hunk decisions is fine).\n- Done when: verification passes and the merge commit exists.\n\n### 5. Hand back\n\n- Produce a completion summary naming EVERY hunk decision:\n  `file:lines — class — which side(s) kept — rationale`. For every\n  same-question-different-answer hunk, state the design question and the\n  answer you picked so a human can veto it — never bury a design call.\n- Kanban: `kanban_complete(summary=...)`. Standalone: print the summary.\n- Done when: the summary is delivered and lists all hunks.\n\n## Pitfalls\n\n- **Self-favoring**: if you were spawned by one of the conflicting agents,\n  you are structurally biased — state this and weigh the other side's intent\n  deliberately. Prefer the third-profile shape so this never arises.\n- **Splitting the difference** on a design collision produces a hybrid nobody\n  designed; pick one answer and surface it.\n- **Per-file classification**: files usually mix hunk classes; classifying a\n  whole file as one class silently drops a disjoint change.\n- **Drive-by edits** make the merge unreviewable and steal decisions from the\n  original agents.\n- **Missing intents**: commit messages alone can be thin; prefer kanban\n  completion summaries or PR bodies. If neither side's intent is recoverable,\n  escalate instead of guessing.\n- **Repeat offenders**: repeated conflicts on the SAME file across rounds are\n  a hotspot signal, not routine reconciliation work — flag it (e.g. a\n  `hotspot: \u003Cpath> — \u003Creason>` kanban comment) so the orchestrator decomposes\n  that file, rather than serially reconciling every new collision on it.\n\n## Verification\n\n- `git status` shows a clean tree on the target branch with a merge commit.\n- No conflict markers remain (`search_files` pattern `\u003C\u003C\u003C\u003C\u003C\u003C\u003C`).\n- Build\u002Ftests pass; both sides' intents are demonstrably present or the\n  dropped one is explicitly named in the summary.\n- The hand-back summary enumerates every hunk with class and rationale.\n","# Agent Merge-Conflict Arbiter\n\nResolve a git merge conflict between two AGENTS' branches as an impartial third\nparty. Agents resolving conflicts against a peer's work reliably either\noverwrite the peer or abandon their own change — they lack the peer's context\nand are biased toward their own side. This skill is the fix: a neutral\nreconciler that receives both diffs plus both sides' stated intents and\nproduces a merged result, like a merge-queue arbiter.\n\n## When to Use\n\n- Two agent branches\u002Fworktrees collide during a parallel campaign (kanban\n  engineering pipeline, parallel-PR wave, multi-worktree refactor).\n- `git merge` or `git rebase` halts on conflicts between two agents' work and\n  neither original agent should self-adjudicate.\n- Do NOT use for conflicts within a single agent's own work, or for trivial\n  lockfile\u002Fgenerated-file conflicts (regenerate those instead).\n\n## Prerequisites\n\n- A repo checkout containing the halted merge, or the two branch names plus\n  permission to run the merge yourself.\n- Both sides' intent sources: kanban completion summaries (`terminal` running\n  `hermes kanban show \u003Ctask-id>`), PR bodies, or at minimum each branch's\n  commit messages.\n- The project's build\u002Ftest command, if one exists.\n\n## How to Run\n\n**Standalone** — a human (or agent) invokes this skill inside the conflicted\nrepo: load the skill, then follow the Procedure top to bottom.\n\n**Spawned neutral agent** — the preferred shape in multi-agent campaigns:\n\n- `delegate_task`: spawn a subagent whose task message contains the repo path,\n  both branch names, and both sides' intent summaries verbatim, plus an\n  instruction to follow this skill.\n- Kanban-native: create a reconciliation card assigned to a **third profile**\n  (not either worker's profile) with BOTH conflicted cards linked as parents —\n  `kanban_create(title=\"reconcile branch-a x branch-b\", assignee=\"reconciler\",\n  parents=[\"t_a\", \"t_b\"])`. The parent links carry both sides' completion\n  summaries into the reconciler's context automatically; the card body should\n  name the repo path and the two branches.\n\n## Quick Reference\n\n| Hunk class | Definition | Resolution |\n|---|---|---|\n| disjoint-intent | The two changes serve different goals and can coexist | Combine both |\n| same-question-different-answer | Both sides answered one design question differently | Pick ONE per stated intents; surface the decision |\n| superseded | One side's premise no longer holds after the other's change | Keep the surviving side; note why |\n\nImpartiality contract: never favor the side that spawned you; touch ONLY\nconflicted regions (no drive-by edits); every design-question pick must appear\nexplicitly in the hand-back summary.\n\n## Procedure\n\n### 1. Gather both sides\n\n- Run via `terminal`: `git status` (confirm the conflicted state and list\n  conflicted files), `git merge-base \u003CA> \u003CB>`, then for each side\n  `git log --oneline \u003Cbase>..\u003Cside>` and `git diff \u003Cbase>..\u003Cside> -- \u003Cfile>`\n  for every conflicted file. In a halted merge, `HEAD` is one side and\n  `MERGE_HEAD` is the other.\n- Collect each side's intent: `hermes kanban show \u003Ctask-id>` for completion\n  summaries\u002Fmetadata, or the PR body, or the commit messages from the log\n  above. Write down one sentence of intent per side before touching any file.\n- Done when: you can state both intents in your own words and have both diffs\n  for every conflicted file.\n\n### 2. Classify every conflicted hunk\n\n- Open each conflicted file with `read_file` and locate each\n  `\u003C\u003C\u003C\u003C\u003C\u003C\u003C`\u002F`=======`\u002F`>>>>>>>` block.\n- Assign each hunk exactly one class from the Quick Reference table, judging\n  by the stated intents — not by which change looks nicer.\n- If a single hunk contains multiple independent decisions (e.g., new logic\n  that combines cleanly PLUS a styling\u002Frounding choice both sides answered\n  differently), decompose it into sub-decisions and classify each one.\n- A single file often mixes classes: one hunk may be a design collision while\n  a neighboring hunk is disjoint. Classify per hunk, not per file.\n- Done when: every hunk has a written class and a one-line rationale.\n\n### 3. Resolve under the impartiality contract\n\n- Edit each hunk with `patch` (or `write_file` for whole-file rewrites):\n  - disjoint-intent → merge both changes so each intent is fully served.\n  - same-question-different-answer → pick the answer that best serves the\n    STATED intents (e.g., an intent of \"strict validation\" beats \"quick\n    default\" if the task required correctness). Never split the difference\n    into a hybrid neither side asked for.\n  - superseded → keep the surviving side; delete the dead premise.\n- Never favor the side that spawned you. If intents genuinely tie, escalate\n  (block the kanban card \u002F report back) rather than guess.\n- Change nothing outside conflict markers — no formatting, renames, or\n  opportunistic fixes.\n- `git add` each resolved file via `terminal`.\n- Done when: `search_files` finds no `\u003C\u003C\u003C\u003C\u003C\u003C\u003C` markers in the repo and every\n  resolved file is staged.\n\n### 4. Verify\n\n- Run the project's build\u002Ftests via `terminal`; at minimum import\u002Fexecute the\n  touched modules. Both intents must be observable in the merged behavior\n  (e.g., side A's new semantics AND side B's disjoint addition both present).\n- Complete the merge: `git commit` (the default merge message plus a body\n  listing hunk decisions is fine).\n- Done when: verification passes and the merge commit exists.\n\n### 5. Hand back\n\n- Produce a completion summary naming EVERY hunk decision:\n  `file:lines — class — which side(s) kept — rationale`. For every\n  same-question-different-answer hunk, state the design question and the\n  answer you picked so a human can veto it — never bury a design call.\n- Kanban: `kanban_complete(summary=...)`. Standalone: print the summary.\n- Done when: the summary is delivered and lists all hunks.\n\n## Pitfalls\n\n- **Self-favoring**: if you were spawned by one of the conflicting agents,\n  you are structurally biased — state this and weigh the other side's intent\n  deliberately. Prefer the third-profile shape so this never arises.\n- **Splitting the difference** on a design collision produces a hybrid nobody\n  designed; pick one answer and surface it.\n- **Per-file classification**: files usually mix hunk classes; classifying a\n  whole file as one class silently drops a disjoint change.\n- **Drive-by edits** make the merge unreviewable and steal decisions from the\n  original agents.\n- **Missing intents**: commit messages alone can be thin; prefer kanban\n  completion summaries or PR bodies. If neither side's intent is recoverable,\n  escalate instead of guessing.\n- **Repeat offenders**: repeated conflicts on the SAME file across rounds are\n  a hotspot signal, not routine reconciliation work — flag it (e.g. a\n  `hotspot: \u003Cpath> — \u003Creason>` kanban comment) so the orchestrator decomposes\n  that file, rather than serially reconciling every new collision on it.\n\n## Verification\n\n- `git status` shows a clean tree on the target branch with a merge commit.\n- No conflict markers remain (`search_files` pattern `\u003C\u003C\u003C\u003C\u003C\u003C\u003C`).\n- Build\u002Ftests pass; both sides' intents are demonstrably present or the\n  dropped one is explicitly named in the summary.\n- The hand-back summary enumerates every hunk with class and rationale.\n",{"name":5,"author":45,"license":15,"version":46,"metadata":47,"platforms":56,"description":7},"Hermes Agent","1.0.0",{"hermes":48},{"tags":49,"related_skills":55},[50,51,52,53,54],"Multi-Agent","Git","Merge-Conflict","Kanban","Arbitration",[39],[29,28,30],"main","0d1434f89f4bc6b07e9d272accd8c1013768820f","archive\u002Fskill-md-reviewed\u002Fsha256\u002Ff8\u002Ff8b1a0cf2392a1da0d3890e1ebc6429b1edb83a8f076e104b8f7c8cb7465d1be",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":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add zapabob\u002FSkills --skill agent-merge-conflict-arbiter",{"tool":71,"command":72},"bunx","bunx skills add zapabob\u002FSkills --skill agent-merge-conflict-arbiter",{"tool":74,"command":75},"pnpm","pnpm dlx skills add zapabob\u002FSkills --skill agent-merge-conflict-arbiter","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002Ff8\u002Ff8b1a0cf2392a1da0d3890e1ebc6429b1edb83a8f076e104b8f7c8cb7465d1be\u002FSKILL.md",true,[],[80,109,144,171,198,215],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":95,"publishedAt":40},"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",[86,89,90],{"categoryNo":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[82,96,28,97,98,29,30,99,100,101,102,103,104,33,34,105,57,106,107,108],"openclaw","cli","github","official","search","https","social-media","api","Media","twitter","social","via","post",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":126,"publishedAt":40},"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",[115,118,121,122,123],{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},{"categoryNo":124,"categoryName":125,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000036","内容创作者",[127,128,129,130,28,131,29,132,30,133,134,135,136,137,138,139,140,141,142,143],"writing","writing plans","plans","design","review","workflow","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":40},"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":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[146,28,29,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":40},"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":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",[181,28,182,183,30,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":40},"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":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[200,28,206,98,29,207,208,209,210,211,212,33,34,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":40},"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":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},[224,225,226,29,227,154,228,229,230,157,231,103,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"]