avi/Orion
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Orion vault — clean initial history

Browse source 
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.
This commit is contained in:
Avi 2026-10-02 08:34:04 -05:00
commit a66996ac10
233 changed files with 103810 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

483
3. Resources/Research/prompts/Hermes Vault Prompt.md Normal file
View file

@ -0,0 +1,483 @@
#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.