hermes - 💡(How to fix) Fix hermes -z (oneshot) discards --skills silently [3 pull requests]

Summary

hermes -z (oneshot mode) accepts --skills <name> on the command line but the runtime entry point does not consume it. The skill is never loaded, the agent runs without that context, and the user gets a generic answer. No warning, no error.

Steps to reproduce

hermes -z --skills some-skill "your prompt here"

The agent runs as if --skills had not been passed.

Source evidence

• hermes_cli/_parser.py:180 — --skills declared as _inherited_flag at top level.
• hermes_cli/_parser.py:256 — --skills declared again on chat_parser.
• hermes_cli/oneshot.py:127 (run_oneshot()) — signature is (prompt, model, provider, toolsets); no skills parameter, so the parsed value is dropped on the way in.

(Verified against upstream/main at commit 186bf25cb, 2026-05-24.)

Expected behavior — two options

Option A (preferred — preserves CLI contract): run_oneshot() accepts skills: list[str] | None = None, propagates the value into the run context the same way chat does. Larger change but keeps the CLI surface consistent with what the parser advertises.

Option B (fail-loud, trivial): Parser rejects --skills when the subcommand is -z (oneshot) with a clear message: "--skills is not supported in oneshot mode; use hermes chat -s ... -q ... instead". Smaller change; documents the gap rather than closing it.

Happy to send a PR for whichever option maintainers prefer.

Context

Hit during downstream wiring of a DeFi orchestrator harness. The harness was supposed to invoke a single skill in oneshot mode; the LLM returned generic output and we wasted ~1 hour finding the silent drop. Worked around with hermes chat -s <skill> -q "<prompt>" (which honors -s).

Related issue: #28992 ("Use -z (oneshot) mode for kanban worker spawn instead of chat -q") — same motivational area; fixing this unblocks that pattern.