tools-update-cron: sync 2026-07-15 — 23 skill(s) updated

hermes-config-bulk-update/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: hermes-config-bulk-update
 description: "Bulk-update all Hermes config files (base + profiles) in one pass using execute_code."
-version: 1.0.0
+version: 1.0.1
 author: Hermes Agent
 ---
 
@@ -39,8 +39,12 @@ for p in configs:
 
 - `references/nous-research-api.md` — Nous Research model name mapping (Ollama `:cloud` → Nous `provider/model`), config structure examples, auth status, and testing instructions.
 - `references/dgx-vllm-server.md` — DGX vLLM server (10.0.0.6) connection details, current model, smoke tests, container info.
-- `references/model-temperature-configuration.md` — Main inference temperature is NOT user-configurable in v0.17.0 (`_fixed_temperature_for_model` only handles Kimi/Arcee; PR #34219 unmerged). Lists per-subsystem temps that DO work (compression, vision, MoA), Ollama `:cloud` model behavior (honors `options.temperature` but Hermes never sends it), and ranked workarounds (Modelfile bake, cherry-pick PR, proxy).
+- `references/model-temperature-configuration.md` — Main inference temperature IS configurable via `custom_providers[].extra_body.temperature` (confirmed v0.18.0). Full code-path trace from `_custom_provider_extra_body_for_agent` through OpenAI SDK merge to Ollama cloud passthrough. Per-model specifics (MiniMax M3 [0,2], DeepSeek, GLM), three-temperature-location alignment requirement, and `_fixed_temperature_for_model` behavior (Kimi OMIT_TEMPERATURE, Arcee 0.5, everything else None).
+- `references/temperature-validation-test-suite.md` — Reusable 4-question test suite for validating temperature changes are effective. Run at two temps, compare Q1-Q4 outputs. Includes expected results, validation criteria, and model-specific notes.
 - `references/profile-config-deep-clean.md` — Single-profile config.yaml deep-clean + max optimization workflow: remove unused sections, max all limits, set full permissions, configure auxiliary models to local Ollama, test infrastructure endpoints, fill empty values, categorize intentional empties.
+- `references/config-schema-classification.md` — Complete Hermes config.yaml key classification reference (v33): REQUIRED/RECOMMENDED/OPTIONAL/DEPRECATED/OBSOLETE for every key, gateway-only sections, invalid enum values found in real configs, stale defaults, bogus keys, minimal config templates by profile type, and batch cleaning script pattern. Built from deep research against DEFAULT_CONFIG source code + official docs.
+- `references/post-cleanup-verification.md` — After any bulk config change, `hermes config check` passing is NOT sufficient. Smoke-test every profile with a real chat query. Covers the sequential test pattern, what failures it catches (unreachable endpoints, model not found, auth failures), and the pitfall of parallel backgrounding causing event loop conflicts.
+- `references/multi-agent-config-validation-loop.md` — Proven 4-phase workflow for cleaning configs across many profiles: deep research → per-profile dev/Claude validation loop → smoke test → fix failures. Used successfully to clean 22 profiles (41% line reduction). Covers the ask-dev/ask-claude dispatch pattern, standard validation questions, and pitfalls.
 - `references/searxng-search-requirement.md` — Hard rule: ALWAYS use `mcp_searxng_searxng_web_search` for web searches, never the built-in `web_search` tool. User-corrected behavior.
 - `references/performance-tuning.md` — Comprehensive Hermes config performance/quality review: critical fixes (web.extract_backend), streaming, tool output limits, session pruning, checkpoints, browser engine, smart model routing, delegation depth, prompt caching, watch items, and bulk-patch YAML paths with verification commands.
 - `references/local-ollama-profile-model-selection.md` — When setting a profile model to an Ollama-hosted model, query the live local catalog, pick only from available models, and verify/correct the profile's `base_url` so it points at local Ollama rather than an inherited remote vLLM endpoint.
@@ -298,6 +302,9 @@ docker exec hermes-webui ls -d /workspace/{default,ai,automation,coding,comfy,dg
 
 ## Pitfalls
 
+- **`hermes config check` passing does NOT mean the profile works.** It validates YAML structure and key recognition only — it does not test that the model endpoint is reachable, the model exists, or auth works. After any bulk config change, smoke-test every profile with a real chat query: `hermes -p <name> chat -q "respond with exactly: OK <name>" -Q --max-turns 3 --yolo`. See `references/post-cleanup-verification.md` for the full pattern and what failures it catches. The CLI's YAML serializer interprets `off` as a boolean. The resulting `mode: false` is not a recognized approvals mode (valid values: `manual | smart | off` — all strings). The agent will fall back to default behavior (manual approval, which hangs in headless/cron contexts). **Fix:** use `execute_code` with `yaml.safe_load`/`yaml.dump` to write the string value directly, or edit config.yaml manually. Do NOT use `hermes config set` for this key.
+- **`approvals.cron_mode` is a SEPARATE gate from `approvals.mode`.** Even with `mode: off`, `cron_mode: deny` blocks dangerous commands in cron context. The agent must find another path rather than executing the command. For cron jobs that need full tool access, set BOTH: `approvals.mode: off` AND `approvals.cron_mode: approve`. These are independent gates — setting one does not affect the other.
+- **The `default` profile uses base `~/.hermes/`, NOT `~/.hermes/profiles/default/`.** `hermes -p default` targets the base config directory. `hermes profile list` shows it, but `ls ~/.hermes/profiles/default/` fails because the directory doesn't exist. When iterating profiles for bulk operations, include `default` by targeting `~/.hermes/config.yaml` and `~/.hermes/skills/` — not by looking for a `profiles/default/` directory. Count profiles as: base config + N profile dirs.
 - **`provider: custom` for ALL self-hosted endpoints (vLLM, Ollama, llama.cpp, etc.).** The correct provider ID is `custom`, NOT `openai`. The `openai` provider ID is reserved for the official OpenAI API with `OPENAI_API_KEY` / `openai-api`. Using `provider: openai` with a self-hosted base_url may appear to work in some cases but is incorrect per Hermes docs and will cause routing/auth issues. The docs canonical form:
   ```yaml
   model:
@@ -370,8 +377,9 @@ External APIs like Nous Research are configured as `custom_providers` entries +
   ```
   If you accidentally modify one, revert by reloading the snapshot and setting the field back, or restore from `~/.hermes/backups/pre-update-*.zip`. Snapshots are NOT git-tracked, so there's no `git checkout` fallback.
 - **"Unknown toolsets: moa, rl" warning at startup means stale toolset entries in config.** The `moa` and `rl` toolsets are off-by-default and their tool modules don't exist. Removing them from the `toolsets:` list silences the warning. This does NOT disable the `/moa` slash command — MoA is a core feature, not a toolset. Use line filtering (not YAML parse/dump) for safe removal — see `references/toolset-cleanup.md`.
-- **Model temperature is NOT user-configurable for the main inference path (v0.17.0).** Do NOT tell the user they can set `model.temperature` — that key does not exist in the config schema (confirmed via DEFAULT_CONFIG introspection). `_fixed_temperature_for_model()` (`agent/auxiliary_client.py:287-306`) only returns OMIT_TEMPERATURE for Kimi/Moonshot and 0.5 for Arcee Trinity; everything else gets no temperature field → provider default. PR #34219 would add `model.temperature` but is open/unmerged. Per-subsystem temps DO work: `compression.summarization.temperature` (default 0.3), `auxiliary.vision.temperature` (0.1), MoA preset temps. For Ollama `:cloud` models, the backend honors `options.temperature` but Hermes never sends it — the fastest fix is a Modelfile (`FROM <model>:cloud` + `PARAMETER temperature <x>`, `ollama create`). See `references/model-temperature-configuration.md` for the full stack analysis and ranked workarounds.
+- **Model temperature IS configurable via `custom_providers[].extra_body.temperature` (confirmed v0.18.0).** Do NOT tell the user they can set `model.temperature` — that key does not exist in the config schema. The working mechanism is `extra_body.temperature` nested under the Ollama `custom_providers` entry. This merges into the OpenAI SDK's `extra_body` kwarg, which becomes a top-level `temperature` field in the JSON request body. Ollama's cloud proxy forwards it verbatim to the cloud provider. Confirmed working for MiniMax M3 (range [0,2]), DeepSeek, GLM, and other `:cloud` models. Three temperature locations must be aligned for consistency: `custom_providers[].extra_body.temperature` (main model), `moa.presets.<name>.reference_temperature`, and `moa.presets.<name>.aggregator_temperature`. See `references/model-temperature-configuration.md` for the full stack analysis, confirmed code paths, and per-model specifics.
 - **NEVER assume model selection for cron jobs.** When creating agent-driven cron jobs, always ask the user which model/provider to use. Do not default to the session model or pick one yourself. Script-only cron jobs (`no_agent=true`) don't need a model. This applies to any cron job that uses an LLM — the model must be explicitly chosen by the user and pinned via the `model` parameter on `cronjob(action='create')` or `cronjob(action='update')`.
+- **Removing `cron:`, `gateway:`, or `streaming:` sections from a profile breaks its cron scheduler.** Even if a gateway process is running for that profile, the scheduler won't initialize without these config sections. During config cleanup, CLI-only profiles that still have cron jobs defined in `jobs.json` must retain these sections. The `cron:` section with `chronos.portal_url` is sufficient — the gateway and streaming sections can be minimal. See `hermes-cron-management` skill for the full cron lifecycle.
 - **`discover_models` on a `custom_providers` entry controls the `/model` picker source.** When `true` (or absent with an api_key set), the picker calls `<base_url>/v1/models` and uses the live response. When `false`, the picker is locked to the static `models:` dict under that entry. The picker logic lives in `hermes_cli/model_switch.py` (`should_probe` block) and the live fetch caches to `<HERMES_HOME>/provider_models_cache.json` (deleted on `--refresh`). Implication: if a user says "the /model picker only shows N models for provider X", the fix is almost always flipping `discover_models: false` → `true` on that custom_provider entry across all configs — not adding more entries to the static `models:` list. Always do a live `curl` against `<base_url>/v1/models` first to confirm the endpoint actually returns more than the static list claims, before writing to 9 files.
 - **When an agent stops early ("stopped after N iterations"), check `agent.max_turns` in the ACTIVE PROFILE first, not the server.** vLLM has no built-in iteration limit — it serves requests until the client stops. nuntius-mcp has its own `max_iterations` but is a separate system. The #1 culprit is the profile's `agent.max_turns` overriding the base config's higher value. If the stopped-at number is exactly 60, 50, or 20, it matches a Hermes default and confirms the limit is Hermes-side. See `references/iteration-turn-limits.md` for the full multi-layer checklist.
 - **Reasoning models on vLLM need `extra_body` to disable thinking.** Models like `qwen3.6-35b-a3b-uncensored` on vLLM put output in the `reasoning` field with `content: null` by default. The `/chat/completions` endpoint returns HTTP 200 but the message content is empty. Fix: add `extra_body: {chat_template_kwargs: {enable_thinking: false}}` to the model entry in `custom_providers`. Verify with a direct curl before writing to all configs — test both with and without the flag to confirm the endpoint accepts it.