Patch Wizard

Finding

Small Hermes maintenance edits become risky when agents rewrite whole files instead of applying narrow, reviewable patches.

Current

A real Hermes installation usually accumulates prompts, skills, runbooks, public pages, config notes, workflow files, and documentation that need frequent small corrections. If those edits are handled as broad rewrites, the operator risks losing proven wording, introducing unrelated changes, and making review harder than the actual fix. Patch Wizard maturity means the installation treats targeted patching as the default for small, local changes.

Suggested

Define a patch-first decision boundary for maintenance work. Exact change: add a short rule to SOUL.md or the profile maintenance prompt: “Use targeted patches for typo fixes, prompt refinements, skill updates, small config edits, and public copy changes; use full rewrites only for new files, schema changes, or major restructuring.”
Add patch verification to the file-editing runbook. Exact change: update the relevant skill or runbook section for file work with this habit: after every patch, review the diff, confirm the changed section still matches the task, and run the smallest relevant syntax, lint, or smoke check before reporting success.
Make patch scope visible in public-content and skill updates. Exact change: add a checklist item to the content workflow, dashboard copy workflow, or skill hygiene prompt: “State which exact section was patched, why the patch was narrow, and what was intentionally left unchanged.”

Impact

Targeted patches reduce accidental regressions because the edit surface stays small. They also make human review faster: the operator can inspect one clear change instead of comparing an entire regenerated file. Over time, this makes Hermes maintenance safer across skills, prompts, runbooks, public documentation, and workflow definitions.

Effort

Small — this requires one prompt or runbook rule, one verification habit, and consistent use of existing patch tooling rather than a new system.

Public page note

Safe public content can explain the patch-first maturity rule, the kinds of edits that should be patched, and the review benefits of narrow diffs. Internal-only content should exclude private file paths, raw diffs from sensitive repositories, logs, secrets, credentials, exact config values, and any unreleased operational details.