Turning Cursor into a task-based AI coding system
Maybe we don’t have to separate product requirements, tasks and prompts? In my experience, that’s the way to go. And there are finally tools for it now.
But let’s take a step back first and look at where we are and how we got here.
Where are we at?
A brief history of coding:
Coding 1.0 — by hand
You just write the code by hand, like it was done for decades.
Coding 2.0 — by autocomplete and chat
When co-pilot came out, it felt like magic. At the same time I was doing a lot of copy-pasting from ChatGPT to and from my code editor.
Coding 3.0 — with agents and embedded chat
This meant that finally you didn’t have to copy-paste code — the chat or agent reads your code and makes edits inside the code. However, it could get off track and you still needed to repeat yourself a lot with prompts.
Coding 4.0 — task-directed development
I think this will be the way to do it “professionally” as Brian Casel put it. Basically you’ll have some kind of a system for product requirements, tasks and sub-tasks which are embedded in the workflow.
So, how do you do it?
The two most popular ways are probably using either Taskmaster AI or AI Dev Tasks for Cursor. I’ll focus on the latter cause it’s simpler and it’s what I’ve used for testing out the flow.
I have a side project called Flexora — a yoga mat that helps you track how your flexibility improves. It needed a mobile app for tracking the progress. There was a Cursor meetup happening in Tallinn, so it was the perfect opportunity to try it out.
Three files to rule them all
Ai Dev Tasks for Cursor is just a folder with three files in it which act as guides (Cursor rules):
- How to create a product requirements document (PRD)
- How to create tasks and sub-tasks from PRD
- How to process and complete tasks
It’s all it is. Just three simple files that live in the ./.cursor/rules folder that provide extra guardrails for the AI agent. As they’re files, you can of course easily modify them to fit your needs.
Once you prompt Cursor with what you want to create, it will ask some clarifying questions. I found this very useful actually — it can bring up use cases or edge cases that you didn’t necessarily think about already.
After you answer the clarifying questions, it will create a product requirements document under ./tasks/.
It’s worth paying very close attention to what’s here — otherwise the task list that will be created next might include stuff you don’t really want.
Once the task list is created, it will be split into sub-tasks.
Go over this super carefully as well. In my case, it also added in TypeScript and testing, which were not needed and which actually resulted in errors.
It’s also a good time to commit the project to make sure these files don’t get lost (as almost happened in my case when the AI tried to initialize the new Expo React Native project).
How good is it?
I pretty much let it run on autopilot. In a few places it wanted to do some weird stuff so I needed to instruct it to stop. But in general it completed around 30 subtasks with only one major error that I had to correct in order to get the mobile app working.
I then did a few other small tweaks — adding safe env margins, renaming some stuff and correcting minor design mistakes. But at that point the app was basically ready. It took an hour and a half.
I also noticed that sometimes it had duplicate sub-tasks — it already finished something under one task and then got to a similar sub-task later and was able to skip it.
When I looked at the actual app, I also noticed stuff that I didn’t originally specify. In my case, it was a good thing actually — I’m going to keep some of it. It all depends on how specific you make the initial prompt I think. I kept it quite general.
Some quick take-aways
Watch out
- Make the initial prompt for PRD more specific if you don’t want side-effects
- Go over the general task list very carefully and weed out complexities
- After generating sub-tasks, ask it to remove duplicate sub-tasks
- Commit PRD and tasks document as soon as they’re ready before doing any tasks
- If the response takes a long time to generate it’s probably because the thread is too long — just create a new one
The process
- Come up with the initial prompt for product requirements
- Approve the PRD document
- Approve the tasks that were created based on the PRD
- Approve the sub-tasks
- Commit changes
- Start doing the sub-tasks
I have still yet to test it out for existing products — for doing new features. But for new projects, I wouldn’t want to do it any other way anymore. It’s just way more focused and systematic than having your tasks and PRDs in Notion, Jira or Linear.
Btw, if you’re aware of any other tools for AI-based task-directed development, please drop a comment.
Update #1 (23-Aug-2025) — Accessing Up-To-Date Docs with Context7 MCP
One big shortcoming of using AI agents (or chat) is that the info might not be up to date.
Indexing & Docs
Cursor has setting for docs which allow you to add docs that will be indexed. It’s what I used to do a lot:
However, the problem is two-fold:
- It’s pretty time-consuming
- It eats up tokens when you reference the docs
Luckily, there’s a good solution for it.
Context7 MCP Server
Context7 has docs about pretty much all the popular frameworks, packages, services etc. This reduces both your token count and hallucinations. Not to mention the time you spend looking for them.
Installation is super easy. Basically just copy-paste the MCP server info to Cursor.
As you can see, it came back with the correct answer while not using Context7 MCP gave the outdated answer.
So, yeah, I highly recommend using Context7 and using the Docs & Indexing feature for your own docs basically or for some obscure things.
# Update 2 (15 Jan 2026) — We’ve Come A Long Way
Making It Simple
Cursor and Claude both have planning modes now built in and they’re pretty good. So, I don’t think it’s necessary anymore to actually use something like Taskmaster AI (unless there’s a very specific need for it).
Usually my process is this:
- A lot of back and forth with different AIs outside Cursor (if it’s a big project) — output a general PRD
- Use the plan mode in Cursor (with the PRD as basis) and let Cursor plan out the details
- Save the plan
- Use a new chat instance for individual tasks (unless they’re simple and don’t require a lot of context)
Making It Complex
However, there is one missing piece when developing an app from scratch — how to get the designs right.
I’ve found Design OS very beneficial for this although it’s clearly better for webapps than for mobile apps.
It basically just lets you go step by step to arrive at a simplified data model and screens. And then it outputs everything needed for building into a single shot prompt and PRD, along with screenshots, data models etc.
