Claude Projects Templates: 8 Paste-Ready Briefs (2026)

Every "Claude templates" page has the same problem: it hands you a paragraph of prompt prose with no reason for its shape. Then you paste it into the wrong field — account instructions instead of project instructions, a repository's CLAUDE.md instead of a project brief — and wonder why Claude follows it about half the time.

This post runs the other way: the five-part skeleton with a reason per section, the four fields project context lives in (most template failures are a field-selection failure), then eight paste-ready templates across engineering, content, non-code and Cowork work. Scoped to September 2026, when the redesigned Claude Code Projects are public beta on Pro and Max.

TL;DR

Every template below uses one skeleton: Purpose → Where → Verification → Missing input → Approval boundary.

Why five parts

Anthropic's guidance for the field lists what a useful brief covers: what the project is for; where the work happens — repositories, starting branch, how to name pull requests; how a thread checks its own work; what to do when something it needs is missing; and what needs your go-ahead first. That's a skeleton, not a suggestion, and it explains why one-paragraph "act as a senior engineer" prompts decay.

Two properties make it work. Instructions are "context, not enforced configuration," so wording determines compliance rather than guaranteeing it. And every new thread gets the same text at start, so a rule stated once is cheaper than repeating it per task — while a vague or contradicted rule is dead weight you pay context for on every thread.

Deletion matters more than fill order: write all five sections, then cut anything a thread could derive from the repository. Keep "facts Claude should hold in every session" — a multi-step entry belongs in a skill or a path-scoped rule instead.

The eight templates

Template 1 — Engineering service desk

The default for owning one service over weeks. Allocation rule: anything about a single repo belongs in its CLAUDE.md; only cross-cutting rules go here.

## Purpose

Own <service>: p95 under <target>, bug queue keeps moving. Nothing else in scope.

## Where the work happens

Repos: <repo-a>, <repo-b>. Branch from `main`. One draft PR per thread, named
`thread/<issue-slug>`. Push work in progress every ~20 minutes.

## Verification

Run `make test` and `make lint`, paste both summaries, and say which behaviour
you actually exercised.

## Missing input

Can't reach a repo, secret, API or connector? Name what's missing and stop. No
substituting, mocking, or guessing numbers.

## Approval boundary

No merging, force-pushing, or CI config changes without my go-ahead. Ask before
adding a dependency or touching the schema.

Fill: service, target, repos, real build commands. Delete: the latency line if that isn't the goal.

Template 2 — Cross-repo migration

For a change landing in several repositories at once. The hard part is stopping eight threads making eight different judgement calls.

## Purpose

Move <repos> from <old> to <new>, per @docs/<plan>.md. Done = every repo green
on the new path, old path deleted.

## Where the work happens

One thread per repo, smallest first. Never two repos in one thread.

## Verification

Run `<test command>`, paste output, list every call site changed and any you
left alone, with the reason.

## Consistency

Decide once what should be decided once: at the first ambiguous case, stop,
propose the rule, wait. Record each decision in project memory.

## Missing input / approval

Can't reach the plan doc: say so and stop. No PRs against `main`; target
`migration/<wave>`. Merge order is mine.

Why the "propose the rule" line exists: migration threads fail by drifting, not breaking — one reasonable local choice each becomes eight incompatible shapes.

Template 3 — Code review and CI response desk

For anyone who reviews more than they write. Deliberately short: review instructions bloat fastest.

## Purpose

Keep <repos>' open PRs moving: CI green, comments answered, nothing merged
without me.

## Where the work happens

One thread per PR, watched after opening: push fixes when CI fails, answer
comments, report back when checks pass.

## Review gate

In order: does it do what the ticket said; do tests prove behaviour not
implementation; does it match that repo's CLAUDE.md; what breaks in six months.
Comment inline, summarise once, don't restyle untouched code.

## Missing input

Reviewer contradicting these instructions: surface it, don't pick a side.
Ambiguous ticket: ask.

## Approval boundary

Never merge, self-approve, or edit CI config. Nothing is "done" because it looks
finished — only because you ran it.

Delete: the "six months" line if you don't want architectural comments.

Template 4 — Documentation and changelog maintenance

Docs drift is a recurring job, which is what projects are for. Pair it with a routine to run unattended — routines are research preview as of September 2026.

## Purpose

Keep documentation true to the code, so writers don't have to remember to
update prose.

## Where the work happens

Docs live in <docs-repo>. Each run: read PRs merged in <code-repo> since last
time, flag docs now citing a changed API, open update PRs for an editor.

## Verification

Quote the old line and the new line. Can't point at the commit that broke the
doc? Propose a question, not an edit.

## Style

Match the file's voice; don't prettify correct passages. Never delete a
documented behaviour without a PR link proving it's gone.

## Missing input / approval

Unclear whether an API broke intentionally: ask, mark `NEEDS DECISION`. Never
edit `security/` or legal pages without me.

Template 5 — Content production line

The highest-value non-code template, because content work carries the most unsaid constraints. Note the field selection: brand facts belong in the knowledge base, not the instructions — knowledge is retrieved when relevant, instructions go into every thread.

## Purpose

Produce <artefact type> for <audience> that an expert wouldn't wince at.

## Sources of truth

Only @facts.md and the knowledge base. A claim not in them: ask. Never invent a
statistic, customer name, price or capability. Sources disagree: use the newer
and say which.

## Voice

Short declaratives, active voice, concrete nouns. Banned: "leverage",
"seamless", "revolutionary", rhetorical openers, sentences over 25 words.

## Output format

Markdown to the Library, `<channel>-<topic>.md`: promise, evidence, mechanism,
next step. End with three titles and the claim you'd most want verified.

## Approval boundary

