# dotpm: Gantt, table and board views over plain Obsidian notes

> dotpm is an Obsidian community plugin that turns Markdown notes into project tasks, with a table, a Gantt timeline and a Kanban board reading the same files, plus a local HTTP and MCP server so a coding agent can pick up and close a task. The scheduling is real, and so are the limits.

**dotpm/obsidian-pm** — Project management inside Obsidian. Table, Gantt and Kanban over plain Markdown notes, with a local API for agents and scripts.

- Repository: https://github.com/dotpm/obsidian-pm
- Website: https://dotpm.pm
- Stars: 758 · Forks: 86
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/dotpm-obsidian-pm

## A project is a note and a task is a note

dotpm does project management inside Obsidian, with a table, a Gantt timeline and a Kanban board over plain Markdown notes. The problem it names is that project tools keep the plan in one application and the thinking in another, and the plugin keeps both in the vault.

The design consequence is that a project is a note and a task is a note. A task is a Markdown file with YAML properties in the frontmatter, and the body is ordinary Markdown text. The documentation says a task can be opened in Obsidian, edited in any text editor, or diffed in git, and that search, the graph, templates and Dataview all work on them because they are notes rather than rows in a database.

Here is what a task file looks like:

```yaml
---
pm-task: true
projectId: '[[Website redesign]]'
title: 'Write the launch post'
type: 'task'
status: 'in-progress'
priority: 'high'
start: '2026-09-01'
due: '2026-09-20'
progress: 40
assignees: ['[[Alice]]']
tags: ['marketing']
dependencies: ['[[Design the homepage]]']
---
Draft, review with the team, publish on launch day.
```

Everything in the views is in that file. The status, the priority, the dates, the progress number, the assignees, the tags and the dependencies are all frontmatter properties, and the last line is the body of the task.

Because the format is a plain file, sync works the way it does for any other note. Obsidian Sync, iCloud, Syncthing and git all carry projects along, and a project folder can be diffed and reviewed in git like any other code. The documentation is also honest about what that does not buy you: two people editing the same task at the same moment produce an ordinary sync conflict, and there is no real-time collaboration beyond that.

## Scheduling with dependencies, not just due dates

The headline feature is described as scheduling rather than checkboxes. Tasks have start and due dates, dependencies drawn as arrows, and a Gantt timeline that moves dependents when a blocker slips.

That last clause is the substantive one, and it is repeated in the features list under planning as auto-scheduling, where dependents move when a blocker moves. A task board that only stores a due date is a list, and a board that propagates a slip through the dependency chain is a schedule.

The timeline view is where that shows up. Dragging a bar reschedules the task, dragging its edge changes the duration, and dragging from one bar to another adds a dependency. The scale zooms from days to years and is kept per view, milestones are diamonds, and a line marks today.

The planning features around it are more modest but practical. There are due date reminders, archiving either by hand or automatically after a set number of days, and undo and redo.

The task model itself is broader than the classic three fields. Subtasks go to any depth. Dependencies work within a project or across projects, and there are milestones. There are recurring tasks, time estimates and time logs, and custom fields with the types text, number, date, select, multi-select, person, checkbox and URL. Every task also carries a Markdown body.

Dependencies across projects is worth pausing on, because it is the kind of feature that changes how you structure your vault. It means a project can depend on a task in a different project, so the auto-scheduling will move work that lives in another folder, and the propagation is not confined to a single project boundary.

## The three views read the same files in different ways

The table, the timeline and the board are three ways of looking at the same data, and each view is genuinely different rather than a reskin.

The table sorts, filters and edits inline. A multi-row selection changes status, priority, assignee, tags, due date or parent for all of them at once, and a filter and sort combination can be saved as a named view. Sorting works on up to three keys in the table and on the board.

The board has one column per status, or per priority, assignee, tag, type or custom field. Dragging a card to another column changes that value, columns can be reordered or hidden, and cards show priority, assignees, tags and due date.

The timeline is the Gantt view described earlier, and the scale is kept per view, so a project can open on a week scale and a yearly plan can open on a quarter scale without you resetting it each time.

Underneath the views there is a shared filtering and organizing layer. You can filter on any field, custom fields included, with the operators is, is not, contains, between, date buckets and ranges. Saved views are named filter and sort combinations, and one of them can be starred as the view a project opens with. There are sub-projects with an overview page per project showing progress, milestones, sub-projects and properties. A view can cover one project, its subtree, a folder, the whole vault, or a set of projects picked by hand. There is a project list you can search, filter by progress or tag, sort, group by folder or tag, and save views of.

People notes are a nice touch for assignees. Each person gets a note with a per-person task list, and an avatar colour set by the note's own color property.

## The local API and MCP server are the interesting part

The claim in the README is that agents and scripts can work the board. A local HTTP and MCP server and a command line client edit the same notes the views do, so a coding agent can pick up a task, update it and close it.

This is the feature that distinguishes dotpm from a plugin that only renders views. The design keeps the notes as the source of truth, so an agent does not need a special integration: it edits the same Markdown files the table edits, and the views pick up the change. The alternative design, where a project tool has its own database and its own API, would have put a second representation of your plan next to your notes, and this one deliberately avoids that.

The API is turned on from Settings > Local API, and the README section describing it is cut off in the version available here, so the exact endpoints and the command line client syntax are not visible. What is visible is that both exist, and that the Local API setting is what switches the server on.

