{
  "tool": "list_pack_skills",
  "slug": "hermes-ops",
  "kind": "agent",
  "name": "hermes-ops",
  "format": "mybot.farm/agent-pack",
  "skills": [
    {
      "name": "autopilot-ops",
      "content": "---\nname: autopilot-ops\ndescription: \"Autopilot bot: TDD hotfix cycle, deploy, prod verification.\"\nversion: 1.4\nauthor: hermes-curator\nlicense: internal\nmetadata:\n  hermes:\n    tags: [autopilot, docker, ci, llm]\n    related_skills: [uroboros-server, pm-orchestrator]\n---\n\n# Autopilot Ops\n\n## When to Use\nЛюбая работа с ботом autopilot (lead-gen): правки кода, hotfix прода, деплой, верификация после деплоя, диагностика сбоев LLM-вызовов.\n\nLead-gen бот `autopilot` (GitHub `mytab0r/autopilot`). Kanban-борда: `/opt/data/kanban/boards/autopilot/`. Финальное саммари по закрытой таске — тег `[SUMMARY]` (формат см. skill uroboros-server).\n\n## Пути\n- Repo: `/opt/data/projects/autopilot`; worktree на ветку: `/opt/data/projects/autopilot-wt/<branch>`.\n- Prod-конфиг: `/workspace/stack/apps/autopilot-config.yaml`; SQLite прода: `/app/data/leads.sqlite` внутри контейнера.\n- Контейнер `autopilot`, образ `ghcr.io/mytab0r/autopilot`; всегда `export DOCKER_HOST=tcp://127.0.0.1:2375`.\n\n## Цикл изменения (TDD, каждый раз)\n1. `python -m devtools.finish start <branch>` — создаёт worktree.\n2. Тест ПЕРВЫМ, и fixture воспроизводит ТОЧНУЮ форму прод-payload, а не правдоподобный чистый вариант: тест на чистом JSON прошёл, а прод падал на ответе с SSE-суффиксом — фикс «вслепую» не ловится.\n3. Минимальная реализация. Локальный pytest — только быстрая итерация; финальный гейт = CI на GitHub.\n4. `python -m devtools.finish finish <branch> --push --test-cmd \"<venv>/bin/python -m pytest tests -q --ignore=tests/test_pipeline.py --ignore=tests/test_agent.py --ignore=tests/test_finish.py --ignore=tests/test_claim.py\"` — создаёт PR и авто-мержит на зелёном CI. `--test-cmd` парсится shlex, без shell.\n5. CI ждать через `gh run view <run-id> --json jobs` (gh: `/opt/data~/bin/gh`); job `build-push` пушит образ.\n\nПитфоллы:\n- Follow-up коммит, запушенный ПОСЛЕ авто-мержа squash'ем, молча теряется — если CI-фикс не успел до мержа, cherry-pick в свежую ветку и новый PR.\n- Каскад крашей в проде чинить по одному кл",
      "description": "Autopilot bot: TDD hotfix cycle, deploy, prod verification."
    },
    {
      "name": "autonomous-execution",
      "content": "---\nname: autonomous-execution\ndescription: Before saying \"I'll do X\" later. Act now, don't narrate.\n---\n\n# Autonomous execution\n\nThe user explicitly corrected this: saying \"делаю X\" / \"работаю над Y\" / \"сейчас сделаю\" and then NOT doing it in the same response wastes their time and breaks trust. They have to come back and ask \"И?\" (\"And?\") to get actual progress.\n\n## Rule\nNever end a response with a promise of future action unless genuinely blocked on something only the user can provide (credentials, a decision, a real capability gap like OAuth consent in a browser). If you can call a tool right now to make progress, call it in THIS response, not the next one.\n\n\"Запускаю X и дальше делаю Y\" is only acceptable if X is an actually-running background process you then follow up on in the SAME turn (poll/wait), or if the response is about to end anyway and you say so explicitly (\"жду фонового процесса, отпишусь по готовности\" is fine ONLY for things that take minutes and were already started).\n\n## No trailing permission-questions\nUser repeated-corrected this specifically: ending a response with \"Подтверждаешь?\" / \"Продолжать?\" / \"Устраивает?\" when you already know the answer (you decided the right action, nothing truly needs his input) is the same failure as promising future action — it stalls work waiting on a reply instead of just doing it. If you already have enough to act, act and report the result, full stop, no question mark fishing for permission. Only ask when genuinely blocked on something only he can supply (credentials, a real irreversible-risk decision, a creative preference only he can judge).\n\n## What NOT to do\n- Write a multi-step plan (\"1. Music 2. Shorts module 3. Test\") and stop there, implying it's in progress, when zero files were touched.\n- Say \"готовлю/доделываю\" across multiple responses without new tool calls each time advancing the actual artifact.\n- Treat a recap/summary message as if it were a progress update.\n\n## What TO do\n- If asked \"И?\" / ",
      "description": "Before saying \"I'll do X\" later. Act now, don't narrate."
    },
    {
      "name": "code-review-and-quality",
      "content": "---\nname: code-review-and-quality\ndescription: Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch. Use when asked to review a diff or a pull request, even when the diff is pasted inline.\n---\n\n# Code Review and Quality\n\n## Overview\n\nMulti-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance.\n\n**The approval standard:** Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it.\n\n## When to Use\n\n- Before merging any PR or change\n- After completing a feature implementation\n- When another agent or model produced code you need to evaluate\n- When refactoring existing code\n- After any bug fix (review both the fix and the regression test)\n\n## The Five-Axis Review\n\nEvery review evaluates code across these dimensions:\n\n### 1. Correctness\n\nDoes the code do what it claims to do?\n\n- Does it match the spec or task requirements?\n- Are edge cases handled (null, empty, boundary values)?\n- Are error paths handled (not just the happy path)?\n- Does it pass all tests? Are the tests actually testing the right things?\n- Are there off-by-one errors, race conditions, or state inconsistencies?\n\n### 2. Readability & Simplicity\n\nCan another engineer (or agent) understand this code without the author explaining it?\n\n- Are names descriptive and consistent with project conventions? (No `temp`, `data`, `result` without context)\n- Is the control flow straightforward (avoid nested ternaries, deep callbacks)?\n- Is the code organized ",
      "description": "Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch. Use when asked to review a diff or a pull request, even when the diff is pasted inline."
    },
    {
      "name": "planning-and-task-breakdown",
      "content": "---\nname: planning-and-task-breakdown\ndescription: Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.\n---\n\n# Planning and Task Breakdown\n\n## Overview\n\nDecompose work into small, verifiable tasks with explicit acceptance criteria. Good task breakdown is the difference between an agent that completes work reliably and one that produces a tangled mess. Every task should be small enough to implement, test, and verify in a single focused session.\n\n## When to Use\n\n- You have a spec and need to break it into implementable units\n- A task feels too large or vague to start\n- Work needs to be parallelized across multiple agents or sessions\n- You need to communicate scope to a human\n- The implementation order isn't obvious\n\n**When NOT to use:** Single-file changes with obvious scope, or when the spec already contains well-defined tasks.\n\n## The Planning Process\n\n### Step 1: Enter Plan Mode\n\nBefore writing any code, operate in read-only mode:\n\n- Read the spec and relevant codebase sections\n- Identify existing patterns and conventions\n- Map dependencies between components\n- Note risks and unknowns\n\n**Do NOT write code during planning.** The output is a plan document saved to `tasks/plan.md` and a task list recorded in the task list target (see Output Files; default `tasks/todo.md`), not implementation.\n\n### Step 2: Identify the Dependency Graph\n\nMap what depends on what:\n\n```\nDatabase schema\n    │\n    ├── API models/types\n    │       │\n    │       ├── API endpoints\n    │       │       │\n    │       │       └── Frontend API client\n    │       │               │\n    │       │               └── UI components\n    │       │\n    │       └── Validation logic\n    │\n    └── Seed data / migrations\n```\n\nImplementation order follows the dependency graph bottom-up: build foundations first.\n\n### Step 3: Slice V",
      "description": "Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible."
    },
    {
      "name": "spec-driven-development",
      "content": "---\nname: spec-driven-development\ndescription: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when drafting a PRD or requirements document with objectives and scope, or when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.\n---\n\n# Spec-Driven Development\n\n## Overview\n\nWrite a structured specification before writing any code. The spec is the shared source of truth between you and the human engineer — it defines what we're building, why, and how we'll know it's done. Code without a spec is guessing.\n\n## When to Use\n\n- Starting a new project or feature\n- Requirements are ambiguous or incomplete\n- The change touches multiple files or modules\n- You're about to make an architectural decision\n- The task would take more than 30 minutes to implement\n\n**When NOT to use:** Single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained.\n\n## The Gated Workflow\n\nSpec-driven development has four phases, preceded by a scope check (Phase 0) that activates only when one request bundles several independently testable capabilities. Do not advance to the next phase until the current one is validated.\n\n```\nSPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT\n   │          │        │          │\n   ▼          ▼        ▼          ▼\n Human      Human    Human      Human\n reviews    reviews  reviews    reviews\n```\n\n### Phase 0: Scope Check\n\nMost requests describe one capability. If this one does, skip this phase and go straight to Specify — Phase 0 exists for the exception, not the rule, and it puts no hierarchy on single-capability features.\n\n**Detection.** Decompose before specifying when a single requirement bundles several independently testable capabilities:\n\n- The requirement names distinct capabilities with t",
      "description": "Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when drafting a PRD or requirements document with objectives and scope, or when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying."
    },
    {
      "name": "system-maintenance",
      "content": "---\nname: system-maintenance\ndescription: Routine VPS disk & cache cleanup procedure.\n---\n\n# System Maintenance – Disk & Cache Cleanup\n\n## When to run\n- Disk usage > 80 % on any mount holding runtime data.\n- Before a large deploy or model download.\n- Periodically (weekly) to avoid surprise 90 % alerts.\n\n## Procedure (run inside the `hermes` container as root)\n1. **Snapshot current usage**\n   `df -h /` – note total, used, free, %.\n2. **Identify top consumers**\n   `du -sh /opt/data/* /opt/hermes/* /workspace/stack/* 2>/dev/null | sort -hr | head -20`\n3. **Backup before deletion**\n   - `/opt/data/installs` → `tar -czf /opt/data/backups/installs-$(date +%F-%H%M).tgz -C /opt/data installs`\n   - Any other directories you plan to clean.\n4. **Delete known‑safe caches** (recreated on next run)\n   - `rm -rf /opt/data/installs/*`\n   - `rm -rf /opt/data/cache/scratch/*`\n   - `rm -rf /opt/data/cache/acf-gate-venv/*`\n5. **Prune old backups** (>30 days)\n   `find /opt/data/backups -type f -mtime +30 -delete`\n6. **Verify result**\n   `df -h /` – confirm free space > 5 GB on a 49 GB disk.\n\n## Pitfalls / Rules\n- **Never delete** `/opt/hermes/tools` – contains the Hermes runtime.\n- **Never delete** active project sources under `/workspace/stack/apps/*` unless sure they are unused.\n- Run commands as **root** inside the hermes container (`docker exec -u root hermes sh -c '…'`).\n- Always **backup first**; abort on tar failure (`set -e` or check exit code).\n- Log before/after numbers for owner audit.\n\n## References\n- `references/disk-cleanup.md` – detailed safe‑to‑wipe paths, size estimates, recovery notes.\n",
      "description": "Routine VPS disk & cache cleanup procedure."
    },
    {
      "name": "kanban-fleet-ops",
      "content": "---\nname: kanban-fleet-ops\ndescription: \"Use when kanban work stalls across boards, or before proposing any project/board/epic/task structure change.\"\nversion: 1.1\n---\n\n# Kanban как флот досок: диспетч, зависимости, гейты\n\nКогда карточек больше, чем один проект, и они живут на нескольких досках, вопрос\nперестаёт быть «как закрыть карточку» и становится «почему очередь стоит и кто\nкого блокирует». Этот скилл — про флот, не про отдельный проект. Правила эскалации\nвладельцу и сторожевые циклы — в `pm-orchestrator`; здесь только механика досок.\n\n## Процедура проверки «почему стоит» (в этом порядке)\n1. Снимок: `hermes kanban boards list` — счётчики по статусам на каждой доске.\n   Доска с `ready>0` и без `running` = авария диспетча, не «работа идёт».\n2. Список досок, которые РЕАЛЬНО диспатчатся, и КЕМ. Диспетч разделён по\n   хостам: VPS-тикер (`/opt/data/scripts/kanban_dispatch_tick.sh`) обслуживает\n   только `default` (CI/инфра) и ограничен капом в 2; проектные доски\n   диспатчит ПК (`pc_dispatch_tick.sh`) — динамический список «все, кроме\n   default», `--max 6` на доску, ротация досок. Строка `BOARDS=\"default\"` в\n   VPS-тикере — не забытая правка и не баг: это граница хостов. Проверять,\n   что проектные доски уходят, надо по `pc_dispatch_tick.sh` и статусу\n   `running`, а не по VPS-скрипту.\n3. Гейты ресурсов: `.disk-halt`, запас памяти по cgroup, `max_in_progress`.\n   Гейт может отсекать старт, не оставляя ни строчки в логе — проверять\n   наличие/отсутствие маркер-файлов, а не только вывод команды.\n4. Assignee: `ready` с `(unassigned)` не спавнится, пока профиль не назначен.\n5. **Возраст `running`, до того как объяснять «ready не едет».** Кап `--max N`\n   считает строки в статусе running, а не прогресс: воркер с живым heartbeat и\n   без движения часами держит слот. Мерить `started_at` карточки и\n   `task_runs.started_at` активного прогона, а не heartbeat. Если все слоты\n   заняты такими — причина голодовки найдена, конфиг диспетча трогать не надо.\n6. Ручной `dispatch --",
      "description": "Use when kanban work stalls across boards, or before proposing any project/board/epic/task structure change."
    },
    {
      "name": "kanban-worker-liveness",
      "content": "---\nname: kanban-worker-liveness\ndescription: \"Use when kanban workers hang or a runtime cap does not fire.\"\nversion: 1.0\n---\n\n# Живучесть воркеров kanban: лимит прогона и голодовка слотов\n\n## When to Use\nКарточка висит в `running` часами; очередь `ready`/`review` стоит при живом\nдиспетчере; надо доказать, что лимит прогона реально стреляет, а не просто\nописан в коде; после backfill лимитов нужно подтвердить результат.\n\nДополняет `kanban-fleet-ops` (структура досок и диспетч): здесь — как отличить\nдолгую работу от зависания и как доказать, что гейт реально стреляет.\n\n## Возраст прогона: считать по активному run\n`tasks.started_at` — самый ПЕРВЫЙ старт за жизнь карточки, после рестартов не\nдвигается. «73 часа running» по нему — история карточки, а не зависание.\nРабочая формула:\n\n```sql\nselect t.id, t.title, coalesce(r.started_at, t.started_at) as run_start,\n       t.max_runtime_seconds\nfrom tasks t left join task_runs r on r.id = t.current_run_id\nwhere t.status = 'running';\n```\n\nЖивой heartbeat + отсутствие прогресса часами = зависание, даже если процесс\nсуществует. Такой воркер держит слот из `--max N`, и очередь `ready` стоит при\nформально работающем диспетчере.\n\n## Лимит есть ≠ лимит применяется\n`enforce_max_runtime` выбирает только строки с `max_runtime_seconds IS NOT NULL`.\nПроверять заполненность, а не наличие кода:\n\n```sql\nselect status, count(*), count(max_runtime_seconds) from tasks group by 1;\n```\n\nНоль в третьей колонке = гейт мёртв для всех карточек. Лечение: backfill NULL\nстрок в cap (по умолчанию 3 ч, явные per-task лимиты не укорачивать) + cron на\nтот же скрипт, потому что новые карточки создаются без `--max-runtime`.\n\n## Доказательство, а не чтение кода\nПроверять гейт прогоном на копии БД: искусственно состарить\n`task_runs.started_at` активного прогона, подставить `signal_fn`, который\nтолько записывает вызовы, и ожидать возврат id + SIGTERM/SIGKILL.\nГотовый пробник: `scripts/verify_max_runtime_gate.py`.\n\n## Питфоллы пробника:\n- `sqlite3.connect(...)` с",
      "description": "Use when kanban workers hang or a runtime cap does not fire."
    },
    {
      "name": "browser-account-signup",
      "content": "---\nname: browser-account-signup\ndescription: Use when registering web accounts via browser automation.\n---\n\n# Browser account signup (vault-backed)\n\n> Gmail через headful-chrome ПК: signup упирается в crossflowverification (QR), потом при входе в YouTube ещё раз uplevelingstep (QR): владельцу нужно 2 ссылки. URL брать декодом свежего QR (zxingcpp), не из логов: ссылка живёт ~10 мин, протухшая даёт «Something went wrong». iPhone открывает её в приложении YouTube → «We couldn't verify your info»: сразу писать «скопируй и открой в Safari».\n\nUser stance: generating a password and filling it like in autotests is expected — do not refuse or ask him to type it. Passwords go only through the vault (never printed, never in chat).\n\nIf the user registers himself and pastes the password in chat: accept it, write it to `/opt/data/secrets/<service>.env` (chmod 600) plus an ACCOUNTS.md row, and continue. No lecture about passwords in chat: Telegram is his only channel.\n\nUser has no shell on the PC/host and reads only Telegram: never reply \"run `grep …`\" or \"open URL and fill the form yourself\". Do every automatable step; send him only the irreducible human piece inline (e.g. captcha image as MEDIA), then finish yourself.\n\n## Identity: on whose name (decide before filling any form)\n- Read `/opt/data/ACCOUNTS.md` first: payment/KYC owner, roles, existing logins. Never guess or invent names.\n- Accounts with KYC, payouts, or physical-mail verification (Shipito/USPS 1583, PayPal, Payoneer, Upwork, W-8BEN) go on the registered payment owner: Latin name as in passport, real country. A mismatch with documents freezes money or closes the account.\n- Brand-only accounts (mailbox, socials) may use the brand. The user works as the technical executor; outward wording: owner's business, user = estimator/tech specialist. No invented staff or fake US company — it breaks at the first call or document check.\n\n## Procedure\n0. Search before registering or answering \"whose account / what name\": ACCOUN",
      "description": "Use when registering web accounts via browser automation."
    },
    {
      "name": "airtable",
      "content": "---\nname: airtable\ndescription: Airtable REST API via curl. Records CRUD, filters, upserts.\nversion: 1.1.0\nauthor: community\nlicense: MIT\nplatforms: [linux, macos, windows]\nprerequisites:\n  env_vars: [AIRTABLE_API_KEY]\n  commands: [curl]\nmetadata:\n  hermes:\n    tags: [Airtable, Productivity, Database, API]\n    homepage: https://airtable.com/developers/web/api/introduction\n---\n\n# Airtable — Bases, Tables & Records\n\nWork with Airtable's REST API directly via `curl` using the `terminal` tool. No MCP server, no OAuth flow, no Python SDK — just `curl` and a personal access token.\n\n## Prerequisites\n\n1. Create a **Personal Access Token (PAT)** at https://airtable.com/create/tokens (tokens start with `pat...`).\n2. Grant these scopes (minimum):\n   - `data.records:read` — read rows\n   - `data.records:write` — create / update / delete rows\n   - `schema.bases:read` — list bases and tables\n3. **Important:** in the same token UI, add each base you want to access to the token's **Access** list. PATs are scoped per-base — a valid token on the wrong base returns `403`.\n4. Store the token in `${HERMES_HOME:-~/.hermes}/.env` (or via `hermes setup`):\n   ```\n   AIRTABLE_API_KEY=pat_yo...here\n   ```\n\n> Note: legacy `key...` API keys were deprecated Feb 2024. Only PATs and OAuth tokens work now.\n\n## API Basics\n\n- **Endpoint:** `https://api.airtable.com/v0`\n- **Auth header:** `Authorization: Bearer $AIRTA...KEY`\n- **All requests** use JSON (`Content-Type: application/json` for any POST/PATCH/PUT body).\n- **Object IDs:** bases `app...`, tables `tbl...`, records `rec...`, fields `fld...`. IDs never change; names can. Prefer IDs in automations.\n- **Rate limit:** 5 requests/sec/base. `429` → back off. Burst on a single base will be throttled.\n\nBase curl pattern:\n```bash\ncurl -s \"https://api.airtable.com/v0/$BASE_ID/$TABLE?maxRecords=5\" \\\n  -H \"Authorization: Bearer ***\" | python -m json.tool\n```\n\n`-s` suppresses curl's progress bar — keep it set for every call so the tool output stays clean fo",
      "description": "Airtable REST API via curl. Records CRUD, filters, upserts."
    },
    {
      "name": "notion",
      "content": "---\nname: notion\ndescription: \"Notion API + ntn CLI: pages, databases, markdown, Workers.\"\nversion: 2.0.0\nauthor: community\nlicense: MIT\nplatforms: [linux, macos, windows]\nprerequisites:\n  env_vars: [NOTION_API_KEY]\nmetadata:\n  hermes:\n    tags: [Notion, Productivity, Notes, Database, API, CLI, Workers]\n    homepage: https://developers.notion.com\n---\n\n# Notion\n\nTalk to Notion two ways. Same integration token works for both — pick by what's available.\n\n◆ **`ntn` CLI** — Notion's official CLI. Shorter syntax, one-line file uploads, required for Workers. macOS + Linux only as of May 2026 (Windows support \"coming soon\"). **Default when installed.**\n◆ **HTTP + curl** — works everywhere including Windows. **Default fallback** when `ntn` isn't installed.\n\n## Setup\n\n### 1. Get an integration token (required for both paths)\n\n1. Create an integration at https://notion.so/my-integrations\n2. Copy the API key (starts with `ntn_` or `secret_`)\n3. Store in `${HERMES_HOME:-~/.hermes}/.env`:\n   ```\n   NOTION_API_KEY=***\n   ```\n4. **Share target pages/databases with the integration** in Notion: page menu `...` → `Connect to` → your integration name. Without this, the API returns 404 for that page even though it exists.\n\n### 2. Install `ntn` (preferred path on macOS / Linux)\n\n```bash\n# Recommended\ncurl -fsSL https://ntn.dev | bash\n\n# Or via npm (needs Node 22+, npm 10+)\nnpm install --global ntn\n\nntn --version    # verify\n```\n\n**Skip `ntn login` — use the integration token instead.** This works headlessly, no browser needed:\n```bash\nexport NOTION_API_TOKEN=$NOTION_API_KEY      # ntn reads NOTION_API_TOKEN\nexport NOTION_KEYRING=0                       # don't try to use the OS keychain\n```\n\nAdd those exports to your shell profile (or to `${HERMES_HOME:-~/.hermes}/.env`) so every session inherits them.\n\n### 3. Choose path at runtime\n\n```bash\nif command -v ntn >/dev/null 2>&1; then\n  # use ntn\nelse\n  # fall back to curl\nfi\n```\n\nWindows users: skip step 2 entirely until native `ntn` ships ",
      "description": "Notion API + ntn CLI: pages, databases, markdown, Workers."
    },
    {
      "name": "research-loop",
      "content": "---\nname: research-loop\ndescription: Use for researched verdicts. Hypothesis-critic cycles.\n---\n# Research loop\n\nWhen: question needs a researched verdict, not a quick fact (architecture, process, tool/model choice).\nOne pass = one hypothesis + one critic = not enough. Minimum 2 full cycles, max 4.\n\n## Before cycle 1 (write to file, not head)\n- Goal: what decision this enables.\n- Done-criteria: 3-6 checkable claims the verdict must support.\n- Search space map BEFORE searching: (1) new models/releases last 90 days, (2) built-in features of tools we already run (Hermes docs/changelog, CLI --help), (3) vendor engineering blogs, (4) papers last 12 months, (5) OSS repos, (6) contrary evidence / failure reports. Uncovered category = gap.\n\n## Each cycle\n1. Hypothesis (own, not owner's words restated).\n2. Evidence: >=1 source per uncovered category; record source + number.\n3. Independent critic (delegate, fresh context): attack hypothesis, find missed alternatives, verify numbers.\n4. Recompute numbers yourself (stats, costs): critics miscalculate too.\n5. Score: each done-criterion = supported / contradicted / open. Count findings that changed the verdict.\n\n## Stop / continue / pivot\n- Continue: criterion open AND last cycle changed the verdict.\n- Stop (done): all criteria supported, last cycle changed nothing (saturation).\n- Pivot: 2 cycles contradict the core hypothesis -> new hypothesis from best alternative.\n- Stop (blocked): needs data only owner has -> one question with options.\n- Hard cap 4 cycles; report open items honestly.\n\n## Automation\nLong research = kanban card with `--goal --goal-max-turns N`: built-in judge checks done-criteria each turn.\n\n## Pitfalls\n- skill_manage on this setup writes to runner ~/.hermes/skills; kanban workers read /opt/data/skills. After creating a skill, copy it to /opt/data/skills/<category>/ or cards crash with 'Unknown skill(s)'.\n- Restating owner's idea as the plan = failure. Owner input is a hypothesis to test.\n- Skipping categories ",
      "description": "Use for researched verdicts. Hypothesis-critic cycles."
    },
    {
      "name": "market-research",
      "content": "---\nname: market-research\ndescription: Use when a build needs market validation before coding.\nversion: 1.0.0\nauthor: Hermes agent (curator-managed)\nlicense: MIT\nmetadata:\n  hermes:\n    tags: [Market-Research, Best-Practices, Tooling-Survey, Monetization]\n    related_skills: [grounded-citations, competitor-news-monitor, spike]\n---\n\n# Market research before building\n\n## When to Use\n\n- Owner asks to \"поресерчить\" a feature/niche before building it, or to\n  \"выявить бестпрактис / поискать готовые решения\".\n- A production parameter (format length, tempo, key, cadence, payout\n  expectation) is about to be picked and could be picked from folklore.\n- Choosing build-vs-adopt for a tool/library and license/fit analysis is\n  needed.\n- Don't use for: recurring monitoring of named companies\n  (competitor-news-monitor), one-off fact lookups (web_search directly),\n  paper search (arxiv).\n\nAndrey requires researched justification before any new feature class:\n\"поресерчить как делают другие, выявить бестпрактис, поискать готовые\nрешения, переиспользовать необходимое\". Building on genre folklore gets\nrejected, and so does citing \"competitive analysis\" that never actually\nhappened. Research narrows the design; the owner still approves creative\nchoices (sound, genre, visuals) on real samples — never swap production\nparameters on research conclusions alone.\n\n## Non-negotiable: measured sources or no claim\n\n- Every \"the market does X\" number (format length, tempo, key, posting\n  frequency, payout) must trace to a source that MEASURED real artifacts or\n  ran a large-N study: key/BPM databases over actual tracks, Buffer /\n  Socialinsider / Metricool platform studies, platform policy and developer\n  docs. Genre stereotypes (\"sad genre = minor key\") and SEO blogs do not\n  count — when actually measured they have contradicted the stereotype.\n- If challenged on a parameter: re-verify against measured data before\n  defending it; admit which claims were stereotype-based and fix the\n  production",
      "description": "Use when a build needs market validation before coding."
    },
    {
      "name": "github",
      "content": "---\nname: github\ndescription: \"GitHub via gh CLI: PRs, issues, reviews, repos, auth.\"\nversion: 2.0.0\nauthor: Ben Barclay (benbarclay), Hermes Agent\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [github, gh, git, pull-requests, issues, code-review, repos, auth, ci]\n    category: software-development\n    related_skills: [codebase-inspection, requesting-code-review]\n---\n\n# GitHub\n\nWork GitHub end to end with the `gh` CLI (REST fallback where noted): auth,\nissues, the PR lifecycle, issue-to-PR delivery, code review, and repo\nmanagement. This skill consolidates six former skills; each workflow lives\ncomplete in its reference file — ALWAYS read the matching reference before\nstarting that workflow, the body below only routes.\n\n## Routing\n\n| Task | Read first |\n|---|---|\n| Auth broken / new machine / token or SSH setup / gh login | `references/auth.md` |\n| Create, triage, label, assign, close issues | `references/issues.md` |\n| Branch, commit, open PR, watch CI, merge | `references/pr-workflow.md` |\n| Carry an ISSUE to a verified PR (full delivery loop) | `references/issue-to-pr.md` |\n| Review someone's PR: diffs, inline comments, verdict | `references/code-review.md` |\n| Clone/create/fork repos, remotes, releases | `references/repo-management.md` |\n\nSupporting assets: `scripts/gh-env.sh` + `scripts/git-credential-token.py`\n(auth helpers), `templates/` (PR bodies, bug report, feature request),\n`references/ci-troubleshooting.md`, `references/conventional-commits.md`,\n`references/github-api-cheatsheet.md`, `references/review-output-template.md`.\n\n## Core discipline (applies to every workflow)\n\n- Preflight once per session: `gh auth status` — if it fails, go to\n  `references/auth.md` before anything else.\n- Prefer `gh` over raw REST; drop to `gh api` only for endpoints the\n  porcelain lacks (the cheatsheet lists them).\n- Never report CI green without checking `gh pr checks` yourself; never\n  claim merged without verifying `state,mergedAt`.\n- Rea",
      "description": "GitHub via gh CLI: PRs, issues, reviews, repos, auth."
    },
    {
      "name": "spike",
      "content": "---\nname: spike\ndescription: \"Throwaway experiments to validate an idea before build.\"\nversion: 1.0.0\nauthor: Hermes Agent (adapted from gsd-build/get-shit-done)\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [spike, prototype, experiment, feasibility, throwaway, exploration, research, planning, mvp, proof-of-concept]\n    related_skills: [sketch, subagent-driven-development]\n---\n\n# Spike\n\nUse this skill when the user wants to **feel out an idea** before committing to a real build — validating feasibility, comparing approaches, or surfacing unknowns that no amount of research will answer. Spikes are disposable by design. Throw them away once they've paid their debt.\n\nLoad this when the user says things like \"let me try this\", \"I want to see if X works\", \"spike this out\", \"before I commit to Y\", \"quick prototype of Z\", \"is this even possible?\", or \"compare A vs B\".\n\n## When NOT to use this\n\n- The answer is knowable from docs or reading code — just do research, don't build\n- The work is production path — use the `plan` skill instead\n- The idea is already validated — jump straight to implementation\n\n## If the user has the full GSD system installed\n\nIf `gsd-spike` shows up as a sibling skill (installed via `npx get-shit-done-cc --hermes`), prefer **`gsd-spike`** when the user wants the full GSD workflow: persistent `.planning/spikes/` state, MANIFEST tracking across sessions, Given/When/Then verdict format, and commit patterns that integrate with the rest of GSD. This skill is the lightweight standalone version for users who don't have (or don't want) the full system.\n\n## Core method\n\nRegardless of scale, every spike follows this loop:\n\n```\ndecompose  →  research  →  build  →  verdict\n   ↑__________________________________________↓\n                  iterate on findings\n```\n\n### 1. Decompose\n\nBreak the user's idea into **2-5 independent feasibility questions**. Each question is one spike. Present them as a table with Given/When/Then framing:",
      "description": "Throwaway experiments to validate an idea before build."
    },
    {
      "name": "youtube-content",
      "content": "---\nname: youtube-content\ndescription: \"YouTube transcripts to summaries, threads, blogs.\"\nversion: 1.0.0\nauthor: Teknium (teknium1), Hermes Agent\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [YouTube, Video, Transcripts, Media]\n    related_skills: []\n---\n\n# YouTube Content Tool\n\n## When to use\n\nUse when the user shares a YouTube URL or video link, asks to summarize a video, requests a transcript, or wants to extract and reformat content from any YouTube video. Transforms transcripts into structured content (chapters, summaries, threads, blog posts).\n\nExtract transcripts from YouTube videos and convert them into useful formats.\n\n## Setup\n\nUse `terminal` with the Python from a PM-prepared Hermes source checkout. The\n`youtube` extra declares the helper's dependency; do not install packages into\nHermes with raw pip or project-discovering `uv run`.\n\nFrom that checkout, first follow the isolated development-home setup in\n[Package Management](https://hermes-agent.nousresearch.com/docs/reference/package-management#developer-workflow),\nthen prepare the extra and reactivate before running the helper:\n\n```bash\nsource ./activate\npython -c \"import pm; pm.sync_venv(['youtube'], explicit=True)\"\nsource ./activate\npython -c \"import youtube_transcript_api; print(youtube_transcript_api.__file__)\"\n```\n\nOn Windows, use `. .\\activate.ps1` instead of `source ./activate`. If the terminal\nruns on a different host or in a sandbox, use an explicitly isolated helper\nenvironment there, not the agent's production environment. Run every command\nbelow with the interpreter whose import check succeeded.\n\n## Helper Script\n\n`SKILL_DIR` is the directory containing this SKILL.md file. The script accepts any standard YouTube URL format, short links (youtu.be), shorts, embeds, live links, or a raw 11-character video ID.\n\n```bash\n# JSON output with metadata\npython SKILL_DIR/scripts/fetch_transcript.py \"https://youtube.com/watch?v=VIDEO_ID\"\n\n# Plain text (good for piping in",
      "description": "YouTube transcripts to summaries, threads, blogs."
    },
    {
      "name": "p5js",
      "content": "---\nname: p5js\ndescription: \"p5.js sketches: gen art, shaders, interactive, 3D.\"\nversion: 1.0.0\nauthor: SHL0MS, Hermes Agent\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [creative-coding, generative-art, p5js, canvas, interactive, visualization, webgl, shaders, animation]\n    related_skills: [ascii-video, manim-video, excalidraw]\n---\n\n# p5.js Production Pipeline\n\n## When to use\n\nUse when users request: p5.js sketches, creative coding, generative art, interactive visualizations, canvas animations, browser-based visual art, data viz, shader effects, or any p5.js project.\n\n## What's inside\n\nProduction pipeline for interactive and generative visual art using p5.js. Creates browser-based sketches, generative art, data visualizations, interactive experiences, 3D scenes, audio-reactive visuals, and motion graphics — exported as HTML, PNG, GIF, MP4, or SVG. Covers: 2D/3D rendering, noise and particle systems, flow fields, shaders (GLSL), pixel manipulation, kinetic typography, WebGL scenes, audio analysis, mouse/keyboard interaction, and headless high-res export.\n\n## Creative Standard\n\nThis is visual art rendered in the browser. The canvas is the medium; the algorithm is the brush.\n\n**Before writing a single line of code**, articulate the creative concept. What does this piece communicate? What makes the viewer stop scrolling? What separates this from a code tutorial example? The user's prompt is a starting point — interpret it with creative ambition.\n\n**First-render excellence is non-negotiable.** The output must be visually striking on first load. If it looks like a p5.js tutorial exercise, a default configuration, or \"AI-generated creative coding,\" it is wrong. Rethink before shipping.\n\n**Go beyond the reference vocabulary.** The noise functions, particle systems, color palettes, and shader effects in the references are a starting vocabulary. For every project, combine, layer, and invent. The catalog is a palette of paints — you write the",
      "description": "p5.js sketches: gen art, shaders, interactive, 3D."
    },
    {
      "name": "pc-infra",
      "content": "---\nname: pc-infra\ndescription: Протоколы доступности среды — ПК-раннер недоступен (status=degraded, SSH-ошибка) и блокировка запросов с IP VPS (403, капча, гео-блок). Перенесено из SOUL.md 2026-10-15.\nversion: 1.0\n---\n\n# ПК недоступен (status=degraded / SSH-ошибка)\n\nСреда: лёгкий VPS; терминал, файлы, code_execution и браузер физически выполняются на ПК пользователя через SSH. Ошибка SSH или status=degraded означает, что ПК выключен или нет связи.\n\n- Не повторяй вызов более одного раза.\n- Перед выводом «ПК выключен» проверь Docker API ПК из browser_exec (`pc_diag.sh` → `== ping: OK`): ответил — ПК жив, сломан конкретный контейнер; диагноз по разделу «hermes-runner исчез» в references/failure-map.md. SSH :2223 идёт через pc-link в hermes-runner, поэтому degraded бывает и при живом ПК.\n- Ответь пользователю по-русски одной-двумя фразами: «ПК сейчас недоступен (выключен или нет связи). Тяжёлую часть выполню, когда он вернётся» — и предложи, что можно сделать без ПК (поиск, анализ, план).\n- Технические детали ошибки не показывай, пока не спросят.\n\n# Делегирование задач на ПК (delegate_task Codex) — правила верификации\n\n- Никогда не запускай delegate_task, который пишет файлы на ПК (D:\\hermes-codex\\ или /opt/data/scripts), пока SSH-туннель 127.0.0.1:2223 не поднят и pc_diag.sh не показывает контейнеры Up. Саб-агент «отработает в памяти», но write_file упадёт (Permission denied / SSH refused), а self-report может заявлять о коммитах, которых нет (галлюцинация).\n- После завершения subagent'а ВСЕГДА верифицируй заявленные коммиты/ветки через `gh api` ПЕРЕД тем, как сообщать владельцу: `gh api repos/mytab0r/hermes-scripts/commits/<sha>` и `gh api repos/mytab0r/hermes-scripts/branches/<name>` — 404 = ничего не приземлилось. Не доверяй отчёту саб-агента без внешнего подтверждения.\n- pc_diag.sh exec arg form: `pc_diag.sh exec sh -c 'cmd'` — exec получает все аргументы после exec как Cmd для docker exec. Для kb.sh: `pc_diag.sh exec sh /opt/data/scripts/kb.sh --board X list`. Ко",
      "description": "Протоколы доступности среды — ПК-раннер недоступен (status=degraded, SSH-ошибка) и блокировка запросов с IP VPS (403, капча, гео-блок). Перенесено из SOUL.md 2026-10-15."
    },
    {
      "name": "owner-reporting",
      "content": "---\nname: owner-reporting\ndescription: \"Use before replying to the owner: report shape, length.\"\nversion: 1.0\n---\n\n# Отчёт владельцу: формат и границы\n\n## When to Use\nПеред любым ответом владельцу после выполненной работы, статуса или\nдиагностики — чтобы ответ был сдачей, а не отчётом о процессе.\n\nПравила про ФОРМУ ответа, а не про работу. Работа делается до ответа; ответ —\nтолько сдача. Нарушение формы читается как перекладывание работы обратно на\nвладельца («нахуй мне все эти сообщения»).\n\n## Форма сдачи\n1. 2–4 строки: что теперь РАБОТАЕТ + доказательство (прогон, статус, вывод\n   команды, ссылка). Одна тема — один абзац.\n2. Если что-то недоделано — одна строка «осталось: X», без плана и без\n   запроса разрешения.\n3. Ничего не «подсвечивать» как следующий шаг и не заканчивать вопросом\n   «начинать с X?»: обратимое действие, которое можешь сделать сам, делаешь\n   ДО ответа.\n\nВопрос в конце технически невозможен: плагин `owner-no-question`\n(`/opt/data/plugins/owner-no-question`, hook `transform_llm_output` с\n`hold_stream`) срезает хвостовые вопросы на telegram/cli до отправки и пишет\nсрез в `/opt/data/logs/owner_question_gate.log`. Исключение — деньги, оплата,\nюридическое, бан, удаление данных, пароль/2FA, регистрация: там вопрос\nостаётся. Хочется спросить — значит решение принимает оркестратор/карточка.\n\n## Что не писать никогда\n- Разделы «что не так / что чинить / что улучшать» — это внутренняя работа\n  агента, а не его триаж.\n- Таблицы счётчиков (`running/ready/blocked` по доскам), перечисление всех\n  найденных мелочей, пошаговый лог диагностики.\n- Пересказ его слов как плана; «предлагаю», если решение уже очевидно.\n- Обещания («добавлю защиту», «разберусь за 2 ч») без установленного\n  механизма в том же ходе — засчитывается только механизм, проверенный\n  реальным выводом. Повторная проблема после обещания — худший исход.\n\n## Что докладывать обязательно\n- Реальный блокер, который может снять только он (деньги, доступ, бан,\n  юридическое действие): одно сообщение,",
      "description": "Use before replying to the owner: report shape, length."
    },
    {
      "name": "autonomous-remediation",
      "content": "---\ndescription: Self-fixing guards silent on success. Alert only on failure.\nname: autonomous-remediation\n---\n\n# Autonomous Remediation: Silent Success\n\n## Always\n\nIf a guard/monitor fully self-remediates (auto-PR, auto-fix, auto-revert), it MUST NOT emit an owner-facing alert on success.\n\nAlert only when:\n- Self-remediation fails (git push / PR creation errors)\n- The issue is outside the guard's authority (infra down, auth failure)\n\n## Selftest Rule\n\nWhen you silence success output, update the corresponding selftest assertion. The old pattern:\n```python\nr = run(); assert r.returncode == 1 and \"LOCAL EDIT\" in r.stdout\n```\nMust become:\n```python\nr = run(); assert r.returncode == 0 and not r.stdout.strip()\n```\n\nLeaving the old assertion causes CI to fail every run.\n\n## Pitfall\n\nDo not confuse \"guard saw a diff\" with \"owner needs to know.\" A drift branch + draft PR IS the notification to the developer who made the local edit. The owner only needs to know if that self-service path failed.",
      "description": "Self-fixing guards silent on success. Alert only on failure."
    },
    {
      "name": "hermes-kanban-orchestration",
      "content": "---\nname: hermes-kanban-orchestration\ndescription: \"Use when running kanban orchestrator loops or TG digests.\"\nversion: 1.0\n---\n\n# Hermes Kanban Orchestration\n\nContinuous orchestrator loops on one or more kanban boards using Hermes primitives (specify, decompose, dispatch, stats), plus periodic Telegram dashboards and heartbeats. Board-level diagnosis rules live in `kanban-fleet-ops`; this skill is the running loop itself.\n\n## Primitives: what actually exists\nVerify with `hermes kanban --help` before writing a loop — the mental model drifts.\n\n- `specify [id|--all]` — fleshes triage cards into concrete specs, promotes to todo. Fails entirely on the first `triage_loop_hold` card.\n- `decompose [id|--all]` — splits triage cards into children. Same failure mode.\n- `dispatch --json` — reclaims stale, promotes ready, spawns workers up to caps. Returns `spawned` (list of `{task_id, assignee, workspace}`), `promoted`, `reclaimed`.\n- `stats --json` — counts by status/assignee plus `oldest_ready_age_seconds`.\n- `request-review` / `request-changes` / `reopen-review` — the review gate trio.\n- `link` / `unlink` — parent→child, WITHIN one board only.\n- `completion-contract` — NOT a subcommand. It is `create --completion-contract OWNER/REPO` (`local-only` is the default) or an exact PR URL.\n- `stuck_escalate` — does not exist in the CLI. Implement it in the loop.\n- `config` — does not exist as a `kanban` subcommand; dispatcher config lives in `~/.hermes/config.yaml` under `kanban:`.\n\n## Loop shape (one process per board)\n```python\ndef orchestrator_cycle(board):\n    for task in list_status(board, 'triage'):          # per-card, never --all\n        try:\n            specify_one(board, task['id'])\n        except TriageLoopHold:\n            comment(board, task['id'], 'RELEASE: <new fact>')   # required first\n            specify_one(board, task['id'])\n    for task in list_status(board, 'triage'):\n        try:\n            decompose_one(board, task['id'])\n        except TriageLoopHold:\n   ",
      "description": "Use when running kanban orchestrator loops or TG digests."
    },
    {
      "name": "live-deploy-verification",
      "content": "---\nname: live-deploy-verification\ndescription: \"Use when a deploy looks live but prod shows no change.\"\nversion: 1.0.0\nauthor: hermes-curator\nlicense: MIT\nmetadata:\n  hermes:\n    tags: [deploy, verify, edge, sso, zoraxy, ci]\n    related_skills: [deploy-via-github, live-funnel-audit]\n---\n\n# Live deploy verification\n\n«Выкатил» — не утверждение, а измерение. Этот скилл отвечает на вопрос\n«изменение реально на проде?» в правильном порядке: край → образ → код.\nПрименять и когда сам отчитываешься о выкатке, и когда владелец пишет\n«на проде ничего не изменилось».\n\n## Порядок диагностики (сверху вниз, не наоборот)\n\n1. **Край (прокси/SSO/ingress).** `curl -s <публичный URL> | grep <новый markup>`.\n   Если маркапа нет — `curl -o /dev/null -w '%{http_code}' <публичный URL>`.\n   `307/302` на страницу логина или `403` = путь не доходит до приложения:\n   в Zoraxy/ingress нет exception-правила для этого префикса. Код при этом\n   может быть уже в контейнере и полностью рабочим.\n2. **Образ.** Если сервис отдаёт билд-sha (`/healthz` → `{\"ok\":true,\"sha\":\"…\"}`),\n   сравни его с `git rev-parse origin/master`. Один вызов закрывает вопрос\n   «новый образ вообще живёт». Нет `/healthz` — `docker inspect` на сервере\n   или digest тега в ghcr.\n3. **Код.** Только после 1–2. Если sha совпадает и публичный путь 200, но\n   содержания нет — тогда читается приложение.\n\nПрыжок сразу к шагу 3 — главная потеря времени: код зелёный, тесты зелёные,\nа причина в правиле маршрута. Владелец видит ровно `307` и называет это\n«никаких изменений».\n\n`scripts/probe_deploy.py <public-url> <expected-substring> --protected <path>\n--healthz <url> --expected-sha <sha>` делает все три проверки одним прогоном и\nпечатает таблицу путь→код→вердикт. Запускать перед любым сообщением о выкатке.\n\n## Красный CI не равен «нельзя выкатить»\n\nОбразовый workflow обычно отдельный от линт/тест-джоб. Если мастер красный из-за\nнесвязанных проверок (lint, чужой python-тест):\n- `gh workflow run <image-workflow>.yml --ref master` собирает",
      "description": "Use when a deploy looks live but prod shows no change."
    },
    {
      "name": "sdlc-review",
      "content": "---\nname: sdlc-review\ndescription: Review Kanban handoffs and route verified outcomes.\nversion: 1.1.0\nauthor: Jakub Wolniewicz (@frizikk) + Hermes Agent\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [kanban, review, quality, verification]\n    category: devops\n    requires_toolsets: [kanban]\nenvironments:\n  - kanban\n---\n\n# SDLC Review Skill\n\nIndependently verify work handed from a Kanban implementation run to the review lane, then approve it, request changes, or escalate. This skill reviews the deliverable and its evidence; it does not take over the implementer's work.\n\n## When to Use\n\nUse this skill when all of the following are true:\n\n- the dispatcher spawned you for a task claimed from the `review` lane;\n- an implementer submitted a `review_requested` handoff;\n- the task needs an independent verdict before it can be completed.\n\nDo not use it for a separate downstream review card. A downstream card is ordinary implementation work with a review-oriented specification and completes through its own lifecycle.\n\n## Prerequisites\n\n- A Kanban worker context with the current task and run identifiers.\n- Native Kanban tools: `kanban_show`, `kanban_comment`, `kanban_complete`, `kanban_request_changes`, and `kanban_block`.\n- Workspace access through `read_file`, `search_files`, and `terminal` when the deliverable is code.\n- The task's original specification, acceptance criteria, handoff summary, and prior run history must be available through `kanban_show`.\n\n## How to Run\n\nThis skill is loaded automatically by the review dispatcher. Start with `kanban_show` before inspecting files or choosing a verdict.\n\n1. Read the task specification and the latest `review_requested` handoff.\n2. Inspect the actual deliverable and run relevant verification.\n3. Choose exactly one verdict: approve, request changes, or escalate.\n4. Record concrete evidence in the terminal Kanban transition.\n\n## Quick Reference\n\n| Verdict | When | Final action |\n|---|---|---|\n| Appr",
      "description": "Review Kanban handoffs and route verified outcomes."
    }
  ],
  "memory": [
    {
      "kind": "profile",
      "content": "Hermes Ops runs fully autonomous: plans, executes, and reports on multi-step engineering tasks without human intervention. Uses kanban, skills, and a knowledge base to self-route work."
    }
  ],
  "sharedMemory": [],
  "members": []
}