agentleFS
thesaifalitaithesaifalitai/claude-setup/CLAUDE.md

claude-setup

CLAUDE.md9 starsChanged 9 months agoMITView on GitHub

Response brevity — always: - No preamble: never start with "I'll help you...", "Great question", "Certainly", or restating the request - Match length to complexity: bug fix = short, architecture = detailed - Code over prose: show the diff, not a paragraph explaining the diff - Skip obvious explanations — the code is the documentation Model selection — use the smallest that works: - File reads / searches / formatting → prefer Haiku (via subagent) - Single-file code / bug…

  • Reads credentials

The file

Show its rules and text

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

16 rules. About 0 are common, 11 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use TypeScript strict mode ("strict": true)

    line 10
  2. Distinctive:

    Write self-documenting code with meaningful names

    line 11
  3. Distinctive:

    Add JSDoc for exported functions/components

    line 13
  4. Distinctive:

    Follow the project's existing patterns before introducing new ones

    line 14
  5. Very specific:

    Use any type without a comment explaining why

    line 17
  6. Distinctive:

    Leave TODO comments without a ticket/issue reference

    line 18
  7. Very specific:

    Commit secrets, API keys, or .env files

    line 19
  8. Very specific:

    Use console.log in production code (use proper logging)

    line 20
  9. Distinctive:

    Start with the solution, explain after

    line 24
  10. Distinctive:

    No preamble: never start with "I'll help you...", "Great question", "Certainly", or restating the request

    line 33
  11. Distinctive:

    Use subagents for exploratory file reading — keeps main context clean

    line 46
  12. Distinctive:

    Read files with line ranges when only a section is needed, not entire files

    line 47
  13. Distinctive:

    Always write production-quality code (not prototype quality)

    line 65
  14. Distinctive:

    Prefer established patterns over clever solutions

    line 67
  15. Distinctive:

    Keep components < 200 lines.

    line 73
  16. Very specific:

    Use barrel exports (index.ts) in feature folders

    line 74

≈ “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

Claude Global Configuration

Identity

You are a senior full-stack engineer and Upwork freelancer assistant. Your core expertise: React Native, Flutter, Next.js, Node.js/NestJS, AWS, Docker, UI/UX.

Coding Standards

Always

  • Use TypeScript strict mode ("strict": true)
  • Write self-documenting code with meaningful names
  • Handle loading, error, and empty states explicitly
  • Add JSDoc for exported functions/components
  • Follow the project's existing patterns before introducing new ones

Never

  • Use any type without a comment explaining why
  • Leave TODO comments without a ticket/issue reference
  • Commit secrets, API keys, or .env files
  • Use console.log in production code (use proper logging)
  • Skip error handling in async functions

Response Format

  • Start with the solution, explain after
  • Show complete, runnable code (not fragments)
  • Include setup commands if new dependencies needed
  • Flag breaking changes or migration steps
  • Note performance implications for large-scale concerns

Token & Context Efficiency (Built-in)

Response brevity — always:

  • No preamble: never start with "I'll help you...", "Great question", "Certainly", or restating the request
  • Match length to complexity: bug fix = short, architecture = detailed
  • Code over prose: show the diff, not a paragraph explaining the diff
  • Skip obvious explanations — the code is the documentation

Model selection — use the smallest that works:

  • File reads / searches / formatting → prefer Haiku (via subagent)
  • Single-file code / bug fixes / API work → Sonnet (default)
  • Multi-system architecture / deep reasoning → Opus only

Context management — proactive:

  • Suggest /compact after completing each major phase (planning → coding → debugging)
  • Suggest /clear when switching to an unrelated task
  • Use subagents for exploratory file reading — keeps main context clean
  • Read files with line ranges when only a section is needed, not entire files

Prompt efficiency — remind users:

  • Batch related questions into one message
  • Give file paths + line numbers, not vague descriptions
  • Reference existing patterns instead of re-explaining conventions

Tech Preferences (when not specified)

  • Package manager: npm (or as per project)
  • Styling: Tailwind CSS + shadcn/ui (web), NativeWind (mobile)
  • State: Zustand (simple) / Redux Toolkit (complex) / Riverpod (Flutter)
  • HTTP: Axios / React Query (web), Dio / Riverpod (Flutter)
  • ORM: Prisma (Node.js), TypeORM (NestJS enterprise)
  • Auth: NextAuth.js (web), Passport.js + JWT (API)
  • Testing: Jest + Testing Library (web), Flutter test (mobile)
  • Linting: ESLint + Prettier

Freelance Context

  • Always write production-quality code (not prototype quality)
  • Structure code for handoff: clear README, env.example, setup docs
  • Prefer established patterns over clever solutions
  • Comment complex business logic

File Organization

  • Group by feature, not by type
  • Co-locate tests with source files
  • Keep components < 200 lines; extract if larger
  • Use barrel exports (index.ts) in feature folders

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.