Types

A note's type in frontmatter tells Mindex what kind of thing it is: a project, a person, a call, a daily note. The app then shows the fields that suit it.

A type never restricts the file. Mindex will not refuse a note because a field is missing or because you put a key it has never heard of in the frontmatter. The type decides what is drawn for you, not what is allowed.

What ships

Mindex includes types for projects, people, organizations, goals, payments, expenses, call transcripts, call debriefs, knowledge notes, chat exports, daily notes and assets — plus the untyped note, which is just a file.

What a type defines

Part	What it does
Fields	The frontmatter keys and what kind of value each holds
Icon and colour	How the note reads in the tree
Default folder	Where new notes of this type go
Filename pattern	What a new note is called
Template	The body a new note starts from

Field kinds

Deliberately few, because each one has to be drawable in the frontmatter panel and filterable in a view.

Kind	Holds
text	A string
number	A number
date	A date
boolean	On or off
select	One of a fixed list, each with its own colour
relation	A wiki link to another note, optionally of a given type
list	Several values

Editing and creating types

Types you create or change are written to .mindex/types/<id>.md in the vault. A built-in type you have edited keeps its identity — the shipped definition becomes the factory setting your file is compared against.

See Create a type.

Types the assistant can read

Mindex writes your types out as a skill file the CLI reads natively, so the assistant knows that a project has a status of exactly these values and that participants is a list of links. Without it, an agent opens a neighbouring file and copies whatever frontmatter it happens to find — which is how a vault ends up with status: active beside status: ACTIVE.

See Skills.