hermes - 💡(How to fix) Fix fix(cron): scope skill index to bound skills when cron job specifies skills=[...]

Problem

When a cron job is bound to a single skill (via cronjob action=create skills=[X]), the cron agent's system prompt still contains the global skill index — every skill discoverable in ~/.hermes/skills/ plus external skill dirs. The bound skill's instructions are in the user message, but the index advertises every other skill as an available option.

Concrete repro from @gbanyan in #492: two cron jobs, ai-news-zh bound to a web-crawling skill and freshrss-triage bound to a FreshRSS reader skill. Once both existed, the model running ai-news-zh started silently using FreshRSS data instead of crawling its source URLs, because the global skill index put FreshRSS in front of it as a "convenient alternative."

Their workaround disables the entire skills toolset in cron, which regresses anyone who legitimately wants skills_list/skill_view for dynamic discovery inside cron prompts.

Proposed fix

When a cron job specifies skills=[...], scope the skill index that appears in the system prompt to only those skills (and their referenced/linked skills, if any). Other skills are still loadable via skill_view if the agent explicitly asks for them by name — they just don't appear pre-advertised in the index.

Implementation lives in agent/prompt_builder.py around the iter_skill_index_files call sites (lines ~1080, ~1132). The cron job's bound-skills list is already available via cron/scheduler.py's job config; needs to be threaded through to _build_system_prompt.

Scope

• Cron-only behavior change. Interactive CLI / gateway sessions keep the full skill index.
• Backward-compatible: cron jobs without skills=[...] get the same full index they get today.
• No SKILL.md schema change.

Out of scope

The broader "Autonomous Skill Templates" framing in #492 (per-skill tool allowlists, requirement declarations, per-skill model config, skill→cron bridge as a new surface) — those were either already covered by existing enabled_toolsets / cronjob capabilities or conflicted with prompt-cache invariants. This issue is the one concrete bug that surfaced from that thread.

Reference

• #492 (closed) — original proposal that surfaced this bug
• #25752 — prior cron toolset hardening for context