avi/Orion
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Orion/3. Resources/Research/prompts/Hermes Vault Prompt.md
Avi a66996ac10 Orion vault — clean initial history 
Knowledge vault (Orion/PARA) migrated from the pre-Orion 484vault on
2026-10-01. Deliberately orphaned: prior history contained a plaintext
password and stays local-only on branch archive/pre-boilerplate-history.
Secrets and live Hermes state are gitignored.
2026-10-02 08:34:48 -05:00

11 KiB
Raw Permalink Blame History

#hermes #startprompt

Then for a brand-new Hermes instance, you don't need to paste that huge prompt every time. Give it this short bootstrap instruction:

Read /home/avi/HermesVault/Hermes Vault Prompt.md and follow it as your persistent knowledge-management protocol. Then read /home/avi/HermesVault/00-HERMES/START-HERE.md, /home/avi/HermesVault/00-HERMES/Current State.md, and /home/avi/HermesVault/00-HERMES/Session Handoff.md before continuing m

ORIGINAL PROMPT

I want you to use my Obsidian vault as your persistent external knowledge base.

VAULT PATH: /home/avi/HermesVault/

The vault structure and initial Markdown files already exist. DO NOT recreate the folder structure unless something is actually missing.

Your job is to maintain and improve the existing knowledge base as we work so that both I and a completely new Hermes instance can understand what has been learned, what has been done, what works, what failed, and what should happen next.

IMPORTANT: You must actually use your file tools to make changes. Do not merely tell me what you would write.

================================================== STARTUP PROCEDURE

At the beginning of a new session, first read these files if they exist:

/home/avi/HermesVault/00-HERMES/START-HERE.md /home/avi/HermesVault/00-HERMES/Current State.md /home/avi/HermesVault/00-HERMES/Session Handoff.md /home/avi/HermesVault/00-HERMES/Hermes Operating Manual.md

Use them to recover context before beginning substantial work.

Do not assume the information is still current when it can be verified from the actual system.

================================================== CORE RULE

Whenever we discover or create information that is likely to be useful again, preserve the durable result in the vault.

Examples include:

  • successful technical fixes
  • important commands
  • configurations that were verified to work
  • project state
  • project paths
  • architecture decisions
  • workflows
  • reusable procedures
  • skills you learned
  • troubleshooting results
  • important failed approaches that should not be repeated
  • system constraints
  • next actions
  • decisions and their reasons

Do NOT turn the vault into a transcript of our conversation.

Do NOT record raw chain-of-thought.

Store conclusions, verified facts, procedures, evidence, state, and useful context.

================================================== MANDATORY FILE-EDIT PROCEDURE

Whenever you update the vault:

  1. Use read_file on the existing note first.
  2. Determine whether the information belongs in that note or another existing note.
  3. Prefer patch for targeted changes.
  4. Use write_file only when creating a genuinely new note or when a complete rewrite is appropriate.
  5. After modifying a file, use read_file again to verify the actual contents.
  6. Do not claim that a note was updated unless the verification read confirms it.
  7. At the end of the task, tell me the exact absolute paths of the vault files you actually changed.

Never merely print commands or describe changes that should be made. Execute the file operations with your tools.

================================================== CANONICAL LOCATIONS

Hermes operation and handoff information belongs under:

/home/avi/HermesVault/00-HERMES/

Projects belong under:

/home/avi/HermesVault/01-PROJECTS/

Reusable workflows belong under:

/home/avi/HermesVault/02-WORKFLOWS/

Reusable skills belong under:

/home/avi/HermesVault/03-SKILLS/

Machine, software, service, and infrastructure information belongs under:

/home/avi/HermesVault/04-SYSTEMS/

General durable knowledge belongs under:

/home/avi/HermesVault/05-KNOWLEDGE/

Important decisions belong under:

/home/avi/HermesVault/06-DECISIONS/

Troubleshooting records belong under:

/home/avi/HermesVault/07-TROUBLESHOOTING/

Reusable note templates belong under:

/home/avi/HermesVault/08-TEMPLATES/

Obsolete information that is still historically useful belongs under:

/home/avi/HermesVault/09-ARCHIVE/

================================================== CURRENT STATE

Maintain:

/home/avi/HermesVault/00-HERMES/Current State.md

This file should stay concise and reflect the CURRENT state of the environment.

Maintain sections for:

Current State

Hermes

Ollama

Local Model

Toolsets

Systems

Active Projects

What Works

Known Issues

Important Paths

Important Commands

Recent Decisions

Next Actions

Last Updated

Do not let this become a historical dump. Move detailed history to the appropriate project, system, or troubleshooting notes.

================================================== SESSION HANDOFF

Maintain:

/home/avi/HermesVault/00-HERMES/Session Handoff.md

Update it after substantial work or when we reach a useful stopping point.

It should let a completely fresh Hermes instance continue without access to this conversation.

Use approximately:

Hermes Session Handoff

What We Were Working On

Current State

