Skills Carry the How, Projects House the What: Organizing Claude Cowork

Six months into using Claude seriously, most people's workspace looks like a junk drawer: forty open chats, a global instruction file stuffed with every rule they've ever needed, and the daily ritual of re-pasting the client's brand guide into chat number forty-one. The tool isn't the problem — the organization is. Everything got dumped into one context because nothing had a designated place.

Claude Cowork's two organizing primitives exist precisely for this. Skills are capabilities — how the work should be done. Projects are contexts — what the work is about. Most confusion and most wasted effort come from mixing those two jobs, so this guide is about the distinction, the workflow that follows from it, and the cost habits that keep it sustainable. (The setup mechanics — the guided start, plugins, connectors — are covered in the earlier quick-start guide; this is what you do once the wheels are on.)

Capabilities vs Contexts

The cleanest way to hold the distinction:

The rule of thumb fits on a sticky note: if you do it repeatedly, it's a Skill; if you return to it as a place, it's a Project. Drafting contracts is a Skill. Everything about Client A is a Project. A formatting standard is a Skill. The campaign brief it formats is a Project.

What a Well-Built Skill Looks Like

A Skill is an executable formula. When you build one well, it becomes a slash command that behaves identically every time it's called — in any chat, in any Project:

### /weekly-report

Goal: turn the raw notes below into our house-format weekly report.

Formula:
1. Headline: one sentence, outcome not activity
2. Wins: max 3, each with a number
3. Risks: what's blocking, owner named
4. Next week: max 3 commitments
Tone: direct, no filler. If a section has nothing real,
write "none" — never invent.
Input: [raw notes]

Three rules for the building:

• Define the goal sharply — "generate a project timeline" beats "help with timelines"
• Enough detail to repeat, not so much it calcifies — the formula constrains structure, not judgment
• Point it at busy work — the repetitive formatting and boilerplate you resent; that's where Skills pay back their build cost in a week

What a Well-Built Project Looks Like

A Project is a room with a filing cabinet. Everything inside becomes Claude's primary working knowledge for conversations in that space — and crucially, it doesn't leak into your other work:

project: client-a
contents:
  - brand guidelines + banned words
  - engagement history + past deliverables
  - the current statement of work
  - stakeholder map + tone notes per person
shared: true        # teammates see the same facts
mission: "Every chat in this room knows Client A
          without anyone re-pasting a thing."

The team effect is the quiet superpower: interns and managers work from the same fact base, so the fifth person to touch the account doesn't rediscover the account. For a solo operator, the same structure means Monday-you inherits Friday-you's context for free.

Layering: Where It Gets Powerful

The two primitives compose. Inside Client A's Project, call the /contract-draft Skill:

[Project: Client A]           <- Claude knows WHO (their docs, voice, history)
> /contract-draft Q4 renewal  <- Claude knows HOW (your legal phrasing formula)

Neither primitive alone gets you there: the Skill without the Project drafts a generic contract for a stranger; the Project without the Skill knows everything about the client and none of your process. Layered, the output arrives both informed and in your house style — which is the entire promise of the tool.

The Lean-Global Principle

The mistake that quietly degrades everything: stuffing the global "About Me"/instructions section with every rule you own. A model juggling forty always-on rules becomes rule-bound — less creative, more rigid, occasionally paralyzed trying to satisfy constraints that don't apply to the current task.

The fix is architectural: instructions should live where they apply.

• Formatting rules for one deliverable → that Skill
• Client facts → that Project
• Truly universal preferences (voice basics, "always ask before assuming") → global, kept to a handful

Test your global section by asking: does this rule matter in most conversations? If it matters in five out of fifty, it's context pollution for the other forty-five.

Cost Habits That Keep It Sustainable

Cowork's multi-agent planning is powerful and token-hungry, so three habits protect the budget:

Watch chat bloat. Every new message in a long thread re-processes the whole history. Past a point, you're paying to re-read your own noise.

Restart with a summary. When a task completes or the topic shifts: "summarize our current status" → copy → paste into a fresh session. You keep the context and drop the sediment. (Every ~20 messages is a reasonable rhythm.)

Match model to task. Deep strategy and complex analysis earn the big model; grammar passes and routine formatting run on the faster tier. Same principle as the consulting-firm routing — partner rates for thinking, associate rates for volume.

weekly maintenance (5 minutes):
- close finished chats (they're paid-for sediment)
- new Skill? extract it from whatever you just did twice
- new Project? any topic that needed 3+ re-pasted docs
- prune global instructions that fail the "most conversations" test

Frequently Asked Questions

What's the actual difference between a Skill and a Project?

A Skill is a repeatable capability — how Claude should act ("write our weekly report in this format"). A Project is a context bucket — what Claude should know ("everything about Client A"). Skills travel to any conversation; Projects stay put and hold the facts.

Why not put everything in global instructions?

Because always-on rules tax every conversation, including the ones they don't apply to. A model balancing dozens of permanent instructions gets more rigid and less creative. Move each rule to the Skill or Project where it actually matters, and keep global for the few preferences that genuinely apply everywhere.

How do I keep costs down in Cowork?

Three habits: don't let old chats bloat (every message re-reads the thread), restart sessions with a pasted summary when tasks complete, and route routine work to smaller models while reserving the heavy model for strategy and analysis.

Can my team share this organization?

Yes — Projects can be shared, so everyone works from the same documents and knowledge. Skills standardize the how across the team too: one person's /weekly-report formula becomes everyone's, which is how a five-person team starts sounding like one.

Wrap-Up

The junk drawer isn't a personality; it's an architecture problem. Skills carry your processes anywhere they're needed, Projects house your knowledge where it belongs, and the two layer into work that's simultaneously informed and consistent. Keep the global section lean, restart threads with summaries, and spend five minutes a week filing. The workspace that results does the remembering — so the humans can do the thinking.