[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6G9CATTGF7XDWYV8PVD0YA5":3,"skill-same:01M6G9CATTGF7XDWYV8PVD0YA5":76},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6G9CATTGF7XDWYV8PVD0YA5","self-improver-operations",null,"Curator runs and skill upkeep for self-improver.","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\u002F77\u002F770473306039049f04f4a8d2a52fa84c4064739f674108fd05655cf4232c9620\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],"operations","self","self improver operations","macos","linux","windows","verification","cron","hermes","hermes agent","devops","maintenance","org","hermes-agent","2026-11-10 10:12:30",false,"---\r\nname: self-improver-operations\r\ndescription: \"Curator runs and skill upkeep for self-improver.\"\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: [curator, skill-maintenance, self-improver, cron, verification]\r\n    category: devops\r\n    related_skills: [ai-employee-org, hermes-agent]\r\n---\r\n\r\n# Self-Improver Operations\r\n\r\nSkill maintenance and curator workflows for the self-improver profile.\r\nCovers the weekly review cycle, ad-hoc skill verification, and Windows\r\ncron pitfalls that affect autonomous maintenance jobs.\r\n\r\n## When to Use\r\n\r\n- Running the self-improver weekly\u002Fcron review: liveness check → cron census →\r\n  curator run record → warning log review → skill patching → report\r\n- Verifying SKILL.md frontmatter and structure after patches\r\n- Triaging cron job failures on Windows — auth-retry loops, `[drift_skip]`,\r\n  profile-scoped `cron status` misleading you\r\n- Deciding what is safe to fix autonomously vs. what needs human approval\r\n- Debugging cron job failures on Windows (inline Python blocked, path issues)\r\n\r\n## Prerequisites\r\n\r\n- Hermes profile `self-improver` created and configured\r\n- `curator.enabled: true` in `~\u002F.hermes\u002Fconfig.yaml`\r\n- API key set for the auxiliary model used by curator LLM review\r\n\r\n## Weekly Review Procedure\r\n\r\nRun in this order. Steps 1–3 are file-first on purpose: the CLI equivalents are\r\nslow and profile-scoped (see Pitfalls), and a wrong-but-plausible CLI answer\r\nsent a whole review in the wrong direction on 2026-10-02.\r\n\r\n1. **Establish liveness first** — `read_file`\r\n   `%USERPROFILE%\u002F.hermes\u002Fcron\u002Fticker_heartbeat` and `ticker_last_success`\r\n   (epoch floats). If these are recent, the scheduler is alive; do **not**\r\n   infer a dead gateway from any CLI warning.\r\n2. **Census cron via `search_files` counts** over\r\n   `%USERPROFILE%\u002F.hermes\u002Fcron\u002Fjobs.json` (see the pattern table below), then\r\n   pull context for anything with a live `failure_streak`.\r\n3. **Read the newest curator `run.json`** at\r\n   `~\u002F.hermes\u002Fprofiles\u002Fself-improver\u002Flogs\u002Fcurator\u002F\u003Cnewest>\u002Frun.json` —\r\n   authoritative for `auto_transitions`, `tool_calls_total`, and `llm_final`.\r\n4. **Only then** try `hermes curator status` \u002F `hermes curator run` if a live\r\n   view is genuinely needed — and expect the 420s cap.\r\n5. Read the Cursor learning inbox (`%USERPROFILE%\u002FDocuments\u002Fops\u002Fcursor-learning-inbox\u002F*.md`)\r\n   — process or move to `processed\u002F`\r\n6. Patch up to 3 agent-created skills (description trim, pitfalls, platforms)\r\n7. Write report to `_docs\u002FYYYY-MM-DD_self-review.md`\r\n8. If headless: surface destructive items (cron pause\u002Fedit, DB or log removal,\r\n   config mutation) as **explicit human-approval requests** in the handoff.\r\n   Do not apply them; see \"Reporting under a no-destroy constraint\" below.\r\n\r\n## Ad-hoc Skill Verification\r\n\r\nAfter patching SKILL.md files, run a quick frontmatter + structure check.\r\nSee `scripts\u002Fverify-skills.py` for the reusable verification script.\r\n\r\nChecks to run:\r\n- SKILL.md exists in expected skill directory\r\n- Frontmatter block present (--- delimited)\r\n- `description:` field present and ≤60 characters\r\n- `platforms:` field present when applicable\r\n- Required sections present (Pitfalls, Verification, etc.)\r\n- No leftover temp files in workspace\r\n\r\n## Quick Reference\r\n\r\n| Task | Command |\r\n|---|---|\r\n| Check curator state | `hermes curator status` (may hang — see Pitfalls) |\r\n| Read curator last run | `read_file ~\u002F.hermes\u002Fprofiles\u002Fself-improver\u002Flogs\u002Fcurator\u002F\u003Cnewest>\u002Frun.json` |\r\n| Run curator review | `hermes curator run` |\r\n| Check cron liveness | `read_file %USERPROFILE%\u002F.hermes\u002Fcron\u002Fticker_heartbeat` (epoch float) |\r\n| Read all cron jobs | `read_file %USERPROFILE%\u002F.hermes\u002Fcron\u002Fjobs.json` (profile-scoped CLI lies) |\r\n| Check warnings | `hermes logs --level WARNING` |\r\n| Patch a skill | `skill_manage(action='patch', name='...', old_string='...', new_string='...')` |\r\n| Verify patches | `python scripts\u002Fverify-skills.py` |\r\n\r\n## Cron health census (no CLI, no scripts)\r\n\r\nThe reliable way to inventory cron on this host is `search_files` counts over\r\n`%USERPROFILE%\u002F.hermes\u002Fcron\u002Fjobs.json` — each pattern maps to one metric:\r\n\r\n| Pattern (as a regex) | Metric |\r\n|---|---|\r\n| `\"id\": \"[0-9a-f]{12}\"` | total registered jobs |\r\n| `\"enabled\": true` | active jobs |\r\n| `\"state\": \"paused\"` | paused jobs |\r\n| `\"state\": \"error\"` | jobs in error state |\r\n| `\"last_status\": \"ok\"` | last run succeeded |\r\n| `\"last_status\": \"(error\\|failed)\"` | last run failed |\r\n| `\"last_run_at\": \"2026-10-..` | jobs that fired in a window |\r\n| `\"failure_streak\": [1-9][0-9]*` | jobs with a live failure streak |\r\n| `\"drift_alerted\": true` | jobs the drift guard already warned about |\r\n| `\"preflight_alerted\": true` | jobs already reported as blocked_config |\r\n\r\n`failure_streak` is the priority sort key: a job with a streak in the\r\nhundreds is burning a schedule slot every run and deserves a human decision\r\nbefore anything with a single-digit streak.\r\n\r\n## Reporting under a no-destroy constraint\r\n\r\nMost reviews run with an explicit \"no destructive changes, no cron\r\npause\u002Fedit, no DB deletion — surface items needing human approval\" rule. That\r\nconstraint is not a limitation to apologise for; it is the shape of the\r\ndeliverable. The output is **a precise, ranked decision queue**, not a\r\nhalf-applied fix.\r\n\r\nHow to make it maximally useful to the human who unblocks it:\r\n\r\n1. **Rank by real harm, not by discovery order.** A job with\r\n   `failure_streak: 1278` on a 20-minute schedule outranks everything with a\r\n   single-digit streak. Sort by consequence.\r\n2. **Attach a concrete fix command per item**, copied from the job's own error\r\n   message where it provides one (Hermes drift guards embed the exact\r\n   `hermes cron edit \u003Cid> --provider \u003Cprovider> --model \u003Cmodel>` to run).\r\n   A recommendation without a copy-pasteable command costs the human a lookup.\r\n3. **State the human-time cost** where it is the real blocker — e.g. \"MCP\r\n   `notion`\u002F`linear`\u002F`figma` are parked on `OAuthNonInteractiveError`, which is\r\n   impossible to clear headless; it needs ~3 min of interactive\r\n   `hermes mcp login`.\" That converts \"stuck\" into \"here is your queue\".\r\n4. **Distinguish \"measured\" from \"could not measure\".** If `du -sm` timed out or\r\n   `curator status` exceeded the cap, say so in a dedicated section. A silently\r\n   narrowed claim is worse than an acknowledged gap.\r\n5. **Name leftover artifacts explicitly** (quarantined files, unverified\r\n   counts) in the handoff `not_done` field so the next session inherits the\r\n   truth instead of rediscovering it.\r\n6. **Carry forward corrections, don't quietly overwrite them.** When a prior\r\n   report's headline finding is falsified, put the retraction in its own\r\n   section at the top with the evidence that overturned it. Silently\r\n   correcting it destroys the audit trail and leaves the reader unsure whether\r\n   the old claim was ever checked.\r\n\r\n## Pitfalls\r\n\r\n### Windows cron job constraints\r\n\r\n- **Inline Python blocked**: `python -c \"...\"` is flagged as dangerous in\r\n  cron mode (no user present to approve). Write scripts to a file first with\r\n  `write_file`, then execute via `terminal(command=\"python path\u002Fto\u002Fscript.py\")`.\r\n- **Security Center blocks ad-hoc scripts (second gate)**: the write-then-run\r\n  workaround above is NOT sufficient. A `write_file`-created `.py` under a\r\n  gitignored dir (`tmp\u002Fprobes\u002F`) is rejected with\r\n  `Security Center blocked a unverified execution candidate: \u003Cpath> (SCAN_ERROR, score 0)`,\r\n  and `uv run python \u003Cpath>` is blocked identically. **Do not fight this gate.**\r\n  Read state with `read_file` \u002F `search_files`, and prefer the Hermes CLI\r\n  (`hermes curator usage`, `hermes curator list-archived`) over a hand-rolled\r\n  parser. See `references\u002Fsecurity-center-script-block.md`.\r\n- **A blocked script path becomes UNDELETABLE — never create one in a Kanban\r\n  workspace.** Confirmed 2026-10-02: after a `write_file` probe was refused\r\n  execution, every `terminal` command *naming that path* was refused too,\r\n  including `rm -f`, `find -delete`, and `rm` with an absolute path. The file\r\n  could not be removed for the rest of the run and had to be left to workspace\r\n  GC or a foreground operator. `read_file` \u002F `ls` on the same path still work,\r\n  so the block is easy to mistake for a transient. **The write is what creates\r\n  the trap**: in headless Kanban mode, go straight to the `search_files` census\r\n  in SKILL.md and never write an executable probe. If one already exists, cap\r\n  retries at one and name the leftover in the handoff.\r\n- **Long CLI commands need `background=true`**: `hermes curator status` and\r\n  `hermes logs --level WARNING` each take 60-120s+ on this host (cold import +\r\n  Bitwarden warnings). A foreground call with `timeout=120` can hit exit 124.\r\n  Launch them backgrounded and `process(action='wait')` instead.\r\n- **`process(action='wait'\u002F'poll')` can also hang past its own timeout**: on\r\n  this host the process tool itself timed out at 420s waiting on the very\r\n  commands the note above tells you to background. Do not burn three retries\r\n  on it — fall back to reading state files directly (see below), and treat\r\n  `execute_code`, `python -c`, and bash heredocs as **blocked** in headless\r\n  single-query mode (`approvals.single_query_mode`). The only script route\r\n  that survives is the Security-Center-approved one, which is usually not\r\n  worth fighting. State-file reads via `read_file` \u002F `search_files` \u002F\r\n  `stat` + `tail` cover the same ground.\r\n- **`hermes cron status` \u002F `hermes cron list` are PROFILE-SCOPED**: run from\r\n  the `self-improver` profile they resolve to\r\n  `~\u002F.hermes\u002Fprofiles\u002Fself-improver\u002Fcron\u002F`, which holds **zero** jobs, and\r\n  report `No scheduled jobs` \u002F `cron jobs will NOT fire`. The real jobs\r\n  (59 enabled of 71) live in the **default** profile at\r\n  `%USERPROFILE%\u002F.hermes\u002Fcron\u002Fjobs.json`. **Falsified diagnosis caught\r\n  here on 2026-10-02**: a prior review reported \"Gateway stopped, cron will\r\n  NOT fire\" as P0 based on that output — the gateway was actually running.\r\n  Never trust `cron status` output without confirming which profile it\r\n  resolved. Read `~\u002F.hermes\u002Fcron\u002Fjobs.json` for ground truth.\r\n- **`last_error` is HISTORIC, not current**: cron never clears it after a\r\n  later success. Seven jobs still carried\r\n  `Failed to compute next run ... (is the 'croniter' package installed?)`\r\n  from an old incident while actually running fine. Diagnose with the\r\n  **triple**: `last_status` AND `next_run_at` AND `fire_claim`. A non-null\r\n  `last_error` alone proves nothing about current health.\r\n- **Ticker liveness is the fastest health check**: read\r\n  `~\u002F.hermes\u002Fcron\u002Fticker_heartbeat` and `ticker_last_success` (epoch floats).\r\n  Age in seconds = seconds since last tick. This is a two-`read_file` check\r\n  that avoids the slow CLI entirely, and it is authoritative.\r\n- **`hermes curator status` hangs past the 420s tool cap on this host**:\r\n  the fallback is reading the newest\r\n  `~\u002F.hermes\u002Fprofiles\u002Fself-improver\u002Flogs\u002Fcurator\u002F\u003Cts>\u002Frun.json` directly.\r\n  It carries `duration_seconds`, `auto_transitions` (marked_stale \u002F\r\n  archived), `counts.tool_calls_total`, and `llm_final` — enough to tell\r\n  whether the auto pass ran even when the LLM pass 404'd.\r\n- **`\u002Ftmp\u002F` path mismatch**: git-bash `\u002Ftmp\u002F` resolves to a real path on\r\n  Windows, but Windows-native Python cannot find files written there via\r\n  bash. Use workspace-relative paths (`C:\u002FUsers\u002F\u003Cuser>\u002FDocuments\u002Fops\u002F`) or\r\n  `$TEMP` for temp scripts in cron jobs.\r\n- **Cron path guard blocks `rm \u002Ftmp\u002F`**: Cleanup of `\u002Ftmp\u002F` files is blocked\r\n  by the cron safety guard. Accept the leftover or clean manually in a\r\n  non-cron session.\r\n- **A whole-run tool-layer outage is possible, not just a slow CLI.** Observed\r\n  2026-10-04: every filesystem\u002Fshell tool call — `terminal` (including a\r\n  3-character `echo hi`), `read_file`, `write_file`, `search_files` — failed\r\n  instantly with `RuntimeError: Windows terminal command length exceeds safe\r\n  limit`. The message is **misleading**: it names command length, but it fired\r\n  on all tools and all payload sizes, including `read_file` which sends no\r\n  command at all. `skill_view` \u002F `skill_manage` kept working, so the fault is\r\n  in the shell\u002Ffilesystem dispatch path, not the whole runtime.\r\n  **Do not burn the run retrying it** — after `echo hi` fails, the outage is\r\n  confirmed; further identical retries only trip the loop guard. Fall back to:\r\n  (a) report the outage plainly, (b) apply only `skill_manage` work that is\r\n  safe without verification, (c) leave `_docs\u002F` for the next healthy run\r\n  rather than assuming `write_file` succeeded — it did not.\r\n- **Missing skill on a scheduled job is not a blocker**: if the job's skill\r\n  list names a skill that is absent from disk, report it in the summary and\r\n  continue with the remaining procedure. Do not create a replacement umbrella\r\n  for a single skipped reference.\r\n\r\n### Recurring config defects (fix in config, not per-job)\r\n\r\n- **A cron `skill:` naming a PROFILE is a latent defect.** Observed on\r\n  2026-10-02: `320b7b876e04` (self-improver-weekly-review) carries\r\n  `skill: \"self-improver\"`, and `842f96e965de` carries\r\n  `skill: \"delivery-worker\"` — both are *profile* names, not skills. A skill\r\n  of that name does not exist, so the load silently yields nothing. Real\r\n  alternatives: `self-improver-operations` for self-improver,\r\n  `delivery-worker`-adjacent review skills for delivery-worker. This is a\r\n  recurring template bug in the cron *creator*, not a one-off — check it on\r\n  every review and prefer fixing the creating template.\r\n- **`auxiliary.\u003Crole>.model: ''` makes drift guards misfire.** With\r\n  `curator.provider: auto` and an empty model, the role inherits the global\r\n  inference config; when that global changes, every unpinned job trips\r\n  `[drift_skip:silent]` and is skipped to avoid unintended spend. The fix is\r\n  either pin the job (`hermes cron edit \u003Cid> --provider\u002F--model`) or pin the\r\n  role in config. Both change cost\u002Fmodel behaviour, so both need human\r\n  approval — surface them, never apply them autonomously.\r\n- **A job whose auth prerequisite is missing retries forever.** Seen:\r\n  `510d48c0c367` (Google Workspace token refresh, every 20m) reached\r\n  `failure_streak: 1278` purely because `google_token.json` never appeared.\r\n  Cron has no `blocked_config` equivalent to stop it. When reporting, rank\r\n  by streak and recommend pause-with-reason rather than \"keep retrying\".\r\n\r\n### Skill authoring standards (quick reference)\r\n\r\n- `description:` ≤ 60 characters, one sentence, ends with period\r\n- No marketing words (\"powerful\", \"comprehensive\", \"seamless\")\r\n- `platforms:` must match actual script imports (POSIX-only = linux\u002Fmacos)\r\n- `created_by: agent` in usage.json determines if curator can auto-manage\r\n- Bundled\u002Fhub-installed skills are off-limits to autonomous curation\r\n\r\n### Curator quirks\r\n\r\n- **The LLM pass is optional — auto-transitions still run.** A failed LLM\r\n  review does not abort the run. The pure time-based pass (mark-stale at 30d,\r\n  archive at 90d) is separate and always executes. A 404 or provider stall\r\n  therefore still yields a real, non-empty result; report it as\r\n  \"LLM pass skipped, auto pass applied\", not as a failed run.\r\n- **HTTP 404 = wrong model\u002Froute, not a bad API key.** Seen twice\r\n  (2026-09-27): `llm: API call failed after 2 retries: HTTP 404: 404 page not\r\n  found`, where `REPORT.md` names\r\n  `custom:127.0.0.1-8080\u002Fqwen3.8-27b-abliterated-mtp` via `nvidia`. A 404 is\r\n  the endpoint rejecting the *path\u002Fmodel*, so no amount of key rotation fixes\r\n  it. Earlier a stall appeared instead: `Provider has been unresponsive ... for\r\n  7 consecutive stale attempts`. Check the configured auxiliary model resolves\r\n  before blaming credentials.\r\n- **When the LLM pass fails, consolidation silently does not happen.**\r\n  `consolidate: on` is reported in `curator status`, but with 0 tool calls the\r\n  run consolidates nothing. Duplicate\u002Foverlapping agent skills will keep\r\n  accumulating until the auxiliary model is fixed — this is the main reason\r\n  the managed-skill count drifts upward.\r\n- **A 30-day-idle profile re-stales in bulk.** A 27-day gap since the last run\r\n  meant every skill past 30d flipped at once (26 stale + 11 archived in one\r\n  29-second run). That is expected behaviour, not a bug, but review the newly\r\n  archived list before the gap grows again — recovery is\r\n  `hermes curator restore \u003Cname>`.\r\n- Pinned skills are exempt from all auto-transitions and LLM review.\r\n\r\n## Verification\r\n\r\nAfter any skill patch session:\r\n1. Re-load the skill with `skill_view(name)` and read the rendered content —\r\n   confirm each intended section is actually present and correctly nested.\r\n   This is the only reliable check when `scripts\u002Fverify-skills.py` cannot run\r\n   headless (it hits the same Security Center gate as any other script).\r\n2. **List the workspace directory** (`ls -la`) and confirm no leftover temp\r\n   files. If a probe path has been quarantined, `ls` still works even though\r\n   `rm` does not — so this check catches what the blocked `rm` cannot report.\r\n3. Confirm the report file exists at its `_docs\u002F` path and is non-trivial in\r\n   size (a stub or a truncated write is worse than nothing).\r\n4. Check `hermes curator status` for incremented patch counts — only if it\r\n   completes inside the 420s cap; otherwise read the next `run.json` later.\r\n","# Self-Improver Operations\r\n\r\nSkill maintenance and curator workflows for the self-improver profile.\r\nCovers the weekly review cycle, ad-hoc skill verification, and Windows\r\ncron pitfalls that affect autonomous maintenance jobs.\r\n\r\n## When to Use\r\n\r\n- Running the self-improver weekly\u002Fcron review: liveness check → cron census →\r\n  curator run record → warning log review → skill patching → report\r\n- Verifying SKILL.md frontmatter and structure after patches\r\n- Triaging cron job failures on Windows — auth-retry loops, `[drift_skip]`,\r\n  profile-scoped `cron status` misleading you\r\n- Deciding what is safe to fix autonomously vs. what needs human approval\r\n- Debugging cron job failures on Windows (inline Python blocked, path issues)\r\n\r\n## Prerequisites\r\n\r\n- Hermes profile `self-improver` created and configured\r\n- `curator.enabled: true` in `~\u002F.hermes\u002Fconfig.yaml`\r\n- API key set for the auxiliary model used by curator LLM review\r\n\r\n## Weekly Review Procedure\r\n\r\nRun in this order. Steps 1–3 are file-first on purpose: the CLI equivalents are\r\nslow and profile-scoped (see Pitfalls), and a wrong-but-plausible CLI answer\r\nsent a whole review in the wrong direction on 2026-10-02.\r\n\r\n1. **Establish liveness first** — `read_file`\r\n   `%USERPROFILE%\u002F.hermes\u002Fcron\u002Fticker_heartbeat` and `ticker_last_success`\r\n   (epoch floats). If these are recent, the scheduler is alive; do **not**\r\n   infer a dead gateway from any CLI warning.\r\n2. **Census cron via `search_files` counts** over\r\n   `%USERPROFILE%\u002F.hermes\u002Fcron\u002Fjobs.json` (see the pattern table below), then\r\n   pull context for anything with a live `failure_streak`.\r\n3. **Read the newest curator `run.json`** at\r\n   `~\u002F.hermes\u002Fprofiles\u002Fself-improver\u002Flogs\u002Fcurator\u002F\u003Cnewest>\u002Frun.json` —\r\n   authoritative for `auto_transitions`, `tool_calls_total`, and `llm_final`.\r\n4. **Only then** try `hermes curator status` \u002F `hermes curator run` if a live\r\n   view is genuinely needed — and expect the 420s cap.\r\n5. Read the Cursor learning inbox (`%USERPROFILE%\u002FDocuments\u002Fops\u002Fcursor-learning-inbox\u002F*.md`)\r\n   — process or move to `processed\u002F`\r\n6. Patch up to 3 agent-created skills (description trim, pitfalls, platforms)\r\n7. Write report to `_docs\u002FYYYY-MM-DD_self-review.md`\r\n8. If headless: surface destructive items (cron pause\u002Fedit, DB or log removal,\r\n   config mutation) as **explicit human-approval requests** in the handoff.\r\n   Do not apply them; see \"Reporting under a no-destroy constraint\" below.\r\n\r\n## Ad-hoc Skill Verification\r\n\r\nAfter patching SKILL.md files, run a quick frontmatter + structure check.\r\nSee `scripts\u002Fverify-skills.py` for the reusable verification script.\r\n\r\nChecks to run:\r\n- SKILL.md exists in expected skill directory\r\n- Frontmatter block present (--- delimited)\r\n- `description:` field present and ≤60 characters\r\n- `platforms:` field present when applicable\r\n- Required sections present (Pitfalls, Verification, etc.)\r\n- No leftover temp files in workspace\r\n\r\n## Quick Reference\r\n\r\n| Task | Command |\r\n|---|---|\r\n| Check curator state | `hermes curator status` (may hang — see Pitfalls) |\r\n| Read curator last run | `read_file ~\u002F.hermes\u002Fprofiles\u002Fself-improver\u002Flogs\u002Fcurator\u002F\u003Cnewest>\u002Frun.json` |\r\n| Run curator review | `hermes curator run` |\r\n| Check cron liveness | `read_file %USERPROFILE%\u002F.hermes\u002Fcron\u002Fticker_heartbeat` (epoch float) |\r\n| Read all cron jobs | `read_file %USERPROFILE%\u002F.hermes\u002Fcron\u002Fjobs.json` (profile-scoped CLI lies) |\r\n| Check warnings | `hermes logs --level WARNING` |\r\n| Patch a skill | `skill_manage(action='patch', name='...', old_string='...', new_string='...')` |\r\n| Verify patches | `python scripts\u002Fverify-skills.py` |\r\n\r\n## Cron health census (no CLI, no scripts)\r\n\r\nThe reliable way to inventory cron on this host is `search_files` counts over\r\n`%USERPROFILE%\u002F.hermes\u002Fcron\u002Fjobs.json` — each pattern maps to one metric:\r\n\r\n| Pattern (as a regex) | Metric |\r\n|---|---|\r\n| `\"id\": \"[0-9a-f]{12}\"` | total registered jobs |\r\n| `\"enabled\": true` | active jobs |\r\n| `\"state\": \"paused\"` | paused jobs |\r\n| `\"state\": \"error\"` | jobs in error state |\r\n| `\"last_status\": \"ok\"` | last run succeeded |\r\n| `\"last_status\": \"(error\\|failed)\"` | last run failed |\r\n| `\"last_run_at\": \"2026-10-..` | jobs that fired in a window |\r\n| `\"failure_streak\": [1-9][0-9]*` | jobs with a live failure streak |\r\n| `\"drift_alerted\": true` | jobs the drift guard already warned about |\r\n| `\"preflight_alerted\": true` | jobs already reported as blocked_config |\r\n\r\n`failure_streak` is the priority sort key: a job with a streak in the\r\nhundreds is burning a schedule slot every run and deserves a human decision\r\nbefore anything with a single-digit streak.\r\n\r\n## Reporting under a no-destroy constraint\r\n\r\nMost reviews run with an explicit \"no destructive changes, no cron\r\npause\u002Fedit, no DB deletion — surface items needing human approval\" rule. That\r\nconstraint is not a limitation to apologise for; it is the shape of the\r\ndeliverable. The output is **a precise, ranked decision queue**, not a\r\nhalf-applied fix.\r\n\r\nHow to make it maximally useful to the human who unblocks it:\r\n\r\n1. **Rank by real harm, not by discovery order.** A job with\r\n   `failure_streak: 1278` on a 20-minute schedule outranks everything with a\r\n   single-digit streak. Sort by consequence.\r\n2. **Attach a concrete fix command per item**, copied from the job's own error\r\n   message where it provides one (Hermes drift guards embed the exact\r\n   `hermes cron edit \u003Cid> --provider \u003Cprovider> --model \u003Cmodel>` to run).\r\n   A recommendation without a copy-pasteable command costs the human a lookup.\r\n3. **State the human-time cost** where it is the real blocker — e.g. \"MCP\r\n   `notion`\u002F`linear`\u002F`figma` are parked on `OAuthNonInteractiveError`, which is\r\n   impossible to clear headless; it needs ~3 min of interactive\r\n   `hermes mcp login`.\" That converts \"stuck\" into \"here is your queue\".\r\n4. **Distinguish \"measured\" from \"could not measure\".** If `du -sm` timed out or\r\n   `curator status` exceeded the cap, say so in a dedicated section. A silently\r\n   narrowed claim is worse than an acknowledged gap.\r\n5. **Name leftover artifacts explicitly** (quarantined files, unverified\r\n   counts) in the handoff `not_done` field so the next session inherits the\r\n   truth instead of rediscovering it.\r\n6. **Carry forward corrections, don't quietly overwrite them.** When a prior\r\n   report's headline finding is falsified, put the retraction in its own\r\n   section at the top with the evidence that overturned it. Silently\r\n   correcting it destroys the audit trail and leaves the reader unsure whether\r\n   the old claim was ever checked.\r\n\r\n## Pitfalls\r\n\r\n### Windows cron job constraints\r\n\r\n- **Inline Python blocked**: `python -c \"...\"` is flagged as dangerous in\r\n  cron mode (no user present to approve). Write scripts to a file first with\r\n  `write_file`, then execute via `terminal(command=\"python path\u002Fto\u002Fscript.py\")`.\r\n- **Security Center blocks ad-hoc scripts (second gate)**: the write-then-run\r\n  workaround above is NOT sufficient. A `write_file`-created `.py` under a\r\n  gitignored dir (`tmp\u002Fprobes\u002F`) is rejected with\r\n  `Security Center blocked a unverified execution candidate: \u003Cpath> (SCAN_ERROR, score 0)`,\r\n  and `uv run python \u003Cpath>` is blocked identically. **Do not fight this gate.**\r\n  Read state with `read_file` \u002F `search_files`, and prefer the Hermes CLI\r\n  (`hermes curator usage`, `hermes curator list-archived`) over a hand-rolled\r\n  parser. See `references\u002Fsecurity-center-script-block.md`.\r\n- **A blocked script path becomes UNDELETABLE — never create one in a Kanban\r\n  workspace.** Confirmed 2026-10-02: after a `write_file` probe was refused\r\n  execution, every `terminal` command *naming that path* was refused too,\r\n  including `rm -f`, `find -delete`, and `rm` with an absolute path. The file\r\n  could not be removed for the rest of the run and had to be left to workspace\r\n  GC or a foreground operator. `read_file` \u002F `ls` on the same path still work,\r\n  so the block is easy to mistake for a transient. **The write is what creates\r\n  the trap**: in headless Kanban mode, go straight to the `search_files` census\r\n  in SKILL.md and never write an executable probe. If one already exists, cap\r\n  retries at one and name the leftover in the handoff.\r\n- **Long CLI commands need `background=true`**: `hermes curator status` and\r\n  `hermes logs --level WARNING` each take 60-120s+ on this host (cold import +\r\n  Bitwarden warnings). A foreground call with `timeout=120` can hit exit 124.\r\n  Launch them backgrounded and `process(action='wait')` instead.\r\n- **`process(action='wait'\u002F'poll')` can also hang past its own timeout**: on\r\n  this host the process tool itself timed out at 420s waiting on the very\r\n  commands the note above tells you to background. Do not burn three retries\r\n  on it — fall back to reading state files directly (see below), and treat\r\n  `execute_code`, `python -c`, and bash heredocs as **blocked** in headless\r\n  single-query mode (`approvals.single_query_mode`). The only script route\r\n  that survives is the Security-Center-approved one, which is usually not\r\n  worth fighting. State-file reads via `read_file` \u002F `search_files` \u002F\r\n  `stat` + `tail` cover the same ground.\r\n- **`hermes cron status` \u002F `hermes cron list` are PROFILE-SCOPED**: run from\r\n  the `self-improver` profile they resolve to\r\n  `~\u002F.hermes\u002Fprofiles\u002Fself-improver\u002Fcron\u002F`, which holds **zero** jobs, and\r\n  report `No scheduled jobs` \u002F `cron jobs will NOT fire`. The real jobs\r\n  (59 enabled of 71) live in the **default** profile at\r\n  `%USERPROFILE%\u002F.hermes\u002Fcron\u002Fjobs.json`. **Falsified diagnosis caught\r\n  here on 2026-10-02**: a prior review reported \"Gateway stopped, cron will\r\n  NOT fire\" as P0 based on that output — the gateway was actually running.\r\n  Never trust `cron status` output without confirming which profile it\r\n  resolved. Read `~\u002F.hermes\u002Fcron\u002Fjobs.json` for ground truth.\r\n- **`last_error` is HISTORIC, not current**: cron never clears it after a\r\n  later success. Seven jobs still carried\r\n  `Failed to compute next run ... (is the 'croniter' package installed?)`\r\n  from an old incident while actually running fine. Diagnose with the\r\n  **triple**: `last_status` AND `next_run_at` AND `fire_claim`. A non-null\r\n  `last_error` alone proves nothing about current health.\r\n- **Ticker liveness is the fastest health check**: read\r\n  `~\u002F.hermes\u002Fcron\u002Fticker_heartbeat` and `ticker_last_success` (epoch floats).\r\n  Age in seconds = seconds since last tick. This is a two-`read_file` check\r\n  that avoids the slow CLI entirely, and it is authoritative.\r\n- **`hermes curator status` hangs past the 420s tool cap on this host**:\r\n  the fallback is reading the newest\r\n  `~\u002F.hermes\u002Fprofiles\u002Fself-improver\u002Flogs\u002Fcurator\u002F\u003Cts>\u002Frun.json` directly.\r\n  It carries `duration_seconds`, `auto_transitions` (marked_stale \u002F\r\n  archived), `counts.tool_calls_total`, and `llm_final` — enough to tell\r\n  whether the auto pass ran even when the LLM pass 404'd.\r\n- **`\u002Ftmp\u002F` path mismatch**: git-bash `\u002Ftmp\u002F` resolves to a real path on\r\n  Windows, but Windows-native Python cannot find files written there via\r\n  bash. Use workspace-relative paths (`C:\u002FUsers\u002F\u003Cuser>\u002FDocuments\u002Fops\u002F`) or\r\n  `$TEMP` for temp scripts in cron jobs.\r\n- **Cron path guard blocks `rm \u002Ftmp\u002F`**: Cleanup of `\u002Ftmp\u002F` files is blocked\r\n  by the cron safety guard. Accept the leftover or clean manually in a\r\n  non-cron session.\r\n- **A whole-run tool-layer outage is possible, not just a slow CLI.** Observed\r\n  2026-10-04: every filesystem\u002Fshell tool call — `terminal` (including a\r\n  3-character `echo hi`), `read_file`, `write_file`, `search_files` — failed\r\n  instantly with `RuntimeError: Windows terminal command length exceeds safe\r\n  limit`. The message is **misleading**: it names command length, but it fired\r\n  on all tools and all payload sizes, including `read_file` which sends no\r\n  command at all. `skill_view` \u002F `skill_manage` kept working, so the fault is\r\n  in the shell\u002Ffilesystem dispatch path, not the whole runtime.\r\n  **Do not burn the run retrying it** — after `echo hi` fails, the outage is\r\n  confirmed; further identical retries only trip the loop guard. Fall back to:\r\n  (a) report the outage plainly, (b) apply only `skill_manage` work that is\r\n  safe without verification, (c) leave `_docs\u002F` for the next healthy run\r\n  rather than assuming `write_file` succeeded — it did not.\r\n- **Missing skill on a scheduled job is not a blocker**: if the job's skill\r\n  list names a skill that is absent from disk, report it in the summary and\r\n  continue with the remaining procedure. Do not create a replacement umbrella\r\n  for a single skipped reference.\r\n\r\n### Recurring config defects (fix in config, not per-job)\r\n\r\n- **A cron `skill:` naming a PROFILE is a latent defect.** Observed on\r\n  2026-10-02: `320b7b876e04` (self-improver-weekly-review) carries\r\n  `skill: \"self-improver\"`, and `842f96e965de` carries\r\n  `skill: \"delivery-worker\"` — both are *profile* names, not skills. A skill\r\n  of that name does not exist, so the load silently yields nothing. Real\r\n  alternatives: `self-improver-operations` for self-improver,\r\n  `delivery-worker`-adjacent review skills for delivery-worker. This is a\r\n  recurring template bug in the cron *creator*, not a one-off — check it on\r\n  every review and prefer fixing the creating template.\r\n- **`auxiliary.\u003Crole>.model: ''` makes drift guards misfire.** With\r\n  `curator.provider: auto` and an empty model, the role inherits the global\r\n  inference config; when that global changes, every unpinned job trips\r\n  `[drift_skip:silent]` and is skipped to avoid unintended spend. The fix is\r\n  either pin the job (`hermes cron edit \u003Cid> --provider\u002F--model`) or pin the\r\n  role in config. Both change cost\u002Fmodel behaviour, so both need human\r\n  approval — surface them, never apply them autonomously.\r\n- **A job whose auth prerequisite is missing retries forever.** Seen:\r\n  `510d48c0c367` (Google Workspace token refresh, every 20m) reached\r\n  `failure_streak: 1278` purely because `google_token.json` never appeared.\r\n  Cron has no `blocked_config` equivalent to stop it. When reporting, rank\r\n  by streak and recommend pause-with-reason rather than \"keep retrying\".\r\n\r\n### Skill authoring standards (quick reference)\r\n\r\n- `description:` ≤ 60 characters, one sentence, ends with period\r\n- No marketing words (\"powerful\", \"comprehensive\", \"seamless\")\r\n- `platforms:` must match actual script imports (POSIX-only = linux\u002Fmacos)\r\n- `created_by: agent` in usage.json determines if curator can auto-manage\r\n- Bundled\u002Fhub-installed skills are off-limits to autonomous curation\r\n\r\n### Curator quirks\r\n\r\n- **The LLM pass is optional — auto-transitions still run.** A failed LLM\r\n  review does not abort the run. The pure time-based pass (mark-stale at 30d,\r\n  archive at 90d) is separate and always executes. A 404 or provider stall\r\n  therefore still yields a real, non-empty result; report it as\r\n  \"LLM pass skipped, auto pass applied\", not as a failed run.\r\n- **HTTP 404 = wrong model\u002Froute, not a bad API key.** Seen twice\r\n  (2026-09-27): `llm: API call failed after 2 retries: HTTP 404: 404 page not\r\n  found`, where `REPORT.md` names\r\n  `custom:127.0.0.1-8080\u002Fqwen3.8-27b-abliterated-mtp` via `nvidia`. A 404 is\r\n  the endpoint rejecting the *path\u002Fmodel*, so no amount of key rotation fixes\r\n  it. Earlier a stall appeared instead: `Provider has been unresponsive ... for\r\n  7 consecutive stale attempts`. Check the configured auxiliary model resolves\r\n  before blaming credentials.\r\n- **When the LLM pass fails, consolidation silently does not happen.**\r\n  `consolidate: on` is reported in `curator status`, but with 0 tool calls the\r\n  run consolidates nothing. Duplicate\u002Foverlapping agent skills will keep\r\n  accumulating until the auxiliary model is fixed — this is the main reason\r\n  the managed-skill count drifts upward.\r\n- **A 30-day-idle profile re-stales in bulk.** A 27-day gap since the last run\r\n  meant every skill past 30d flipped at once (26 stale + 11 archived in one\r\n  29-second run). That is expected behaviour, not a bug, but review the newly\r\n  archived list before the gap grows again — recovery is\r\n  `hermes curator restore \u003Cname>`.\r\n- Pinned skills are exempt from all auto-transitions and LLM review.\r\n\r\n## Verification\r\n\r\nAfter any skill patch session:\r\n1. Re-load the skill with `skill_view(name)` and read the rendered content —\r\n   confirm each intended section is actually present and correctly nested.\r\n   This is the only reliable check when `scripts\u002Fverify-skills.py` cannot run\r\n   headless (it hits the same Security Center gate as any other script).\r\n2. **List the workspace directory** (`ls -la`) and confirm no leftover temp\r\n   files. If a probe path has been quarantined, `ls` still works even though\r\n   `rm` does not — so this check catches what the blocked `rm` cannot report.\r\n3. Confirm the report file exists at its `_docs\u002F` path and is non-trivial in\r\n   size (a stub or a truncated write is worse than nothing).\r\n4. Check `hermes curator status` for incremented patch counts — only if it\r\n   completes inside the 420s cap; otherwise read the next `run.json` later.\r\n",{"name":5,"author":43,"license":15,"version":44,"metadata":45,"platforms":53,"description":7},"Hermes Agent","1.0.0",{"hermes":46},{"tags":47,"category":34,"related_skills":51},[48,49,50,31,30],"curator","skill-maintenance","self-improver",[52,37],"ai-employee-org",[28,27,29],"main","0d1434f89f4bc6b07e9d272accd8c1013768820f","archive\u002Fskill-md-reviewed\u002Fsha256\u002F77\u002F770473306039049f04f4a8d2a52fa84c4064739f674108fd05655cf4232c9620",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":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add zapabob\u002FSkills --skill self-improver-operations",{"tool":68,"command":69},"bunx","bunx skills add zapabob\u002FSkills --skill self-improver-operations",{"tool":71,"command":72},"pnpm","pnpm dlx skills add zapabob\u002FSkills --skill self-improver-operations","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002F77\u002F770473306039049f04f4a8d2a52fa84c4064739f674108fd05655cf4232c9620\u002FSKILL.md",true,[],[77,106,141,168,195,210],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":92,"publishedAt":38},"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",[83,86,87],{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[79,93,27,94,95,28,29,96,97,98,99,100,101,32,33,102,54,103,104,105],"openclaw","cli","github","official","search","https","social-media","api","Media","twitter","social","via","post",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":123,"publishedAt":38},"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",[112,115,118,119,120],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},{"categoryNo":121,"categoryName":122,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000036","内容创作者",[124,125,126,127,27,128,28,129,29,130,131,132,133,134,135,136,137,138,139,140],"writing","writing plans","plans","design","review","workflow","documentation","tasks","development","code","planning","code-review","subagent","write","superpowers","paths","test-driven-development",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":150,"publishedAt":38},"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",[147],{"categoryNo":148,"categoryName":149,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[143,27,28,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167],"openai","speech","multimodal","Transformers","ASR","Audio","text","model","speech recognition","use","general","multilingual","translation","english","identification","processing","Audio Processing",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":177,"publishedAt":38},"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",[174],{"categoryNo":175,"categoryName":176,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",[178,27,179,180,29,181,182,183,184,185,186,158,187,188,189,190,191,192,193,194],"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":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":202,"publishedAt":38},"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",[201],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[197,27,203,95,28,204,205,206,31,207,208,32,33,34,209],"terminal","automation","http","monitoring","json","rss","with",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":218,"publishedAt":38},"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",[216,217],{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},[219,220,221,28,222,151,223,224,225,154,226,100,227,228,229,230,231,232,233,234],"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"]