a66996ac10
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.
483 lines
No EOL
11 KiB
Markdown
483 lines
No EOL
11 KiB
Markdown
#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/<Project Name>/
|
|
|
|
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. |