task-ops
Most advice about using ChatGPT for project management is a list of prompts. Ask it to draft a project plan. Ask it to write a risk register. Ask it to summarise this status update into three bullets. The prompts work, in the sense that plausible text comes back.
Then comes the part the prompt lists skip. The output has to get into the place where the work actually lives. Someone copies the twelve tasks out of the chat window and types them into a board, one at a time, adding owners and dates by hand. Someone pastes the current state of the board into the chat first, because otherwise the answer is generic. Within about two weeks the copying outweighs the drafting, and the habit dies.
That loop is the whole problem. Everything below is about where prompting genuinely helps, where the copying makes it not worth doing, and what has changed recently that removes the loop entirely.
Three jobs come out well and are worth doing even with the copy and paste tax.
Turning shapeless input into structure. A page of meeting notes, a long email thread, a voice memo transcript. Asking for the actions as a list with an owner and a date guessed from context produces something like twelve items, of which nine are right. Deleting three is faster than typing twelve. This is the highest value use and the least discussed, because it makes a boring demo.
First drafts of documents nobody wants to write. A project brief, a status note to a client, a retrospective agenda, the awkward email explaining a slip. A blank page costs more than a bad draft, and the correction pass is short when the facts are supplied.
Thinking through a plan out loud. Asking what could go wrong with a five week schedule that depends on one approver, or what a reasonable sequence is for a job the team has not done before. The value here is not the answer but the checklist it produces, which surfaces two or three things nobody had thought about.
Notice what these have in common. All three take input a person supplies and give text back. None of them requires the assistant to know what is on the board.
The failure is not the quality of the writing. It is context and it is durability.
It does not know the state of the work. Ask which items are at risk this week and the answer is invented unless the current state has been pasted in. Pasting the current state means exporting a board into text, which is work, and the paste is stale the moment anyone moves a card.
The output lands in the wrong place. A list of tasks in a chat window is not a task list. It becomes one when someone types it into the tool, and that person is the bottleneck. This is where most attempts stop.
Nothing is recorded. A decision reached in a chat thread is invisible to the rest of the team, does not appear in the project history, and cannot be found in three months by anyone who was not in the conversation. Project management is largely the discipline of keeping a record, and a chat window is the opposite of one.
Numbers get treated as facts. Asked for a realistic estimate, an assistant will supply one confidently. It is a plausible sentence, not a measurement. Estimates that enter a plan this way are the ones that fail quietly.
The first three of these have the same root. The assistant is outside the system where the work lives, and everything has to be carried across the gap by a person.
ChatGPT's own features take some of the sting out of the loop. On paid plans, Projects, scheduled tasks and custom GPTs are available together, which covers a few of the recurring annoyances.
A project keeps files and instructions in one place, so the standing context about how the team works does not have to be restated in every conversation. A custom GPT lets the tone, the format of a status update and the house rules be fixed once. Scheduled tasks can produce a recurring prompt on a rhythm, such as a Monday draft.
What none of these do is read the board. They reduce how often the context has to be retyped, not whether it has to be supplied at all. The gap between the chat and the tool is unchanged.
That gap is what makes the difference between an interesting experiment and something the team still uses in month three.
There is one more reason the gap matters on a team rather than for an individual. A custom GPT belongs to whoever built it. The instructions, the house format and the accumulated tweaks sit in one person's account, and colleagues either get a link or reinvent their own version. That is fine for drafting. It is not fine for anything the team depends on, because the setup is now a single point of failure attached to an individual subscription rather than to the workspace.
The change worth knowing about is MCP, a protocol for letting an assistant talk to another system directly. Where a project tool supports it, ChatGPT can be pointed at the actual boards rather than at a pasted copy of them.
The practical effect is that the questions stop being hypothetical. Which cards are due this week is answered from the board. Turning the decisions in a set of notes into cards creates them, in the right list, with the fields filled in. Moving something to done moves it. Creating a board for a new project creates one.
It is worth being precise about what is happening underneath, because it determines how safe this is. The assistant is acting through the same public API a person's clicks go through, as that person. Boards the account cannot see stay invisible to it. The actions appear in the activity log and fire webhooks exactly as manual ones do, so there is a record rather than a mystery. Tools that connect to ChatGPT and Claude this way generally also keep billing, API token creation and domain settings out of reach of an assistant, which is the right line to draw.
Setting it up is short. In ChatGPT it means turning on developer mode in settings, creating an app with the tool's MCP address, and choosing OAuth for authentication. The tool's sign in page opens, the workspace to connect is chosen, and access is granted. Two constraints are worth knowing before starting: developer mode is available on paid plans rather than the free one, and each connected assistant is listed in the workspace settings so it can be revoked.
Once the assistant can read and write the board, the useful prompts change shape. They stop being requests for text and become requests for work.
| Before a connector | After |
|---|---|
| Paste the board state, then ask what is at risk | Ask what is at risk |
| Get a list of tasks back, then type them in | Ask for the notes to become cards, and they appear |
| Ask for a status update from a pasted summary | Ask for a status update from the current state |
| Nothing is recorded outside the chat | Every change is in the activity log |
The second row is the one that matters most, for the reason given earlier. Retyping is where the habit dies, and removing it is what turns this from a demonstration into a routine.
A caution that applies from day one. An assistant that can create and move things will occasionally create and move the wrong things, usually because the request was ambiguous rather than because the model was wrong. The sensible starting posture is to ask for one thing at a time, look at what happened, and build up from there. Reading operations are safe to be liberal with. Writing operations deserve a week of paying attention.
The abstract version is unconvincing, so it is worth describing the rhythm concretely.
Monday morning starts with a question rather than a survey of boards. What is due this week, what has not moved since the middle of last week, what is sitting in review with nobody assigned. Three questions, answered from the live state in under a minute, replacing the twenty minutes somebody used to spend opening views and filtering them.
After a client call, the notes get pasted with one instruction: make these decisions into cards on the right board, with the dates that were mentioned. A dozen appear. Two are wrong because the notes were ambiguous, and fixing two is a minute of work.
Midweek, the question is usually a lookup that someone else has asked. Whether the copy came back, whether the invoice went out, whether the layout was approved. The value is not the answer itself but that colleagues can ask it directly, so those interruptions stop landing on one person.
Friday is the written update. Rather than assembling it from memory, the request is for a draft from the current state of the board, in the format the team already uses. The draft is wrong about emphasis roughly half the time, because emphasis depends on things not written down. Correcting emphasis takes five minutes. Writing from nothing takes forty.
None of these are impressive individually. Together they account for a few hours a week, and unlike most efficiency claims they survive contact with month three, because none of them depend on anyone remembering to do something extra.
Three jobs stay with people even after the connector is working.
Deciding priority, because priority depends on things that are not written on the board. Who is about to go on leave, which client mentioned something twice, which project was quietly cancelled on Thursday.
Committing to dates with anyone outside the team, because an estimate produced from a title is a sentence rather than a measurement.
Being the record. A decision still needs to be written down where the team can find it, attached to the thing it concerns. An assistant can draft that note in seconds, and someone still has to make sure it lands on the card rather than in a chat log.
For teams weighing this against buying AI features inside the project tool, the comparison of the major tools is a faster way to see which ones support outside connectors at all than reading through five sets of documentation.
Pick the one chore that involves the most retyping, which for most teams is turning meeting notes into tasks, and do it with a connector rather than with copy and paste for two weeks. Compare the minutes, not the impression.
If the project tool in use does not support connecting an assistant, that is worth knowing before investing further in prompt templates. Pinateca supports MCP and is free for up to five people and ten boards.
Yes, where the project tool supports MCP and a connector has been set up. The assistant then creates cards, moves them between lists and fills in fields through the tool's public API, acting as the account that authorised it. Without a connector it can only produce a list of tasks as text, which someone has to type in.
Beyond the subscriptions already in place, usually nothing on the project tool side. The constraint is on the ChatGPT side: adding a custom connector requires developer mode, which is available on paid plans rather than the free tier. For teams already paying for ChatGPT, this route avoids buying a second AI subscription inside the project tool.
It acts with exactly the permissions of the account that connected it, so boards that account cannot see stay hidden. Actions appear in the activity log and fire webhooks the same way manual ones do, which means changes are traceable rather than mysterious. Billing, API token creation and domain settings are typically excluded. The practical risk is ambiguity in requests rather than access, so it is sensible to start with reading and add writing gradually.
The ones that supply real facts and ask for structure: turn these notes into tasks with owners and dates, list everything with no activity since a given date, draft a client update from this state. Prompts asking for generic plans or estimates produce plausible text that is not grounded in the project, which is the category most likely to cause harm if it enters a schedule.
No. An assistant is good at reading, restating and retrieving, and a chat thread is a poor record. Project work needs somewhere durable that the whole team can see, where decisions stay attached to the work they concern. The assistant sits on top of that and removes the typing, which is a different job from being the place the work lives.