The vault as a database

Tasks and kanban

Two more fences complete Clew's database views. tasks gathers every checkbox in the vault — or a filtered slice of them — into one list, and ticking a gathered task writes the [x] back into the note it came from. kanban projects notes onto a board whose columns are the values of one frontmatter field, and dragging a card to another column rewrites that note's field. Like queries, both are views over the plain files: the vault stays the only source of truth, and every view follows every edit.

Where tasks come from

A task is an ordinary Markdown checkbox item — a list bullet (-, *, or +) followed by [ ] for open or [x] for done (a capital X also counts as done):

- [ ] Renew library carrel for the year
- [ ] Book train for the Bristol workshop
- [x] Send Synthese the conflict-of-interest form

Indented (nested) items count too, and checkboxes inside fenced code blocks are ignored — an example of the syntax never becomes a real task. Tasks live wherever they are natural: the study-vault keeps errands in an Errands note and the per-paper to-dos inside the papers themselves, and lets the fence below do the gathering.

In reading mode, a note's own checkboxes are live: click one and Clew flips the [ ] to [x] (or back) on that source line. When the note is open in an editor, the toggle is applied through the editor — so it is undoable and auto-saved — and otherwise it is written straight to disk.

The tasks fence

A tasks fence scans the vault's notes and renders their checkbox items as one aggregated view, grouped under a link to each source note. The fence body takes a status word plus filters:

```tasks
not done
limit: 12
```

That is the study-vault Dashboard's “everything still to do” block: three errands, and the open items from two papers, gathered from three different files. The options, all of them:

not done · todo · done · all

A bare word on its own line selects which tasks to show: not done (or its synonym todo) shows open items and is the default, done shows completed items, all shows both.

from: Folder

Gather only from notes in this folder and its subfolders — the same semantics as a query's from:.

tag: #name

Gather only from notes whose tags frontmatter property contains the tag (# optional, case-insensitive). As with queries, body hashtags do not count here.

group: note · group: none

By default (note) tasks appear under a linked heading for each source note. group: none drops the headings for one flat checklist.

limit: n

Cap the total number of items shown across the whole view.

Notes appear in alphabetical order by name, tasks in the order they occur within each note. A fence that gathers nothing renders “No matching tasks.”

Ticking a gathered task

The checkboxes in a tasks view are live, and — this is the point — each one knows the note and line it came from. Tick a box on the Dashboard and Clew rewrites the [ ] in the source note: the box in Errands flips because the file Errands.md now says [x]. As with in-note checkboxes, the write goes through an open editor when there is one (undoable, auto-saved) and straight to disk otherwise; Clew even tolerates the task having drifted a line up or down since the view was rendered. Because every open query view re-renders on any file change, the ticked task then vanishes from every “not done” list at once.

The Tasks plugin's dialect

Obsidian's popular Tasks plugin uses the same ```tasks fence with a different query language — instruction lines such as not done, path includes Inbox, heading includes todo, due before today, priority is high, sort by due, group by heading, limit 20, and layout lines like hide backlink or short mode. Clew serves both dialects from the one fence: a block whose lines are all Clew syntax renders exactly as before, and a block using a plugin instruction runs the plugin dialect — a flat, vault-wide task list with metadata badges and a backlink to each task's note, checkboxes live and writing back to their source lines as always.

The plugin's emoji conventions on the task line are understood and hidden from the rendered text, exactly as the plugin hides them: 📅 due, ⏳ scheduled, 🛫 start, ✅ done-on, ➕ created, 🔁 a recurrence rule, and the priority marks 🔺⏫🔼🔽⏬. Filters like due before 2025-01-01, has scheduled date and is recurring read them.

An instruction line neither dialect knows refuses the whole block by name — a silently dropped filter would show too many tasks, which is worse than showing none. filter by function and its siblings are JavaScript and are refused as such.

The kanban fence

Where a query is notes-as-rows, a kanban is notes-as-cards. The board groups notes into columns by the value of one frontmatter field — by default status — with one card per note. The study-vault Pipeline note drives its whole papers workflow from this fence:

```kanban
group: status
from: Papers
columns: drafting, submitted, revise, accepted
show: venue, due
```

The options, all of them:

group: field

The frontmatter field whose values become the columns. Defaults to status.

from: Folder and tag: #name

Which notes become cards — the same filters as queries and tasks. With no filter, every note in the vault is a card, which is rarely what you want.

columns: a, b, c

An explicit column list. This fixes the columns and their order — drafting, submitted, revise, accepted reads left-to-right as a pipeline — and makes the board exclusive: notes whose field value is not one of the listed columns are not shown. Without columns:, the board grows one column per distinct value, ordered alphabetically, plus a “—” column for notes where the field is missing or empty. A board wider than the note column does not wrap — it scrolls horizontally, so trailing columns sit just past the edge of the pane.

show: f1, f2, …

Fields to display on each card beneath its title, as field: value pairs joined with a “·” separator. Fields a note does not have are omitted from its card. The built-ins (name, path, modified) are allowed here too.

Each column header carries a count of its cards; within a column, cards are ordered alphabetically by note name. Double-click a card to open its note in a new tab — a single click begins a drag.

Dragging a card writes the field

Drag a card into another column and drop it. Clew rewrites the group field in that note's frontmatter to the new column's value: move Signals and Society from drafting to submitted and the file now reads status: submitted. If the note did not have the field, the drop creates it. The card moves immediately, and the live re-render then confirms the board from the file itself.

Because the board wrote an ordinary frontmatter value, every other view reading that field follows on the next render: the Dashboard's papers-by-status groups reshuffle, a where: status = drafting table loses the row, the properties panel on that note shows the new value. Nothing synchronised these views — they all read the same file.

Obsidian Kanban-plugin boards

Obsidian's Kanban plugin stores a whole board as an ordinary note: kanban-plugin: basic in the frontmatter, one ## heading per lane, one - [ ] list item per card, and a settings block at the bottom that belongs to the plugin alone. Clew recognises the frontmatter key and renders such a note as a board in reading mode — one column per lane, card checkboxes live and writing back to their exact source lines, the plugin's archive (everything below the *** divider) left out just as the plugin leaves it out. In source mode the note is the markdown it always was, which is the point of the format; and because Clew only ever rewrites a checkbox character, a board edited in Clew reopens in Obsidian's plugin untouched.

Rearranging cards between lanes is editing in Obsidian's plugin; in Clew (for now) it is a source-mode edit — move the list item under another heading and the board follows on the next render.

Boards and task lists on the canvas

Note embeds on the canvas are live previews, so a note holding a kanban or tasks fence works there too — the study-vault ships Pipeline Board.canvas, where the papers board sits alongside the papers themselves. Drags, ticks, and cell edits inside canvas embeds route back to the source notes exactly as they do in reading mode, and the embedded views re-render as the vault changes.

Reference

See also

• Queries — the table and list views over the same data, and the full filter semantics from:/tag: share.
• Properties and metadata — the frontmatter the boards rewrite, and the safety valve that protects it.
• How rendering works — reading mode, where checkboxes in a note's own body are toggled.
• The canvas — live note embeds, boards included.
• Daily notes and the diary — a natural home for a personal tasks view.