Nothing publishes from here. Drafts only; anything touching price, customer
names or legal claims is DRAFT — NEEDS SIGN-OFF.

That last line is the most valuable here — an explicit "mark this for a human" beats a general "be careful," because it's checkable.

Template 6 — Research and due-diligence notebook

For competitive analysis and vendor evaluation — work whose failure mode is confident synthesis of a weak source.

## Purpose

A citable, running brief on <topic>. Accuracy over coverage: "unverified" is a
good outcome, a plausible wrong line is the worst.

## Method

Build on this project's existing notes instead of re-deriving. Open every source
you cite; record URL and access date in research/<subtopic>.md.

## Evidence rules

Claim in one line, then the quote or figure, then the source. Mark [primary] vs
[secondhand]. Vendors disagree: report both, labelled — never average them.
Prefer a spec, filing or changelog over a post summarising it.

## Missing input

No primary source: write "unverified", say what you searched, stop.

## Approval boundary

No opinion unless I ask. Recommend only with evidence attached and the strongest
counter-argument named.

Template 7 — Non-code operations (contracts, tickets, admin)

The documentation lists "a folder of contracts or a support-ticket export you keep coming back to with new questions" as a first-class use case: no repository, files in the Library, threads doing the analysis.

## Purpose

Turn <document set> into answers I can act on; keep the register current.

## Where the work happens

Documents live in the Library. Maintain <area>/register.md: each item, its date,
where the source lives, what's still missing.

## Evidence rule

Answer only from documents here, citing name and heading. Need a document I
haven't uploaded? Name it instead of reasoning around it.

## Output format

One file per question, one-line summary in the thread. ISO dates. Anything due
inside 30 days goes at the top.

## Approval boundary

No final legal, medical or financial conclusions — restate the documents, flag
what needs a professional, stop.

Fill: register filename, citation shape, your domain's caveat — and replace the last section with something stricter.

Template 8 — Cowork project (knowledge work)

Cowork projects are a different object: workspaces "with their own files, context, instructions, and memory," where memory is "scoped to the project, so what Claude learns in one project doesn't carry over to others." They carry project-scoped scheduled tasks natively, so this template has a schedule section the others don't.

## Purpose

Own <recurring knowledge task> so it happens without me remembering it.

## Standing rules

Tone and format: <your defaults>. Output to <folder or Library>. Anything I'll
forward must read as a standalone document.

## Inputs

Working folder: <local folder or linked chat project>. Re-read inputs/<file>
first; if a required input is missing, list it and stop rather than working from
an older copy.

## Scheduled work

Run <cadence>. Each run updates the same named deliverable and appends a
one-line changelog.

## Memory

Record each of my corrections as a project memory rule — and if it contradicts
something above, say so instead of quietly choosing.

Caveat: a Cowork project started from a local folder stays on that machine.

Filling them in without making them worse

Three edits do most of the work. Make every rule verifiable: "use 2-space indentation" beats "format code properly"; "run npm test before committing" beats "test your changes." Cut the persona — ten lines about being a senior engineer cost context and change little. Resolve contradictions: conflicting rules get picked arbitrarily, so delete what a new one makes wrong.

Then test it as the docs suggest: send one small real piece of work, open the thread when it finishes, read how it reported. Guessed at anything? Your missing-input section is too soft. Then ask Claude to propose threads before starting them, a couple at a time — a verbal thread limit is a preference, not a cap.

FAQ

Where exactly do I paste one?

Claude Code Projects: the project header's gear icon → Project settings → Memory → Project instructions, or ask Claude to change them. It takes up to 16,000 characters, sent to every new thread and the coordinator, and changes reach new threads only. In claude.ai chat projects it's "Set project instructions" on the knowledge panel.

Project instructions vs custom instructions?

"Instructions for Claude" in account Settings is account-wide. Project instructions reach one project. Skills are the third layer — task-specific, loaded when relevant. Use each for its scope instead of writing the same rule in all three.

How do these relate to AGENTS.md and CLAUDE.md?

Different layer. CLAUDE.md and AGENTS.md live in a repository and travel with it; threads clone each repo and load its CLAUDE.md and skills. Anthropic's split is explicit: repo rules in CLAUDE.md, project rules in project instructions.

My instructions get ignored. What's the fix?

Usually one of four: too long, so adherence drops; contradictory, so Claude picks one; vague, so nothing is verifiable; or a procedure that belongs in a skill. This is context, not enforced configuration — for something that must never happen, use a PreToolUse hook. Run /context to check what loaded.

Do these work on the free plan?

Partly. Classic claude.ai Projects exist on every plan, free accounts capped at five, so Templates 5–7 work there. Thread-based Claude Code Projects are Pro and Max beta only; RAG-backed knowledge needs a paid plan.

Are Cowork templates the same as Claude Code ones?

No. A Cowork project is a knowledge-work container — files, instructions, memory, project-scoped scheduled tasks. A Claude Code project is a coordinator over repositories with threads opening PRs. Keep the structure; rewrite the body.

Can I run these on cheaper models?

Locally, yes — Claude Code accepts an Anthropic-compatible endpoint through environment variables, which is how the Claude Code Router tutorial and the GLM Coding Plan guide wire other providers in, and a project's thread model and effort are selectable in Project settings → General. But project threads are cloud sessions with Anthropic as the provider, so a router on your machine doesn't reach them.

Related

• Claude Code project examples — what to point these at
• Claude Projects vs Artifacts — Projects, Artifacts, Skills, Cowork, chats compared
• AGENTS.md template — the repository-side half
• Claude Skills tutorial — where procedures belong
• Claude Code subagents tutorial — workers inside one thread
• Claude Cowork + DeepSeek guide — Cowork on a cheaper path