eyaltoledano
Feature: GitHub Integration
Motivation
TaskMaster currently relies on local files (tasks.json and individual task files) to manage tasks. This approach is effective and straightforward for individual developers, but it quickly breaks down in team scenarios. Specifically, local storage causes merge conflicts when multiple developers add tasks simultaneously across different branches.
To address this limitation and enable "TaskMaster Multiplayer," we propose integrating GitHub Projects to serve as a centralized task management backend.
Proposed Solution
Add an option to TaskMaster CLI to use external task management backends (starting with GitHub Projects), in addition to the existing local storage approach. Tasks would then be sourced from GitHub Issues instead of local files.
This integration would significantly improve collaborative workflows by eliminating task conflicts, providing centralized task storage, and allowing two-way synchronization between GitHub Projects and the CLI.
Key Elements
-
Centralized Task Database: Use GitHub Projects and Issues as the primary source of tasks, replacing local files (
tasks.jsonand task files). -
Configurable Backend: Allow the user to choose between:
- Local task storage (current behavior).
- GitHub Projects (new integration).
- Future support for other services like Trello, Asana, Linear, etc.
-
Benefits:
- Eliminates merge conflicts associated with local task storage.
- Allows collaboration ("TaskMaster Multiplayer") with tasks visible to the whole team.
- Enables users to manage tasks directly via GitHub’s UI, providing an additional interface.
- Potential for seamless two-way synchronization (CLI <-> GitHub).
-
Implementation Considerations:
- Requires GitHub token stored securely (e.g., in an environment variable).
- Introduces latency due to network/API calls, mitigated through caching or optimized SDK usage.
- Each task would correspond to a unique branch and Pull Request (PR).
- Major effort: requires updating ~20 existing CLI commands to support remote task storage.
- Create a reusable
GitHubServiceclass wrapping GitHub’s SDK to abstract API interactions.
Example Workflow
- User creates a new task using TaskMaster CLI.
- CLI creates a corresponding GitHub Issue and branch.
- Developers collaborate via GitHub Projects UI or CLI commands.
- When tasks are updated via GitHub (e.g., status change, comments), CLI reflects these updates locally upon sync.
- Merging branches becomes straightforward, avoiding the issues seen with local JSON files.
New Commands or Flags
-
task-master sync: Synchronize tasks from GitHub Projects to local CLI (bi-directional). - Potential new flags (
--backend=github) on task-related commands (e.g.,add,update,complete) to specify the active backend.
Out of Scope (Future Considerations)
- Integration with other task/project management tools via MCP or custom wrappers (e.g., Trello, Linear).
- Real-time sync optimizations or advanced caching layers to reduce latency.
Feedback Wanted
- Does this clearly solve the issues encountered with local storage?
- Are there any additional considerations or edge cases I may have missed?
- Suggestions regarding the usability or UX of choosing between local storage and external services
Feels like vendor lock.
Would create our own platform, that would read the tasks inside the repo and make it prettier. Similar to supabase database viewer.
Then we would later on add support for all the other tasks and just move them into our platform. Easier to handle tasks.
Would be nicer than having to integrate with:
- jira
- linear
- GitHub
- plane
- asana
- the list goes on...
Yeah our own platform would effectively be the local way. We'll still want to be able to support using an external service to properly plug into people's workflows. Not everybody is down to run their task management through text files, especially if their workflows already depend on GitHub Issues, Linear, or some other.
We don't need to support all of them all at once. We can create a service to consume the api/sdk docs and produces the interface for it. it should just be a repeatable/reusable system
This is fairly low priority for now but an eventuality
Thinking about this -- unsure if we ought to use just regular GitHub issues or actually leverage the GitHub projects. The latter is more involved but lesser adopted.
Even we aren't using it (yet)
Would be nice to integrate it with github-project sub-issues https://github.com/github/github-mcp-server/issues/117
Just a small thought 🤔 on this. I believe a stronger approach would be to build something "locally"/"custom" so you can have a curated user experience workflow ✨.
For example, with the tasks that I create, or that I've seen people create with Taskmaster, they're normally tasks that can be accomplished fairly quickly ⚡. And the beauty of what Taskmaster allows us to do is to create the dependency graph 🕸️ along with all the tasks for a build very quickly.
Imagine seeing a directed a cyclical graph (DAG) 📈 around all those tasks -- powerful 💪. I think that no tool is suited yet to display what you all are trying to do with Taskmaster and there is a unique way to visualize it. (shrimp does some visualization that i'm thinking about, but I think taskmaster has an edge to build something better)
I wouldn't look to have GH or an "out of box" task application be your primary GUI because it doesn't do your product justice. In the future you can implement an adapter pattern to help you integrate. Just my current thoughts 🤷🏼 .
FIle based config is ok, BUT GH should be out-of-the-box, imho. Because here we are...
The ability to store tasks as GitHub issues is just admitting that you're using GitHub issues - PR to track changes in your development workflow, which is normal and not mandatory; users could still use the local storage. It would also unlock the possibility for users to use Copilot Coding Agent to work on issues for them.
On a related note, a nice feature to have would be to have the PRD definition coming from a Github issue instead of from a local file.
