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.

3. Resources/Research/prompts/Continuation Prompt.md

@@ -0,0 +1,43 @@
+# **When Hermes reaches its context limit, use the vault to create a clean handoff before starting a new instance.**
+
+```
+You are approaching the context limit. Stop starting new work and perform the session-end procedure now.
+
+Update all relevant project files, 00-HERMES/Current State.md, 00-HERMES/Session Handoff.md, and Knowledge-Vault Projects Index.md.
+
+In Session Handoff.md, record:
+- What we were trying to accomplish
+- What was completed
+- What remains unfinished
+- What failed or is unverified
+- The exact current state
+- The exact next action
+- Relevant file paths, commands, errors, decisions, and warnings
+- Which files you modified
+
+Do not summarize vaguely. Write enough detail for a new Hermes instance to continue without asking me to repeat the session.
+
+```
+
+# **<font color="#0070c0">Then start a new Hermes instance and paste your startup prompt:</font>**
+
+
+```
+Use my Obsidian vault as your persistent memory.
+
+Read 00-HERMES/Hermes Vault Prompt.md first, then follow its startup procedure. Read the current state, operating manual, session handoff, project index, and relevant project files before beginning work.
+
+Reconstruct the current state of my projects and systems. Report your understanding, active projects, blockers, decisions, and next actions before proceeding.
+
+During the session, save durable information to the appropriate vault files. Before ending, follow the session-end procedure and update all affected project notes, Current State.md, Session Handoff.md, and Knowledge-Vault Projects Index.md.
+
+```
+
+**If it already reached it's context length do this one** 
+
+```
+The previous Hermes instance reached its context limit before completing the handoff. Inspect the vault and reconstruct the current state from the existing notes, project files, commands, logs, and any unfinished changes.
+
+Do not assume the previous task was completed. Mark anything without evidence as Unverified. First report what you can determine, what is missing, and the safest next action.
+
+```

3. Resources/Research/prompts/Hermes Vault Prompt.md

@@ -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.

3. Resources/Research/prompts/Impeccable Styles.md

