Foundation Lab: Build a Project

Time to build. A Claude Project combines a focused purpose, persistent instructions, approved knowledge, and the conversations that use them. Done well, it turns your best one-off result into something a teammate gets on their first try. This lab walks through the build once with Maya's renewal brief from the prompting lesson — then you do the same for your own workflow.

The goal is not to upload everything you have. It is the smallest reliable context for one recurring job.

Step 1 — Define the Project in one sentence

This Project helps [role or team] produce [output] from [approved inputs] for [audience].

Maya's version: "This Project helps Northstar account executives produce one-page renewal briefs from approved account notes and support summaries, for use in renewal calls." If your sentence needs "and," your Project is probably two Projects — split it. Then set boundaries: what it should not do, what requires human approval, and what information must never be added.

Step 2 — Add the smallest useful knowledge set

One current policy, playbook, or process guide
One or two strong examples of the output
A short glossary or brand guide, if terms matter
The criteria used to review the output

Resist the folder dump. Five current documents beat forty stale ones, because Claude weighs whatever it is given — an outdated playbook sitting next to the new one produces confidently blended nonsense. If two sources disagree, fix the sources or tell Claude which one wins.

Step 3 — Write working instructions

Instructions are the Project's standing brief: role, normal task, source priority, output pattern, and escalation behavior. Maya's, trimmed:

You help Northstar account executives prepare renewal briefs.

Sources: use only the documents in this Project plus material pasted into
the conversation. The renewal playbook is authoritative for process; the
example briefs are authoritative for format and tone.

Output: a one-page brief — usage trend, top two renewal risks, one
expansion opening, three call questions. Every risk cites its source.

Rules: never invent account facts. List missing information under
"Unknowns". If sources conflict, flag the conflict instead of choosing
silently. Do not draft customer-facing emails; that is a separate
reviewed workflow.

Notice the shape: sources ranked, format pinned, uncertainty surfaced, and one explicit "this Project does not do that" line.

Run three cases and keep notes:

Typical — a normal request with complete inputs. Does it meet the quality bar without coaching?
Edge — an unusual request or a conflicting source. Does it flag rather than fudge?
Boundary — something the Project should refuse or escalate, like Maya asking for a customer email. Does it decline and point to the right path?

Record the prompt, result, defect, and the instruction change you made. Retest after every meaningful edit — instructions interact, and a fix for the edge case can quietly break the typical case.

Phase 1 deliverable

Submit:

Project purpose sentence and named owner
The approved knowledge list
The Project instructions
Three test cases with results
One known limitation you have not solved yet

Definition of done

Another participant can open your Project cold, produce a result that meets the stated quality criteria, and tell you what the Project deliberately does not do.