Start with the reported outcome
The official user-story collection links to many accounts of Hermes in practical use. A reported outcome is a useful lead, but usually leaves out some implementation detail. Preserve the original source and its date, describe what the author reports, and keep that separate from any implementation you propose.
Extract the goal, input, transformation and output. For a ticket-summary example, identify which tickets were read, how they were grouped and where the summary appeared. Then list what is missing: permissions, integration, selection rules, model, schedule or a way to verify completeness. Unknowns are useful research tasks rather than details to fill with plausible guesses.
Create the smallest reproducible version
Choose a sample with inspectable input and a harmless destination. Write a starter prompt in your own words, state prerequisites and define the result check. For a research brief, inspect source links and coverage before scheduling anything. A complete recipe explains recovery when an input is missing, not just the happy path.
After a successful trial, record the environment and observed output. Save the repeatable procedure as a skill when that is useful; the official skills system supports reusable procedural material. Keep account credentials and changing datasets outside the procedure. If another reader cannot reproduce the result, improve the missing step instead of treating the source's success as universal proof.
Scope and limits
This is our editorial method for developing examples, informed by the official collections and skills guidance. A community report remains community-reported until a separate reproduction provides evidence. Documentation support verifies the described mechanism, not the story's business results, cost savings or suitability for every account.
Primary sources
Spotted something wrong or out of date? Tell us on X at @HermesWatcher (opens in a new tab) and we will fix it.
New Hermes Agent updates every day on X. Follow @HermesWatcher