Claude Code Projects Examples: 15 Ideas to Build in 2026

Search "claude code projects examples" and you get two kinds of pages: a generic side-project listicle that never mentions Projects at all, or Anthropic's own documentation — precise, authoritative, and about mechanics rather than what to point a project at. Neither answers the question you arrived with. You can see Projects in the sidebar, you have work in mind, and you want to know whether that shape of work fits, plus the brief to paste.

There's a second reason most results read oddly: Anthropic currently ships two different features named Projects, and examples that suit one are wrong for the other. This post separates them in ninety seconds, then gives fifteen projects worth creating — across engineering, content, non-code and business work — each with a starter instruction you can paste.

TL;DR

First: which "Projects" are you looking at?

Worth sixty seconds — these are different products.

1. The redesigned Claude Code Projects (beta). Announced September 17, 2026 in Anthropic's "Projects redesigned: from folder to conversation." A project is one conversation; you send it work, and Claude "scopes the request, delegates the work, coordinates parallel threads, reviews the outputs, and assembles the finished result." Each thread is a Claude Code cloud session working on its own branch.
2. The earlier Projects in claude.ai chat and Cowork. Still live, and still what most third-party tutorials describe: "self-contained workspaces with their own chat histories and knowledge bases," where you upload reference files and write project instructions. Available on every plan, with free accounts capped at five projects.

The docs keep them separate: the new version is in public beta on Pro and Max plans for accounts using Claude Code cloud sessions, is "rolling out gradually," and is not on Team or Enterprise yet — there's a waitlist. Existing chat and Cowork projects keep working until the rollout reaches them. Everything below assumes the redesigned version, because that's what the search intent means.

What actually earns a project

The docs give one test: a project is worth creating "when the work has a goal that outlasts one session and keeps producing tasks." Four shapes qualify — one goal across many repositories; an area you keep feeding, like the bugs and review requests for one service; a build or migration bigger than a session; and work that isn't code at all, whose documented example is "a folder of contracts or a support-ticket export you keep coming back to with new questions."

