Get AI summaries of any video or article — Sign up free
Automatically Send all your Todo's / Tasks to a master Todo file like Roam in Obsidian thumbnail

Automatically Send all your Todo's / Tasks to a master Todo file like Roam in Obsidian

Productivity Guru·
4 min read

Based on Productivity Guru's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Install and verify Ruby with `Ruby -V` before running `todo.rb`.

Briefing

Roam’s standout “master task” workflow—where tasks created anywhere automatically appear in a single central list—is now replicable inside Obsidian using a Ruby script. The approach scans an Obsidian vault (including all subdirectories) for Markdown files containing todo/task syntax, then aggregates every matching task into one master file so users can review and manage everything from a single location.

The setup starts with verifying Ruby is installed by running `Ruby -V` in a terminal. With Ruby available, the next step is downloading a script from a GitHub repository under a larger collection called “Obsidian Utilities.” The user then opens the specific “Todo” script (named `todo.rb`) and edits a path variable inside it. That path points to the vault location in Dropbox/Flat para (as shown in the transcript), and the script uses it to locate and scan the vault’s directories.

Once the script is saved, it’s run manually with `Ruby todo.rb` from within the folder containing the script. The script performs a full scan, finds Markdown files that include todo/task entries, and writes them into a master todo file. If the master file already exists, the script overwrites it on each run, ensuring the central list reflects the current state of tasks.

A practical test confirms the behavior. A sample task added to the vault’s journal section appears in the aggregated master list. Existing tasks already present across multiple files also show up, including tasks embedded in templates. The transcript notes that tasks are tracked along with their source file, so the aggregated list reflects where each task came from.

Task completion status also syncs through the aggregation process. When a task is marked done in the master list, it disappears from the next aggregated output after rerunning the script—indicating the script respects completion state and rebuilds the master list accordingly. The same effect occurs when marking tasks done from different source areas (for example, tasks originating in a “template” file versus a journal file).

For automation, the workflow is designed to run on a schedule—such as via a cron job at a set time each day—so the master todo file updates automatically without manual intervention. The transcript highlights an important caution: because the script overwrites `todo.md` every time it runs, any manual notes written directly into the master file will be lost. The master file should function strictly as an aggregator, not a place for additional content.

Overall, the method delivers a “single pane of glass” for tasks across an entire Obsidian vault, eliminating the need to hunt through nested folders to find todos and making task review consistent and centralized.

Cornell Notes

A Ruby-based script can aggregate all Obsidian todo/task entries from an entire vault into one master `todo.md` file. It scans the vault and all subdirectories for Markdown files containing todo syntax, then rewrites the master file on every run so the list stays current. Tasks marked done in the source (or reflected in the master) stop appearing after the next aggregation. The workflow can be run manually with `Ruby todo.rb` or automated with a cron job (e.g., daily). Because the script overwrites `todo.md`, users should not store extra notes in that master file.

How does the script find todos across an Obsidian vault?

It runs a vault-wide scan starting from a configured path (edited in the script to point to the vault location, shown as a Dropbox/Flat para path). The scan includes subdirectories, and it looks for Markdown files that contain todo/task entries. Matching tasks are then collected into the master todo file.

What command runs the aggregation, and where does it run from?

The transcript shows running `Ruby todo.rb` after changing into the folder containing the script. On macOS, the user drags and drops the script folder into the terminal to set the working directory, then runs `Ruby todo.rb`.

What happens to the master todo file each time the script runs?

The script overwrites the master `todo.md` file on every run. That’s why the aggregated list updates in real time after rerunning—new tasks appear, and tasks marked done no longer show up.

How can users confirm tasks are being pulled from multiple places (journal, templates, nested files)?

The transcript demonstrates adding a sample task in the journal and seeing it appear in the aggregated master list. It also shows tasks originating from a template being picked up, with the master list reflecting which source file each task came from.

Why is a path formatting detail important?

A mistake in the configured folder path initially prevented the master file from being created. Adding a backslash after the folder path corrected the issue, after which the script successfully generated the aggregated `todo.md`.

What’s the key risk of writing directly into `todo.md`?

Any manual edits or notes added directly to the master `todo.md` will be erased the next time the script runs, because the script rebuilds/overwrites that file every run. The master file should be treated as an aggregator only.

Review Questions

  1. What changes in the script configuration are required before running the aggregation, and why does the path matter?
  2. After a task is marked done, what should happen to it in the master todo list after the next script run?
  3. Why should users avoid adding custom notes directly into `todo.md` when using this workflow?

Key Points

  1. 1

    Install and verify Ruby with `Ruby -V` before running `todo.rb`.

  2. 2

    Download the Obsidian Utilities collection from GitHub and open the specific `todo` script to edit its vault path.

  3. 3

    Configure the script’s path to the Obsidian vault root (including correct formatting such as a trailing backslash) so it can scan all subdirectories.

  4. 4

    Run the script with `Ruby todo.rb` from the script’s folder to generate or refresh the aggregated master `todo.md` file.

  5. 5

    Expect the script to overwrite `todo.md` on every run, so the master file should not be used for manual notes.

  6. 6

    Use a cron job (e.g., daily at a set time) to keep the master task list continuously updated without manual execution.

  7. 7

    Marking tasks done should remove them from the next aggregated output, reflecting the current completion state across the vault.

Highlights

The workflow rebuilds a single master `todo.md` by scanning every Markdown file in an Obsidian vault, including nested folders.
Each run overwrites the master file, so the central list stays accurate—but manual notes in `todo.md` get wiped.
Tasks from multiple sources (journal entries and templates) appear together, with the master list reflecting their originating files.
A cron job can automate daily aggregation, turning scattered todos into a consistent “one place to check” system.

Topics

  • Obsidian Todos
  • Ruby Script
  • Task Aggregation
  • Cron Automation
  • Master Todo File