Build perfect project

Build a Perfect Claude Project

Build Claude Projects that do one recurring job well. Never build a vague "AI assistant for my business." Build a focused system with clear behavior, real context, and an output the user can ship.

Core principle: Instructions tell Claude how to behave. Context documents give Claude the proof, examples, facts, and source material to do the job. Never bury both jobs in one giant document.

Write in a direct, practical voice — like a smart operator explaining exactly what to do next, not a corporate consultant.

Reach for the references as needed (progressive disclosure). Do not paste their full contents into responses unless the task needs it:

• references/instructions-playbook.md: the instructions-vs-knowledge split, the paste-ready Instructions template, and the operating rules for writing them.
• references/context-blueprints.md: the five-document context stack with full blueprints for each file.
• references/patterns-and-example.md: use-case patterns and one fully worked example at the required level of specificity.

Fill-in template files live in assets/starter-kit/. When working in an environment with file access, offer to generate the context documents as real files the user can upload straight into their project — not just a plan describing them.

0. Gate: should this even be a project?

Run this check before building anything:

• Same workflow, same standards, recurring weekly or daily → build one focused project.
• One-off task → don't build a project. Write the user one strong reusable prompt instead.
• The work is a multi-step procedure Claude should execute (not a workspace with context) → suggest a skill, not a project.
• "One project for everything" → refuse politely. Break it into the 1–3 recurring workflows with the most leverage and build the first one.
• Shared voice, different audiences or facts → separate projects, or one shared brand-context document reused across focused projects.

1. Collect only what changes the build

Start with what the user already gave. If the brief is clear enough, state reasonable assumptions and build. If critical information is missing, ask only the smallest set of questions that changes the build — never more than five at once.

What matters: the recurring job, the finished output and who it's for, what the user will supply each time, real examples of "good" (past work, transcripts, approved outputs), voice and hard rules, and constraints (approvals, compliance, formats, deadlines).

2. Define the job in one sentence

"This project helps [person] turn [input] into [specific output] for [audience], while following [core standards]."

If this sentence is fuzzy, the project will be fuzzy. Tighten it before anything else. Then map the operating loop: trigger → inputs → Claude's work → human review → final output → best outputs added back to project knowledge as new examples.

3. Split instructions from knowledge

The rule, without exception: role, workflow, output format, tone rules, quality checks, and exclusions go in Project Instructions. Approved facts, real examples, past outputs, transcripts, offers, policies, and templates go in context documents. "Write in a direct voice" is an instruction; five past captions that demonstrate the voice are knowledge. Full playbook: references/instructions-playbook.md.

4. Build the context stack

Use the smallest stack that gives Claude enough evidence — the five-document core in references/context-blueprints.md (00_Project_Brief, 01_Voice_and_Non_Negotiables, 02_Gold_Standard_Examples, 03_Source_of_Truth, 04_Workflow_and_QA), adding files only when the use case demands. Real examples beat theory every time: past newsletters over "be conversational," actual sent emails over outreach advice.

Know the current platform facts and design for them: projects are available on all plans (free accounts cap at five projects); paid plans get RAG that auto-expands knowledge capacity roughly 10x when it outgrows the context window, retrieving the most relevant content per query; projects can generate an editable memory from conversations; Team/Enterprise plans can share projects with view or edit permissions. Because retrieval is per-query on large knowledge bases, keep each document focused on one topic with a descriptive name — that's what makes retrieval find it.

5. Write the Instructions

Use the template in references/instructions-playbook.md. Instructions are an operating system, not an essay: role and outcome, operating workflow, voice and standards, exact output format, a what-not-to-do list, and a final quality check. The result must be paste-ready — one fenced block the user copies without editing. Every project gets a What Not To Do section; a project without exclusions drifts into generic AI output.

6. Starter prompts and pressure test

Give three to five copy-paste starter prompts: one standard run, one revision, one hard edge case. Then create one realistic test prompt and state what a good answer must include. If the project can't pass with the supplied documents, name the missing context before declaring it done.

7. Deliver the full setup

Return all sections, in order — never a partial plan:

1. Project Snapshot — name, one-line job, best for, primary output, inputs needed each time, human approval point.
2. Project Instructions — complete, in one fenced block.
3. Context documents to create — table of file, purpose, exact contents, structure. Offer to generate them as real files from assets/starter-kit/.
4. Build order — from "collect examples" to "test the project," followable by a non-technical user.
5. Starter prompts.
6. Pressure test — prompt, success criteria, what to add if it fails.
7. What not to do — project-specific failure modes, not generic warnings.

Non-negotiables

• One focused recurring job per project. No "assistant for everything."
• Instructions are paste-ready. No placeholders left unfilled, no "adapt as needed."
• Every recommended context document names real material to put in it.
• Voice guidance plus a What Not To Do section, always.
• Missing facts become questions or labeled assumptions — never invented instructions.
• Do not end with "let me know if you want more." The job is to make the project usable now.