Using Claude to run projects by connecting it to your task board
Claude is already open in a tab for most of the working day. It writes the status update, untangles the requirements document, and drafts the awkward message to the client. So the next thought is obvious: if it can do all of that, it should be able to run the project. Then comes the part nobody warns about. Claude has a feature called Projects, and it is not a project tracker. Finding that out three days into setting one up is a common and avoidable waste of time.
The useful version of this idea exists, but it is a different arrangement than most people picture. It is not Claude replacing the board. It is Claude reading and writing the board you already have.
Projects in Claude is a naming collision
A Claude Project is a self contained workspace with its own chat history, its own knowledge base of uploaded files, and its own instructions. It exists so that every conversation about the same body of work starts with the same context instead of being re explained each time. Anthropic's documentation describes it in exactly those terms, and when the uploaded knowledge approaches the context limit, Claude switches to a retrieval mode that expands capacity by roughly ten times.
What it does not contain: tasks with owners, due dates, states, or any notion that something is late. There is no board, no list, no assignee field, no notification when a date passes. A Project is a container for conversation and reference material.
That distinction decides the whole approach. The knowledge base is the right place for the things that do not change weekly, and the wrong place for the things that do. Specifications, decisions, brand rules, the client's requirements, a style guide: these belong in project knowledge. The current state of the work does not, because a file uploaded on Monday is a snapshot, and by Thursday it is confidently wrong.
Two plan details are worth knowing before building anything on this. Free accounts can create a maximum of five Projects. Project sharing and collaboration is not available on Free, Pro or Max, only on Team and Enterprise, so on an individual plan a Project is a private workspace no matter how much of the team's material goes into it.
What Claude handles well with no setup at all
Before any connection is involved, there is real value in the plain chat, and it is worth being precise about which jobs those are.
Turning a mess into a structure. Paste half an hour of meeting notes and ask for the decisions, the open questions, and the tasks each one implies. This is the single highest return use, because it converts something nobody will reread into something that can be acted on, and it takes one prompt.
Writing the update nobody wants to write. Given a list of what moved and what did not, Claude produces a status note in the register the audience needs. The reason this matters is not the writing time. It is that status updates get skipped when they are unpleasant, and the skipping is what makes projects go quiet.
Interrogating a document. With the specification in project knowledge, asking what the document actually commits to, where it contradicts itself, and what it leaves undefined is faster and more thorough than reading it again.
Drafting the plan. Describe a project and it returns a work breakdown with phases and dependencies. The structure is usually sound. The durations are guesses, since it has no record of how fast this team works.
The four things it cannot do from a chat window
It does not know the current state. Anything pasted in is a snapshot. Ask on Thursday what is overdue and the answer describes Monday, delivered with the same confidence as a fact.
It does not remember what it told you to do. A task agreed in a conversation exists in that conversation. Nothing surfaces it later. This is the failure that makes people abandon the approach, usually about two weeks in, when three things have quietly fallen through.
It cannot notify anyone. No due date, no reminder, no mention. Whatever is decided has to be carried by hand into the place the team actually looks.
The rest of the team cannot see it. Unless the organization is on Team or Enterprise, the Project and its chats are yours alone. Work discussed there is invisible to everyone else, which is the opposite of what a project needs.
Each of these is the same problem in a different coat: the record of the work is not in Claude, and a chat window is not a shared system.
Connecting Claude to the board is the part that matters
The arrangement that works puts the board in charge of state and Claude in charge of language. Claude reads the board when it needs the current picture, and writes to it when something is decided.
That connection is made with a connector. Anthropic documents custom connectors, meaning remote MCP servers, as available across Free, Pro, Max, Team and Enterprise, with Free accounts limited to one connector. On Pro and Max a user adds one under Customize, then Connectors, then add custom connector, and enters the server URL. On Team and Enterprise an owner adds it under Organization settings, then Connectors, and members authenticate individually afterwards.
What this means in practice is that the barrier is lower than most teams assume. A single free Claude account can hold exactly one connector, and if that one is the task board, the whole arrangement is available without a subscription decision.
On the board side, the tool has to publish an MCP server. Several now do. Trello publishes one at https://mcp.trello.com/v1, covering boards, lists, cards, checklists and search, and documents it as available on any Trello plan including Free. Other task tools expose the same kind of endpoint, typically with a sign in step that scopes the connection to one workspace.
Once it is in place, the prompts change shape. Instead of pasting the board in, the questions are direct: what is due this week, which cards have not moved in ten days, turn these notes into cards in the backlog, move that card to review. The answers come from the live board, and the changes land where the team will see them.
What a week actually looks like
Monday starts with a question rather than a report: ask what is due this week and what has not moved. The answer is the state of the board, not an impression of it, which matters because the cards nobody has touched are exactly the ones nobody mentions in a stand up.
After each meeting, the notes go in and the decisions come out as cards, with owners and dates set in the same step. This is where most of the time is saved, and it is also the step that used to be skipped. The gap between a decision being spoken aloud and a card existing is where projects leak.
Midweek, the useful prompt is a comparison rather than a summary: what changed since Monday. A model reading the board can answer that. A model reading a pasted snapshot cannot.
Friday is the status note, written from the board rather than from memory, which removes the quiet bias where the things somebody remembers are the things that get reported.
None of this is dramatic. The change is that the board stays current because updating it stopped being a separate chore.
What to put in project knowledge, and what to leave out
Once the board is connected, the Claude Project stops being a filing cabinet and starts being the thing that makes the answers specific to this team rather than generic. That only works if the right material is in it.
Worth uploading: the specification or statement of work, the definition of done the team agreed, the naming conventions for cards and lists, the escalation rules, and a short note on how this team writes status updates. Those change rarely and they are the difference between a summary that reads like a template and one that reads like it came from inside the project.
Worth writing into the project instructions rather than uploading: the shape of the board itself. Which list means what, which labels are meaningful, who the people are and what each one is responsible for. Board structures are rarely self explanatory, and a model reading a list called "Blocked" has no way of knowing whether that means waiting on a client or waiting on a decision. Three sentences of explanation here changes the quality of every answer afterwards.
Worth leaving out: anything the board already holds. Uploading an export of the cards creates a second copy that ages immediately, and the model will occasionally prefer the stale file over the live connection. The same applies to meeting notes once their decisions have become cards. The point of the connection is that there is one current record, and adding snapshots alongside it undoes that.
Also worth leaving out: material that is confidential in a way that has not been thought through. Project knowledge on an individual plan is private to one account, which sounds safe until someone leaves and the context leaves with them.
Where this goes wrong
Write access granted too early. Start with read only. An assistant that can create and move cards on a board the whole team depends on will, early on, create a card in the wrong list or move something that was deliberately parked. Watching it read for a week costs nothing and makes the write step boring instead of alarming.
Trusting a connector that has not been vetted. Anthropic's own documentation is blunt that custom connectors let Claude reach services Anthropic has not verified, and that a malicious server can carry hidden instructions intended to make Claude act against your intent. The practical rule is to connect servers published by the vendor whose product you are using, at the URL documented on that vendor's own site, and to read the permissions on the consent screen rather than clicking past them.
Assuming an audit trail exists. When an assistant edits a board, somebody will eventually ask who changed a card. That answer has to come from the board's activity log, not from Claude. It is worth checking before rollout that the tool records the connection by name and that the log shows the change the same way it would show a human one.
Forgetting that it acts as you. A connector uses your permissions. It cannot see boards you cannot see, which is the reassuring half. The other half is that it can do anything you can do, including in workspaces you had forgotten you were a member of.
Choosing where the record lives
The whole arrangement rests on one decision: which system is the truth. If it is the board, Claude is a fast, articulate interface to it and the setup is stable. If the truth is spread across a chat history, a shared document and somebody's memory, connecting an assistant makes the confusion faster rather than smaller.
That is also the honest reason this works better with some tools than others. A board that holds dates, owners, states and a searchable history gives an assistant something to reason about. A board that is a wall of one line cards gives it very little, and the output reflects that. Tools where the schedule, the calendar and the conversation sit on the same set of cards tend to answer these questions better, because there is only one record to read.
What to change first
Pick the single board where things are actually slipping, connect it to Claude with read only permission, and spend one week asking it what changed rather than asking people. If the answers are right, add write access and move the post meeting step into it, using a board that publishes a connector on every plan such as Pinateca.
Q1. Can Claude Projects be used as a project tracker?
No. A Claude Project is a workspace holding chat history, uploaded reference files and custom instructions. It has no tasks, owners, due dates or states, and nothing in it will remind anyone of anything. It is useful for the material that stays stable, such as specifications and decisions, and unsuitable for the state of the work, which changes faster than an uploaded file.
Q2. Which Claude plan is needed to connect a task board?
Custom connectors, which is the mechanism for connecting a remote MCP server, are documented as available on Free, Pro, Max, Team and Enterprise, with free accounts limited to one connector. So a single free account can connect one board. Team and Enterprise differ in that an owner adds the connector centrally and members then authenticate to it individually.
Q3. Can the rest of the team see the Claude Project set up for the work?
Only on Team and Enterprise. Project sharing and collaboration is not available on Free, Pro or Max, so on an individual plan the Project and its conversations stay private to one person. That is the main reason the shared record has to live on the board rather than in the Project.
Q4. Is it safe to let Claude write to a live board?
It acts with the permissions of the account that authorised the connection, so it cannot reach anything that account cannot reach. The genuine risks are different: a connector from an unverified source can carry hidden instructions, and an assistant with write access will make ordinary mistakes at speed. Granting read only for the first week, then adding write, handles both without much ceremony.
Q5. What happens if the board does not publish an MCP server?
Then the connection has to be built or bought, which for most teams is not worth it. The realistic options are to use the tool's API through something that already speaks MCP, or to choose a board that publishes an endpoint itself. It is a reasonable thing to check on a vendor's integrations page before committing, since it is becoming a standard rather than a differentiator.