cdno templates

Inspect and edit note templates. Use vars before writing a custom template in .cuaderno/templates/ to see which {{placeholders}} a note type supports — unknown placeholders render verbatim, so this is how you learn the valid set without reading the source.

cdno templates vars <type>

List the {{placeholders}} a note type’s template supports.

cdno templates vars [OPTIONS] <TYPE>

Arguments

Takes only the global options.

Sources

Each placeholder is classified by where its value comes from:

A config or prompt name that collides with a supplied key is omitted: the supplied value shadows it, so it would never take effect.

With --json, emits an array of { name, source } objects (prompt entries also carry message).

Examples

cdno templates vars project
cdno templates vars tracking
cdno templates vars question --json | jq -r '.[].name'

cdno templates eject <type>

Copy a built-in template into .cuaderno/templates/<type>.md as an editable starting point. Note types use an in-binary default until you add a file for them (only daily is seeded on cdno init); this materialises one so you can customise it (add sections, reorder frontmatter, reference {{placeholders}} from templates vars) without hand-reconstructing it from the source tree.

cdno templates eject [OPTIONS] <TYPE>

Arguments

Options

Plus the global options. With --json, single-type eject emits the { path, message } write result; --all emits an object with written and skipped arrays (note-type names).

Only base note-type templates eject — no <type>-<variant> template ships built-in. To create a tracking activity variant, copy one from examples/templates/tracking/ to .cuaderno/templates/tracking-<activity>.md instead.

Examples

cdno templates eject project              # → .cuaderno/templates/project.md
cdno templates eject tracking             # → the generic tracking template
cdno templates eject project --force      # overwrite an earlier customisation
cdno templates eject --all                # eject all built-ins, skip customised
cdno templates eject --all --force        # eject all, overwriting everything

The written file is exactly the built-in default, so a note created straight after ejecting is byte-identical to before — customise from there.

cdno templates sync <type>

Bring a customised template up to date with frontmatter keys a later release added to the built-in one, without losing your customisation. A file you ejected or saved never receives such keys by itself; nothing breaks without them (new notes from it just lack the key), but nothing else adds them either, and eject --force would throw your edits away.

cdno templates sync [OPTIONS] <TYPE>
cdno templates sync --all [--check]

For each key of the built-in template’s frontmatter that your file lacks, sync inserts the built-in line verbatim: a literal such as closed: null, or a placeholder line such as core_question: {{core_question}}. It goes right after the nearest built-in key that precedes it and your file has: after that key’s whole block, or, when that key has a one-line plain value, straight after its line, so a comment above your next key stays with it; failing that, right before the nearest built-in key that follows it; failing that, last in the frontmatter. A key your file already has, quoted ("closed": null) or with a space before the colon, counts as present. Nothing else changes: your own keys, their values, their order and the body stay byte for byte, and no key is ever removed. Running it again on an up-to-date file writes nothing.

cdno templates sync project
# project: added `closed` to .cuaderno/templates/project.md; kept your `owner`
cdno templates sync --all --check     # in CI: fails while any override is behind

--json emits an array with one object per override (with <TYPE> and no override, one not_customised object), each with note_type, path, status (synced, behind, up_to_date, not_customised, no_frontmatter or unreadable, the last with an error), added and kept (your own keys, listed so you can see nothing was dropped). A file with no --- frontmatter block, or one that cannot be read, is reported and left alone; an unreadable one makes the command exit non-zero, with or without --check. It writes through the same path as templates save.

cdno templates list and cdno lint both say when an override has fallen behind.

cdno templates list

Every note type with the state of its template: whether a custom override exists, which source is in effect, and the path the override lives (or would live) at. A custom override that lacks a key its built-in has gained shows custom (lacks closed; …) in the Template column.

cdno templates list [OPTIONS]

--json reports source as a stable token — builtin_default, builtin_variant, custom_base, custom_variant, or none — rather than the human label in the table, and lists the missing keys under missing_builtin_keys (empty when there are none).

cdno templates show <type>

Print a template’s effective content verbatim: the custom override when one exists, else the built-in default. A custom type with no template yet shows the starter new would write.

cdno templates show [OPTIONS] <TYPE>

Output is byte-verbatim, so it round-trips:

cdno templates eject project
cdno templates show project | diff - .cuaderno/templates/project.md   # no output

--json emits {content, source} instead.

cdno templates save

Write a template. On a built-in type this creates the custom override transparently — no prior eject needed.

cdno templates save [OPTIONS]

Without --file, an interactive run opens $EDITOR seeded with the template as it stands. Off a terminal --file is required, so a scripted save cannot silently truncate a template to nothing.

cdno templates save --note-type project --file my-project.md
cat my-project.md | cdno templates save --note-type project --file -

cdno templates new

Scaffold a starter template for a config-defined custom type that has none yet — a frontmatter block of type plus each declared required field as a {{placeholder}}, and a # {{title}} heading.

cdno templates new [OPTIONS]

Refuses a built-in type, which already has a default to edit — use eject or save for those — and refuses to overwrite an existing template.

A custom type has exactly one template, so --variant is not accepted on show, save or new for one; declare a separate note type instead.

Related

• Customising templates and frontmatter — how to write a custom template and use [variables] / [variables.prompt].