Problem

Skills are unconditionally advertised in the system prompt regardless of whether their runtime dependencies are actually available. This causes the agent to claim capabilities it cannot deliver — it sees the skill in its prompt, promises the user it can help, then fails at execution time with cryptic errors.

This was first surfaced via #630 (GIF search), but the problem is systemic: any skill that depends on a CLI binary (e.g., himalaya, openhue, ddgs) or an API key (e.g., TENOR_API_KEY, NOTION_API_KEY) will exhibit the same behavior if those dependencies aren't installed.

Root Cause

1. build_skills_system_prompt() in agent/prompt_builder.py lists all skills in ~/.hermes/skills/ (filtered only by OS platform). There is no mechanism for a skill to declare runtime prerequisites.
2. skill_view() returns skill content with zero prerequisite validation — the agent gets instructions to run commands that may not exist.
3. Several bundled skills depend on non-universal CLI tools or API keys but don't declare this anywhere.

Proposed Solution

Add a prerequisites field to the SKILL.md frontmatter spec:

---
name: gif-search
description: Search GIFs from Tenor
prerequisites:
  env_vars: [TENOR_API_KEY]     # checked via os.getenv()
  commands: [curl, jq]          # checked via shutil.which()
---

Three layers of defense:

Skills that need prerequisites declared:

Design principles:

• Backward compatible — skills without prerequisites behave exactly as before
• Mirrors existing patterns — tools already use check_fn + requires_env for the same purpose; this brings skills to parity
• Generalizable — any future skill author just adds the frontmatter field

Related

• [Bug]: GIF lookup fails — no built-in tool, skill dependency not surfaced #630 — GIF lookup fails (the specific instance that surfaced this)

Environment

• Hermes Agent v1.0.0
• All platforms