\n| Main use<\/td>\n | Code standards, architecture, workflow<\/td>\n | Build commands, debug findings, preferences<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n CLAUDE.md itself gained a richer structure in 2026. Four scopes<\/strong> are supported: organisation-wide managed policy<\/strong> files distributed by IT\/DevOps (macOS at \/Library\/Application Support\/ClaudeCode\/CLAUDE.md<\/code>, Linux at \/etc\/claude-code\/CLAUDE.md<\/code>, Windows at C:Program FilesClaudeCodeCLAUDE.md<\/code>); team-specific project<\/strong> files (.\/CLAUDE.md<\/code> or .\/.claude\/CLAUDE.md<\/code>); user<\/strong> files covering all your projects (~\/.claude\/CLAUDE.md<\/code>); and local<\/strong> files for project-only personal notes that go into .gitignore<\/code> (.\/CLAUDE.local.md<\/code>). More specific scopes override broader ones.<\/p>\nLoading mechanics widened too. Starting from the working directory, Claude walks upward to the filesystem root<\/strong> scanning every directory for CLAUDE.md<\/code> and CLAUDE.local.md<\/code>; all matches are pulled into context. CLAUDE.md files in subdirectories are not loaded at launch \u2014 they load on-demand<\/strong> when Claude reads a file in that directory. If you bring in extra directories with --add-dir<\/code>, set the CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1<\/code> environment variable to load their CLAUDE.md files too. After a compaction (\/compact<\/code>) the project-root CLAUDE.md is reloaded automatically; nested files come back with the next relevant read.<\/p>\n \n<\/span>2026 New Features: Imports, .claude\/rules\/, AGENTS.md Interop<\/span><\/h2>\nTo stop CLAUDE.md from ballooning into one giant file, Anthropic standardised the @path\/to\/import<\/code><\/strong> syntax. It pulls other markdown files into CLAUDE.md; relative and absolute paths both work; recursion is allowed up to 5 hops deep<\/strong>. Typical usage:<\/p>\nSee @README for project overview and @package.json for available npm commands.\n\n# Additional Instructions\n- git workflow @docs\/git-instructions.md\n- personal preferences @~\/.claude\/my-project-instructions.md\n<\/code><\/pre>\nThe second major addition is the .claude\/rules\/<\/code><\/strong> folder and its path-scoped rules<\/strong>. Instead of cramming every instruction into one CLAUDE.md, split rules into topic-specific markdown files with YAML frontmatter that activates them only when Claude touches matching paths:<\/p>\n---\npaths:\n - "src\/api\/**\/*.ts"\n - "lib\/**\/*.{ts,tsx}"\n---\n\n# API Development Rules\n- All API endpoints must include input validation\n- Use the standard error response format\n- Include OpenAPI documentation comments\n<\/code><\/pre>\nRules files with no path frontmatter load every time; ones with it activate only when Claude is working in matching files. This is critical for monorepos where different teams maintain their own rule sets. The claudeMdExcludes<\/code><\/strong> setting also lets you selectively disable ancestor-directory CLAUDE.md files.<\/p>\nThe third addition is AGENTS.md interoperability<\/strong>. Cursor, Codex, Aider and other agents read AGENTS.md; Claude Code only reads CLAUDE.md. The standard way to resolve the conflict now:<\/p>\n@AGENTS.md\n\n## Claude Code\nUse plan mode for changes under `src\/billing\/`.\n<\/code><\/pre>\nSame instruction set shared across all your agent tools; the short Claude-specific section adds the extras. On the slash-command side: \/init<\/code><\/strong> drafts the file, \/memory<\/code><\/strong> lists currently loaded files and lets you edit them, and the InstructionsLoaded<\/code> hook<\/strong> lets you debug what loaded when. Setting CLAUDE_CODE_NEW_INIT=1<\/code> turns \/init<\/code> into an interactive multi-phase flow: a subagent inspects the repo, asks you about gaps, and proposes a reviewable file before writing.<\/p>\n \n<\/span>Karpathy’s Idea File Approach (April 2026)<\/span><\/h2>\nOn 3 April 2026, Karpathy proposed a new sharing format on X and then in a GitHub gist: the “idea file”<\/em>. Classic open source is built on sharing code; an idea file shares the idea, and the other side’s agent rebuilds it for their environment<\/strong>. The reasoning was simple: in 2026 \u2014 with agent models strong enough \u2014 copying intent<\/strong> is more efficient than copying code pixel-by-pixel.<\/p>\nThe concrete shape is a three-layer structure. Layer one is the raw\/<\/code> folder: papers, articles, images, datasets land here. The LLM reads but never modifies<\/strong> this folder \u2014 sources are immutable and verifiable. Layer two is the wiki\/<\/code> folder: LLM-produced summary pages, concept pages and entity pages live here, cross-referenced and growing cumulatively<\/strong> instead of being re-derived per query. Layer three is the CLAUDE.md<\/code> file (alternatively AGENTS.md<\/code> or OPENCODE.md<\/code>), which defines the schema<\/strong> of the whole system and how it’s maintained.<\/p>\nThe system runs three operations. Ingest:<\/strong> when a new source lands in raw\/<\/code>, the LLM reads it and simultaneously updates 10\u201315 wiki pages, keeps an index and an activity log. Query:<\/strong> questions go through the structure; valuable answers get filed back as new pages so knowledge compounds. Lint:<\/strong> periodic health checks surface contradictions, orphan pages, missing concepts and suggested reviews. Karpathy ties this to Vannevar Bush’s 1945 Memex concept<\/strong>; Bush’s unsolved “who maintains it?” question is finally answered by LLMs.<\/p>\nThis architecture diverges from classic RAG (Retrieval-Augmented Generation) on one core point. RAG goes back to sources and synthesises on every query; the idea file approach compiles knowledge once and keeps it fresh<\/strong>, rather than re-deriving each time. In Karpathy’s words: “The knowledge is compiled once and then kept current, not re-derived on every query.”<\/em> CLAUDE.md is the schema file that turns a generic chatbot into a disciplined wiki maintainer<\/strong>.<\/p>\n \n<\/span>How to Write an Effective CLAUDE.md (2026 Standards)<\/span><\/h2>\nFour principles from Anthropic’s own docs form the core of effective CLAUDE.md writing. Size:<\/strong> keep the file under 200 lines; longer files consume more context and reduce adherence. If instructions grow, split via path-scoped rules or imports. Structure:<\/strong> instructions grouped under markdown headings and bullets are far more scannable than loose paragraphs; Claude reads like a human. Specificity:<\/strong> write verifiable, concrete instructions. “Format code properly”<\/em> \u2192 “Use 2-space indentation”<\/em>; “Test your changes”<\/em> \u2192 “Run npm test<\/code> before committing”<\/em>; “Keep files organised”<\/em> \u2192 “API handlers live in src\/api\/handlers\/<\/code>“<\/em>. Consistency:<\/strong> when instructions conflict, Claude picks one at random; review and refresh CLAUDE.md and nested CLAUDE.md files periodically.<\/p>\nWhen should something go into CLAUDE.md? Anthropic’s guidance is blunt: “Treat CLAUDE.md as the place you write down what you’d otherwise re-explain.”<\/em> If Claude makes the same mistake twice, if a convention caught in code review is something Claude also needs to know, if you find yourself writing the same correction you wrote last session, or if a new teammate would need a piece of context to be productive \u2014 all of those are CLAUDE.md entries. Multi-step procedures or rules that apply to only a corner of the codebase belong in a skill<\/strong> or a path-scoped rule<\/strong>, not in CLAUDE.md itself.<\/p>\nThe template below is the minimum functional starting point for a 2026 CLAUDE.md. Copy it directly into your project:<\/p>\n # Project Name\n\n## What this is\nOne-paragraph summary of what the project does and why it exists.\n\n## Tech stack\n- Language: Python 3.12 \/ TypeScript 5.4\n- Framework: FastAPI \/ Next.js 15\n- DB: PostgreSQL 16\n- Tests: pytest + httpx \/ vitest\n\n## Commands\n- Install: `uv sync` \/ `pnpm install`\n- Run dev: `uv run uvicorn app.main:app --reload` \/ `pnpm dev`\n- Test: `uv run pytest -x` \/ `pnpm test`\n- Lint: `uv run ruff check .` \/ `pnpm lint`\n- Typecheck: `uv run mypy app\/` \/ `pnpm typecheck`\n\n## Conventions\n- Type hints everywhere\n- Public functions: docstrings (Google style)\n- Tests live in `tests\/` matching `app\/` structure\n- No global state \u2014 pass dependencies explicitly\n\n## Don't\n- No emoji in code or commits\n- No `print()` for debug \u2014 use `logger.debug()`\n- No new dependencies without justifying in PR description\n- Don't write code comments that just restate what code does\n\n## Common pitfalls\n- DB migrations: run `alembic upgrade head` after pulling\n- The `vendor\/` folder is git-tracked but not editable\n- `pytest` requires `.env.test` (copy from `.env.test.example`)\n\n## Architecture in 3 lines\n- Request \u2192 middleware (auth) \u2192 router \u2192 service \u2192 repository \u2192 DB\n- Async I\/O end-to-end with `asyncpg`\n- Background jobs in `app\/jobs\/` use `arq` (not Celery)\n\n## Imports\n@README.md\n@docs\/architecture.md\n@AGENTS.md\n<\/code><\/pre>\nTwo extra pieces of advice from Karpathy’s practice: first, the “AI is a junior dev with infinite enthusiasm”<\/em> analogy \u2014 the AI agent is like a talented but amnesiac junior developer who needs the morning briefing each day; CLAUDE.md is that briefing in writing. Second, the “living memory”<\/em> principle: the file shouldn’t be a write-once-and-forget README \u2014 it should grow with every new mistake the AI makes.<\/p>\n \n<\/span>CLAUDE.md vs Cursor Rules vs ChatGPT Custom Instructions<\/span><\/h2>\nThe three main AI coding tools store developer context in different ways. As of 2026 Claude Code’s CLAUDE.md system<\/strong> is the richest and most hierarchical \u2014 managed\/project\/user\/local + path-scoped rules + auto memory + imports. Cursor<\/strong> offers a similar structure with markdown + YAML frontmatter inside .cursor\/rules\/<\/code>, but lacks a user-level shared scope. ChatGPT Custom Instructions<\/strong> is tied to your OpenAI account, stored in the cloud, and consists of two free-text fields \u2014 no project context support.<\/p>\n\n\n\n| Dimension<\/th>\n | CLAUDE.md (Claude Code)<\/th>\n | Cursor Rules<\/th>\n | ChatGPT Custom Instructions<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Location<\/td>\n | Repo + user + managed (org)<\/td>\n | .cursor\/rules\/*.md<\/code><\/td>\n| OpenAI account (cloud)<\/td>\n<\/tr>\n | \n| Hierarchy<\/td>\n | 4 scopes + nested + auto memory<\/td>\n | Project only<\/td>\n | User only<\/td>\n<\/tr>\n | \n| Format<\/td>\n | Markdown + YAML frontmatter (rules)<\/td>\n | Markdown + YAML frontmatter<\/td>\n | Plain text (2 fields)<\/td>\n<\/tr>\n | \n| Imports<\/td>\n | @path<\/code> 5-hop recursive<\/td>\n| Limited<\/td>\n | None<\/td>\n<\/tr>\n | \n| Path-scoped rules<\/td>\n | \u2705 .claude\/rules\/<\/code> + paths glob<\/td>\n| Partial<\/td>\n | \u274c<\/td>\n<\/tr>\n | \n| Auto memory<\/td>\n | \u2705 v2.1.59+<\/td>\n | \u274c<\/td>\n | \u274c<\/td>\n<\/tr>\n | \n| AGENTS.md interop<\/td>\n | \u2705 @AGENTS.md<\/code> import<\/td>\n| \u274c<\/td>\n | \u274c<\/td>\n<\/tr>\n | \n| Version control<\/td>\n | Yes (in Git)<\/td>\n | Yes (in Git)<\/td>\n | No (cloud-only)<\/td>\n<\/tr>\n | \n| Team sharing<\/td>\n | Yes<\/td>\n | Yes<\/td>\n | No<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The practical takeaway: if you use all tools in the same project, write CLAUDE.md as the master source<\/strong>, import AGENTS.md from it, and copy 1:1 into .cursor\/rules\/<\/code> for Cursor. Put personal preferences only<\/strong> into ChatGPT Custom Instructions (e.g. “Reply in English, code comments in English”) \u2014 project details don’t belong there because they apply to every project in your account.<\/p>\n \n<\/span>Practical Tips for Turkish Developers<\/span><\/h2>\nCLAUDE.md adoption spread quickly across Turkey’s developer community from late 2025. You see it in side projects opened on GitHub by Insider, Trendyol, Hepsiburada, Getir and others. The shared rule across those projects is language consistency<\/strong>: code comments, error messages and docstrings should be in English; user-facing documentation can be in Turkish; PR descriptions are bilingual. A single line in CLAUDE.md does it: “Code comments, docstrings, error messages: English. Documentation in docs\/<\/code>: Turkish. PR descriptions: bilingual.”<\/em><\/p>\nThe second issue you encounter in Turkish projects is encoding and locale<\/strong>. UTF-8 file encoding (no BOM), utf8mb4_unicode_ci<\/code> database collation, and explicit tr_TR.UTF-8<\/code> for locale-sensitive sort tests are standard practice. Without that small note the classic “i \/ \u0130 \/ \u0131 \/ I”<\/em> trap keeps producing bad results. The third critical block is regulation and local business rules<\/strong>: KVKK compliance (don’t log TC ID numbers), e-fatura inside the eFatura.NS<\/code> namespace, TL pricing format adhering to f\"{amount:,.2f} \u20ba\"<\/code> \u2014 none of which the AI can infer on its own.<\/p>\nA final tip: version CLAUDE.md with your team<\/strong>. Keep it on main<\/code> and review every change in PR. A rule one developer adds becomes the team’s instant standard because the AI always reads the latest version. This is the foundation of the recent shift in Turkish engineering teams toward codifying technical standards together with the AI<\/strong>.<\/p>\n | | | | |
|