hermes - 💡(How to fix) Fix Feature: Immutable/protected skills - prevent agent from modifying critical skills without user approval [1 participants]

Problem

The skill_manage tool treats all skills as fully mutable. The agent can create, patch, edit, or delete any skill in ~/.hermes/skills/ at any time. There is no way to protect critical skills (governance rules, safety constraints, domain-specific principles) from being modified or shadowed by the agent.

While external_dirs skills are read-only, the agent can create a local shadow copy with the same name that takes precedence — effectively replacing the protected skill without the user knowing.

Proposed Solution

Add an immutable flag to SKILL.md frontmatter:

---
name: my-governance-skill
metadata:
  hermes:
    immutable: true
---

Behavior when immutable: true:

1. skill_manage rejects any action (create/patch/edit/delete) on the skill
2. Local shadow copies cannot override an immutable skill from an external directory
3. Only user-initiated CLI commands can modify the skill:
   • hermes skills unlock <name> — temporarily allows modifications
   • hermes skills lock <name> — re-enables protection
   • hermes skills edit <name> — opens in $EDITOR (works on locked skills since it is user-initiated)
4. Agent attempts to modify immutable skills log a warning and notify the user via the active messaging channel

Why This Matters

Users building domain-critical workflows (financial analysis, medical, legal, security) need to encode principles that the agent must follow but cannot self-modify. The current architecture assumes the agent is always right about what to learn — but in high-stakes domains, the human must control which rules are negotiable and which are not.

The conditional activation system (requires_toolsets, fallback_for_tools) already demonstrates metadata-driven skill behavior. Adding immutable follows the same pattern.

Alternatives Considered

• Filesystem permissions (chmod 444): Fragile, breaks agent tool flow, not portable
• Git-tracked external dirs only: Agent can still shadow locally; detection not prevention
• Separate "protected" directory: Would work but adds conceptual complexity vs a simple metadata flag

Related

• The external_dirs read-only behavior already proves the concept of permission-scoped skill access
• The skill_manage tool already has action-based routing — adding a permission check is a small extension