Project managers

A project can have a manager: a Claude contact that oversees the other conversations working on it, each in a worktree of its own. It knows what the project is building, from the PRDs, tickets, Slack discussions and designs you point it to. Each time one of the others changes files, it looks at the changes against all of that, and tells that conversation what has to change.

Turning one on. Open Settings, pick the project, and go to its Manager page. Turn on A manager oversees this project. A contact named Manager joins the project's section of your contact list. It works in the main checkout, and it changes no files itself.

Sources. On the same page, Add source for each place it learns what the project is building: a Linear project or tickets, a PRD in Google Docs or Notion, a Slack channel or thread, a Figma file, a doc in the repository. Give each a name, such as "PRD", and its link. One without a link works too, such as "#proj-tags on Slack". The manager reads them with the tools Claude has, so connect Linear, Slack and the rest to Claude first. It also follows the links it finds in them, such as the thread a ticket links to.

Or share a link with it. Say it in the manager's conversation: "here's the PRD: https://…". The manager adds the link to the sources, named by what it is, and reads it into the brief. The Manager page shows it at once. Ask it to drop a source that no longer holds, and it takes that one out.

The brief. What the manager learns goes into the project's brief: the goals, the decisions and where they were made, the acceptance criteria of each ticket, the open questions, and which conversation is on what. It writes the brief itself and keeps it up to date. The brief is on the Manager page, for you to read. Edit it to set something right, and the manager is told what you changed. The brief is kept with the project, so it lasts when the manager starts a new chat or the app restarts.

When it looks. The manager hears from a conversation each time a round of its turns is over and an agent there wrote or edited a file. A turn you stopped, or one that went wrong, doesn't count. The manager's window shows a line, such as "Claude (com-630-tags) changed 4 files: Tags are in…". Its agent is sent:

the conversation's branch and folder
what it was first asked, and its last reply
the files it changed against the main line, with how many lines
with the overlap check on, the files another conversation changed too

The manager then finds the conversation's ticket, often named in its branch, and looks at the changes. It reads the files in that worktree, and asks the app for the diff.

Checks. Tick what it looks for on the Manager page. All four are on to begin with:

Follows the design: built the way the project is, as its instructions, its CLAUDE.md and the code on the main line have it.
Does what its ticket asks: every acceptance criterion, and what was decided since, with tests.
Changes no file another one changes: two worktrees that change the same file are likely to conflict when they merge.
Doesn't repeat or contradict another: two conversations building the same thing, or deciding it two ways, such as names, APIs or data shapes.

Your own checks. Under those, Add check adds one of yours, a sentence each: "Uses the design system's components, not plain HTML elements", "Every new table has a migration that can be rolled back". The manager checks every change against them too, after the four. The ✕ on a row takes it out. Up to 20, each up to 300 characters.

Rules are what it is told on top, such as how strict to be.

Messages. Where something has to change, the manager sends that conversation a message. Its window shows "Manager says: Tags are per publication, not per post…", and its agent reads it once it is done with what it is doing. That conversation's answer goes back to the manager, whatever it changed. Where all is well, the manager says so in its own conversation and messages nobody.

A conversation is sent as many messages as Hand-offs in Settings > Teams allows, six to begin with, until you write to it again. Past that, the manager tells you instead.

Talking to it. The manager is a contact like any other: ask it "how is everyone doing?", "what's left on COM-630?", or "catch up on Slack". It can list the conversations working on the project, with what each is doing and what it changed.

Good to know:

It takes a turn after every change, on your Claude plan. Turn it off on the Manager page when you don't need it: the contact stays, with its conversation, and oversees nothing until you turn it on again.
It oversees every conversation in the project's section, whatever its service: Codex and Gemini contacts too. Archived ones are left out.
Each line in a conversation's window says who it is from, and so does what its agent is sent: a manager's message is never taken for yours.
Delete the Manager contact and the project has no manager. Turning it on again adds a new one.
Only Claude can be a manager, as only Claude has the app's tools. Its model, effort and mode are set like any contact's, in its conversation window.
A folder outside a git repository has no worktrees to oversee, and its Manager page says so.
In demo mode, a manager that is turned on writes a made-up brief, and a link you send it is added to the sources, named after its site. A conversation that then changes files, say after "fix", is asked for the test its ticket wants, and answers that it is on it.