Project plan in Cursor or VS Code: keep it next to your code

Developers rarely abandon a project plan because they dislike planning. They abandon it because the plan lives in another tab, and the tab is closed when the work happens. If you already spend your day in an editor with an AI agent, a better setup is a project plan in Cursor or VS Code: the schedule stays in a Gantt chart, and the agent in your editor reads and updates it while you work. This guide shows how that works, what to ask for, and what to keep for yourself.

Why the plan drifts away from the code

A typical week looks like this. You finish an endpoint, find that the migration needs two more days, and agree with a teammate to cut a feature. All of that is plan information, and none of it is written in the plan. To record it you would have to switch to the planning tool, find the right bars, change three dates and check what moved.

So you postpone it. By Friday the chart shows last Monday's reality. If this sounds familiar, our guide on keeping a project plan up to date covers the routine side. The setup below attacks the cause: updating the plan costs a sentence instead of a context switch.

How the connection works

ProGantt Flow has a built-in MCP server. MCP, the Model Context Protocol, is an open standard that lets an AI assistant use tools outside the chat. If the term is new, the plain-English guide to MCP for project management explains it without jargon.

For Cursor and VS Code the connection uses a personal access token. According to the connector docs, the steps are:

1. In ProGantt, click Connect AI on the dashboard, pick your client and generate a token. It starts with pgmcp_ and is shown only once, so copy it right away.
2. Add the server to your editor configuration with the token as a bearer header.

For Cursor, in .cursor/mcp.json:

{
  "mcpServers": {
    "progantt": {
      "url": "https://mcp.progantt.com/mcp",
      "headers": {
        "Authorization": "Bearer <your-pgmcp-token>"
      }
    }
  }
}

For VS Code, in .vscode/mcp.json:

{
  "servers": {
    "progantt": {
      "type": "http",
      "url": "https://mcp.progantt.com/mcp",
      "headers": {
        "Authorization": "Bearer <your-pgmcp-token>"
      }
    }
  }
}

Treat the token like a password: do not commit a config file that contains it to a shared repository. If a token leaks or you stop using it, revoke it from Connect AI or your profile and it stops working immediately.

Once connected, everything the agent does is a normal edit to your project. Changes appear in the web app straight away, for you and for anyone the project is shared with.

An example: a two-week feature

Suppose you are building a "team invitations" feature for a web app. You start by describing the work to the agent, ideally with the specification file open in the editor:

Create a ProGantt project called "Team invitations". Read the spec in this repository and draft a plan with three phases: backend, frontend and release. Use realistic durations in working days, link tasks with dependencies, and add a milestone called "Ship to production".

The connector can create a whole plan in one step, with phases as groups, subtasks inside them and the order expressed as dependencies. A result might look like this:

Phase	Task	Days	Depends on
Backend	Invitation data model	1	none
Backend	Invite and accept endpoints	3	Invitation data model
Backend	Email sending	2	Invite and accept endpoints
Frontend	Invite dialog	2	Invite and accept endpoints
Frontend	Accept-invite page	2	Invite and accept endpoints
Release	QA pass	2	Email sending, Invite dialog, Accept-invite page
Release	Deploy	1	QA pass

Do not accept this draft blindly. The agent only knows what is in the spec, so check durations against your own experience and look at the chart in the web app. If you need a refresher on reading the bars and arrows, see how to read a Gantt chart.

Prompts that fit the way developers work

The best prompts are short, specific and tied to something that just happened. Here are the ones that tend to pay off.

Record progress as you finish work

Mark "Invite and accept endpoints" as 100% done and "Email sending" as 20% done.

The agent finds each task by its title and applies the changes. You can send several changes in one message, and the connector can apply all fields of one task, such as progress, tags and people, in a single update.

Handle a slip without recalculating by hand

The email provider integration took two extra days. Push "Email sending" back by 2 days and tell me the new date for "Ship to production".

The agent can read the dependency graph, move the affected tasks and report the result. This is the moment where a plan in a Gantt chart beats a list: the dependencies do the arithmetic you would otherwise do in your head. For the human side of a slip, such as what to tell people, read how to handle project delays.

Ask questions about the plan

What is still blocking "Ship to production"?

Who has the most work in the next two weeks?

These are read-only questions. The agent looks at the tasks, dependencies and the load per person, then answers. Nothing changes, which makes them a safe way to start.

Turn code work into tasks

I found three missing edge cases while reviewing this pull request. Add them as subtasks under "QA pass", 0.5 to 1 day each, tagged "bug".

Durations in the plan are whole days, so ask for a minimum of one day or fold small items into a single task. Giving an explicit start date is also wise: the docs note that tasks created through the connector start today at 00:00 UTC when you do not give one, which can differ slightly from your local midnight in the web app.

What to delegate and what to keep

An agent in your editor is good at mechanical plan maintenance: creating tasks, shifting dates, setting progress, tagging and answering questions about dependencies. It is not good at judgment it cannot see.

Keep these for yourself:

• Estimates. The agent does not know how long your team takes to ship an endpoint. Propose numbers yourself or review every one it suggests. Our guide to estimating task duration helps.
• Priorities and scope cuts. Deciding to drop a feature is a conversation with people, not a prompt.
• Deletions. The connector can delete tasks, and deletions cannot be undone. Ask the agent to list what it would remove and confirm each one. The connector cannot delete a whole project, change who it is shared with or touch billing; those stay in the web app.

Your editor may also ask you to approve write actions before they run. Leave that on until you trust the workflow.

Permissions and shared plans

The agent acts as you. It sees the projects you see and nothing else. If you are a viewer on a project, it can read it but every write is refused. If a title matches several tasks, it asks which one you mean instead of guessing.

That matters when the plan is shared with a client or a product manager. They keep their own roles, and your agent cannot give itself more access than you have. For the thinking behind roles, see editor vs viewer access.

A simple routine

You do not need a ceremony. Try this for one sprint:

1. At the start, ask the agent to draft the plan from your spec, then review and correct it.
2. After each meaningful piece of work, send one line to record progress.
3. When something slips, ask for the new end date before you tell anyone.
4. On Friday, ask what is blocked and who is overloaded, and fix those first.

The result is a plan that costs a few sentences a day and stays close enough to reality to be useful. To set it up, generate a token from the dashboard at app.progantt.com and follow the connector docs for your editor.