Project Setup Checklist: Instructions, Files, and Scope
A quick walkthrough before you create a new Project, so it starts useful instead of needing a rebuild a few weeks in.
How to Use This Checklist
- Work through it before creating the Project, not after - scope and naming are much easier to get right up front.
- Treat the scope items as a gate: if you can't answer them clearly, the instructions and files that follow will be harder to get right.
- Revisit this checklist a few weeks after setup to check whether the Project's real use still matches what you planned.
- It's fine to start smaller than this checklist implies and add depth later - the goal is a clear starting point, not a perfect one.
Scope (1-6)
- Name the Project's single, specific purpose. Write one sentence describing what it's for - "drafting billing support replies," not "customer stuff."
- Confirm the audience is stable. The people or context the output is for should stay consistent across most conversations in this Project.
- Confirm the rules are stable. The constraints and tone that apply should hold true for nearly every conversation you expect to have here.
- Check whether this overlaps with an existing Project. If another Project already covers this audience and rule set, a new conversation there may be better than a new Project.
- Decide if this is really a one-off. If you don't expect to repeat this kind of task, skip the Project and use a plain chat instead.
- Choose a specific, descriptive name. Name the Project after its purpose, not a broad category, so its scope stays obvious later.
Custom Instructions (7-13)
- State the audience explicitly. Who is this output ultimately for, and what do they already know or not know?
- List what Claude should always do. Concrete, checkable behaviors - format, length, structure, required elements.
- List what Claude should never do. Hard constraints matter more than general tone guidance, and are easy to forget without writing them down.
- Define the tone in specific terms. "Warm and direct" is more usable than "professional."
- Avoid vague, unenforceable phrasing. Replace "be concise" with an actual limit, like a word count or section count.
- Keep instructions to a single, coherent purpose. If you're covering two different tasks, split them into two Projects instead of one longer instruction block.
- Plan to test before relying on it. Note that you'll run a few realistic conversations after saving, not just read the instructions back to yourself.
Knowledge Files (14-19)
- Identify what facts or terminology this Project actually depends on. Only files that answer a real, recurring need belong here.
- Start with one or two files, not everything you have. Add more only as real gaps show up in test conversations.
- Check that each file is current. An outdated file produces confidently wrong answers, since Claude has no way to know it's stale.
- Check for overlap or contradiction between files. Two files with different numbers for the same thing will produce inconsistent answers.
- Prefer short, purpose-built files over long general documents. A one-page reference beats a 40-page document with the useful part buried inside.
- Confirm file size and count against your plan's limits. Check current Project knowledge limits in settings rather than assuming a fixed number.
Verification (20-22)
- Run a realistic test conversation. Ask something the Project should clearly be able to handle well, and check the answer reflects your instructions and files.
- Run an edge-case test conversation. Ask something near the boundary of the Project's stated scope, since edge cases are where vague setup breaks down first.
- Note anything that didn't land, and fix the specific line. Trace a wrong answer back to the instruction or file that should have caught it, rather than adding general guidance on top.
Applying the Checklist in Order
Work through Scope (1-6) before writing a single instruction. A Project with unclear scope produces instructions that hedge and files that only partly apply, no matter how carefully you write them afterward.
Custom Instructions (7-13) and Knowledge Files (14-19) can be done in either order, but instructions are usually faster to get right first, since they don't require gathering source material.
Verification (20-22) is not optional polish - it's the step that actually tells you whether the setup worked, and it's far cheaper to catch a gap now than after a week of relying on inconsistent answers.
FAQs
Do I need to complete every item before using a new Project?
The scope items (1-6) are worth settling first, since they shape everything after. Instructions and files can be built up incrementally as real needs appear, rather than all at once.
What's the single most important item on this list?
Naming the Project's specific purpose (item 1). Nearly every later problem, hedged instructions, irrelevant files, traces back to an unclear or overly broad purpose.
How do I know if two tasks belong in one Project or two?
Check whether the audience and rules are the same for both (items 2-3). If they diverge, separate Projects usually produce more consistent results than one broader Project.
Should I upload every relevant file I can find right away?
No. Start with one or two files that answer a clear, recurring need (item 15), and add more only as real gaps show up in test conversations.
What if my custom instructions still feel too long after following this checklist?
Long instructions aren't automatically a problem, but check whether they're covering more than one purpose (item 12). Instructions that hedge across multiple audiences are usually a scope issue, not a length issue.
Why does the checklist emphasize testing at the end?
Instructions and files that read well on paper can still miss in practice. Testing (items 20-22) is what actually confirms the setup works, and it's much cheaper to catch gaps here than after relying on the Project for real work.
What should I do if a test conversation gives a wrong or generic answer?
Trace it back to the specific instruction or file that should have prevented it, and fix that line directly (item 22), rather than adding a general instruction on top that may not actually address the root cause.
Is it ever fine to skip the knowledge files section entirely?
Yes. Some Projects depend only on tone and behavioral rules, not specific facts, and don't need any uploaded files. Skip section 14-19 if nothing in your Project's purpose depends on reference material.
How often should I re-run this checklist for an existing Project?
There's no fixed schedule, but it's worth revisiting whenever the Project's instructions start needing frequent exceptions, or whenever its actual use seems to have drifted from its original purpose.
Can I use this checklist for a Project I already created?
Yes. It works as a review tool for an existing Project just as well as a setup guide for a new one - run through it and note where the current setup falls short.
What's the risk of skipping the scope items and jumping straight to instructions?
Instructions written without a clear scope tend to hedge, trying to cover more ground than a single coherent purpose should, which produces less consistent answers later.
Related
- Setting Up a Project with Custom Instructions - a full walkthrough of the instructions section of this checklist.
- Uploading Knowledge Files to a Project - a full walkthrough of the files section of this checklist.
- What Makes a Good Project: Scope and Shared Context - the reasoning behind the scope items.
- Projects & Artifacts Best Practices - ongoing habits once a Project is up and running.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.