Task Genius: turning an Obsidian vault into a task management system

Task views over notes you already keep

Task Genius is described as a plugin that transforms Obsidian into a task management system with advanced features, visualisations and in-editor task management, while preserving Obsidian's philosophy of plain-text note taking. The homepage is taskgenius.md, which carries the full feature documentation.

The core features are grouped in a table, and the grouping is instructive because it distinguishes two different kinds of extension. Some features are view based: task views in list, kanban, calendar and gantt form, recurring tasks and multiple date types with visual priority indicators, habit tracking with daily habits and streak tracking and a visual calendar and progress analytics, and gamification through achievements, custom milestones and motivational feedback. Others are editor based: multi-stage workflows with automatic timestamping, templates and process tracking, and advanced in-editor filtering with saved queries and custom perspectives. Quick capture sits between them, with global commands, templates and automated task creation.

That split is the interesting design decision. A plugin that only added a board would be a viewer, and a plugin that only added inline decorations would be a formatter. Task Genius does both, and the view-based features exist to give a different read on the same underlying Markdown tasks that the editor-based features manipulate. The stated goal is a workflow inside the editor rather than a separate task application.

The plugin is TypeScript, published under the taskgenius organisation with the issue tracker at taskgenius/taskgenius-plugin and feature requests in the discussions area of the same repository.

Installing from the community list or by hand

There are two documented routes and both are short.

The recommended one is the Obsidian community plugin route: open Obsidian Settings, go to Community plugins, search for Task Genius, click Install, then Enable. That is the normal path for any Obsidian plugin and requires no command line.

The manual route is for a vault that cannot reach the community plugin directory. You download the latest release from GitHub Releases, extract the files to the plugin folder in your vault, and then enable the plugin in Obsidian settings:

.obsidian/plugins/obsidian-task-progress-bar/

That path is worth reading twice. The folder name is obsidian-task-progress-bar, which reflects the plugin's earlier identity as a progress bar tool rather than the current Task Genius name. The repository name, the plugin name and the directory name are three different strings, and the readme also still points its release links and version badge at a Quorafind/Obsidian-Task-Genius repository while the issue tracker and discussions links go to taskgenius/taskgenius-plugin. None of this is a problem in practice, since Obsidian reads the plugin identity from the manifest, but it does mean that when you go looking for the release page you have two candidate repositories in the readme and the answer is not obvious from the text alone.

After installation the readme offers two ways forward. You can enable the plugin and let it guide you through an onboarding flow. Or you can open the task view directly, either from the ribbon icon or by searching Open Task Genius View in the Command Palette, create your first task through the Quick Capture panel, and then switch between the different views to find the one that fits how you work.

The onboarding path is the more guided one, and for a plugin with this many settings it is probably the right first step.

The build pipeline, and the beta channel the project runs on

The repository is a pnpm workspace with a fairly involved release setup, and the package.json scripts describe it precisely.

The development loop is a dev script that runs node esbuild.config.mjs, and the production build runs a type check first and then esbuild in production mode:

tsc -noEmit -skipLibCheck && node esbuild.config.mjs production

The build configuration is a separate esbuild.config.mjs at the root, and the output is a single main.js, which is the entry point Obsidian loads for a plugin.

The release machinery is where the repository's size comes from. There are three release-it configurations, .release-it.cjs, .release-it.beta.cjs and .release-it.beta-continue.cjs, and a set of scripts wrapping them: release:patch, release:minor, release:major, release:dry, plus a separate beta family built on a script called smart-beta-release.mjs with its own continue, patch, minor, major and dry modes. A version script runs version-bump.mjs and then stages manifest.json, manifest-beta.json and versions.json, so the plugin manifest, a separate beta manifest and a version list are all kept in step.

There are two manifests, manifest.json and manifest-beta.json, and a separate CHANGELOG-BETA.md alongside CHANGELOG.md. The recent releases confirm which line is running: 9.14.0-beta.3 from 2025-12-15, 9.14.0-beta.4 from 2026-01-05 and 9.14.0-beta.5 from 2026-06-28, all titled as betas. The version in the package.json is 9.14.0-beta.5.

Testing is jest, with jest.config.js at the root, and there is a test:watch script alongside. Formatting and linting are configured with .eslintrc, .eslintignore and .prettierignore, and .husky/ holds the git hooks. Internationalisation has its own toolchain: an i18n/ directory, an extract-translations script, a generate-locale-files script and a compile-i18n script.

Localisation, privacy and the optional Google credential

Two repository files deserve attention because they describe behaviour a user would otherwise have to discover.