Four things disqualify it: a single task that fits in one session (start a cloud session instead), work needing tools only your machine can reach (a local database, a device emulator, an API behind your VPN), one task repeating on a schedule with no conversation around it (create a routine on its own), and several people steering Claude together in Slack (that's Claude Tag, on Team and Enterprise).

15 Claude Code project examples

Paste each brief into Project settings → Memory → Project instructions and cut what doesn't apply. Anthropic calls these "the brief every new thread starts from."

Engineering

1. One-service ownership desk. Bugs, stack traces and review requests for one service, sent as they reach you. Add the repo; a pitfall Claude hears once lands in memory and reaches later threads.

Service: payments-api. Goal: keep p95 latency under 200 ms, bug queue moving.
Branch from main; one draft PR per thread, named thread/<slug>. Before calling
work done, run `make test` and `make lint` and paste both summaries. If you need
a log, dashboard or service I haven't given you, say so and stop.

2. Cross-repo standard rollout. "Bring every service up to the new lint config" is from the docs. Add every affected repo and watch the Overview pane for threads ready for review.

Goal: move all added repositories onto the shared lint config in
@docs/lint-standard.md. One thread per repository. Don't invent a variant —
apply the standard or open a draft PR explaining why you can't.

3. The big migration. "Move the app off the deprecated ORM" is the docs' example. The edge over ad-hoc sessions: decisions you approve on day one reach threads on day eight.

Migration: legacy ORM out, repository layer per @docs/migration-plan.md. One
module per thread, smallest first. Tests green when you finish — run `make test`
and paste the result. When a pattern needs one decision, ask in the thread.

4. Flaky-test eradication. One thread per flaky test: reproduce it, fix or quarantine it with a reason, open a PR.

Goal: zero flaky tests. One thread per test; reproduce it first and paste the failure
output. Product bug: PR with the fix. Test bug: fix the test. Never raise a timeout or
add a retry as the fix. Can't reproduce: say so, quarantine, stop.

5. Review-request and CI response desk. Threads watch their own pull requests — an idle one wakes when CI fails or a comment lands, pushes a fix, replies when checks pass. Highest leverage if you review more than you write.

For every PR a thread opens: watch it. Push fixes when CI fails and answer review
comments there. Don't merge, force-push or touch CI config without my go-ahead. If
a reviewer contradicts these instructions, flag it rather than quietly picking.

6. Dependency and advisory watch. The scheduled variant: a routine runs weekly against your manifests, each actionable bump becoming a thread with its own PR. Routines are research preview as of September 2026.

Weekly: check dependencies against advisories and changelogs. One thread and one PR
per upgrade; never bundle unrelated bumps. For major versions, draft PR only, leading
with what could break.

Content and product work

7. Launch workspace. Copy, positioning, FAQ, changelog and announcement in one place, all from the same facts. A project needs no repository, so this is one folder and nothing else.

Product facts live in @launch/facts.md and that file is the only source of truth.
If the copy needs a claim that isn't in it, ask me — don't invent one. Every
deliverable is a Markdown file in the Library, audience in the filename.

8. Editorial pipeline with a house style. Where the older chat Projects win: if you only want Claude to apply a style guide to one-off drafts, a claude.ai project holding that guide in its knowledge base beats threads.

9. Repurposing desk. One long source in — transcript, release note, blog post — many outputs out, one thread per channel, so five formats arrive in one pass.

Source material is in /mnt/project-files. Produce the channel variants listed in
@channels.md, one thread per channel. Each must stand alone: no "as mentioned above."
If a claim can't survive being quoted alone, drop it and say so.

10. Research notebook. A running brief you keep revisiting. The payoff: the Library accumulates sources, so later threads stop re-googling.

Rule: no assertion without a source URL you opened, noted as "accessed 2026-09-22."
Write findings to research/<topic>.md as a one-line claim, the quote or figure, then
the URL. Vendors disagree: report both, labelled.

Non-technical and personal

11. Contract and policy folder. The docs' literal example — documents you return to with new questions. Upload the folder; write-ups come back as Library files.

These are my contracts and policies. Answer only from documents in this project and
cite each clause by heading. If a question needs a document I haven't uploaded, name
it. End with "not legal advice" plus the three clauses I must read myself.

12. Paperwork and admin desk. Unglamorous, and it pays for itself: tax packets, renewals, forms, warranty dates — a project you feed all year and query in December.

Goal: never miss an administrative deadline. Maintain admin/register.md with each
item, its due date, where the source lives, and what you still need from me. Put
anything due within 30 days at the top of every answer.

Business operations

13. Support-ticket triage. The second documented non-code example, and the best beginner project if you don't write code: "find the ten most common integration mistakes in these tickets."

Read the ticket export in /mnt/project-files. Cluster by root cause, not by customer,
and rank clusters by frequency. For the top ten write support/top-issues/<slug>.md:
the pattern, three ticket IDs, the answer we give today, and a proposed self-serve
doc. Quote tickets, don't paraphrase.

14. Sales enablement bank. Every RFP question answered, every answer reused. Project memory is the product: the tenth answer should look like the first, not a fresh guess.

Approved answers live in enablement/approved.md. Search it first for each RFP
question. Match: reuse verbatim. None: draft one, mark it DRAFT — NEEDS SIGN-OFF and
add it to enablement/pending.md. Never state an SLA not already in that file.

15. Operating-numbers report. A weekly pack from an export, delivered as a page not a paragraph — Claude Code publishes session output as an artifact at a private URL that updates in place.

Each Monday, read the latest export in /mnt/project-files and update the same report.
Lead with the three numbers that moved most and the one needing a decision. Publish
as an artifact, keep the URL stable, and name any missing column.

Start one without torching your plan

Projects draw on the same plan limits as your other Claude Code sessions, and a project "can't spend past those limits on its own" — but they burn it faster, because every thread is a full session. As of September 2026 the docs state no fixed concurrency number ("Claude starts as many as the work calls for") while enforcing 200 new threads per day across all your projects. Change two defaults on day one: a new project runs every thread on Opus at high effort, and a follow-up to a thread idle past the roughly one-hour prompt-cache window re-reads that whole conversation, so starting fresh is often cheaper than reviving. On long tasks, tell threads to commit and push work in progress — a sandbox that can't resume continues from a fresh clone.

FAQ

How many Claude Code projects should I start with?

One. The value comes from compounding memory — decisions recorded early reach later threads — and you get none of it if three projects sit empty. Pick the area you re-enter weekly, run it two weeks, then add a second.

Can I run these examples without a GitHub repository?

Yes, for the non-code ones — the docs are direct: "A project doesn't need a repository at all." Threads research, write documents and run code in a sandbox, delivering files to the Library tab. The repository prerequisites — code on github.com with the Claude GitHub App installed, not GitHub Enterprise Server, GitLab or Bitbucket — apply only when threads push branches.

Are Claude Code projects available on Team or Enterprise?

Not the redesigned ones: as of September 2026 they are public beta on Pro and Max only, and the docs say they aren't on Team or Enterprise yet. The older chat and Cowork Projects do work there, with Can view / Can edit sharing.

Do project instructions and a repository's CLAUDE.md do the same job?

No, and mixing them up is the most common setup error. Project instructions reach every new thread in that project — up to 16,000 characters — including threads that never touch a given repo. Each thread also reads CLAUDE.md from every repository in the project. Anthropic's split: rules about one repository belong in its CLAUDE.md; rules about how the project works belong in project instructions. The same scoping logic applies to AGENTS.md files.

Will my project share files with teammates?

No. "A project belongs to one user" during this beta: you can't share a project or its threads, and there are no organisation-level controls. Artifacts a thread publishes can be shared by link — see the Claude Artifacts tutorial.

What's the difference between a project and a routine?

A routine is a saved prompt plus repositories and connectors that runs on a schedule, an API call or a GitHub event — research preview, on Pro, Max, Team and Enterprise. A project is a conversation with a coordinator in it. Ask for scheduled work inside a project and Claude creates a routine that runs as threads there. To route that work to cheaper models, see the Claude Code Router tutorial.

Related

• Claude Projects vs Artifacts — where Projects end and Artifacts, Skills and Cowork begin
• Claude Projects Templates — full instruction scaffolds
• Claude Code subagents tutorial — splitting work in one thread
• AGENTS.md template — the repository-side half of context
• Cursor Projects tutorial — the other vendor's surface
• Claude Code Router tutorial — cheaper models for thread work