TaskNotes for Obsidian: Tasks as Markdown Notes, Views as Bases Queries

The problem it solves: portable tasks without a proprietary database

Most task managers lock your data into a plugin-specific database or a proprietary cloud service. TaskNotes takes the opposite route. It stores each task as a separate Markdown note with YAML frontmatter, and it builds every view, the Task List, Kanban, Calendar, and Agenda, as Obsidian Bases queries. That means your tasks are just files. You can read them with any text editor, transform them with scripts, or migrate them to another tool. There is no plugin-specific database to export or recover. The intended user is an Obsidian user who already trusts Markdown for notes and wants the same portability for tasks. The README makes this explicit: "Tasks are just Markdown files with YAML, so you can read them with any tool, transform them with scripts, or migrate them elsewhere." That is a concrete design decision, not a marketing phrase. It also means the plugin's value depends on Bases, Obsidian's core plugin for turning notes into databases. If Bases is not part of your Obsidian setup, TaskNotes has nothing to render its views with.

How the data model works: frontmatter as the schema

The core unit is a task note with YAML frontmatter. The README shows a typical example with fields like title, status, due, priority, contexts, projects, timeEstimate, and timeEntries. Time entries are stored as an array of objects with startTime and endTime, which is a straightforward way to capture time tracking without a separate table. Recurring tasks use RRULE format, a standard from the iCalendar specification, with a complete_instances array to track which occurrences have been done. For example, a weekly meeting note carries recurrence: "FREQ=WEEKLY;BYDAY=MO". When a single occurrence needs its own note, TaskNotes can materialize it. That occurrence note includes recurrence_parent and occurrence_date, and it inherits planning metadata from the parent, such as scheduled time, due offset, tags, contexts, projects, reminders, details, and time estimate. It does not copy the parent's recurrence rule, completion history, or time entries. This split is a deliberate trade-off. It keeps the parent note clean, but it means you have two notes to manage for one recurring task. The README does not say how the plugin reconciles edits between parent and occurrence, so you may need to test that behaviour yourself.

Views are Bases queries, not hardcoded panes

Every view in TaskNotes is a .base file. The plugin registers as a Bases data source and provides custom view types: tasknotesTaskList, tasknotesKanban, tasknotesCalendar, and tasknotesMiniCalendar. The default Agenda file is a preconfigured tasknotesCalendar list view with listWeek. This architecture means you can edit the .base files directly to change filters, sorting, or grouping, or you can duplicate them to create new views. The README gives a concrete example of formula properties that compute values on the fly. For instance, daysUntilDue is calculated as ((number(date(due)) - number(today())) / 86400000).floor(), and isOverdue is due && date(due) < today() && status != "done". There is also urgencyScore, which combines priorityWeight with daysUntilDue, and efficiencyRatio, which compares timeTracked to timeEstimate. These formulas are plain text in the .base file, so you can tweak them without touching plugin code. This is a strong design for flexibility. However, it also means you need to understand Bases query syntax to get the most out of it. If you are not comfortable editing YAML or reading formula expressions, the defaults may be enough, but customisation will require learning Bases.

Getting it running: commands, natural language, and configuration

The README's quick start is short. You create a task with the command "TaskNotes: Create new task". The plugin parses natural language, so typing "Buy groceries tomorrow #errands" extracts the due date and context automatically. That parsing works in English, German, Spanish, French, Italian, Japanese, Dutch, Portuguese, Russian, Swedish, Ukrainian, and Chinese. The UI language is a slightly different set: English, German, Spanish, French, Japanese, Russian, Chinese, Portuguese, and Korean. Once tasks exist, you open views with commands like "TaskNotes: Open tasks view" or "TaskNotes: Open kanban board", which open the corresponding .base files from TaskNotes/Views/. Configuration is done through settings. The README explicitly says all property names are configurable. If you already use deadline instead of due, you can remap it in settings. That is a useful touch for people migrating from other systems. There is also an optional HTTP API, a browser extension, and a CLI, all listed in the Integrations section. The README does not give installation steps beyond the commands, so you would install it like any Obsidian community plugin, either through the community plugins directory or by manually copying the release files into your vault's .obsidian/plugins folder. The repository has a 5.0.0-beta.2 release, so you have a choice between a stable 4.12.5 and a beta with possible changes.

