What’s the recommended post-v1 workflow for new features?

[rhinck]

First off, huge thanks for building this. I’ve tried stitching together similar workflows manually when I hit friction with vibe-based coding, but having a structured system like this with both framework and code is incredibly valuable.

I understand the core flow: write a PRD → generate tasks → implement a task/subtask with Cursor AI → mark task as done (repeat). What I’m unsure about is what the recommended workflow looks like after I ship a v1 of my project.

Specifically:
• Is tasks.json intended to be a running log of the full project history?
• Or is it something you reset per version or release?
• Is the PRD just meant to define the initial vision and scope, and after that everything is handled via the CLI (e.g. add-task, update, expand, etc.)?
• Or should I continue writing new PRDs for each major feature or update and parse them to append to the task list?

When I want to add a new feature post-launch, should I:
• Create a new PRD per feature?
• Parse it and append to the existing tasks.json?
• Or skip the PRD and just use the CLI to add new tasks directly?

I might have missed this if it’s been answered already—apologies in advance! Just looking for guidance on how best to organize ongoing development using Task Master + Cursor as the project evolves.

Thanks again for making this tool 🙌

[eyaltoledano]

i've been thinking about this a lot. i think this merits a proper response so here goes:

there are some nuances because tasks.json is meant for solo-dev (see #91), but i've also been wondering whether it makes sense for tasks.json to also be disposable if need be when used within the context of a single PR for example (start a PR, init, start tasks only around PR). The tasks files for that PR would get checked in with the PR which is a useful thing for the next dev who pulls that PR to be able to reference and build upon. Things start to get dicey when you introduce multiplayer -- and #91 is meant to address that

as far as what to do post v1, i'd honestly just tell you to add-task

i finished "v1" of taskmaster on the first night I released it. as i worked on it, I'd been adding a bunch of ideas to my task list. now, those tasks are waiting for me and are pre-researched. i just need to tell the agent to work on them and commit them as PRs one at a time.

So, specific answers to your questions based on how I use it :

1. Yes, I use tasks.json as a running log of the full project history. This gets heavier the more tasks you have, so Move finished tasks into "done" folder #8 is something I considered doing and may still end up doing. But yes, everything stays, and it's permanent context you never know when you'll need.
2. Per my above comments, you certainly could try a workflow where you're doing a task-master init on a per version or per PR basis -- and I think that would work potentially really well, but you'll be missing the global view which I think is the main value proposition. Folks need to be able to wrap their minds around the entire project and then orchestrate the AI towards it
3. Yes, the PRD is meant only as a way to generate the initial list of tasks (to satisfy the PRD "initial version") and you're meant to build on top of those tasks as you finish the original tasks (ideas will come up that you may defer to later) and after you've finished it (next versions). That said, my plan is to introduce a new paradigm whereby the PRD, the code and the tasks are always in sync with each other. Thus, when you finish the project and add Task ABC, the PRD should reflect that change by recomposing itself. We're not ready for this yet, but it's part of the eventual complete solution.
4. If you write different PRDs for each feature and parse them, right now they'll overwrite your initial tasks list. I don't think that makes sense. I've created an issue (feat: Add --append flag to parsePRD command to append generated tasks #207) that adds the --append flag to parsePRD so that the tasks it generates get appended to the tasks list rather than at the top of it. This way, the use case of doing PRD-by-PRD work becomes possible and elevates the workflow up a level of abstraction even more. Solid gold here, wouldn't have come up with this one with you.

When you want to create a new feature post launch, just add-task and then expand the task in as many subtasks as needed. I have some tasks with as many as 60 subtasks. Especially if i have to go back and add more features related to that task.

So TLDR: the PRD can be the entire app or just a single feature -- the current version doesn't support appending more tasks with another PRD, but I've added a new issue to support that #207

Edit: parse-prd now supports the --append flag. :)

[CREWorx]

This is a great discussion and lots of valid points!

One issue that can arise is when users keep adding tasks, leading to a significant increase in the context. I believe a feature like “compact session” similar to Claude Code could be beneficial. This feature could condense existing tasks into smaller overviews that remain part of the context, without consuming too much valuable context.

[trauts2]

my plan is to introduce a new paradigm whereby the PRD, the code and the tasks are always in sync with each other. Thus, when you finish the project and add Task ABC, the PRD should reflect that change by recomposing itself. We're not ready for this yet, but it's part of the eventual complete solution.

I think this vision nails it. It addresses my questions about how to use it. In particular the drift between task, PRD and actual source. I'm currently unclear how to keep taskmaster informed if I make manual changes or work with the Agent outside of taskmaster to make changes/fixes. This enhancement would clarify significantly the solo use case, which I think goes a long way to cementing taskmaster's usefulness.

[rhinck]

Thanks for the in-depth and thoughtful response to my original questions—really appreciate it.

Just to confirm: is the ability to parse multiple PRDs (via the --append flag) part of v0.12.1? If so, that’s awesome. It’s really cool to see a concept like that go from idea to reality so quickly—feels like the tool is evolving in real time alongside the way people want to use it.

Thanks again for building this. Task Master is quickly becoming a core part of how I organize and move through solo dev work.

[Crunchyman-ralph]

Yup, --apend is already in 0.12.1 :D

[eyaltoledano]

Thanks for the in-depth and thoughtful response to my original questions—really appreciate it.

Just to confirm: is the ability to parse multiple PRDs (via the --append flag) part of v0.12.1? If so, that’s awesome. It’s really cool to see a concept like that go from idea to reality so quickly—feels like the tool is evolving in real time alongside the way people want to use it.

Thanks again for building this. Task Master is quickly becoming a core part of how I organize and move through solo dev work.

--append did indeed ship with v0.12

vibe on friend :)

[gabadi]

Hi, great job!
I want to share some feedback regarding post-v1 iteration

I’ve tried both approaches: appending a new PRD-v2.txt and creating a new task with sub tasks

At least from my experience the —append is not effective. I’ve been working a lot to generate a clear and full PRD-v2.txt to give all the necessary context to task-master, but the final tasks splits in general does not fit with the current project structure/arch decisions

With a task and sub tasks I have more control and in general the results are great

Maybe if we have some kind of extra document what we can add with arch/tech decisions would be useful, but at this moment I’m using the task + sub tasks approach, works great

[Crunchyman-ralph]

You can parse a whole PRD inside a new tag instead, if that helps, that way you're doing one tag per PRD :D