cheetah-tradecheetah-trade/claude-code-team-kit/templates/CLAUDE.md

claude-code-team-kit / templates

CLAUDE.md0 starsChanged 29 days agoMITView on GitHub

A yes covers the one action it was given for, not similar actions later. Write acceptance criteria as checkable lines, for example: - "Saving an empty name shows 'Enter a name' under the field and keeps the form open." - "The orders table loads 500 rows in under 1 second on the staging data set."

In this repository12 other files it gives its agents.
- accessibility-basicsSkill
- approvalsSkill
- backlog-itemSkill
- component-statesSkill
- department-briefSkill
- forms-feedbackSkill
- grill-before-buildSkill
- handoffSkill
- layout-and-hierarchySkill
- release-checklistSkill
- theme-token-auditSkill
- ui-review-checklistSkill

The file

We split this CLAUDE.md into the rules it gives an agent

12 rules. About 0 are common, 9 are distinctive, and 3 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Run locally: <dev command> (opens on <local URL>)
line 20
Very specific:
Before saying a change is done, run: <the checks that must pass>
line 23
Distinctive:
Ask and wait for an explicit yes in the conversation before you:
line 39
Distinctive:
delete data, run migrations on shared databases, or rewrite git history.
line 44
Distinctive:
add or change secrets, access rights or third-party integrations.
line 45
Distinctive:
every acceptance criterion in the task is met and you can show how (test output, a screenshot, a command).
line 53
Distinctive:
Write acceptance criteria as checkable lines, for example:
line 58
Very specific:
Look up facts yourself first: the code, <docs folder>, <decision log>, open issues.
line 65
Distinctive:
Ask about decisions you cannot look up: scope, behaviour users will notice, anything irreversible.
line 66
Distinctive:
Ask one question at a time, with 2-4 options and your recommendation first.
line 67
Distinctive:
If you are blocked, stop and say what you need.
line 68
Distinctive:
When you learn something others will need, add it there in one or two lines.
line 77

≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

CLAUDE.md

<!--
Team CLAUDE.md template.
Copy this file to the root of your repository as CLAUDE.md, replace every
<placeholder>, and delete sections you do not need. Claude Code reads this
file at the start of every session, so keep it short: rules and facts that
apply to most tasks. The comments explain each section; you can delete them.
-->

`<Project name>`: instructions for Claude Code

<!-- One or two sentences: what the project is and who uses it. Context helps
Claude make sensible choices when the task does not spell everything out. -->

<Project name> is <what it does> for <who uses it>.

Build and test

<!-- Exact commands, copy-pasteable. If a command needs a setup step in a
fresh checkout, say so. Claude runs these to check its own work. -->

Install: <install command>
Run locally: <dev command> (opens on <local URL>)
Tests: <test command>; one file: <single test command>
Lint and types: <lint command>
Before saying a change is done, run: <the checks that must pass>

Conventions

<!-- Only what differs from common practice or what people keep getting wrong.
Point to files instead of describing them. -->

Code style: <formatter, naming, file layout>
Where things live: <e.g. API routes in src/api/, UI in src/components/>
Branches: work on <prefix>/<short-name> branches; never commit to <main branch> directly.
Commits: <message style>
UI: colours and spacing only from <design tokens file>; check light and dark themes.

What needs a human's yes

<!-- The most important section. List actions Claude must not take on its own,
even if a task seems to call for it. Claude stops, explains, and asks. -->

Ask and wait for an explicit yes in the conversation before you:

merge a pull request or push to <main branch>;
deploy, or change infrastructure, CI or environment settings;
spend money: paid services, purchases, plan upgrades, extra usage;
send anything to people: emails, chat messages, comments on issues, posts;
delete data, run migrations on shared databases, or rewrite git history;
add or change secrets, access rights or third-party integrations.

A yes covers the one action it was given for, not similar actions later.

Definition of done

A task is done when:

every acceptance criterion in the task is met and you can show how (test output, a screenshot, a command);
<checks command> passes;
<docs or changelog> is updated if behaviour changed;
your report says what works, what is not done, and anything you could not check.

Write acceptance criteria as checkable lines, for example:

"Saving an empty name shows 'Enter a name' under the field and keeps the form open."
"The orders table loads 500 rows in under 1 second on the staging data set."

Ask instead of guessing

Look up facts yourself first: the code, <docs folder>, <decision log>, open issues.
Ask about decisions you cannot look up: scope, behaviour users will notice, anything irreversible.
Ask one question at a time, with 2-4 options and your recommendation first.
If you are blocked, stop and say what you need; do not work around a check or a permission.

Shared notes

<!-- Where decisions and knowledge live so the next session (or teammate)
does not rediscover them. Pick one place and keep it current. -->

Decisions: <docs/decisions.md or wiki link> (what, why, date, who decided)
Architecture: <ARCHITECTURE.md>
Current state and known limits: <STATUS.md>
When you learn something others will need, add it there in one or two lines.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free