What Is Claude Projects? Using Custom Knowledge Bases with Claude

Why AI Coders Need to Know This

Here's the frustrating pattern every vibe coder knows: you ask Claude to help with your project, but first you need to explain your entire stack. "I'm using Next.js 14 with the App Router, Prisma with PostgreSQL, Tailwind CSS, and Clerk for auth..." By the time you've pasted enough context for Claude to give a useful answer, you've used half the context window.

Next conversation? Same thing. Claude has no memory between chats. You're re-explaining your project from scratch every single time.

Claude Projects solves this by letting you create a persistent knowledge container. You upload your key files once, and every conversation within that project starts with Claude already understanding your codebase.

The difference is dramatic. Without a project:

• "Add a new API endpoint" → generic Express.js boilerplate
• "Fix this database query" → guesses at your schema
• "Update the user dashboard" → doesn't know your component structure

With a project containing your schema, routes, and conventions:

• "Add a new API endpoint" → follows your exact middleware pattern, uses your db client, matches your error handling style
• "Fix this database query" → references your actual table names and relationships
• "Update the user dashboard" → uses your component library and naming conventions

For vibe coders, this is the difference between AI that writes code for a project and AI that writes code for your project.

How Claude Projects Actually Works

Claude Projects has three core components:

1. Project Knowledge (Your Uploaded Files)

You can upload up to 200,000 tokens of files — roughly 500 pages of text or a medium-sized codebase. These files become "project knowledge" that Claude can reference in every conversation. Common files to upload:

• CLAUDE.md or README.md — your project conventions and architecture overview
• Database schema — schema.prisma, schema.sql, or migration files
• API routes — your endpoint definitions
• Configuration files — package.json, tsconfig.json, .env.example
• Key component files — layout files, shared components, utility functions
• Style guide — coding conventions, naming patterns, preferred libraries

2. Custom Instructions (System Prompt)

Each project has a custom instructions field — essentially a system prompt that applies to every conversation. This is where you tell Claude how to work with your project:

You are helping me build a SaaS invoicing app.

Tech stack:
- Next.js 14 (App Router)
- Prisma with PostgreSQL (Neon)
- Tailwind CSS + shadcn/ui
- Clerk for authentication
- Stripe for payments

Conventions:
- Use server components by default, "use client" only when needed
- All API routes go in app/api/ with route.ts files
- Database queries use Prisma — never write raw SQL
- Error responses follow: { error: string, code: number }
- All monetary values stored as cents (integer)

When I ask for code, match the patterns in the uploaded files.
Don't suggest libraries we're not already using without asking.

3. Conversations (The Actual Chats)

Within a project, you can have multiple conversations. Each one automatically includes the project knowledge and custom instructions. You don't re-upload or re-explain anything — just ask your question and Claude already has context.

Conversations within a project are still independent (Claude doesn't remember conversation A when you're in conversation B), but they all share the same project knowledge base.

Real Scenario: Setting Up a Coding Project

Let's say you're building an invoicing SaaS. Here's exactly how to set up a Claude Project for it:

Step 1: Create the project — Click "Projects" in the Claude sidebar, then "New Project." Name it something descriptive: "Invoice SaaS — Main Codebase."

Step 2: Upload your key files — Don't upload everything. Be strategic. For a typical Next.js app, upload:

# Files worth uploading (~30 files, well under 200K tokens)
package.json                    # Dependencies
prisma/schema.prisma            # Database schema (CRITICAL)
app/layout.tsx                  # Root layout
app/api/invoices/route.ts       # Main API pattern
app/api/payments/route.ts       # Payment flow
lib/db.ts                       # Database client
lib/stripe.ts                   # Stripe configuration
lib/utils.ts                    # Shared utilities
components/ui/button.tsx        # Component patterns
middleware.ts                   # Auth middleware
.env.example                    # Environment variable names
CLAUDE.md                       # Project conventions

Step 3: Write custom instructions — Tell Claude your conventions, preferences, and anti-patterns. Be specific about things AI usually gets wrong for your project.

Step 4: Start coding — Now when you ask "Add a recurring invoice feature," Claude knows your schema has an invoices table, your API routes follow a specific pattern, your dates use a specific format, and your Stripe integration uses a specific key structure. The response is immediately project-specific.