Limitations and failure modes: Bases dependency and sync complexity

The biggest limitation is the hard dependency on Obsidian Bases. The README states that all views are Bases queries. If Bases is disabled or unavailable in a particular Obsidian version, TaskNotes has no view layer. The plugin does not provide an alternative rendering engine. That is a real constraint for users on older Obsidian builds or for those who prefer a lighter setup. Another limitation is the time tracking model. Time entries are stored as an array in a single note. That is fine for a few entries, but a task with many sessions will grow its frontmatter, making the note harder to read and edit by hand. The README does not mention any aggregation or compaction for time entries. Calendar sync is another area with complexity. The README mentions Google and Microsoft OAuth and ICS feeds, but it does not describe how conflicts are handled or whether sync is bidirectional. Based on the material, we cannot confirm that calendar events become task notes or vice versa. If you need a robust two-way sync, you should verify that behaviour in the documentation or by testing. The natural language parser is a convenience, but it is not a full NLP engine. It extracts due dates and contexts from simple phrases. Complex sentences or ambiguous dates may require manual frontmatter editing.

Alternatives: the note-per-task vs. database-native approach

The most direct alternative is Obsidian's built-in Tasks plugin, which uses inline markdown checkboxes and a query language for filtering. The key difference is that Tasks does not create a separate note for each task. Tasks live inside your existing notes, which is lighter and keeps related tasks in context. TaskNotes, by contrast, forces a note per task. That is a deliberate trade-off: you get a full note to attach details, but you lose the ability to see tasks inline in your daily notes without extra queries. Another alternative is a dedicated task manager like Todoist or TickTick, which store data in their own cloud. Those tools offer native mobile apps, natural language input, and robust recurrence, but they do not give you plain Markdown files. If portability is your priority, TaskNotes wins. If you want a minimal footprint inside Obsidian, the built-in Tasks plugin may be enough. The README does not compare itself to these tools, but the design choices are clear from the data model.

Maintenance, licensing, and upgrade considerations

The repository is under the MIT license, which is permissive. You can use, modify, and distribute the plugin without restrictions beyond preserving the copyright notice. That is a low-risk license for internal adoption. Maintenance appears active. The last push was August 2026, and there is a 5.0.0-beta.2 release from the same date, alongside the stable 4.12.5. The project is not archived. The README mentions a documentation suite that generates screenshots via Playwright, which suggests a level of testing infrastructure. However, the README does not describe a migration path between major versions. The 5.0 beta could introduce breaking changes to the .base file formats or the HTTP API. Before upgrading from 4.x to 5.x, you should back up your vault and read the release notes, which are not included in the material. The plugin's reliance on Bases means you also need to track Obsidian's own update cycle. If Bases changes its query syntax, TaskNotes may need updates to stay compatible. That is a maintenance cost you inherit by using this plugin.

What to verify before adopting TaskNotes

The README gives you a clear picture, but it leaves several questions open. First, confirm that your Obsidian installation includes Bases and that it is enabled. Second, test the natural language parser with your own phrasing. The README's example is simple, and your date formats or context tags may not parse as expected. Third, check how the recurrence materialization works in practice. The README explains what an occurrence note inherits and what it does not, but it does not show how the UI handles editing a materialized occurrence versus the parent. Fourth, if you plan to use the HTTP API, read the HTTP_API.md file in the docs folder. The README only mentions that it exists. Fifth, if calendar sync matters to you, verify whether it is one-way or two-way. The README does not specify. These checks are concrete and tied to the project's own documentation. Without them, you might assume behaviour that the plugin does not deliver.

Editorial conclusion

Adopt TaskNotes if you already live in Obsidian and want tasks that stay readable as plain Markdown with YAML, and if you are comfortable with Bases as the query layer. Skip it if you need a standalone task database, if your vault is shared with users who do not use Bases, or if you require offline-first time tracking without external sync. Before adopting, verify that your Obsidian version includes Bases, test how the natural language parser handles your date and context phrases, and confirm that the RRULE recurrence plus materialized occurrence behavior matches your scheduling needs. The project is actively maintained with a 5.0 beta, but the beta may change APIs, so pin to a stable release like 4.12.5 for production use.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes