Customize processing prompts

This document introduces OpenViking's current prompt template system, with a focus on:

• what prompts currently exist
• which processing stage each prompt is used in
• which external capabilities or results each prompt affects
• the format requirements for template files
• how to customize prompts safely

This document only covers templates under openviking/prompts/templates/ plus a small set of configuration items related to template loading.

Overview

OpenViking's current prompts fall into two main groups:

1. Regular prompt templates
   • Stored under openviking/prompts/templates/<category>/*.yaml
   • Used to instruct the model to perform tasks such as image understanding, document summarization, memory extraction, and retrieval intent analysis
2. Memory schema templates
   • Stored under openviking/system_assets/memory/memory_templates/builtin/*.yaml
   • Used to define the fields, filename templates, content templates, and directory rules for a memory type

From a usage perspective, these templates mainly serve the following processing stages:

Category	Representative template	Main purpose	Effective stage	External capability affected
vision	vision.image_understanding	Image, page, and table understanding	Resource parsing and scanned-document understanding	Image parsing, PDF page understanding, table extraction results
parsing	parsing.context_generation	Document structure splitting and semantic node generation	Resource ingestion and parsing	Document chapter structure, node summaries, image summaries
semantic	semantic.document_summary	File-level and directory-level summaries	Semantic indexing	File summaries, directory overviews, downstream retrieval quality
retrieval	retrieval.intent_analysis	Retrieval intent analysis and query planning	Pre-retrieval analysis	Search query planning and context recall direction
compression	compression.ov_wm_v2	Working-memory compression and archived-session summarization	Session commit / memory pipeline	Session compression and working-memory quality
memory	profile	Memory type definitions	Memory persistence and updates	The organization and final content of different memory types
processing	processing.tool_chain_analysis	Extracting experience from interactions or resource background	Post-processing and experience distillation	Strategy extraction, tool-chain experience, interaction learning results
indexing	indexing.relevance_scoring	Candidate relevance evaluation	Retrieval and indexing support	Relevance scoring quality
skill	skill.overview_generation	Skill information distillation	Skill resource processing	Skill retrieval summaries
test	test.skill_test_generation	Automatic test case generation	Test and validation support	Skill test case generation

Prompt Format Requirements

Regular Prompt YAML

A regular prompt template usually contains the following fields:

metadata:
  id: "semantic.document_summary"
  name: "Document Summary"
  description: "Generate summary for documentation files"
  version: "1.0.0"
  language: "en"
  category: "semantic"

variables:
  - name: "file_name"
    type: "string"
    description: "Input file name"
    required: true

template: |
  ...

output_schema:
  ...

llm_config:
  ...

Field meanings:

• metadata
  • Describes the template identity and category
  • id usually corresponds to the file path, for example semantic.document_summary
• variables
  • Defines the input variables accepted by the template
  • Common fields include name, type, description, default, required, and max_length
• template
  • The actual prompt body sent to the model
  • Rendered with Jinja2 variables
• output_schema
  • Optional
  • Describes the expected output structure so callers can constrain model output
• llm_config
  • Optional
  • Describes suggested model-side parameters and is not part of the prompt body itself

When writing a regular prompt, follow these guidelines:

• Keep metadata.id consistent with the template category and purpose
• Keep variable names stable so they stay compatible with callers
• Ensure placeholders inside template match the definitions in variables
• If the template expects structured output, specify the fields, format, and constraints clearly
• If the input is length-sensitive, control prompt size through max_length or upstream truncation

Memory Schema YAML

memory/*.yaml files are not regular prompt text templates. They define memory types. The example below is only a schematic structure showing common fields. Whether a built-in template includes content_template, or whether its directory uses a subdirectory, depends on the specific memory type.

memory_type: "profile"
description: "User profile memory"
fields:
  - name: "content"
    type: "string"
    description: "Profile content"
    merge_op: "patch"
filename_template: "profile.md"
content_template: |
  ...
embedding_template: |
  ...
directory: "viking://user/{{ user_space }}/memories/..."
enabled: true
operation_mode: "upsert"
stage: "user"
peer_enabled: true

Field meanings:

• memory_type
  • The name of the memory type
• description
  • The definition of the memory type and its extraction requirements
• fields
  • The fields included in this memory type
• filename_template
  • The template used to generate the file name
• content_template
  • The body template used when writing the memory file
• embedding_template
  • The template used to render the text that is embedded for semantic retrieval; when unset, a default representation is used
• directory
  • The directory where this memory type is stored
• enabled
  • Whether this memory type is enabled
• operation_mode
  • The update mode of the memory type, such as upsert
• stage
  • Extraction stage. The default is user, which participates in session user-memory extraction; agent is reserved for execution-derived schemas such as trajectories and experiences.
• peer_enabled
  • Whether this memory type is stored separately under peer directories when peer_id or message ranges identify a peer. The default is true; set false for memories that must stay under the current user space.

When writing a memory schema, focus on:

• whether the field granularity is stable
• whether the filename template is predictable and searchable
• whether the directory rule matches the intended retrieval scope
• whether the merge strategy is appropriate for that memory type

Current Prompt Template Reference

The sections below describe template purposes, inputs, and related processing stages. A file in the template directory does not mean a request uses it: the call path, model configuration, and feature switches determine whether it takes effect.

When reading this section, a simple rule helps:

• For regular prompt templates, focus on Purpose and Key inputs
• For memory schemas, focus on Purpose and Key fields

Check Whether a Template Is Used

Template or category	Current usage conditions
compression.ov_wm_v2, compression.ov_wm_v2_update	Initial working-memory generation and later updates in openviking/session/session.py
retrieval.intent_analysis	Query planning when intent analysis is enabled and the session has usable content; specific planner models select dedicated templates, as described below
retrieval.recall_rewrite	Optional server recall compression over assembled context, producing a digest with source references
semantic.*	Selected by the semantic queue processor according to file type or directory task
parsing.image_summary, parsing.audio_summary, parsing.video_summary	Media summaries; audio and video also require an enabled VLM that supports the input
memory/tools.yaml, memory/skills.yaml	Built in with enabled: false; changing their descriptions does not enable them
memory/experimental_memory/*.yaml	Loaded when memory.experimental_memory_switch is enabled
skill_extract/session_skills.yaml	Separate schema for Session Skill extraction; see its loading rules below

compression.structured_summary, indexing.relevance_scoring, parsing.chapter_analysis, parsing.context_generation, parsing.semantic_grouping, processing.*, and test.skill_test_generation remain in the template directory, but no corresponding call sites were found in the current server source. Their inputs and intended purposes are retained below for maintenance and extensions; editing them should not be assumed to change live results.

Compression

These prompts are mainly used for session compression and working-memory updates. Long-term memory extraction uses schema definitions in the memory category.

• compression.ov_wm_v2

  • Effective stage: first working-memory generation stage
  • Affects: archived session overview and current working-memory quality
  • Purpose: creates the initial structured working-memory document for a session
  • Key inputs: messages

• compression.ov_wm_v2_update

  • Effective stage: incremental working-memory update stage
  • Affects: archived session overview and current working-memory continuity
  • Purpose: updates an existing working-memory document using keep, update, or append operations
  • Key inputs: previous_working_memory, messages

• compression.structured_summary

  • Intended stage: session archive summary generation stage
  • Affects: archived session summaries and downstream review/retrieval quality
  • Purpose: generates a structured summary for archived sessions
  • Key inputs: latest_archive_overview, messages

Indexing

This category is mainly used to support retrieval or indexing workflows with relevance judgments.

• indexing.relevance_scoring
  • Intended stage: candidate relevance evaluation stage
  • Affects: retrieval ranking and candidate filtering quality
  • Purpose: evaluates how relevant candidate content is to the user's query
  • Key inputs: query, candidate

Memory

These YAML files define the structure of different memory types. They are not single-inference prompts. Together, they determine how user and peer memories are stored, updated, and used by later retrieval.

• cases

  • Effective stage: case-memory persistence and update stage
  • Affects: trainable and evaluable task-case accumulation
  • Purpose: defines concrete task inputs, evaluation rubrics, and supporting evidence
  • Key fields: case_name, task_signature, input, rubric, evidence

• entities

  • Effective stage: entity-memory persistence and update stage
  • Affects: long-term storage of people, projects, organizations, systems, and other entities
  • Purpose: defines the storage structure for named entities and their attributes
  • Key fields: category, name, content

• events

  • Effective stage: event-memory persistence and update stage
  • Affects: event review, timeline-aware retention, and conversation narrative recording
  • Purpose: defines structured event memory such as summaries, goals, and time ranges
  • Key fields: event_name, goal, summary, ranges

• experiences

  • Effective stage: experience-memory persistence and update stage
  • Affects: reusable guidance distilled from task outcomes
  • Purpose: records durable execution experience and the memories it supersedes
  • Key fields: experience_name, content, supersedes (optional; omit when not replacing another experience)

• identity

  • Effective stage: agent identity memory persistence stage
  • Affects: long-term consistency of the agent's identity settings
  • Purpose: defines the agent's name, persona, vibe, avatar, and self-introduction fields
  • Key fields: name, creature, vibe, emoji, avatar, introduction

• preferences

  • Effective stage: preference-memory persistence and update stage
  • Affects: user preference recall and downstream personalization behavior
  • Purpose: defines user preference memory under different topics
  • Key fields: user, topic, content

• profile

  • Effective stage: user profile memory persistence and update stage
  • Affects: long-term storage of user profile, work background, and stable attributes
  • Purpose: defines the storage structure for "who the user is"
  • Key fields: content

• skills (disabled by default)

  • Effective stage: skill-usage memory persistence and update stage
  • Affects: skill usage statistics, experience accumulation, and recommended workflows
  • Purpose: defines skill usage counts, success rates, best-fit scenarios, and related information
  • Key fields: skill_name, total_executions, success_count, fail_count, best_for, recommended_flow

• soul

  • Effective stage: agent soul memory persistence stage
  • Affects: the agent's core boundaries, continuity, and long-term identity stability
  • Purpose: defines the agent's core truths, boundaries, vibe, and continuity
  • Key fields: core_truths, boundaries, vibe, continuity

• tools (disabled by default)

  • Effective stage: tool-usage memory persistence and update stage
  • Affects: tool usage experience, optimal parameters, and failure pattern accumulation
  • Purpose: defines the storage structure for tool call statistics and tool-usage experience
  • Key fields: tool_name, static_desc, call_count, success_time, when_to_use, optimal_params

• trajectories

  • Effective stage: agent trajectory memory persistence stage (stage: agent, add-only)
  • Affects: reusable operation contracts distilled from agent task trajectories — multi-step decisions, tool calls, and execution traces
  • Purpose: defines compact trajectory memory for "what reusable operation/contract emerged from a task trajectory"
  • Key fields: trajectory_name, outcome, retrieval_anchor, content

Parsing

These prompts are mainly used to convert raw resource content into structured nodes, chapters, summaries, or image overviews that are easier to retrieve and understand.

• parsing.chapter_analysis

  • Intended stage: long-document chapter splitting stage
  • Affects: document chapter structure and page organization
  • Purpose: analyzes document content and splits it into a reasonable chapter structure
  • Key inputs: start_page, end_page, total_pages, content

• parsing.context_generation

  • Intended stage: document node semantic generation stage
  • Affects: node abstract/overview quality and downstream retrieval matching
  • Purpose: generates shorter, retrieval-friendly semantic titles, abstracts, and overviews for text nodes
  • Key inputs: title, content, children_info, instruction, context_type, is_leaf

• parsing.image_summary

  • Effective stage: image node summarization stage
  • Affects: semantic overviews of image resources and downstream retrieval
  • Purpose: generates a concise summary for image content
  • Key inputs: context

• parsing.semantic_grouping

  • Intended stage: semantic grouping and splitting stage
  • Affects: document node granularity and content chunking quality
  • Purpose: decides whether content should be merged or split based on semantics
  • Key inputs: items, threshold, mode

• parsing.audio_summary, parsing.video_summary

  • Effective stage: audio/video understanding, requiring an enabled VLM that supports the media input
  • Purpose: generates a media overview for semantic indexing, retaining topics, events, facts, and identifiable content
  • Key inputs: filename, fallback_language; the media file is supplied separately to the model

Processing

These prompts are mainly used to distill strategies or experience from interaction records, tool chains, and resource background. They are used for post-processing and knowledge accumulation rather than direct one-turn user answering.

• processing.interaction_learning

  • Intended stage: post-interaction experience extraction stage
  • Affects: reusable interaction experience and distillation of effective resources and successful skills
  • Purpose: extracts reusable experience from interaction records
  • Key inputs: interactions_summary, effective_resources, successful_skills

• processing.strategy_extraction

  • Intended stage: post-resource-addition strategy extraction stage
  • Affects: structured extraction and reuse of resource background intent
  • Purpose: extracts usage strategies from the reason, instruction, and abstract associated with resource addition
  • Key inputs: reason, instruction, abstract

• processing.tool_chain_analysis

  • Intended stage: tool-chain analysis stage
  • Affects: tool combination pattern recognition and tool experience accumulation
  • Purpose: analyzes tool call chains and identifies valuable usage patterns
  • Key inputs: tool_calls

Retrieval

These prompts are mainly used to understand user intent before retrieval and decide the query plan and context type.

• retrieval.intent_analysis

  • Effective stage: pre-retrieval intent analysis stage
  • Affects: retrieval query planning, recall direction, and search quality across different context types
  • Purpose: generates a retrieval plan using compressed summary, recent messages, and the current message
  • Key inputs: compression_summary, recent_messages, current_message, context_type, target_abstract

• retrieval.ov_intent_analysis_sft_v4, retrieval.ov_intent_analysis_sft_v7

  • Used when the query planner's model exactly matches ollama/guoxuter/ov_intent_analysis_sft:v4_q8 or ollama/guoxuter/ov_intent_analysis_sft:v7_q8, respectively
  • Purpose: uses the corresponding model's query-planning contract; other models use retrieval.intent_analysis
  • Check the configured model before editing the default template to avoid changing an unused file

• retrieval.recall_rewrite

  • Effective stage: optional server compression after context assembly
  • Purpose: produces query-relevant bullets with source URIs; output must pass the caller's format and source validation
  • Key inputs: query, rendered, max_bullets

Semantic

These prompts are mainly used to generate file-level and directory-level summaries and are an important part of semantic indexing.

• semantic.code_summary

  • Effective stage: code file summarization stage
  • Affects: semantic indexing for code files, code retrieval, and understanding results
  • Purpose: generates summaries for code files with a focus on structure, functions, classes, and key logic
  • Key inputs: file_name, content, output_language

• semantic.document_summary

  • Effective stage: documentation file summarization stage
  • Affects: document summaries, document retrieval, and overview quality
  • Purpose: generates summaries for Markdown, text, RST, and similar documentation files
  • Key inputs: file_name, content, output_language

• semantic.file_summary

  • Effective stage: generic file summarization stage
  • Affects: directory indexing and generic file retrieval quality
  • Purpose: generates a summary for a single file as upstream input for directory abstract/overview generation
  • Key inputs: file_name, content, output_language

• semantic.overview_generation

  • Effective stage: directory overview generation stage
  • Affects: directory overviews, global retrieval, and navigation experience
  • Purpose: generates a directory-level overview from file summaries and child directory abstracts
  • Key inputs: dir_name, file_summaries, children_abstracts, output_language

Skill

These prompts are mainly used to compress Skill content into summaries suitable for retrieval and reuse.

• skill.overview_generation

  • Effective stage: Skill content processing stage
  • Affects: Skill retrieval summaries and Skill discovery quality
  • Purpose: extracts key retrieval information from a Skill's name, description, and content
  • Key inputs: skill_name, skill_description, skill_content

• skill.privacy_extraction

  • Effective stage: Skill privacy configuration extraction
  • Purpose: identifies private configuration items maintained by the user for placeholder replacement and privacy configuration storage
  • Key inputs: skill_name, skill_description, skill_content

Test

These prompts are mainly used to help generate test cases.

• test.skill_test_generation
  • Intended stage: Skill testing support stage
  • Affects: Skill scenario test design and validation sample generation
  • Purpose: generates test cases from the names and descriptions of multiple Skills
  • Key inputs: skills_info

Vision

These prompts are mainly used for image, page, table, and multimodal document analysis, and directly affect image parsing and scanned-document understanding.

• vision.batch_filtering

  • Effective stage: multi-image batch filtering stage
  • Affects: keep/drop decisions for images in multi-image document understanding
  • Purpose: determines in batch whether multiple images are worth including in document understanding
  • Key inputs: document_title, image_count, images_info

• vision.image_filtering

  • Effective stage: single-image filtering stage
  • Affects: whether an image enters downstream understanding workflows
  • Purpose: determines whether a single image is meaningful for document understanding
  • Key inputs: document_title, context

• vision.image_understanding

  • Effective stage: image understanding stage
  • Affects: image parsing results and the quality of image abstract, overview, and detail_text
  • Purpose: uses the VLM to generate three-layer information for an image
  • Key inputs: instruction, context

• vision.page_understanding

  • Effective stage: scanned-page understanding stage
  • Affects: scanned PDF page understanding and downstream semantic results
  • Purpose: understands a single image-based document page
  • Key inputs: instruction, page_num

• vision.page_understanding_batch

  • Effective stage: multi-page batch understanding stage
  • Affects: efficiency and consistency when understanding scanned pages in batch
  • Purpose: batch-understands multiple image-based document pages
  • Key inputs: page_count, instruction

• vision.table_understanding

  • Effective stage: table understanding stage
  • Affects: table-image parsing, table summaries, and structural understanding
  • Purpose: analyzes a table image and generates three-layer information
  • Key inputs: instruction, context

• vision.unified_analysis

  • Effective stage: unified multimodal analysis stage
  • Affects: parsing results for complex documents that include images, tables, and chapters
  • Purpose: batch-analyzes document images, tables, and chapter-related information
  • Key inputs: title, instruction, reason, content_preview, image_count, images_section, table_count, tables_section

How to Customize Prompts

OpenViking supports two main customization patterns:

1. Override regular prompt templates
2. Extend memory schemas

Before going into the specific methods, you can use the following table to judge change risk:

Change type	Risk level	Notes
Changing prompt wording, adding examples, adjusting tone	Low	Usually only changes model behavior style and does not change the caller contract
Changing output style, extraction preference, or summary granularity	Medium	Changes result distribution and should be revalidated against the target capability
Changing variable names, output structure, or memory field names	High	Easy to break compatibility with callers or parsing logic
Changing directory, filename_template, or merge_op	Very high	Directly changes memory storage location, organization, and update behavior

Override Regular Prompt Templates

Applicable when:

• you want to adjust memory extraction preferences
• you want to change summarization style
• you want image understanding output to be more detailed or more concise
• you want to change retrieval intent planning behavior

Available configuration:

• prompts.templates_dir
• environment variable OPENVIKING_PROMPT_TEMPLATES_DIR

Load priority:

1. Explicitly provided template directory
2. Environment variable OPENVIKING_PROMPT_TEMPLATES_DIR
3. prompts.templates_dir in ov.conf
4. Built-in template directory openviking/prompts/templates/

In other words, regular prompt customization works by checking the custom directory first and falling back to the built-in template when the same relative path is not found.

Recommended approach:

1. Copy the target file from the built-in template directory first
2. Keep the same category directory and file name
3. Only modify the prompt body or output requirements
4. Avoid changing variable names that callers already depend on

Example directory:

custom-prompts/
├── compression/
│   └── ov_wm_v2.yaml
├── retrieval/
│   └── intent_analysis.yaml
└── semantic/
    └── document_summary.yaml

Example configuration:

{
  "prompts": {
    "templates_dir": "/path/to/custom-prompts"
  }
}

Or:

export OPENVIKING_PROMPT_TEMPLATES_DIR=/path/to/custom-prompts

Impact examples:

• Modifying compression.ov_wm_v2
  • mainly affects initial working-memory generation
  • ultimately affects session archive quality and downstream recall results
• Modifying retrieval.intent_analysis
  • mainly affects pre-retrieval query planning
  • ultimately affects search direction and recall quality
• Modifying semantic.document_summary
  • mainly affects document summarization
  • ultimately affects document indexing and summary output

Extend Memory Schemas

Applicable when:

• you want to add a new business-specific memory type
• you want to adjust the field structure of an existing memory type
• you want to change memory storage directories or filename templates

Available configuration:

• memory.custom_templates_dir

Loading behavior:

1. Load schemas from the built-in memory/ directory.
2. If memory.experimental_memory_switch is enabled, load built-in memory/experimental_memory/ schemas.
3. If memory.custom_templates_dir is configured, load that directory; otherwise, try memory/ under the selected prompt directory.

A later definition with the same memory_type replaces the earlier one; new types are added. Only .yaml and .yml files directly in each directory are read, without recursive loading. Custom schemas can therefore add types or override built-in types; changing the name creates a separate type. Loading failures are logged, so check which schemas actually loaded.

Example directory:

custom-memory/
├── project_decisions.yaml
└── user_preferences_ext.yaml

Example configuration:

{
  "memory": {
    "custom_templates_dir": "/path/to/custom-memory"
  }
}

Recommendations when extending memory schemas:

• Start by following the style of existing memory/*.yaml files
• Confirm that the new memory type really needs to be independent
• Keep field names clear and stable for future updates
• Ensure directory and filename_template are easy to search and maintain

Impact examples:

• Adding project_decisions
  • affects memory persistence types and downstream search organization
• Modifying preferences
  • affects how user preference memories are organized and the granularity of recall
• Modifying tools
  • affects tool experience accumulation and tool usage recommendations

Session Skill Schemas

skill_extract/session_skills.yaml uses the memory schema format but is loaded separately by Session Skill extraction. It defines session skills the user asks to retain, distinct from the usage statistics in memory/skills.yaml.

The loader reads skill_extract/ directly under the selected prompt directory, without the per-file built-in fallback used for regular prompts. When using a custom prompts.templates_dir or OPENVIKING_PROMPT_TEMPLATES_DIR with Session Skill extraction, also copy the built-in skill_extract/ directory and check the schema loading logs. Copying only a file under semantic/ is insufficient for this path.

High-Risk Changes During Customization

The following changes are the most likely to break existing workflows:

• changing variable names in regular prompts
• changing the expected output structure of a prompt without updating downstream parsing logic
• changing key field names in a memory schema
• changing directory, which changes retrieval scope
• changing filename_template, which changes how historical files are organized
• changing merge_op, which changes how existing memories are updated

If your goal is only to improve quality, these are usually the safer first moves:

• add clearer output examples to the prompt
• strengthen rules about what to keep and what to ignore
• adjust summary granularity or response style
• modify only one prompt category at a time instead of several at once

A conservative approach is:

1. copy the existing template first
2. change the instruction content and phrasing first
3. change structural fields last
4. modify only one prompt category at a time so impact is easier to isolate

Validation and Troubleshooting

After modifying a prompt, validate it at two levels: whether the template was actually picked up, and whether the capability output changed as expected.

First: Verify the Template Was Picked Up

Checklist:

• whether the custom directory is configured correctly
• whether the file path keeps the same relative path as the original template
• whether the YAML is valid
• whether the variable names still match the original template

For a regular prompt, focus on:

• whether the template was loaded correctly
• whether the target stage really uses that template

For a memory schema, focus on:

• whether the new schema was loaded successfully
• whether the target memory type actually participates in extraction and persistence

PromptManager caches regular templates by default. After editing files, restart the service process that uses them; embedded applications can clear the corresponding manager's cache and reload. Memory registries also need to be recreated. Do not assume a running process automatically reads new schemas.

Then: Verify That External Results Changed

The most effective validation is capability-focused:

• If you changed a vision template, re-parse images, tables, or scanned PDFs and check whether the results changed
• If you changed a semantic or parsing template, re-import documents or files and check whether summaries and structure changed
• If you changed a retrieval template, rerun the relevant search and check whether query planning and recall behavior changed
• If you changed a compression template, trigger the relevant flow with a new test session and inspect working memory and the archive overview; these alone do not establish that long-term memory extraction changed
• If you changed a memory schema, inspect the final persisted memory files, directories, and field structure

Compare the original and modified templates with the same inputs, model, and other configuration, using separate test resources or sessions. Include a fact that should be retained, irrelevant information that should be omitted, and a case with an easily missed condition. Check whether summaries preserve key facts, retrieval finds the correct sources, and memories reach the expected directory and update existing content correctly. Record failures, latency, and model usage; smoother wording does not establish better accuracy.

Common Troubleshooting Patterns

Symptoms and first things to check:

Symptom	First thing to check
Results do not change at all after modification	The custom directory is not active, or the file path does not match
The model reports missing variables	Template variable names do not match what callers provide
Returned content format is broken	The prompt output format changed, but downstream parsing still expects the old structure
A new memory type never appears	memory.custom_templates_dir is not active, or the schema was not loaded correctly
Retrieval quality gets worse	The retrieval, semantic, or compression prompt was changed too aggressively

Appendix

Template Directory

Built-in prompt template directory:

openviking/prompts/templates/

It contains:

• compression/: working-memory compression and archive summaries
• indexing/: relevance evaluation
• memory/: memory type definitions
• parsing/: structure analysis and semantic node generation
• processing/: experience and strategy extraction
• retrieval/: retrieval intent analysis
• semantic/: file and directory summaries
• skill/: Skill summaries and privacy configuration extraction
• skill_extract/: Session Skill schemas
• test/: test case generation
• vision/: image, page, and table understanding

Key Configuration Items

The main configuration items related to prompt customization are:

Configuration item	Purpose
prompts.templates_dir	Override directory for regular prompt templates
OPENVIKING_PROMPT_TEMPLATES_DIR	Environment variable for the override directory of regular prompt templates
memory.custom_templates_dir	Directory for custom memory schemas

Practical Rule of Thumb

If your goal is:

• to change how the model speaks, extracts, or summarizes
  • modify a regular prompt template first
• to change what a memory looks like, where it is stored, or how it is organized
  • modify or extend a memory schema first

If you are not sure which layer to modify, ask yourself:

"Am I changing the model's instruction, or the structure of the final memory file?"

That question is usually enough to help decide whether you should modify a regular prompt or a memory schema.