How I set up Claude projects so they actually work

Most people use Claude Projects wrong.

They create a project.
Give it a name.
Maybe add one vague instruction.
Then they start chatting like usual.

And the result is almost the same as a normal Claude chat.

That is not a real project.

A real Claude Project should behave like a trained assistant for one specific job. It should already know your goal, your style, your files, your standards, your process, and what a good final answer looks like before you even send the first message.

The difference is huge.

A weak project gives you generic output.
A strong project saves you from explaining the same context every day.

Here is how I set mine up.

Why Most Claude Projects Feel Average

There are usually three problems.

1. The instructions are too vague

"Help me write better" is not enough.

Claude already knows how to be helpful. What it does not know is:

• Your voice
• Your audience
• Your standards
• Your examples
• Your preferred structure
• What you consider bad output

The project instructions need to teach Claude how you work.

2. There are no knowledge files

A project without files is basically just a named chat.

The real power comes when Claude has access to reference material:

• Your writing samples
• Your brand notes
• Your customer research
• Your previous work
• Your templates
• Your internal docs

Without files, Claude guesses. With files, it can match your real context.

3. One project is trying to do too much

Do not make one project called "Work" and expect it to handle everything.

Writing, research, strategy, coding, sales, and planning all need different context.

One project should have one main job.

My Claude Project Setup

Every useful project needs six things.

1. The Role

This tells Claude who it is inside this project.

Not:

~~"You are a helpful assistant."~~

Use something specific.

Example:

You are my senior content assistant. You help me research, plan, draft, and edit practical AI content for people who want useful workflows, not theory.

You know my style: direct, simple, specific, and low on fluff.

Your job is to help me produce clear content that feels useful immediately.

This works because Claude performs better when the role is concrete.

2. The Rules

Rules are the part most people skip.

This is where you define what Claude must always do and what it should avoid.

For example:

Always:

• Write in short paragraphs
• Use clear headings
• Make the first lines strong
• Use specific examples
• Keep the structure easy to scan
• Explain things simply
• Remove filler

Never:

• Use generic business language
• Over-explain obvious points
• Write long blocks of text
• Use vague claims without examples
• Sound like a corporate blog
• Add disclaimers unless they are actually needed

Rules turn your preferences into a system.

Every time you correct Claude, add that correction back into the rules.

3. The Process

Do not only tell Claude what to create. Tell it how to think.

For a writing project, my process looks like this:

1. Identify what the reader already believes.
2. Find the gap or misconception.
3. Build the article around that contrast.
4. Create the structure before writing.
5. Draft the full piece.
6. Review it against the project rules.
7. Cut anything that feels generic.
8. Make the final version easier to scan.

This stops Claude from rushing straight into average output.

4. The Output Format

Claude should know what the finished result looks like.

For example:

• Title: Clear, specific, curiosity-based
• Intro: Short contrast between the wrong way and the better way
• Body: Numbered sections with practical examples
• Paragraphs: Short and easy to read
• Ending: Direct takeaway with a strong final point

This removes guessing.

If you want threads, articles, emails, reports, or scripts, define the format for each one.

5. The Knowledge Files

This is where the project becomes useful.

For a content project, I would upload:

• Style guide
• Best-performing posts
• Audience profile
• Topic list
• Content templates
• Competitor examples
• Rejected examples showing what I do not want

For a coding project, I would upload:

• Architecture notes
• Code conventions
• API docs
• Common commands
• Testing rules
• Examples of good patterns

The files are what make the output feel like yours.

6. The First Message Template

The first message in a project matters.

Do not just say: "Write this."

Use a simple briefing format:

Today we are working on: \[TASK\]

Goal: \[WHAT I WANT\]

Audience: \[WHO THIS IS FOR\]

Context: \[WHAT MATTERS\]

Use these files: \[STYLE GUIDE / TEMPLATE / EXAMPLES\]

Before drafting, tell me:

1. What angle would make this stand out?
2. What would the reader expect?
3. What should we avoid?
4. What structure would work best?

After I approve the direction, write the full draft.

This makes Claude plan before it writes.

The System Prompt Template

Use this as a base and edit it for your own project.

ROLE

You are my [ROLE] for this project.

Your job is to help me [PRIMARY JOB] for [AUDIENCE].

You understand my style, standards, and goals. Your output should feel like it belongs to my existing work, not like a generic AI response.

STYLE

Write in a direct, practical, specific style.

Use short paragraphs.

Make the structure easy to scan.

Avoid filler, vague advice, and corporate language.

RULES

Always:
- [Rule 1]
- [Rule 2]
- [Rule 3]
- [Rule 4]
- [Rule 5]

Never:
- [Anti-rule 1]
- [Anti-rule 2]
- [Anti-rule 3]
- [Anti-rule 4]

PROCESS

For every task:
1. Understand the goal.
2. Check the relevant knowledge files.
3. Identify the strongest angle.
4. Create the structure.
5. Draft the output.
6. Review against the rules.
7. Improve clarity and remove weak parts.

OUTPUT FORMAT

Default format:
- Title: [FORMAT]
- Length: [LENGTH]
- Structure: [SECTIONS]
- Style: [STYLE NOTES]
- Ending: [ENDING TYPE]

The 5 Claude Projects I Would Create First

You do not need twenty projects.

Start with five.

1. Content Project

For posts, articles, newsletters, scripts, and content ideas.

Files to include:

• Writing samples
• Style guide
• Audience profile
• Best-performing content
• Content calendar
• Templates

2. Research Project

For deep dives, market research, competitor analysis, and source review.

Files to include:

• Research standards
• Trusted sources
• Past research examples
• Evaluation criteria
• Industry notes

3. Communication Project

For emails, DMs, client messages, updates, and announcements.

Files to include:

• Examples of good emails
• Tone guidelines
• Audience types
• Common message templates
• Company or personal context

4. Strategy Project

For planning, decisions, offers, positioning, and business thinking.

Files to include:

• Goals
• Constraints
• Business plan
• Competitor notes
• Customer research
• Decision frameworks

5. Technical Project

For coding, architecture, debugging, and technical writing.

Files to include:

• Tech stack
• Coding standards
• Repo notes
• Architecture docs
• Common commands
• Examples of preferred code style

Each project should have its own job.

That is the whole point.

What Changes After Setup

Before this setup:

You write a long prompt.
Claude gives a decent answer.
You spend time fixing the tone, structure, and details.
Then you repeat the same process tomorrow.

After this setup:

You write a short task brief.
Claude already knows the style.
It checks the right files.
It follows your rules.
It uses the right format.
You only edit the final 10-20%.

That is where the time savings come from.

Most people think Claude Projects are just folders.

They are not.

They are reusable work environments.

If you set them up properly, you stop prompting from zero and start working from a system.

If you read this far:

• BOOKMARK THIS.
• Follow @0xwhrrari
• Follow my Private Telegram Channel