How I set up my Claude projects before starting work

Before I ask Claude to build a page, investigate a problem, or help with a campaign, I set up the project it will work inside. The first task is easier to hand over when the background is already there.

I want it to know what we are making, where the current work lives, which decisions are settled, and what a finished result should look like. Otherwise, even a detailed prompt can leave it solving the wrong problem.

This is my approach to the Claude Projects experience with a coordinator and working threads. It is different from the older Projects that group chats and reference files. Availability and settings can change as the beta develops.

Start with an outcome I can recognize

I give the project a name I will recognize in the sidebar, then write its goal in plain language. What is this project for? Who does it serve? What are we trying to improve?

For a website, “help me with marketing” leaves too much open. “Make the offer clear enough that a first-time visitor understands it and knows what to do next” gives the work a direction. I can judge a proposed change against that.

I separate the current state from the ambition. If something is a draft, a hypothesis, or an untested idea, I say so. I do not want a plan for future work to turn into a claim about what already exists.

Give it a small, useful map of the project

Next, I add the sources the work actually depends on: the main repository, the current brief, relevant brand guidance, and the files or folders that explain the product. I start with what most tasks will need.

I would rather give Claude a few current documents than an entire folder of old exports. A large pile of context still leaves it deciding which version is right. I remove duplicates and label anything I keep only as a reference.

Each source gets a short explanation of what it contains and when to use it. If two documents disagree, I specify which one takes priority. The approved brand guide should not compete with a discarded concept that happens to look more complete.

For code, I check access to the attached repositories before assigning work. If an attachment fails, I check the GitHub connection and the Claude GitHub App permissions for that repository.

Write the rules I do not want to repeat

In Project settings, under Memory, I write the standing project instructions. These explain how the sources fit together, where a task belongs, and what Claude should read before making changes.

Repository-specific guidance stays in its CLAUDE.md. The project instructions connect the pieces instead of copying the same build commands and conventions into a second place. That makes future updates easier to keep consistent.

I also make the boundaries explicit. An analysis should produce findings. A draft should stay a draft. A completed local edit should be checked in the browser. Publishing, sending messages, merging changes, and spending money need their own authorization.

The useful instruction is specific enough to act on: preserve the approved offer, check the current source before changing copy, report missing access, and explain what was actually verified. “Do great work” does not tell Claude how to finish.

Check that the work can actually run

Cloud threads do not automatically inherit the tools on my laptop. I review the environment, the packages it needs, and the services it must reach. If setup steps repeat on every task, I put them in the environment setup script.

I keep network access scoped to the work. I start with Trusted and add a specific domain through Custom when a required service is missing. I also separate ordinary configuration, such as project IDs and service URLs, from secrets. When available, API credentials are the place for service keys, rather than the chat or shared environment variables.

Then I check the connectors the task will use. A connected account is only useful if the thread can read the specific resource it needs. I use a small read-only task to check that access before handing over something larger.

The coordinator conversation does not have connectors; cloud threads use them. I also add any required plugin in Project settings, rather than assuming a plugin installed locally will appear in the cloud.

Match the model and effort to the task

I review the coordinator and thread model settings separately. One handles the ongoing conversation and hands off work; the other does the task. Those jobs do not always need the same level of effort.

I do not make the most expensive setting the default for everything. A difficult debugging task may need more reasoning than a small copy revision. I start with a reasonable setting for the work and adjust based on the result, the time it takes, and the usage it consumes.

Once work is running, I look at Usage to see which threads and models are doing the spending. That gives me a better basis for changing the setup than assuming a larger model will solve every slow or unclear task.

Make the first task a useful check

Before a larger assignment, I ask Claude to inspect the relevant sources, summarize the current state, and identify missing access or conflicting guidance. I keep this first pass read-only so I can see whether it understands the project.

After that, I hand over one complete piece of work. A useful task names the outcome, the scope, and the evidence I expect back. For a page update, that might be revised copy, the edited page, and a browser check at desktop and mobile sizes.

When tasks touch the same code, I make sure they have isolated branches or worktrees where appropriate. I prefer a small, reviewable change with a clear reason over several unrelated changes bundled together.

I also define what the handoff means. A pull request ready for review still needs review. A file in the Library is a deliverable to inspect. Neither tells me the work has been published or that the result is correct.

The setup brief I start from

I use this structure as a starting point and fill it with the actual details of the project. It works for a website, a product, or a research project because it describes the work before it describes the tools.

Keep the setup current as the project changes

A good setup can still become stale. I review project memory when the direction changes, remove guidance that describes an old state, and update the source list when files move. I do not want a previous decision to silently override a newer one.

I make important setup changes before starting the next thread. Instructions, repositories, plugins, and environment updates apply to new threads; I do not assume an already running task has picked them up.

Only once the ordinary workflow is clear do I add routines for recurring work. A scheduled report needs the same sources, boundaries, and definition of done as a task I start myself.

That is the preparation I care about: enough context to make good decisions, enough access to do the work, and a clear way to check what comes back. Then the next prompt can be about the task itself.