The other half of the story is export. The dotpm: Export current view as HTML command writes the open table, timeline or board to a single file that opens in any browser, with the tasks, the filter and the icons inside it. So a project review can leave Obsidian entirely, and the plugin runs on desktop and mobile while any view exports to one HTML file.

The context for all of this is that nothing has to be signed up for. Projects sync with whatever already syncs the vault, and there is no account, no service and no subscription involved in the project data.

## Installing it and turning an existing note into a project

Installation is through the Obsidian community plugin directory. In Obsidian you open Settings > Community plugins > Browse, search for dotpm, and install and enable it, or open the listing directly. The plugin needs Obsidian 1.13 or newer and works on desktop and mobile.

There is a path for people who want the beta builds. Using BRAT, you install BRAT itself, choose Add beta plugin and enter dotpm/obsidian-pm. The manual route is to download main.js, manifest.json and styles.css from the latest release into the .obsidian/plugins/project-manager/ folder in your vault, then reload Obsidian and enable the plugin.

The first run is a short sequence. You click the timeline icon in the ribbon or run dotpm: Open projects pane, click New project, give it a name and open it, then click Add task and set a status, a due date, an assignee or whatever you need. You switch between Table, Timeline and Board from the last part of the path at the top of the view. After that you look in your vault and find a Projects/Your project.md note and a Projects/Your project_tasks/ folder with one note per task.

That last step is the one to check. The views are a rendering of files, and seeing those files appear in your vault is the confirmation that the plugin is really writing Markdown rather than keeping its own store.

There is also a path in for existing notes. The dotpm: Import notes as tasks command brings notes you already have in as tasks. To turn an existing note into a project, you add pm-project: true to its properties and run dotpm: Open current file as project, which is the same marker style as the pm-task: true property in the task format.

## Where dotpm is the wrong tool

The first wrong case is a team that needs genuine collaboration. The documentation is explicit that two people editing the same task at the same moment produce an ordinary sync conflict, and that there is no real-time collaboration beyond that. For a team that plans together in the tool rather than asynchronously, that is a disqualifying limitation, and no amount of conflict resolution in the plugin changes the underlying model.

The second is a project with heavy dependencies across a large vault. Auto-scheduling moves dependents when a blocker moves, and that is a good feature until the propagation is large enough that you cannot predict which task will shift when you drag one bar. The scale of the vault you can put in front of the timeline is not documented, and the export is one file, which suggests a view rather than a picture of the whole portfolio.

The third is a task body that needs to be more than text. Every task has a Markdown body, which is excellent for prose and notes, and inadequate for a specification with a table, an embedded diagram or a tracked checklist with dependencies inside it. You can link to other notes, but the body is a file, not a rich editor.

The fourth is anything that wants a real backend. The local API and MCP server are for agents and scripts on the same machine, and the local API is off until you switch it on. There is no shared server, no access control, no web app and no reporting for people who are not using Obsidian. The HTML export is a single file that opens in a browser, which is good for sharing one view and not a replacement for a team dashboard.

One more practical note: the plugin lives in the Obsidian community directory, so its distribution depends on the Obsidian review process and its release cadence rather than on a package registry you control.

## Conclusion

Adopt dotpm if you already keep your notes in Obsidian and want scheduling and dependencies without a separate project tool, since a project and its tasks are ordinary notes you can diff in git, and the local API lets an agent work the board. Keep away if you need real-time multi-user collaboration, because the documentation is explicit that two people editing the same task produce an ordinary sync conflict with nothing beyond that, or if you need a rich text task body, since a task is a Markdown file. Before you install, note that the plugin needs Obsidian 1.13 or newer, that release 2.6.0 is dated 2026-10-06 and the last push was on 2026-10-10, and that the exported HTML is a single file rather than a shareable server app.

## FAQ

### How is a dotpm task stored in my Obsidian vault?

As a plain Markdown note with YAML properties in the frontmatter, including pm-task, projectId, title, type, status, priority, start, due, progress, assignees, tags and dependencies, followed by the Markdown body. You can open it in Obsidian, edit it in any text editor, or diff it in git.

### How do I install the dotpm Obsidian plugin?

In Obsidian open Settings > Community plugins > Browse, search for dotpm, and install and enable it, or open the plugin listing directly. It needs Obsidian 1.13 or newer. For beta builds, add dotpm/obsidian-pm through BRAT, or copy main.js, manifest.json and styles.css into the .obsidian/plugins/project-manager/ folder.

### Can an AI agent or script update tasks in dotpm?

Yes. A local HTTP server and an MCP server edit the same notes the views do, so an agent can pick up a task, update it and close it. The server is switched on through Settings > Local API, and there is also a command line client.

### Does dotpm support real-time collaboration between people?

No. The documentation states that two people editing the same task at the same moment produce an ordinary sync conflict, and that there is no real-time collaboration beyond that. Sync works through Obsidian Sync, iCloud, Syncthing or git.

## Sources

- [dotpm/obsidian-pm on GitHub](https://github.com/dotpm/obsidian-pm)
- [License: MIT](https://github.com/dotpm/obsidian-pm/blob/main/LICENSE)
- [Project website](https://dotpm.pm)
- [README](https://github.com/dotpm/obsidian-pm/blob/main/README.md)
- [Releases](https://github.com/dotpm/obsidian-pm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dotpm-obsidian-pm