Projects

A Project — in the claude.ai sense — is a workspace where instructions and reference material persist across conversations. Attach your style guide, your schema notes, your standing rules once, and every new chat in that Project starts already knowing them. It's the simplest instance of the most important pattern in agentic work: moving knowledge out of the chat and into the environment — and because it's the simplest instance, it's where you should learn the judgement that every later instance (repo briefings, skills, memory files) reuses.

The problem it solves, precisely

Lesson 2 established the brutal fact: a new conversation knows nothing. Without persistent workspaces you compensate by re-explaining — pasting the same conventions, the same architecture overview, the same "never do X" into every session. Three costs, and the third is the one people miss:

1. Time, obviously.
2. Tokens — the same 1,500-word briefing re-pasted forty times.
3. Variance — the real killer. Some days you paste the full briefing; some days you're in a hurry and paste half; one day you forget entirely, and that's the day the output silently ignores your conventions, and you don't notice until review. Quality that depends on a human ritual inherits the reliability of human rituals.

A Project converts the ritual into infrastructure. Rituals get skipped; infrastructure doesn't. And the pattern generalizes immediately: Claude Code has the same concept for repositories (CLAUDE.md, lesson 8), commands and skills are the same move for procedures (lessons 9, 14), memory files are the same move for evolving state (lesson 24). Once you see it, you'll organize all agent work around one question: where should this knowledge live so I never have to say it again?

The admission test: what earns permanence

The temptation is to dump everything in — every doc, the full wiki export, "more context is better." It isn't, for the reason lesson 2 taught: project knowledge occupies the desk in every conversation it serves, displacing working room and diluting attention. The admission test has four criteria, and content should pass all of them:

Stable — true next month without editing. Broadly relevant — useful in most conversations, not one task. Expensive to repeat — you'd otherwise retype or repaste it. Cheap to store — compact relative to its value.

Applied honestly, the test admits a specific and fairly short list:

• Decisions, not descriptions. "We use TypeScript strict mode and Postgres; errors are returned, never thrown across module boundaries; money is integer cents" — ten lines that shape every answer. Contrast a 400-line generated API reference: unstable, narrowly relevant, huge. It shapes mostly the bill.
• Domain vocabulary. What "shipment," "tenant," or "settlement" means here. Ambiguous domain words are exactly where completion machines guess wrong (lesson 1), and a glossary is cheap insurance.
• Boundaries — the highest value per token. The deprecated module nothing new should import. The directory that's generated. The API that looks internal but has external consumers. Negative knowledge is what a model cannot infer from reading code, and violating it is what turns helpful sessions into cleanup jobs.
• One canonical example of each artifact you produce often — a migration, an ADR, an endpoint — because examples out-teach descriptions (lesson 1's show-don't-describe, made permanent).

Three exclusions worth stating as rules: nothing that changes weekly (it will go stale — see below); nothing huge-and-rarely-relevant (paste it into the one task that needs it instead); and never secrets (lesson 5 — anything pasted into any context should be treated as logged somewhere).

Staleness: the failure mode unique to persistence

A bad prompt fails today, visibly, and you fix it. Bad persistent knowledge fails next month, invisibly: the schema note describes a table you dropped; the style rule contradicts the linter you adopted; and the model — which has no way to know which source is current — follows the written word with full confidence. You told it this material was authoritative; it believed you.

The defenses are small and they compound:

1. Date what decays. "Schema snapshot, 2026-06" converts a silent lie into a visible caveat — for the model too, which will hedge appropriately when it can see the age.
2. Fix upstream, always. When a conversation reveals stale project knowledge, the correction belongs in the Project, not in your reply. Correcting in chat fixes one conversation; the other nine keep inheriting the error. (This reflex — fix the environment, not the instance — is the core reflex of lesson 16, learnable here at zero stakes.)
3. Audit on failure. When output goes weird, read the project knowledge first, before blaming the model. A surprising fraction of "the model got dumber" is "the briefing got stale."

Calibration: how much is too much

A practical size intuition: a well-tended Project's instructions read in two minutes. That's usually 300–800 words of decisions, vocabulary, boundaries, plus a couple of examples. If it takes ten minutes to read, it takes a meaningful bite of every conversation's desk — and its important lines are drowning in its trivia, which means the model's attention over it degrades exactly like any long context (lesson 2). When a section outgrows a screen, that's the signal it wants to be an attached reference document (loaded knowledge) rather than standing instructions (always-on behavior) — the resident-versus-on-demand split that lesson 20 turns into arithmetic.

The skill this lesson actually teaches is that split: deciding what rides along always versus what gets fetched when needed. You'll make this exact judgement again for CLAUDE.md versus pointers (lesson 8), skill descriptions versus bodies (lesson 14), and resident rules versus disclosed references (lesson 20). The criteria never change. Learn them here, where a wrong call costs a slightly bloated chat — not where it costs a fleet.