Templates control how a transcript is cleaned and structured, and where the result goes. They are plain Markdown files in your vault, so you edit, rename, reorder, and create them like any other note.
Each template is one `.md` file in your templates folder (default `ReWrite/Templates/`):
```markdown
---
id: my-meeting-notes
name: Meeting notes
insertMode: newFile
newFileFolder: Meetings
newFileNameTemplate: Meeting {{date}} {{title}}
disableSharedCore:
enableContextHint: true
diarize:
titleFromContent: true
noteProperties:
subject: One short line naming the meeting's topic.
participants: Comma-separated list of people present.
date: The meeting date if stated, else today.
---
Turn the transcript into concise meeting notes. Use these sections, omitting any with no content:
## Summary
## Decisions
## Action items
```
- **Frontmatter** (between the `---` lines) configures the template.
- **Body** (everything after) is the prompt sent to the LLM.
Files are sorted by filename in the modal and pickers, so prefix names with `01-`, `02-`, etc. to control order. The frontmatter `id` is the identity, so renaming a file does not break the default-template or last-used references.
## Frontmatter fields
| Field | Type | Purpose |
| --- | --- | --- |
| `id` | string | Stable identity. Keep it unique; do not reuse across templates. |
| `name` | string | Display name in the modal and pickers. |
| `insertMode` | `cursor` / `newFile` / `append` | Where the output goes (see below). |
| `newFileFolder` | string | Folder for `newFile` output. |
| `diarize` | boolean | Set `true` to default the modal's "Identify speakers" checkbox ON for this template (only effective on diarization-capable providers; you can still untick it for a single run). |
| `managed` | boolean (three states) | Marks a file as plugin-managed. `true` (written by Populate/Update on built-in-derived files): the Update button may reconcile it. `false`: you have untracked it; Update never touches it. Empty/absent: treated as managed when the `id` matches a built-in (how files from before this flag behave). Ignored entirely on your own templates. |
Note the polarity difference: `disableSharedCore` is an opt-out (set it to turn the shared core OFF for this template), while `enableContextHint`, `diarize`, and `titleFromContent` are opt-ins (set them to turn a feature ON). Populate always writes the boolean keys as empty stubs so they are discoverable; an empty value means "not set". Obsidian's Properties UI may store an edited boolean as text, so the parser accepts both `true` and the string `"true"` (and, for `managed`, `false`/`"false"`).
- **`cursor`**: inserts at the cursor in the active note. Falls back to `append` when no editor is open.
- **`append`**: appends to the current Markdown note. Falls back to `newFile` when no note is open.
- **`newFile`**: writes a new note in `newFileFolder`, named by `newFileNameTemplate`.
Filename tokens (newFile): `{{date}}` and `{{time}}` expand via Obsidian's date formatting; `{{title}}` expands to the LLM-generated title when `titleFromContent` is on (and collapses cleanly when absent). Collisions are resolved per your "On filename collision" setting.
The per-run Destination control in the modal can override the insert mode for a single run without editing the template on disk.
## The shared core
`ReWrite/SharedCore.md` holds baseline cleanup rules (an anti-injection guardrail, general grammar/filler cleanup, and output discipline). At cleanup time the plugin prepends it to your template prompt, so the assembled system prompt reads: shared core, then template prompt, then any spoken ad-hoc instructions, then the context hint, then known nouns, then note-properties instructions.
Because the shared core is shared, write your template prompt to describe only what is special about this template (the sections, the tone, the format). Do not repeat general cleanup rules. Delete or empty `SharedCore.md` to disable it everywhere; set `disableSharedCore: true` to disable it for one template. A template that opts out runs without the anti-injection guardrail, so the settings tab flags any such template.
## Note properties
For `newFile` templates, `noteProperties` asks the LLM to emit a leading YAML block that becomes the note's frontmatter. Author it as a YAML map (property name to instruction). The key order drives both the prompt and the written order. Properties are written only in `newFile` mode (never into an existing note). Example:
```yaml
noteProperties:
podcast: The show name.
episode: Episode number or title if stated.
host: The host's name.
guests: Comma-separated guest names.
```
## Note title
`titleFromContent: true` asks the LLM to generate a title for the new file. It rides the same leading YAML block as note properties (under a reserved key) but is used only for the filename, never written as a frontmatter property. Use it with a `{{title}}` token in `newFileNameTemplate` (for example `Meeting {{date}} {{title}}`), or with no token, in which case the title becomes the whole filename. The plugin hardens the model's output into a safe filename and falls back to the static name if nothing usable remains.
## Writing a good prompt
1.**Describe the shape, not the cleanup.** The shared core already handles grammar and fillers. Spend the prompt on structure.
2.**Name your sections explicitly.** "Use these sections: ## Summary, ## Decisions, ## Action items" beats a vague "summarize".
3.**Be concrete about format.** If you want a checklist, say "a Markdown checklist with `- [ ]` items".
4.**Extract, do not invent.** Tell the model to leave a section out when there is nothing for it, rather than padding.
5.**Keep it short.** A focused prompt outperforms a long one. One template, one job.
6.**Test and iterate.** Run it on a real transcript and adjust the wording.
## Keeping templates up to date
The Templates section has three buttons (see [Settings reference](Settings-Reference)):
- **Populate**: adds any missing default templates plus the shared core and guide. Never overwrites your files.
- **Update**: reconciles your default-derived templates with the current built-ins using a per-field 3-way merge. Pristine fields (never edited, matching a current or previously shipped default) are brought forward; your edits are kept. Anything it cannot auto-merge (notably an edited prompt body that diverges from a changed default) is written to `Template update report.md` next to the templates folder for you to review. Re-serializing frontmatter drops any YAML comments you added; the prompt body is left untouched.
- **Load prior versions**: writes earlier shipped versions of the defaults as standalone, separately-named templates so you can compare prompt wording. They never collide with your live templates.
Update only reconciles files it recognizes as plugin-managed (see the next section), and skips any built-in you have disabled in **Manage built-in templates**.
## The managed flag: tracking, untracking, and disabling built-ins
Every file Populate or Update creates carries `managed: true` in its frontmatter. That flag is how Update tells a plugin-managed copy of a built-in apart from a template you wrote yourself; a template of your own is never overwritten by Update even if it happens to share a name (or an `id`) with a built-in, because it does not carry `managed: true`.
Two per-template controls live in settings under **Templates, Manage built-in templates** (an **Enabled** switch and a **Tracked** checkbox on each row):
- **Enabled switch**: turning a built-in off removes its file (behind a confirmation) and remembers the choice, so Populate and Update never resurrect it, including after a plugin update re-ships it. Identity is the frontmatter `id`, so this survives renaming the file. Turn it back on any time for a fresh copy.
- **Tracked checkbox**: unchecking it writes `managed: false` into the file. The template stays on disk and fully usable, but Update never changes it again; you have adopted it as your own. Re-check it to resume updates.
An empty `managed:` key (or none at all, as in files created before this flag existed) on a file whose `id` matches a built-in is treated as tracked, which matches the old behavior; only an explicit `managed: false` opts out.
