Automate Work Logs in Obsidian with Templater

The Problem with Work Logs

Every developer knows they should document their work. Few actually do it consistently. The friction is real — by the time you open a blank file, decide on a format, and type out the details, the next ticket is already waiting.

I used to feed my work conversations to an AI prompt that would generate polished work logs. The output quality was great, but the process itself became the bottleneck. Most tasks don't need a carefully crafted narrative. They need a quick record: what was the issue, what did I do, what's the result. So I switched to a Templater-based template that I fill in directly.

Design Principles

Three things mattered. Speed — selecting a task type should scaffold the right sections instantly, no manual formatting. Searchability — YAML frontmatter with ticket numbers, assignees, week numbers, and tags so Dataview queries can surface anything later. Minimal input — dates, URLs, folder placement, and filenames should be automatic.

Eight Task Types

A single generic template forces you to delete irrelevant sections every time. Instead, I mapped out the distinct structures different tasks actually need:

General — Content / Result. The catch-all for anything that doesn't fit elsewhere.

Code Change — Modified files (table) / Changed code. File list first for a quick scope check.

SQL — Query / Table structure (optional). The query is the deliverable.

Bug/Error — Symptom / Root cause / Fix. Mirrors the debugging flow.

Inquiry — Question / Answer. Searchable for when the same question comes back.

Config/Deploy — Target environment / Changes (before→after table) / Deployment. The diff is what matters.

API Integration — Target system / API spec (request/response) / Implementation code. Spec and code stay separate.

Data Correction — Reason / Impact scope / Correction query. "Why" is the most important part.

Templater's suggester function presents these as a selectable list at file creation.

How the Template Works

Collecting Input

Four prompts fire in sequence: ticket number, title, requester, and task type. An optional fifth prompt accepts comma-separated extra tags.

const redmineNum = await tp.system.prompt("Ticket number");
const title = await tp.system.prompt("Title (2-5 words)");
const selectedType = await tp.system.suggester(types, types, false, "Select task type");

Type-Based Branching

A JavaScript object maps each type to its body template. One lookup, no if-else chains.

const bodyMap = {
  "Code": `## Modified Files\n\n## Changed Code\n`,
  "Bug/Error": `## Symptom\n\n## Root Cause\n\n## Fix\n`,
  // ...
};
const body = bodyMap[selectedType];

Tags follow the same pattern — each type has default tags that merge with the base set.

Automatic Housekeeping

The filename becomes Ticket-{number}-{title} via tp.file.rename. The file moves to a year-based folder via tp.file.move. The ticket URL is just the base domain plus the number — no manual entry needed.

YAML Design

tags: ["work-log", "project-tag", ...]
ticket: 12345
ticket_url: "http://example.com/issues/12345"
requester: "[[John Doe]]"
status: in-progress
reported: false
created: 2026-04-28
week: 2026-W18

The requester field is a wikilink so Obsidian's backlinks track all tasks related to that person. The week field enables weekly report queries in Dataview. reported tracks whether you've included this in your status update — filter for false to catch anything you haven't reported yet.

When to Use This vs. AI Generation

The AI prompt approach produces higher-quality output — restructured narratives, blog-ready versions, cross-linked knowledge notes. But it's overkill for routine tasks. The template handles the 80% of work that just needs a clean record. Save the AI pipeline for the 20% worth writing up properly.

The key insight: consistency beats quality in work logs. A brief record you actually write is worth more than a polished document you skip because the process is too heavy.