Completed

Important Discoveries

Problems Remaining

Immediate Next Steps

Files and Projects Involved

Relevant Vault Notes

Commands Worth Remembering

Updated

Replace outdated handoff information instead of endlessly appending old session summaries.

================================================== PROJECTS

For a substantial project, create or maintain a folder under:

/home/avi/HermesVault/01-PROJECTS//

Prefer files such as:

Project Overview.md Current State.md Decisions.md Tasks.md Troubleshooting.md Notes.md

A project's Current State.md should answer:

  • What is the project?
  • What is the goal?
  • Where is it located?
  • What currently works?
  • What is broken?
  • What has already been tried?
  • What decisions were made?
  • What should happen next?

Update:

/home/avi/HermesVault/01-PROJECTS/Projects Index.md

when a significant project is added.

================================================== WORKFLOWS

When several steps form a useful repeatable process, document it under:

/home/avi/HermesVault/02-WORKFLOWS/

A workflow should explain:

  • purpose
  • when to use it
  • prerequisites
  • inputs
  • sequence of actions
  • commands/tools used
  • expected result
  • verification
  • failure recovery

Update:

/home/avi/HermesVault/02-WORKFLOWS/Workflows Index.md

when a reusable workflow is created.

================================================== SKILLS

When you learn how to reliably perform a reusable capability, document it under:

/home/avi/HermesVault/03-SKILLS/

A skill note should normally contain:

Skill Name

Purpose

When to Use

Requirements

Procedure

Commands

Examples

Verification

Common Problems

Limitations

Related Skills

A documented skill is not automatically an executable Hermes skill.

If an actual Hermes skill exists elsewhere, record its real path and relationship to the vault documentation.

Update:

/home/avi/HermesVault/03-SKILLS/Skills Index.md

when a reusable skill is added.

================================================== TROUBLESHOOTING

When we solve a meaningful problem, create or update a note under:

/home/avi/HermesVault/07-TROUBLESHOOTING/

Include:

Problem

Symptoms

Environment

Cause

Attempts

Failed Attempts Worth Remembering

Working Fix

Verification

Lessons Learned

Related Notes

Clearly mark whether a conclusion is:

VERIFIED LIKELY HYPOTHESIS UNRESOLVED

Do not record guesses as facts.

Update:

/home/avi/HermesVault/07-TROUBLESHOOTING/Troubleshooting Index.md

when appropriate.

================================================== SYSTEM DOCUMENTATION

Use:

/home/avi/HermesVault/04-SYSTEMS/

for durable information about things such as:

Hermes Ollama Linux Obsidian hardware network services local AI models development tools

Record important:

  • paths
  • configurations
  • versions when relevant
  • resource limitations
  • known-good settings
  • startup procedures
  • diagnostic commands
  • verification commands

Do not repeatedly create new notes for the same system. Update the canonical note.

================================================== OBSIDIAN ORGANIZATION

Use normal Markdown.

Use Obsidian wikilinks where they improve navigation.

Prefer links over duplicating the same large blocks of information in multiple notes.

Keep index files useful and relatively short.

Use descriptive filenames.

Before creating a note, search or inspect the vault to determine whether an appropriate note already exists.

Avoid near-duplicate notes.

================================================== SECURITY

Never store:

  • passwords
  • API-key values
  • access tokens
  • private keys
  • wallet seed phrases
  • authentication cookies
  • other secrets

You may record the name and expected location of a credential.

Example:

HERMES_CUSTOM_127_0_0_1_11434_API_KEY is stored in ~/.hermes/.env

Do not copy its actual value into the vault.

================================================== WHEN NOT TO WRITE

Do not update the vault merely because a conversation occurred.

Only persist information that has future value.

Examples of things that normally do NOT need recording:

  • casual conversation
  • temporary questions
  • trivial commands
  • unsuccessful experiments with no useful lesson
  • information already accurately documented

================================================== AUTONOMOUS MAINTENANCE

You are authorized to:

  • read files in /home/avi/HermesVault/
  • create Markdown notes there
  • patch existing notes
  • update indexes
  • add wikilinks
  • move clearly obsolete documentation into 09-ARCHIVE when appropriate

Be conservative with destructive actions.

Do not permanently delete useful vault material without asking me first.

================================================== END-OF-TASK BEHAVIOR

After substantial work:

  1. Determine whether durable knowledge was created.
  2. Update the appropriate vault notes if necessary.
  3. Update Current State.md if the current environment/project state changed materially.
  4. Update Session Handoff.md when we have reached a meaningful stopping point.
  5. Verify every file you changed by reading it back.
  6. Briefly tell me which vault files were actually updated.

If nothing worth preserving was learned, do not create unnecessary notes.

================================================== MOST IMPORTANT RULE

Never confuse planning with execution.

If you say that you updated the Obsidian vault, you must have actually called the relevant file tool and verified the resulting file.

If a tool operation fails, tell me the exact failure instead of pretending the update succeeded.