What to Upload (And What Not To)

Upload these — high value, low tokens:

• Database schema (highest ROI per token — Claude needs this most)
• API route files (your endpoint patterns)
• Configuration files (package.json, tsconfig, tailwind.config)
• CLAUDE.md or architectural decision records
• Shared utility files and type definitions
• One or two "reference" components that show your pattern

Don't upload these — wastes your token budget:

• node_modules/ or vendor/ — thousands of files, zero value
• Build artifacts (.next/, dist/, build/)
• Generated files (Prisma client, GraphQL codegen)
• Large data files, images, or binary files
• Test files (unless your question is about testing)
• Every single page/component — upload representative examples instead

What AI Gets Wrong About Projects

Projects don't replace Claude Code. Claude Projects is a web-based knowledge tool. It can't read your file system, run commands, or edit files directly. For actual code modification, you want Claude Code (CLI) or Cursor (IDE). Projects excels at research, planning, architecture decisions, and understanding — not at build-test-iterate cycles.

More files ≠ better responses. If you dump your entire codebase into a project, Claude spends its context budget parsing irrelevant files instead of focusing on what matters. Be selective. A well-curated 20-file project outperforms a 200-file dump every time.

Project knowledge isn't a vector database. Claude reads your uploaded files directly — it doesn't search or embed them like RAG. This means Claude processes all project files for every message, which is powerful (full context) but has a cost: larger projects use more tokens per message. If your project is near the 200K limit, every response costs more of your Pro usage.

Custom instructions are the most underused feature. Most people upload files but leave custom instructions blank. The instructions are where you tell Claude your preferences: "Never suggest React class components," "Always use async/await not .then()," "Our API returns ISO 8601 dates." These save more repeated corrections than any file upload.

Projects don't sync with your codebase. When you change your code locally, the project doesn't update automatically. You need to re-upload modified files manually. For rapidly changing codebases, this means your project knowledge can go stale. Re-upload your schema and key files weekly, or after major refactors.

Claude Projects vs Alternatives

How does Projects compare to other ways of giving AI context?

vs. Pasting code into every conversation: Projects wins. The knowledge persists across conversations. You stop wasting context window on setup.

vs. CLAUDE.md files with Claude Code: CLAUDE.md files are better for build workflows because Claude Code reads them automatically from your file system. Projects is better for research, planning, and understanding. Use both: CLAUDE.md for building, Projects for thinking.

vs. Cursor Rules: Cursor Rules serve a similar purpose inside the Cursor IDE — persistent project context. If you're using Cursor, rules are your version of this. If you use Claude directly (web or API), Projects is what you need.

vs. RAG: RAG is more scalable for very large codebases. Projects has a 200K token hard limit. If your codebase is too big for Projects, consider building a RAG pipeline that retrieves relevant files dynamically.

Power User Tips for Vibe Coders

Create separate projects for separate concerns. Don't put your frontend, backend, and infrastructure into one project. Create "Invoice SaaS — Frontend," "Invoice SaaS — API," and "Invoice SaaS — DevOps." Each project gets a curated set of files and specific custom instructions.

Upload your error log when debugging. Having a persistent project is great, but you can also add temporary files. When hunting a bug, upload the relevant error log or failing test output. Claude can cross-reference it against your schema and routes.

Use the project for architecture decisions. Before building a feature, start a conversation in the project: "I need to add team billing. Given our current schema and Stripe setup, what's the best approach?" Claude can reason about your actual architecture, not generic advice.

Version your project knowledge. When you make a major change (new database table, new auth system, refactored API), update the project files. Stale knowledge leads to outdated suggestions. Add a "Last updated: [date]" note in your custom instructions.

What to Learn Next

• What Is a CLAUDE.md File? — the file-system equivalent of project knowledge, used by Claude Code.
• Claude Code Beginner's Guide — the CLI tool for actually building and modifying code in your terminal.
• What Are Context Windows? — understand the token limits that determine how much Claude can process.
• What Are Cursor Rules? — Cursor's version of persistent project context.
• AI Prompting Guide for Coders — write better prompts that work even better with project context.

FAQ