@@ -0,0 +1,95 @@
+cde#installimpeccable #imnpeccablehermes #impeccablestyles 
+
+
+Impeccable has a Hermes Agent integration, so the simplest setup is to install it from your project directory.
+
+1. Open a terminal in your project:
+
+bash
+
+```
+cd /path/to/your/project
+```
+
+2. Run the installer:
+
+bash
+
+```
+npx impeccable install
+```
+
+Choose Hermes Agent when prompted, then choose whether to install it for:
+
+- This project only — recommended initially
+- All projects — useful if you want Impeccable available everywhere
+
+The installer selects the appropriate build and creates the files/integrations supported by your coding agent. Impeccable explicitly lists Hermes Agent as a supported tool. [GitHub](https://github.com/)
+
+3. Start Hermes in that project and initialize Impeccable:
+
+text
+
+```
+/impeccable init
+```
+
+This inspects the existing project and establishes design context. It can create or use:
+
+- `PRODUCT.md` — product purpose, users, and accessibility requirements
+- `DESIGN.md` — colors, typography, spacing, components, and design rules
+
+Those files let future Hermes sessions preserve the same visual system instead of redesigning each page independently. [GitHub](https://github.com/)
+
+Then give Hermes a concrete task, for example:
+
+text
+
+```
+/impeccable audit the current dashboard and fix the highest-impact visual and usability issues.
+```
+
+Useful commands include:
+
+text
+
+```
+/impeccable polish the settings page/impeccable critique the landing page/impeccable typeset the dashboard for better hierarchy and readability/impeccable layout improve spacing and grouping without changing the brand/impeccable colorize the page using the existing design system/impeccable simplify the onboarding flow/impeccable document
+```
+
+The commands are intended to be used directly in the agent conversation, and `document` records the project’s visual system in `DESIGN.md`. [GitHub](https://github.com/)
+
+If the normal installer does not recognize Hermes, try the shared skills installer:
+
+bash
+
+```
+npx skills add pbakaus/impeccable
+```
+
+Then restart Hermes and try:
+
+text
+
+```
+/impeccable init
+```
+
+For best results, give Hermes product context before asking for visual changes:
+
+text
+
+```
+/impeccable polish the billing page.
+Users are small-business owners reviewing their subscription.The primary goal is to make plan comparison and cancellation status immediately clear.Keep the existing brand colors and rounded-card component.Prioritize mobile usability and accessibility.Do not add gradients, unnecessary cards, decorative animations, or new dependencies.
+```
+
+A practical workflow is:
+
+text
+
+```
+/impeccable init/impeccable audit the page/impeccable polish the highest-priority issues/impeccable document
+```
+
+Run `init` once at the beginning, use `audit` before large changes, and use `document` after the design system has stabilized. Since Hermes retains skills and project information between sessions, keeping `PRODUCT.md` and `DESIGN.md` in the repository helps it maintain continuity. [nousresearch.com](https://hermes-agent.nousresearch.com/)

3. Resources/Research/prompts/Promp SatsAmp Fluidity.md

@@ -0,0 +1,54 @@
+```
+Here's the full playbook — symptoms, how we cornered each agent, and the exact
+commands. Paste the "Recipe" part into any agent for another app.
+What was wrong in SatsAmp (3 stacked causes)
+1. Main-thread disk I/O inside composition. StationRepository (~290ms) and
+StreamRepository (~130ms) read SharedPreferences + parse JSON in their
+constructors. Hilt builds singletons lazily, so that cost landed inside the
+first page-visit's tap frame.
+2. Tab taps animated through every intermediate page, composing/disposing
+heavy screens mid-flight, plus the selected-indicator tracked settledPage
+(lags the animation).
+3. Debug-build tax. First-touch class verification + JIT + shader compile
+produced 400-1100ms frames that only exist in debuggable builds. Release (R8 +
+install-time AOT) collapsed p99 from 900ms → 18-65ms.
+Also fixed along the way: an equalizer composable running
+rememberInfiniteTransition in every list row even when paused, one unkeyed
+LazyColumn, missing row placement animations.
+Recipe: diagnose jank in any Android app
+4. Setup. adb devices, note the device. Get tap coordinates once: adb shell
+uiautomator dump /sdcard/ui.xml, pull the bounds of the buttons you'll drive.
+5. Measure per interaction, not lifetime. Stats accumulate — always reset
+right before the action, sleep, then dump:
+adb shell dumpsys gfxinfo <pkg> reset > /dev/null
+adb shell input tap <x> <y>; sleep 2
+adb shell dumpsys gfxinfo <pkg> | grep -E "Total frames|Janky
+frames:|95th|99th|Slow UI|Slow issue|input latency"
+Key fields: Slow UI thread vs GPU percentiles (in the full dump: 90th gpu
+percentile). GPU > 2ms + slow UI thread = CPU-side problem, stop looking at
+overdraw/shaders.
+6. Idle test — rule out runaway animation. Reset, sleep 6, dump. Total frames
+rendered: 0 = rendering is on-demand, nothing spins. Dozens+ frames idle =
+find the rememberInfiniteTransition / ticker that's always mounted.
+7. Isolate tap path vs content path. Tap the already-selected tab. Clean (0
+janky) = the stall is incoming-page work, not ripple/nav handling.
+8. StrictMode — catches main-thread I/O with stack traces. Add in
+Application.onCreate, gated on debuggable, penaltyLog() only (never crash):
+StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
+    .detectDiskReads().detectDiskWrites().detectNetwork()
+    .detectCustomSlowCalls().penaltyLog().build())
+Drive the app, then adb shell logcat -d | grep StrictMode. Look for app frames
+(at com.yourapp...) and durations — ours showed repository constructors at 130-
+290ms firing from hvilViewModel() during composition.
+9. Composition timing probe. Wrap page content: remember { nanoTime() } +
+SideEffect { log(elapsed) }. Ours showed 6-24ms — proving composition was
+innocent and the stall was elsewhere in the frame.
+10. Per-frame table for position. adb shell dumpsys gfxinfo <pkg> framestats,
+find the Flags= rows missed vsync; compare
+PerformTraversalsStart vs IntendedVsync — a big gap before traversals start
+- dumpsys gfxinfo without reset shows lifetime stats — always reset per
+experiment.
+- am profile start/stop produced 0-byte files whenever a tap occurred mid-
+trace on this device; in-app probes (StrictMode, FrameMetrics, SideEffect
+timers) were more reliable than device-side
+```

3. Resources/Research/prompts/Prompt - 2d Animation.md

@@ -0,0 +1,271 @@
+### What I'd use locally
+
+If you're running **Qwen3.8 Flash locally**, I'd actually keep it for the **planning/director role**.
+
+Your pipeline would look roughly like:
+
+**Qwen3.8 Flash**  
+→ transcript analysis  
+→ characters  
+→ storyboard  
+→ shot prompts  
+→ asset list
+
+**Image model**  
+→ character sheets  
+→ backgrounds  
+→ props
+
+**Video/animation model**  
+→ animate each shot
+
+**FFmpeg / editing software**  
+→ assemble shots + narration + music + captions
+
+The key is that you **don't need one giant model to do everything**.
+
+If your laptop is the Framework machine you've been using for your local AI setup, the exact model choice depends heavily on your GPU/RAM. If you're **CPU-only or using integrated graphics**, I'd approach this very differently than if you have an NVIDIA GPU.
+
+If you tell me **your exact Framework specs (CPU, RAM, and GPU—if any)**, I can give you a specific local stack—**model by model—and tell you which parts Qwen3.8 Flash should handle versus which model should generate the actual 2D animation.**
+
+
+
+```
+You are an expert 2D cutout animation director and storyboard artist.
+
+I already have a completed narration transcript. Your job is to convert the transcript into a simple, AI-friendly 2D cutout animation plan.
+
+IMPORTANT:  
+Do NOT rewrite the narration.  
+Do NOT add unnecessary dialogue.  
+Do NOT create complicated animation.  
+Do NOT use realistic 3D animation.  
+Do NOT use anime.  
+Do NOT use detailed frame-by-frame animation.
+
+ANIMATION STYLE:
+
+- Simple 2D cutout/vector animation
+    
+- Flat colors
+    
+- Clean, minimal shapes
+    
+- Simple characters with recognizable silhouettes
+    
+- Simple facial expressions
+    
+- Characters constructed from reusable pieces: head, torso, arms, hands, legs
+    
+- Limited animation
+    
+- Characters can slide, walk, point, turn, gesture, nod, shake their head, sit, stand, or change facial expressions
+    
+- Reuse the same character designs throughout the entire video
+    
+- Reuse backgrounds whenever possible
+    
+- Use simple props and icons
+    
+- Use camera pans, zooms, and cuts to create visual interest
+    
+- Avoid complex physics, crowds, detailed environments, and complicated interactions
+    
+- Keep every shot easy for an AI image/video generation system to reproduce consistently
+    
+
+VISUAL PRIORITY:
+
+Narration > visual clarity > animation complexity.
+
+The visuals should support what the narrator is saying rather than trying to literally animate every word.
+
+CHARACTER CONSISTENCY:
+
+Create a small cast of recurring characters.
+
+For each character define:
+
+- Character name
+    
+- Age range
+    
+- Gender presentation if relevant
+    
+- Body shape
+    
+- Hair
+    
+- Clothing
+    
+- Main colors
+    
+- Distinguishing features
+    
+- Default facial expression
+    
+- Personality conveyed visually
+    
+
+Once a character is defined, NEVER redesign that character later in the video.
+
+BACKGROUND CONSISTENCY:
+
+Use a small number of reusable locations.
+
+For each location define:
+
+- Location name
+    
+- Basic layout
+    
+- Major objects
+    
+- Color/style
+    
+- Important recurring props
+    
+
+SHOT DESIGN:
+
+Break the transcript into individual shots.
+
+For every shot provide:
+
+1. Shot number
+    
+2. Transcript section being illustrated
+    
+3. Estimated duration
+    
+4. Location/background
+    
+5. Characters present
+    
+6. Character poses
+    
+7. Character actions
+    
+8. Facial expressions
+    
+9. Props
+    
+10. Camera movement
+    
+11. On-screen text, if needed
+    
+12. Transition from previous shot
+    
+13. Exact image-generation prompt
+    
+14. Exact animation/video-generation prompt
+    
+
+Keep individual shots visually simple.
+
+Prefer shots that can be generated using one static image plus limited motion.
+
+Whenever possible, use:
+
+- Character movement
+    
+- Camera movement
+    
+- Object movement
+    
+- Simple transitions
+    
+
+instead of complex animation.
+
+SHOT COMPLEXITY RULE:
+
+Every shot should receive a complexity rating from 1–5.
+
+1 = almost completely static  
+2 = one simple movement  
+3 = several simple movements  
+4 = moderately complex  
+5 = complex
+
+Try to keep at least 80% of the shots at complexity 1–3.
+
+If a shot would be complexity 4–5, redesign it into multiple simpler shots.
+
+AI GENERATION RULE:
+
+Design every shot so that an AI image/video model has the highest possible chance of maintaining character consistency.
+
+Avoid:
+
+- Multiple characters physically interacting
+    
+- Hands touching complicated objects
+    
+- Characters holding many objects
+    
+- Rapid movement
+    
+- Large crowds
+    
+- Complex camera movements
+    
+- Detailed backgrounds
+    
+- Multiple simultaneous actions
+    
+- Tiny text inside generated images
+    
+
+Instead, use separate shots.
+
+OUTPUT STRUCTURE:
+
+FIRST:  
+Give me the overall visual style guide.
+
+SECOND:  
+Give me the reusable character designs.
+
+THIRD:  
+Give me the reusable background/location designs.
+
+FOURTH:  
+Create the complete shot list in a table.
+
+FIFTH:  
+Provide the image-generation prompts for every shot.
+
+SIXTH:  
+Provide the animation/video-generation prompts for every shot.
+
+SEVENTH:  
+Provide a list of reusable assets that should only be generated once, including:
+
+- Characters
+    
+- Backgrounds
+  
+    
+- Props
+    
+- Icons
+    
+- Logos
+    
+
+EIGHTH:  
+Provide a recommended production workflow explaining exactly which assets should be generated first and how they should be reused across the video.
+
+VERY IMPORTANT:
+
+Do not attempt to make the animation visually impressive through complexity.
+
+Make it look intentionally simple, clean, consistent, and professional.
+
+The goal is a style that a local AI pipeline can realistically produce repeatedly without character drift or excessive rendering requirements.
+
+Here is the transcript:
+
+[PASTE TRANSCRIPT HERE]
+```

3. Resources/Research/prompts/Prompt - Orion Boilerplate.md

@@ -0,0 +1,47 @@
+Prompt Kyles Boilerplate Orion
+
+```
+Use this GitHub repository as the source of truth:
+
+https://github.com/kyleisuncool/orion-boilerplate
+
+I want my current repository configured to follow the boilerplate’s conventions and all applicable instructions.
+
+First, inspect the repository yourself. Find and read all relevant instruction and configuration files, including—but not limited to:
+
+- README.md
+- CONTRIBUTING.md
+- AGENTS.md
+- CLAUDE.md
+- GEMINI.md
+- .github/ instructions and workflows
+- package.json or equivalent project manifests
+- Makefile, Taskfile, justfile, or setup scripts
+- .editorconfig
+- .gitignore and .gitattributes
+- linting, formatting, testing, pre-commit, and CI configuration
+- any nested instruction files in subdirectories
+
+Treat more-specific instructions in nested directories as taking precedence over general instructions. Follow the instructions you discover rather than inventing replacements.
+
+Compare those requirements with my current repository and create a migration plan. The plan should identify:
+
+1. Which files need to be copied, adapted, or created
+2. Which commands and scripts I should use
+3. Which Git settings are repository-specific versus global
+4. Any dependencies or tools I need to install
+5. Any conflicts with my current setup
+6. Any potentially destructive actions
+
+Do not make changes yet. Do not:
+- Delete files
+- Rewrite Git history
+- Reset branches
+- Force-push
+- Change my Git username, email, remotes, SSH keys, or credentials
+- Copy secrets, API keys, private keys, or .env files
+- Overwrite existing configuration without explaining the difference
+
+After presenting the plan, wait for my approval. Once approved, give me exact commands in small, reversible steps and verify each step. Preserve my existing source code and uncommitted work.
+
+```

3. Resources/Research/prompts/Prompt Design Copy.md

@@ -0,0 +1,4 @@
+
+
+
+

3. Resources/Research/prompts/Prompt Impeccable Styles - Hermes Agent.md

@@ -0,0 +1,86 @@
+```
+I want you to install and use Impeccable to improve the frontend/UI of this project.
+
+Official documentation:
+https://impeccable.style/docs/
+
+Follow this process carefully:
+
+1. Inspect the current project and identify:
+   - Framework and version
+   - Package manager
+   - Available scripts
+   - Styling solution
+   - Component library
+   - Existing design tokens or theme files
+   - Main entry points and important UI screens
+
+2. Verify whether Impeccable is already installed for Hermes.
+   Check for:
+   - .hermes/skills/impeccable/
+   - Any existing Impeccable SKILL.md file
+   - PRODUCT.md
+   - DESIGN.md
+   - Existing Impeccable configuration or hooks
+
+3. If Impeccable is not installed, install it for this project using the official method:
+   npx impeccable install
+
+   Select Hermes Agent when prompted and choose a project-local installation.
+
+   If the official installer does not work, inspect the Impeccable documentation and use the Hermes-compatible fallback installation method. Do not invent a custom implementation unless necessary.
+
+4. After installation:
+   - Confirm that the Impeccable skill is available to Hermes.
+   - Reload or restart the relevant Hermes session if required.
+   - Verify the skill using Hermes’s skill discovery mechanism.
+   - Do not continue until you have confirmed that Impeccable is installed or clearly explain the exact blocker.
+
+5. Initialize Impeccable for this project:
+   /impeccable init
+
+   Use the project files and existing UI to determine the product context. Create or update PRODUCT.md with:
+   - What the product does
+   - Its target users
+   - The primary user goals
+   - The important workflows
+   - Brand, technical, and accessibility constraints
+   - Anything that must not be changed
+
+6. Document the existing visual system separately:
+   /impeccable document
+
+   Preserve good existing design decisions. Do not replace the entire UI with a generic template.
+
+7. Analyze the current interface before making changes. Run the most appropriate Impeccable reviews, including:
+   - /impeccable critique
+   - /impeccable audit
+   - /impeccable polish
+
+   Focus on hierarchy, usability, accessibility, responsive behavior, spacing, typography, visual consistency, loading states, empty states, error states, and interaction feedback.
+
+8. Propose a prioritized improvement plan before editing code. Separate the plan into:
+   - Critical usability or accessibility problems
+   - High-impact visual improvements
+   - Medium-priority consistency improvements
+   - Optional polish
+
+9. Implement the improvements incrementally. Reuse the project’s existing components and styling conventions where appropriate. Avoid:
+   - Unnecessary rewrites
+   - Random gradients
+   - Excessive rounded cards
+   - Generic AI-dashboard styling
+   - Poor color contrast
+   - Unnecessary dependencies
+   - Breaking existing behavior
+
+10. After implementation:
+   - Run the project’s type checks, linting, tests, and build commands.
+   - Run the Impeccable audit again.
+   - Check responsive layouts and important states.
+   - Fix any regressions you introduce.
+   - Summarize every changed file and the reason for each change.
+
+Start by checking the installation status and repository structure. Do not modify application code until the installation and initial inspection are complete.
+
+```

3. Resources/Research/prompts/Prompt Preparing Arch app for Debian.md

@@ -0,0 +1,35 @@
+```
+I don't know the exact build setup. Inspect the project, tell me what language it is, what dependencies it needs, and write me a Dockerfile that builds a Debian-compatible version and then push to my git
+```
+
+That one prompt covers the identification _and_ the Dockerfile in a single step.
+
+--- 
+
+Docker is only needed on _your_ Arch machine to _build_ the Debian version. Your friends just need the output file.
+
+Think of it like a bakery: you use the oven (Docker) to bake the bread, but your friends just eat the bread.
+
+## What your friends actually need
+
+| You give them               | They need to have                     | They do                                |
+| --------------------------- | ------------------------------------- | -------------------------------------- |
+| **`.deb` file**             | Nothing extra (it's native to Debian) | `sudo dpkg -i app.deb` or double-click |
+| **AppImage**                | Nothing extra                         | `chmod +x app.AppImage` then run it    |
+| **Static binary** (Go/Rust) | Nothing extra                         | `chmod +x app` then run it             |
+
+None of these require Docker, Node, Python, Go, or any build toolchain on the friend's side. They're just finished, self-contained files.
+
+So the workflow is:
+
+```
+Your Arch machine (has Docker)
+    └── docker build → produces app.deb or AppImage
+              │
+              ▼
+        Send the file to friends
+              │
+              ▼
+   Friend's Debian machine (no Docker needed)
+    └── runs the file directly   
+```

3. Resources/Research/prompts/Prompt for Receipts.md

@@ -0,0 +1,36 @@
+
+
+```
+TASK: Receipt Filing & Logging Automation
+
+TRIGGER: Run this workflow when I ask you to process new receipts.
+
+FOLDERS:
+- Source (watch): /home/avi/DCIM/Camera/
+- Destination A: /home/avi/Documents/Lab 484/Receipts  L484 Expenses/
+- Destination B: /home/avi/Documents/LLCs/LLC KCH Kingdom Compass/Receipts KCH Expenses/
+
+SPREADSHEETS:
+- Sheet A: /home/avi/Documents/00_EXPENSES_Lab484.ods  ← logs files in Destination A
+- Sheet B: /home/avi/Documents/00_Expenses_KCH.ods  ← logs files in Destination B
+
+WORKFLOW:
+1. SCAN: List all receipt files in the source DCIM folder that are NOT yet logged in Sheet A. If none, tell me "No new receipts found" and stop.
+
+2. ASK ME: For each new receipt, open/show it and ask: "What is this receipt for?" Wait for my answer (e.g., "gas", "groceries"). Do not guess.
+
+3. NAME IT: Look at the existing filenames in Destination A and infer the naming convention (date format, vendor/category placement, numbering). Name the new file using that exact pattern, inserting my category answer where the other files put theirs. Show me the proposed filename before copying and wait for confirmation.
+
+4. COPY: Copy (do not move) the receipt into both Destination A and Destination B using the confirmed name.
+
+5. LOG IT: In each spreadsheet, add one row matching the existing style — same columns, same date format, same capitalization. Include a working hypTerlink pointing to the copied file in that sheet's corresponding folder. Match any formatting (bold headers, currency columns, etc.) already used.
+   
+6. Each sheet should have a hyperlink to the file just created following the format of all the other entries for example  
+
+7. CONFIRM: Report back with the filename and confirm both copies and both spreadsheet rows were written.
+
+RULES:
+- Never overwrite an existing file; if the name collides, append -2, -3, etc.
+- Always copy, never move or delete from DCIM.
+- If a step fails, stop and tell me exactly what failed rather than continuing.
+```

3. Resources/Research/prompts/Starting a project specific instructions.md

@@ -0,0 +1,65 @@
+Hermes Agent supports project-specific instruction files, so the best way is to put the behavior in your project’s `.hermes.md` or `HERMES.md` file. Hermes also supports `AGENTS.md`, `CLAUDE.md`, and `.cursorrules`, but `.hermes.md`/`HERMES.md` takes priority when multiple context files exist. nousresearch.com1
+
+Create a file named `.hermes.md` in the project’s root directory and add this:
+
+markdown
+
+````
+# Project Continuity and Memory Protocol
+You are working on a long-running project. Maintain continuity across long contexts and future sessions.
+## Before starting work
+1. Inspect the project files and git status.2. Read `PROJECT_STATE.md` if it exists.3. Treat `PROJECT_STATE.md` as the current project source of truth.4. Do not redo completed work unless it is broken or I explicitly request it.
+## During work
+- Keep track of the project objective and acceptance criteria.- Record important decisions and the reasons behind them.- Track files created, modified, or deleted.- Record commands run, tests performed, and their results.- Record failed approaches and why they failed.- Distinguish confirmed facts from assumptions.- If the task changes direction, update the project state.
+## Context management
+When the conversation becomes long, before context compaction, or after a major milestone:
+1. Update `PROJECT_STATE.md`.2. Make the update concise but sufficiently detailed for another agent to continue.3. Preserve exact file paths, names, commands, configuration values, and unresolved issues.4. Never claim that work is complete unless it has been verified.
+## Required PROJECT_STATE.md format
+```markdown# Project State
+## ObjectiveWhat the project is trying to accomplish.
+## Requirements and constraintsImportant requirements, limitations, and acceptance criteria.
+## Current statusWhat is complete, in progress, blocked, or unverified.
+## DecisionsDecisions made and the reason for each.
+## Files and artifactsFiles created or changed, with a brief description.
+## Commands and verificationCommands run, tests performed, and their results.
+## Failed approachesApproaches attempted that did not work and why.
+## Open questionsIssues that still need to be resolved.
+## Next actionsThe exact next steps, in priority order.
+## Continuation instructionsA concise explanation of how a future agent should resume this project.
+````
+
+## At the end of every substantial task
+
+Update `PROJECT_STATE.md` before replying. Then report:
+
+- What changed
+- What was verified
+- What remains
+- The next recommended action
+
+````
+
+You can create it with:
+```bashcat > .hermes.md <<'EOF'# Project Continuity and Memory Protocol
+[ paste the instructions above here ]EOF
+````
+
+You should also create an initial state file:
+
+bash
+
+```
+touch PROJECT_STATE.md
+```
+
+Then tell Hermes:
+
+text
+
+```
+Set up the project continuity system now. Inspect the repository, create or update PROJECT_STATE.md using the required format, and from this point forward update it after every substantial task and before context compaction.
+```
+
+Hermes has built-in persistent memory, but that memory is intentionally bounded and is better for durable facts about your environment, preferences, and project conventions—not for storing the complete evolving state of one project. Project progress belongs in a file such as `PROJECT_STATE.md`; Hermes can read it again in later sessions. [nousresearch.com](https://hermes-agent.nousresearch.com/docs/user-guide/features/memory)
+
+One important limitation: a prompt cannot guarantee that the agent notices context exhaustion before it happens. The file-based approach is more reliable because the state is stored in the workspace rather than only in the conversation. Hermes also has automatic working-directory checkpoints for file changes, but those are rollback snapshots, not a replacement for a human-readable project log. [nousresearch.com](https://hermes-agent.nousresearch.com/docs/user-guide/features/overview)

3. Resources/Research/workflows/Keynctr Dev Loop.md

@@ -0,0 +1,17 @@
+---
+last-updated: 2026-09-13T23:00:00-05:00
+hermes-owned: true
+---
+
+# Keynctr Dev Loop (hot-reload UI, rebuild Rust)
+
+**Project:** [[keynctr]] · `frontend/` + Rust crate `keynectr`
+
+1. Build the backend once: `cargo build --release` (Electron spawns `target/release/keynectr serve`).
+2. Terminal A: `npx vite --port 5173` (in `frontend/`).
+3. Terminal B: `NOSTR_GUI_DEV_URL=http://localhost:5173 KEYNCTR_ENABLE_GPU=1 npx electron .`
+   - `KEYNCTR_ENABLE_GPU=1` is required on this machine ([[electron-apps-crash-software-gl-arch-hyprland]]).
+- **UI edits** hot-reload via vite — no restart.
+- **Rust edits** need `cargo build --release` + backend restart.
+
+Related: [[Workflows Index]]

3. Resources/Research/workflows/Polaris Vault Workflow.md

@@ -0,0 +1,39 @@
+---
+last-updated: 2026-09-25T23:30:00-05:00
+hermes-owned: true
+---
+
+# Polaris Vault Workflow
+
+> Standing directive (2026-09-25): new projects should operate like the **Polaris / orion boilerplate** — a plain-markdown, agent-maintained knowledge vault. Avi asked for "the full process of how I should guide you in following this boilerplate for new projects." Live instance: `/home/avi/Projects/Polaris/` (boilerplate from github.com/kyleisuncool/orion-boilerplate).
+
+## Structure
+- `0. Inbox/` — everything lands here first; goal is to get it OUT (daily notes live here).
+- `1. Projects/` — active work; every project needs a "done when" sentence.
+- `2. Areas/` — long-lived responsibilities; a finished project hands its knowledge back to an Area.
+- `3. Resources/` — things collected while working (PDFs, references); projects reference them.
+- `4. Decisions/` — decisions noted during work, cross-linked, hanging threads resolved here.
+- `5. Archive/` — only moved when told; reversible (`resume X` restores context).
+- `6. Templates/` — reusable document shapes (daily note, decision, contracts, hubs) to minimize token use.
+- `wiki/` — `hot.md` = current 360° state; `index.md`, `log.md` (log folds every ~22 entries into compacted lines).
+- `AGENTS.md` = the rulebook; skills in `.agents/skills/`: ingest, cascade, archive, close, daily, fold, skeleton, lint.
+
+## Commands (say to the agent)
+| Say | Effect |
+|---|---|
+| `new area: X` / `new project: X` | Creates hub against its contract |
+| `ingest` | Files everything in Inbox: people, decisions, updates, references |
+| `cascade` | Rewrites `wiki/hot.md` with everything learned this session, logs it |
+| `daily note` | Closes today's note, writes tomorrow's |
+| `weekly sweep` | One-line list of everything tracked |
+| `close workstream: X` | Finished project hands deliverable back to its Area |
+| `archive: X` / `resume X` | Retire/restore an Area |
+| `lint` | Health check: dead links, missing fields, overdue follow-ups |
+
+## Key conventions from the boilerplate walkthrough
+- Inbox → process → Projects (active) → Areas (retained knowledge) → Archive (done, retained, no usage penalty).
+- Deliverable flow: build artifact in the code repo, HTML → PDF via browser, put in Outbox, note who it went to + channel + where.
+- Inbox and Outbox exist per-machine (desktop + Nextcloud); bring-in docs go to project folder + Resources, with extracted summary + text-by-text copies in-vault.
+- Purpose: minimize token usage per session — keep reproducible templates, compacted logs, deep recall only on request.
+
+Related: [[User Preferences]] · [[Keynctr Dev Loop]] · [[Decisions Log (legacy)]] (D-2026-120)

3. Resources/Research/workflows/Power-Loss Safety Snapshot.md

@@ -0,0 +1,17 @@
+---
+last-updated: 2026-09-18T03:35:00-05:00
+hermes-owned: true
+tags: [shonar, power-loss, checkpoint, workflow]
+---
+
+# Power-Loss Safety Snapshot (Shonar engine + repo)
+
+Standing checklist before a predicted power cut (added 2026-09-18, `shonar-desktop-dev` skill):
+
+1. `git add -A && git commit` — commit even a WIP that may not compile (label it "WIP snapshot"). An uncommitted mid-edit is the only thing a hard cut truly loses.
+2. `PRAGMA wal_checkpoint(TRUNCATE)` + `PRAGMA integrity_check` on `engine.db` so nothing survives only in the WAL.
+3. Sweep stuck recordings: rows with `processing_status` not in (completed, failed, none) AND no queued/running job rows, whose transcribe+summarize jobs all succeeded, need `UPDATE recordings SET processing_status='completed', processing_error=NULL WHERE id=?` — `sweep_stale` requeues orphaned jobs at startup but never repairs the recording row, so the UI shows "processing" forever otherwise.
+
+**Concurrent-session note:** another Hermes session may be editing the same working tree live. Recompile before "fixing" a break you saw minutes ago — the sibling may have fixed it; snapshot-commit whatever compiles and tests green.
+
+Related: [[Shonar]] · [[Keynctr Dev Loop]]

3. Resources/Research/workflows/Workflows Index.md

@@ -0,0 +1,6 @@
+# Workflows Index
+
+## Workflows
+- [[Keynctr Dev Loop]]
+- [[Power-Loss Safety Snapshot]]
+- [[Polaris Vault Workflow]] — new-project vault boilerplate (directive 2026-09-25)