eyaltoledano
Introduce Taskmaster Modes & Remote Integration Support
“When developing solo, using local task files makes sense, but as soon as multiple people contribute or multiple branches are involved, merge conflicts occur. I need a straightforward way to use a centralized remote source (like GitHub or a database) for tasks to avoid conflicts and enhance collaboration.”
⸻
Motivation
Task Master currently stores tasks locally, which works well for solo development. However, this approach introduces merge conflicts and collaboration challenges in team environments or projects with multiple branches. Users need clear operational modes: • Solo Mode: Local task management using files (tasks.json). • Multiplayer Mode: Centralized, remote task management through integrations (GitHub, databases, APIs, SDKs, or MCPs).
Introducing these operational modes will allow Task Master to seamlessly support solo and collaborative workflows. Additionally, the system must be agnostic and easily extensible, enabling quick integration of new remote sources.
Connected to #11
⸻
Proposed Solution
Implement distinct operational modes and an agnostic integration layer for remote task sources: • Operational Modes: • Solo Mode: Uses local task files (tasks.json). Default configuration suitable for solo development. • Multiplayer Mode: Dynamically manages tasks using centralized, remote sources (GitHub, databases, APIs, SDKs, MCP servers). • Dynamic Remote Integration Layer: • Develop a modular integration approach that seamlessly supports: • MCP (Model Context Protocol) servers. • Direct SDK integrations. • API-based integrations. • Database URLs (e.g., PostgreSQL hosted remotely). • Initial Multiplayer Implementation: • Start with GitHub integration as the default multiplayer task source. • Include support for PostgreSQL databases hosted remotely as an additional integration. • Allow users to configure and switch between integrations easily via CLI.
⸻
High-Level Workflow 1. Define and implement operational mode toggling between solo (local files) and multiplayer (remote). 2. Design an integration layer that abstracts task operations for various remote sources: • MCP servers. • SDK-based integrations. • API-driven integrations. • Database-driven integrations via URL (PostgreSQL, etc.). 3. Implement initial integrations: • GitHub for centralized remote task management. • PostgreSQL for database-backed task management. 4. Provide CLI commands for easy mode configuration and remote integration management. 5. Clearly document how users can extend integrations to other remote sources in the future.
⸻
Key Elements • Command syntax:
# Switch to multiplayer mode with GitHub integration
task-master mode multiplayer --integration=github
# Switch to multiplayer mode with PostgreSQL integration
task-master mode multiplayer --integration=postgres --db-url="postgres://user:password@host:port/dbname"
# Switch back to solo mode
task-master mode solo
• Modular and extensible integration architecture.
• Initial implementation and documentation focusing on GitHub and PostgreSQL integrations.
⸻
Implementation Considerations • Clear abstraction layer separating local and remote task operations. • Easy extension and documentation for future integrations. • Robust handling and clear documentation of task conflicts and synchronization. • User-friendly CLI for mode switching and integration management. • Secure handling and validation of database connection URLs and credentials.
⸻
Out of Scope (Future Considerations) • Advanced automatic conflict resolution. • Real-time collaborative editing of tasks. • GUI-based integration configuration.
Would this include integrations with atlasian or other online task trackers like clickup or asana?
I wonder how to design this in agnostic way that can be plugged into Linear, Gh Issues and Atlassian, and even custom tm-native source control / issue tracker etc?
or if it's better with something completely sovereign like https://radicle.xyz/ or broadly https://docs.radworks.org/ or https://codeberg.org/
I think we're going to open a world of hurt if we attempt integrations from the open source package. That's out of its scope (and squarely within the scope of the commercial product)