When to use Projects vs. when not to

A Project that is wrong for a workflow does not fail loudly. It produces outputs that are slightly off — coherent enough to use, wrong enough to create quiet technical debt. The failure is subtle, which makes it hard to diagnose and easy to attribute to Claude's general capability rather than to a configuration mismatch. Knowing when not to build a Project matters as much as knowing how to build one.

Where Projects work well

Projects earn their cost when three conditions hold simultaneously: the task recurs, the context is stable, and the same quality bar applies every time.

A PR review Project works because the codebase standards do not change between Monday and Friday, the output shape is consistent (citation, rule, corrected form), and you run it multiple times a week. The Project absorbs the setup cost once and returns value on every subsequent run.

A customer support triage Project works because the product categories are stable, the triage criteria are documented, and the classifier output feeds a consistent downstream workflow. The context (triage criteria) is stable, so attaching it makes sense.

Where Projects fail quietly

The first failure mode: attached files go stale faster than you update them. You attach the current API reference. The API changes. Six weeks later, Claude is giving answers based on the old version, and you're debugging a problem that doesn't exist in the current system. The Project is confidently wrong.

This failure is not obvious in the output. Claude doesn't say "I'm using stale data." It reasons from what it has.

The second failure mode: the system prompt was written for a task that has since evolved. You wrote the prompt when the team was two people and review criteria were simple. The team is now eight people and the criteria have bifurcated. The Project still runs — it just applies last year's standards to this year's work.

The third failure mode: the Project constrains creative or exploratory work. Projects encode a format and a stance. If you're using a Project for drafting and the Project has a strong format constraint, you will find yourself fighting the constraint when the work needs to go somewhere unexpected. Exploratory work benefits from a blank slate.

Three situations where a Project is the wrong tool

One-off questions. The overhead of loading a system prompt and attached files is pure waste when you only need Claude once. Ad-hoc chat.

Rapidly changing material. If the document you're referencing updates daily or weekly, attaching it to a Project means you are always operating on a version behind. Fetch the current version at query time instead.

Exploratory or divergent work. Projects encode a format and a stance. Exploration benefits from no prior stance. If the task is "figure out what approach to take," the Project's defined output format is the wrong frame.

The cost of an abandoned Project

A Project you stop maintaining is not neutral. If you or a teammate return to it weeks later, the system prompt describes a workflow that no longer exists, the attached files may be outdated, and the output will be wrong in ways that are not immediately visible. An abandoned Project is a source of confident misinformation. Delete it or archive it explicitly.

The maintenance question

Every time you build a Project, ask: what would make this Project wrong to use? Name the condition. Write it down somewhere you will find it — in the README that lives alongside the Project files, or in the system prompt itself as a dated comment.

If you cannot name the condition under which the Project should be retired, you have not thought clearly enough about what it is for.

If you get stuck

Outputs feel generic despite the system prompt. The system prompt describes a disposition, not a procedure. A disposition ("be rigorous") gives Claude no decision rules when it encounters ambiguity. A procedure ("if the PR touches authentication code, check against the security checklist in the attached file before suggesting approval") gives it a concrete next step. Rewrite the system prompt as a procedure.

The Project works for simple tasks but breaks on complex ones. The attached files are not detailed enough to handle the edge cases the complex tasks expose. Either extend the attached files or accept that the Project is only valid for the simple variant of the task.

Cross-reference

l2 covers the setup steps for a Project that holds its shape. l7 covers the Project-plus-Skills stack that handles complex team workflows — the pattern for when a Project alone is not enough.

Deliverable

Write two sentences for the Project you built in l2: what would make this Project wrong to use, and what is the condition under which you would retire it. If you cannot write both sentences, the Project's scope is not yet clear.