Review Hermes Automation Suggestions Before Accepting

/suggestions surfaces candidate automations that Hermes has recorded from recurring work. A suggestion is a proposal, not an active job. Review its schedule, task boundary, delivery destination, cost, and failure behavior before accepting it.

Official slash-command reference: https://hermes-agent.nousresearch.com/docs/reference/slash-commands

Work through the queue deliberately

Use /suggestions to list pending items, /suggestions accept <id> to create the selected automation, /suggestions dismiss <id> to reject one, /suggestions catalog to add curated starter ideas, and /suggestions clear to remove resolved records. Accepted suggestions preserve the current surface as their delivery origin, so review them from the channel or thread that should receive future results.

A recurring task should have a stable source, a bounded mutation policy, and a useful silence rule. Monitoring that says “all good” every hour can be worse than a job that reports only actionable change.

Acceptance checklist

• Confirm the source data is accessible without exposing secrets.
• Choose a schedule that matches the source's real update cadence.
• Define whether the job is read-only or can modify state.
• Require approval for paid, destructive, or external publication actions.
• Verify the current channel is the intended delivery origin.
• Add an exact silent/no-change behavior.
• Set a clear failure and retry policy.
• Estimate model and tool cost for the recurring cadence.

Pitfalls

• Accepting every suggestion because it sounds convenient.
• Creating duplicate monitors for the same source.
• Reviewing from a temporary thread and routing future reports there.
• Scheduling faster than the source can meaningfully change.
• Allowing a proposal to infer permission for purchases or publication.
• Producing repetitive status noise instead of actionable updates.

Verification steps

1. Inspect the full proposal and its intended delivery origin.
2. Compare it with existing cron jobs for duplicates.
3. Accept only a low-risk candidate or reproduce it in a test profile.
4. Inspect the created schedule, prompt, skills, model, and destination.
5. Trigger one manual run and review the actual output.
6. Confirm no-change and error cases behave as designed.
7. Pause or remove the job if the first run reveals an unsafe assumption.