Curator should not auto-archive user-created custom skills without dry-run/approval

[BadTechBandit]

Summary

After updating to the Curator release (v2026.4.30), Curator auto-ran on my live Hermes install and consolidated/archived a large number of personally-created custom workflow skills without a dry-run report or approval step.

I checked the local logs after filing this. I did not manually run hermes curator run. The run was launched by the gateway cron ticker calling Curator in the background.

This is related to the Curator work introduced around PR #16049 / the Curator RFC #16077.

What happened

Curator ran as an automatic background maintenance pass on a live install. The run archived skills by consolidation, not by stale pruning:

• agent-created skills before: 87
• after: 45
• archived/consolidated in the run: 54
• stale/unused prunings without merge target: 0
• new umbrella skills created: 12

The archived items included many personal/custom workflow skills that I had intentionally created for private workflows and project-specific operating procedures. I am intentionally not listing those skill names publicly here, but they were not disposable one-off skills from Hermes' own self-improvement loop.

Evidence that this was an automatic run

Local logs show:

• The gateway log recorded a Curator completion message from a background Curator session.
• The Curator session transcript begins with the internal prompt: You are running as Hermes' background skill CURATOR...
• There was no shell history entry for hermes curator run.
• The gateway source currently calls Curator from the cron ticker path:
  • gateway/run.py calls maybe_run_curator(idle_for_seconds=float("inf"), ...)
• Curator defaults to enabled when no config disables it:
  • agent/curator.py returns cfg.get("enabled", True)
• With no prior last_run_at, should_run_now() returns true.

So the precise issue is not "the update command directly ran Curator." The issue is that after the update, the gateway's background ticker auto-launched Curator because it was enabled by default and had no prior run state.

Problem

As a user, I had no clear way to distinguish:

• skills created by Hermes itself during self-improvement
• skills I personally created for custom workflows
• skills installed from a hub/bundled source
• skills that should never be touched without explicit approval

Curator appears to treat "not bundled / not hub-installed" as eligible for curation. That means user-authored custom skills and Hermes-authored temporary skills can collapse into the same bucket, which is dangerous.

The first run should not mutate a live skill library automatically. It should generate a review report first.

Expected behavior

For a live user install, Curator should be opt-in or report-first by default. A safer flow would be:

1. Curator takes an explicit target path / Hermes home / skills path.
2. It runs in dry-run mode first.
3. It writes a report showing exactly what it would archive, consolidate, or patch.
4. It explains why for each proposed action.
5. It requires explicit user confirmation before modifying anything.
6. It provides a clear way to mark/pin user-authored custom skills before the first live run.

Actual behavior

Curator auto-ran from the gateway background ticker and performed live consolidation/archival. It did preserve archived copies, but that is still a disruptive mutation because many custom skills are individually invokable workflows. Flattening them into broad umbrella skills changes discovery, invocation, profile behavior, and operational assumptions.

Why this matters

Auto-cleaning agent-generated skill clutter is useful. But silently consolidating custom workflow skills is too destructive for a first-run default. A skill library is not just documentation; it can encode private workflows, agent roles, recurring procedures, and project-specific operating rules. Broad umbrella consolidation may look tidy taxonomically while breaking how the user actually works.

Suggested fixes

• Do not run Curator automatically on existing installs after update.
• Add hermes curator run --dry-run and make first run report-only.
• Add a first-run migration/consent screen or CLI prompt for existing skill libraries.
• Add separate provenance for user-created vs agent-created, instead of only not bundled/not hub.
• Add a bulk pin / protect mechanism before first run.
• Make the LLM propose changes, but require deterministic code and/or user approval to apply archive/consolidation operations.
• Consider storing proposed actions as a review artifact instead of letting the LLM execute terminal mv operations directly.

Environment

• Hermes version: v2026.4.30-24-ge5dad4ac5
• Install type: local macOS Hermes install with multiple profiles
• Curator status after discovery: manually paused

I can provide sanitized local Curator report details if useful, but I do not want to post private skill names publicly.