Docs Archaeologist

Finding

Hermes decisions often become slower and riskier when operators jump straight into building, prompting, or configuration changes without first checking official Hermes docs and local documentation.

Current

A mature Hermes installation likely has official docs, local notes, skills, saved runbooks, and previous session knowledge available, but the lookup habit can remain inconsistent. The weak point is not lack of information; it is the missing operating rule that documentation is checked before new workflows, config changes, cron jobs, public pages, or custom integrations are created.

Suggested

Add a docs-first gate before Hermes changes. Exact change: update SOUL.md or the main operator runbook with: “Before building or configuring Hermes, check official Hermes docs, local docs, relevant skills, and recent saved artifacts; only build custom logic after confirming no native feature already covers the need.”
Create a reusable documentation source map. Exact change: add /opt/data/home/research/hermes/source-map.md with sections for official docs, GitHub releases, local config docs, skills, public Agent Info pages, and internal runbooks, then require every Hermes recommendation to cite at least one entry from that map.
Add a verification habit to research and optimizer prompts. Exact change: patch the Optimizer Agent review cron prompt or Hermes research skill to include: “For every suggested Hermes change, state which official doc, local doc, skill, or saved artifact was checked; if none was checked, label the recommendation incomplete.”

Impact

This turns documentation lookup into an operating control instead of an optional courtesy. It reduces duplicated work, prevents custom builds that Hermes already supports natively, and improves confidence before touching config, cron, memory, tools, or public-facing pages. Over time, the installation accumulates a reusable documentation map that makes future decisions faster and less dependent on chat memory.

Effort

Small — one runbook or SOUL.md rule, one source-map file, and one prompt/skill patch are enough to make the habit repeatable.

Public page note

Safe public content includes the docs-first maturity principle, generic source categories, recommended verification habits, and examples of public-safe documentation workflows. Internal-only content includes private filesystem paths with sensitive contents, raw chat excerpts, credentials, environment values, config secrets, unpublished runbooks, and any local documentation that reveals operational vulnerabilities.