# Safe self-optimization prompts

Two prompts. Run them in order. Phase 1 is audit-only and changes nothing.
Do not run Phase 2 until you have read the audit and chosen what you want.

---

## Phase 1 — Audit prompt

Read the "Build a Better Hermes Agent" SOP I have provided.

Audit only the active Hermes profile and current project workspace unless I
explicitly name additional paths or profiles.

Inspect the active profile's SOUL.md, memory usage, project context files, skill
index, and enabled toolsets. For knowledge folders, first inspect only filenames,
routing files, and metadata. Do not read full documents unless necessary to
evaluate a specific issue.

Do not inspect another profile, raw session transcripts, .env, auth files,
credential stores, browser data, private keys, customer records, or unrelated
personal or business files. If broader access appears necessary, list the exact
path and reason, then wait for approval.

Do not expose or print secrets, personal data, customer data, private
conversations, or sensitive business details. Prefer categories, filenames, and
short redacted summaries over quoted contents. Do not delete or overwrite files.
Do not change models, providers, credentials, permissions, gateways, scheduled
jobs, or live automations.

Return:

1. A redacted inventory of the current context layers, listing paths and
   categories rather than private contents.
2. Duplicated, stale, conflicting, overly broad, or always-loaded instructions.
3. Information stored in the wrong layer.
4. Missing retrieval pointers, verification rules, or safety boundaries.
5. The highest-value changes, ordered by expected impact and risk.
6. A proposed file-by-file change plan with backups and verification steps.
7. Anything you are uncertain about and need me to decide.

Prefer the smallest reversible improvements. Wait for my approval before
applying changes.

---

## Phase 2 — Implementation prompt

Use this only after reviewing the audit and choosing the changes you want.

First, restate the exact approved files and edits. If the approved scope is
incomplete or ambiguous, stop and ask one focused question. Otherwise, apply
only that restated list.

Before editing, choose a reversible method appropriate to each file: an existing
version-control diff, a Hermes checkpoint or snapshot, or a backup in a private
user-approved location. Do not create duplicate backups inside a repository or
shared folder. Preserve file permissions, do not back up .env, auth, credential,
or secret files, and report the rollback location before making changes.
Preserve existing approval boundaries. Do not modify models, providers,
credentials, gateways, scheduled jobs, live services, or profiles outside the
approved scope.

Use the smallest targeted edits. Do not replace an entire file when a focused
change will work. After editing:

1. Read back every changed file.
2. Check for duplicate or contradictory instructions.
3. Confirm no secret values were added to instruction, memory, knowledge, or
   skill files.
4. Confirm the intended knowledge and skills can still be found through clear
   triggers.
5. Do not spawn a fresh autonomous session unless I explicitly approve it. If a
   new session is needed to load the new context snapshot, give me the exact
   test prompt to run there.
6. Test with two or three user-approved, read-only or local sandbox tasks. Do
   not send messages, publish, deploy, spend money, modify live data, contact
   customers, restart services, or trigger automations as part of testing. If a
   meaningful test needs side effects, provide the proposed test and wait for
   separate approval.
7. Report exactly what changed, what was intentionally left unchanged, and how
   to roll back.
