AGENTS.md — Tolaria Vault

This is a Tolaria vault, a folder of Markdown files with YAML frontmatter forming a personal knowledge graph.

Keep edits compatible with this starter vault’s current conventions. Prefer small, human-readable changes over heavy restructuring.

Core conventions

  • One Markdown note per file.
  • The first H1 in the body is the preferred display title. Legacy title: frontmatter is still read as a fallback when a note has no H1, but do not add it to new notes.
  • Store note type in the type: frontmatter field.
  • In this starter vault, type definitions currently live at the vault root, for example project.md, person.md, note.md, and type.md. Keep new type files at the vault root unless the user explicitly asks to reorganize them.
  • Saved views live in views/*.yml.
  • Files in attachments/ are assets, not notes. Reference them from notes, but do not treat them as notes or types.
  • Frontmatter properties that start with _ are usually Tolaria-managed state. Leave them alone unless the user explicitly asks for them to change.

Notes

---
type: Note
related_to: "[[tolaria]]"
status: Active
url: https://example.com
---

# Example note

Body content in Markdown.

Types

In this starter vault, types are regular notes stored at the vault root and use type: Type.

---
type: Type
_icon: rocket
_color: "#3b82f6"
_order: 0
_list_properties_display:
  - related_to
_sort: "property:onboarding:asc"
---

# Project

Useful type metadata in this vault includes icon/_icon, color/_color, order/_order, sidebar label, _list_properties_display, _sort, template, view, and visible. When editing an existing file, preserve the key style already used there instead of mass-normalizing underscored keys.

Relationships

Any frontmatter property whose value contains [[wikilinks]] is treated as a relationship. In this starter vault, common relationship keys include related_to and belongs_to, but custom relationship names are valid too.

Preserve older relationship labels such as Belongs to: when editing existing notes that already use them.

Use quoted wikilinks for scalar frontmatter values and YAML lists for multi-value relationships.

  • [[filename]] or [[Note Title]] for normal links
  • [[filename|display text]] for custom display text
  • Works in frontmatter values and Markdown body

Views

Saved views live in views/*.yml and are written as YAML. Tolaria scans every .yml file in views/, and the filename is the stable view id, so use kebab-case filenames such as active-projects.yml.

A view definition looks like this:

name: Active Projects
icon: null
color: null
sort: "property:onboarding:asc"
filters:
  any:
    - field: type
      op: equals
      value: Project
    - field: related_to
      op: contains
      value: "[[tolaria]]"

View rules that matter when creating or editing files:

  • name is required. icon, color, and sort are optional.
  • sort uses option:direction. Built-in options are modified, created, title, and status. Custom-property sorts use property:<Property Name>, for example property:onboarding:asc.
  • filters must be a tree whose root is exactly one all: group or one any: group.
  • Each filter condition uses field, op, and usually value.
  • field can target built-ins like type, status, title, favorite, and body, plus actual frontmatter keys used in this vault such as related_to, belongs_to, or url.
  • Supported operators are equals, not_equals, contains, not_contains, any_of, none_of, is_empty, is_not_empty, before, and after.
  • any_of and none_of expect value to be a YAML list.
  • regex: true is supported with equals, not_equals, contains, and not_contains when pattern matching is needed.
  • Relationship filters can use wikilinks in value, for example "[[tolaria]]".
  • Do not create JSON view files or .view.json filenames.

Filenames

Use kebab-case: my-note-title.md. One note per file.

What agents should do

  • Create and edit notes using the frontmatter and H1 conventions above.
  • Create and edit type documents at the vault root.
  • Add or modify relationships without breaking existing wikilinks.
  • Create and edit saved views in views/.
  • Update AGENTS.md only when the user asks for vault-level guidance changes.

What agents should avoid

  • Do not move existing type files out of the vault root unless the user explicitly asks.
  • Do not treat files in attachments/ as notes, types, or view definitions.
  • Do not silently overwrite an existing custom AGENTS.md.
  • Do not rewrite installation-specific app configuration unless the user explicitly asks.
logo