The .env.example is short and reveals that the plugin has an optional Google OAuth integration. It asks for a Google OAuth client secret, base64 encoded, and points at Google's OAuth 2.0 native app protocol documentation, noting that for development you should use your own Google Cloud Console credentials. It also holds a GitHub token for releases, marked optional and for release-it.

The presence of a Google client secret in an Obsidian plugin is worth pausing over. The environment file is an example rather than a value, and the pattern of a plugin talking to a user's Google account points at some kind of sync or calendar feature. What the repository listing does not show is which feature needs it, so a user evaluating this plugin for a vault with sensitive notes should read the documentation at taskgenius.md before deciding whether to supply a credential. There is a PRIVACY.md at the root, which is where that question should be answered, and the repository's .gitignore is where the real .env is kept out of version control.

The other file of note is CLA.md, the contributor licence agreement, which sits next to DEVELOPMENT.md for developers and scripts/ for the automation.

There is also a .gitmodules at the root, which indicates at least one dependency is pulled in as a git submodule rather than through the package manager, and packages/ alongside src/ suggests the code is split into a workspace of packages and the plugin itself.

Licensing, and the components the author opens up

The licence situation has two parts, and both are unusual.

The readme points at FSL-1.1-ALv2 in the LICENSE file, which is the Functional Source License version 1.1 with the Apache 2.0 licence as the alternative once the change date has passed. A source-available licence of this kind is not the same as an open source licence: the practical effect is that the code is available to read and build on, with conditions attached, and the terms only become Apache 2.0 after a specified date. GitHub's own licence classifier does not recognise this licence, which is consistent with it sitting outside the set GitHub treats as open source. Anyone planning to redistribute the plugin or build on it needs to read the LICENSE file directly rather than rely on the badge.

The second part is a carve-out, and it is stated plainly: you are free to use any part of src/components, such as the Inline Markdown Editor or the Kanban component. So the author is explicitly opening the component layer for reuse while keeping the plugin as a whole under the FSL terms. For a developer who wants an inline Markdown editor or a kanban board component for their own Obsidian plugin, this is the most practically useful line in the readme.

There is a signatures/ directory at the root, which is unusual for a plugin repository and suggests release signing or signature verification material is kept there, and a media/ directory holding the images the readme embeds, including the Task Genius logo in webp form.

Where Task Genius is the wrong choice

The first limitation is the beta channel. Every published release in the list is a 9.14.0 beta, and the last push was on 2026-06-28. The version numbering has been on 9.14.0-beta for several releases across 2025 and 2026, which means the plugin's stable line and its beta line are being shipped separately and the beta is the one advancing. A user who wants a plugin that will not change under them mid-workflow has to pick a stable release and accept that it will be behind.

The second is the sheer size of the thing. This is a plugin with kanban, calendar and gantt views, workflows with templates and timestamping, habit tracking with streak analytics, gamification with achievements and milestones, saved queries and custom perspectives, a Quick Capture system and an onboarding flow. Obsidian's own philosophy is plain-text notes with small composable plugins, and this one is closer to a task application embedded in an editor. That is a legitimate choice, but it is a large amount of surface for a note-taking tool, and every setting is another thing to configure and understand.

The third is the licensing for anyone who intends to build on it beyond the src/components carve-out. FSL-1.1-ALv2 is a source-available licence with a change date, and the practical question of what you may do with a modified plugin before that date has to be answered from the LICENSE text, not from this description.

The fourth is the optional Google OAuth credential. If your reason for using a task plugin is that your notes stay local, then a plugin that can talk to Google with your own client secret deserves a look at PRIVACY.md before you configure it. The readme does not document what the integration is for, which is itself the reason to check.

The fifth is the naming inconsistency for anyone automating an install. The community plugin directory, the ribbon command name Open Task Genius View, the plugin folder obsidian-task-progress-bar and the two candidate GitHub repositories mean that any script that resolves one of those names by string will need the right one for each case.

Editorial conclusion

Task Genius fits an Obsidian user whose tasks already live in notes and who wants dashboards, kanban boards and habit tracking over the same Markdown rather than a second application, since every view reads and writes the tasks already in the vault. It is the wrong choice if you need a stable release, because the published versions are 9.14.0 beta builds and the last push was on 2026-06-28, and it is the wrong choice if the FSL-1.1-ALv2 licence does not fit your distribution plans. Before adopting it, read the LICENSE file, note that the plugin directory name in the manual install instructions does not match the plugin name, and check whether the beta channel is acceptable for your vault.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. taskgenius/taskgenius-plugin on GitHub