If you already use Claude for the writing that surrounds crew work, weekly look-aheads, RFI responses, the manpower summaries a general contractor keeps asking for, you have probably noticed that every conversation starts from nothing. You re-type who your crews are, which jobs are live, and what format the GC wants, and only then do you ask the question you actually opened the tab for.
Table of Contents
Projects is the feature that fixes that, and almost nobody in construction has been shown how to set one up properly, so what follows walks through what a Project holds, what to put in one for crew planning, how to share it so the setup survives one person’s holiday, and where the approach stops working. Setting up your first one takes about fifteen minutes.
What a Claude Project is
A Project is a saved workspace inside Claude that keeps three things together: custom instructions that tell Claude how to behave inside that space, knowledge files you upload once that every conversation in the project can draw on, and the conversation history, which stays grouped rather than scattering across your account.
Anthropic’s own documentation on describes them as self-contained workspaces with their own chat histories and knowledge bases, where you upload documents, provide context, and keep focused conversations in one place. Projects are available on every plan including free accounts, and Anthropic also publishes a short walkthrough on if you want the click-by-click version alongside this one.
The practical difference is that a conversation starts somewhere other than zero, so you can ask about the west wing and Claude already knows which job that is, which crew is on it, and that your weekly update follows a particular format because the GC asked for it that way in March.
Project, prompt, or neither: what goes where
Deciding what belongs in a Project and what stays in the prompt is the choice that determines whether the setup helps you or quietly misleads you six weeks from now, and it is worth making deliberately rather than by habit.
| What you’re working with | Where it belongs | Why |
|---|---|---|
| Report formats and templates | Project knowledge | Changes rarely, and re-explaining the format every week is the cost you are trying to remove |
| Standing job facts: site access, GC contacts, phase sequence | Project knowledge | Set at mobilization, stable for months |
| The labor curve from the estimate | Project knowledge | Fixed at award; useful for asking where the plan has drifted |
| Certification and licence expiry list | Project knowledge, reviewed on a set date | Changes slowly but the consequences of it being wrong are high |
| Current crew assignments | Project knowledge if you will genuinely maintain it, otherwise the prompt | Changes weekly. This is the judgement call |
| This week’s specific change | The prompt | Changes daily, and you want to see the input you are giving it |
| Anything under a specific confidentiality undertaking | Neither | A configured setting is not a reason to upload material that should not be there |
The rule underneath the table: information that changes slower than you will realistically maintain it belongs in the Project, and everything else belongs in the prompt where you can see it.
Setting up a crew planning project
There are four things to do and the order matters, though the whole sequence runs to roughly fifteen minutes for your first Project and five for each one after that.
1. Write instructions that constrain, not just describe
Most people write instructions describing what they want and stop there. The instructions that change output quality are the ones that tell Claude what it must not do, because an assistant with no stated limits will fill a gap confidently rather than flag it.
Example instructions: “You help me plan and communicate crew assignments for a mechanical contractor running multiple commercial jobs. A crew means a foreman plus three to five installers who move between jobs as a single unit rather than being assigned one name at a time. Always report hours by phase and area. Never estimate an hours figure I have not given you. If a certification or licence is missing for a scope, say so plainly rather than assuming it is current. If you had to assume anything to answer, list the assumptions at the end.”
The last three sentences are doing most of the work. Everything before them is context; those are the guardrails that make the output checkable rather than merely plausible.
The difference between a vague instruction and a specific one shows up quickly when you write both out and compare what each one actually asks Claude to do.
Too vague: “Be accurate and helpful when discussing crew scheduling. Use professional language.”
Specific enough to change the output: “Report hours by phase and area. If a crew is assigned to two jobs in the same week, say so before answering anything else. Never estimate an hours figure I have not given you.”
The first version cannot be wrong, which is precisely why it does nothing, whereas the second tells Claude what to check and what to refuse, so the output either meets the standard or visibly fails to.
2. Load the knowledge files that repeat
Upload the material from the “Project knowledge” rows above. Five well-chosen documents beat forty, because a project holding everything produces vaguer answers as the useful signal gets diluted by material irrelevant to the question.
For a crew planning project that comes down to the current roster with crew composition, the certification and expiry list, a real look-ahead you have already sent so the format is demonstrated rather than described, the phase sequence for active jobs, and the labor curve from the estimate.
One caution before you upload a roster: personal data beyond what the planning actually requires should stay out, and it is worth understanding where your data actually goes before rather than after.
3. Test it against a week you already handled
Before trusting a new Project, give it a change you dealt with last month and compare what it produces against what you actually sent. You are checking whether it holds your format, whether it invents anything, and whether it flags the gaps you would have flagged.
Example test prompt: “The GC on the Riverside job has pulled the level 3 rough-in forward by two weeks. Draft the manpower notice in our usual format, flag any crew this creates a conflict for, and list anything you needed to assume.”
Where the output is wrong, the fix is nearly always an instruction rather than a better prompt, so add the correction to the instruction set and it holds for every conversation afterwards instead of needing to be retyped.
Run the refusal test as well, since it is the one people skip: ask for something the instructions say it should decline, such as an hours figure you never supplied, and confirm it says so rather than producing a confident number.
Example refusal test: “How many hours should we carry for the level 3 ductwork next month?”
If it answers with a figure rather than telling you it does not have one, the instruction did not take, and that is worth knowing before the Project is drafting anything that leaves the building.
4. Share it so it outlives you
On Team and Enterprise plans a Project can be shared with permissions controlling who can change what. Several people then work against the same instructions and the same knowledge base, which is what stops the setup living in one person’s head.
The practical payoff is ordinary and worth stating: a second coordinator covering a holiday does not start from a blank window, and someone new to the role is useful in days rather than after a month of asking colleagues how things are done here. If you are building something you expect the team to rely on, share it early, while the instructions are still short enough for someone else to read.
Where this falls short
A Project’s knowledge files are a snapshot taken on the day you attached them, and nothing tells you when the snapshot has gone stale. Upload a roster in March, run the Project through August, and it will answer with total confidence using the March roster, including the two people who left in May and the certification that lapsed in June. An assistant that says it does not know is a minor irritation, whereas one that produces a clean, well-formatted, plausible answer built on stale data is worse than not asking, because nothing in the output signals that it needs checking.
That is the same instinct the industry already has about AI, and it is correct: garbage in, garbage out is the most repeated phrase in any practitioner conversation about this technology. A Project does not escape the problem so much as relocate it, from the data in your systems to the files somebody remembered to re-upload.
There is a plainer risk alongside it. A Project is a separate window living outside the tools you already have open, and separate windows are the things people stop opening around week three. If it does not get into the Monday routine within a fortnight, it will not survive the month.
The structural answer is to stop maintaining a copy of information that already exists somewhere current, which is what a connection layer is for, with the systems where your real work lives becoming things an assistant reads directly rather than things you export and upload. Â鶹´«Ã½ ships an MCP connection for this reason, which is how purpose-built AI workforce planning differs from a general assistant you have configured carefully: one holds the current plan, the other holds a copy of it.
Opinion: the setup matters more than the model
Every few months a new model arrives and the conversation restarts around which one is best. For the work described here, that question matters far less than whether you have spent fifteen minutes on the setup, and I would rather hand a coordinator a well-configured Project on a year-old model than a blank window on the newest one.
The reason is that construction’s AI problem has never really been capability. Contractors who plan crews across multiple jobs carry an unusual amount of standing context, and the tools have been perfectly able to use it for a while now, but there has been nowhere to put it. If you only do one thing from this piece, write the instruction set. The knowledge files can wait a week and the sharing can wait a month, whereas the instructions are what change the output tomorrow morning.
