A CLAUDE.md beállítása 2026-ban: sablon és 6 szabály

Anyagok a vibe codingról: eszközök, esettanulmányok, hibák. Ailoot útmutatók.

Miért van szükséged CLAUDE.md-re, és miért felejti el Claude nélküle a projektet?#

Kedden megnyitod a Claude Code-ot, és elmagyarázod: „Ezen a projekten dolgozom, ezek az eszközök, ezt ne csináld.” Működik.

Csütörtökre az a csevegés már véget ért, ezért mindent megismételsz. Szombaton újra; hétfőn még egyszer.

Ilyen CLAUDE.md nélküli ügynökkel dolgozni: minden új ablak egy üres lappal induló gyakornok, akinek újra és újra ugyanazt kell elmondanod. Régebben minden munkamenet elején 5-10 percet töltöttem ezzel a bevezetővel. A promptok egyre hosszabbak lettek, mert minden kontextust kézzel kellett megadnom. Az eredmény mégis általános maradt: az ügynök nem ismerte a közönségemet, a gazdasági hátteremet vagy az elveimet.

Egy folyamatosan karbantartott CLAUDE.md-vel eltűnik a bevezető kör. Minden szabály, amelyet korábban minden csevegésben megismételtél, egyetlen fájlba kerül, és automatikusan megjelenik minden munkamenet elején. A prompt rövid lesz: „csináld meg az X-et”, ahelyett, hogy „az Y projekten dolgozom, a Z eszközöket használjuk, ne csináld az A-t vagy a B-t, és egyébként a C-re is emlékezz”.

Ezzel megszűnnek az ismétlődő hibák.

Minden ügynöki hiba ok arra, hogy egy sort adj a CLAUDE.md-hez. Egy hónap múlva már élő „projektalkotmányod” van, Claude pedig nem esik bele újra és újra ugyanazokba az ismerős csapdákba.

Van egy harmadik réteg is: az ügynök többé nem légüres térben ír. A CLAUDE.md segítségével olyan mappákba irányítom Claude-ot, amelyekben háttér-információ található: hol keresse a közönséggel, az árazással és a márkával kapcsolatos adatokat. E nélkül az irányítás nélkül az ügynök „minőségi megoldásokat” ír anélkül, hogy ismerné a gazdasági hátteremet, ezért az eredmény elvont, sablonos és „pont olyan, mint mindenki másé”.

Mi az a CLAUDE.md, és milyen sorrendben olvassa Claude?#

Az Anthropic így írja le a CLAUDE.md-t a hivatalos dokumentációjában:

A Claude Code az alábbi négy helyen keresi a CLAUDE.md-t, növekvő prioritási sorrendben:

Mind a négy fájl egyszerre töltődik be a kontextusba. Ha a szabályok ütköznek, az Anthropic dokumentációja nyíltan kimondja, hogy nem tudni, melyik élvez elsőbbséget; Claude akár véletlenszerűen is választhat közülük. Ezért egyszerűbb minden kritikus dolgot a projekt CLAUDE.md-jében tartani, és kerülni a duplikációkat.

Van egy technikai részlet, amelyről szinte senki nem ír, pedig sok furcsa viselkedést megmagyaráz.

Más szóval, a CLAUDE.md szigorú értelemben nem „rendszerprompt”. Ez az első felhasználói üzenet, amelyet Claude lát. A szabályai tehát erős javaslatok, nem törvények. Ha egy szabályt ki kell kényszeríteni, a lefedett eseményhez tesztelt hookot, a szélesebb hozzáférési határhoz pedig jogosultságokat vagy környezeti elkülönítést használj. A hook automatikus futása nem teszi teljessé az ellenőrzéseit. Alább elmagyarázom a hooks és a CLAUDE.md közötti határt.

Hogyan írj meg 5 perc alatt egy minimális CLAUDE.md-t (használatra kész sablon)?#

Az alábbi sablont több tucat projekten teszteltem. A fájl körülbelül 80-120 soros marad, az Anthropic azon ajánlását követve, hogy érdemes 200 sor alatt maradni. Ezzel a sablonnal adja az ügynök a legértelmesebb eredményeket.

# [PROJECT NAME] - project navigation

This document is the project map. Read it at the start of every session
to understand where things are and how to work with them.

## What this project is

**[NAME]** - [one sentence: what it is and who it’s for].
[1-2 sentences: what problem it solves and how].

Details are in `business/INDEX.md`.

## Reading order at the start of every session

1. `about-me/INDEX.md` - who I am and how I think
2. `business/INDEX.md` - what we do (product, audience, economics)
3. `CLAUDE.md` (this file) - repo rules, tools, navigation
4. Task area: the relevant file from `business/`, `plans/<current plan>`,
   `mastery/<area>` or the feature folder in the code

Principle: layer 1 (about me) comes before layer 2 (business) for a reason.
First, **who** is thinking, then **about what**.

## Repository structure

[NAME]/
├── CLAUDE.md            ← this file, navigation
├── about-me/            ← digital projection of you (how you think, what you value)
│   └── INDEX.md
├── business/            ← the business’s second brain
│   ├── INDEX.md
│   ├── audience/        ← customer profile
│   ├── products/        ← products, prices
│   ├── goals/           ← goals, metrics
│   └── economics/       ← unit economics, revenue
├── plans/               ← technical plans (one plan = one feature)
├── retrospectives/      ← reflections after each session
└── (project code)

### Where to find things

| What you need | Where to look |
|---|---|
| Why we’re building the project, and for whom | `business/INDEX.md` |
| Target customer, pains, desires | `business/audience/` |
| Product, plans, prices | `business/products/` |
| Goals and metrics | `business/goals/` |
| Economics | `business/economics/` |
| Technical plans | `plans/` |

## Tools

[INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL].

## Repo rules

1. Never hardcode dynamic data (prices, dates, figures) -
   get everything from files in `business/` and the LIVE marker.
2. Don’t publish without my explicit command.
3. Before `git push`, run `npm run build` and check that it
   builds without errors or warnings.
4. Add files by name with `git add`. Never use `git add .` or `git add -A`.
5. Don’t read `.env` in full. To check a variable, use
   `grep "^VAR=" .env`.

## Big features = a plan in `plans/`

Any task lasting more than an hour must be written up as a plan in the `plans/` folder:
1. Filename: `YYYY-MM-DD-feature-name.md`.
2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`.
3. At the end of the plan, add a summary: whether it was fully implemented and what remains.

## End-of-feature cycle

After each feature is complete, go through these 5 steps:
1. Find errors → prove them with an example → fix them.
2. What was missed (edge cases, input validation, error handling).
3. Is this a real problem in our project? Check `business/` and `plans/`.
4. Take a fresh look: reread the diff as if you’re seeing it for the first time.
5. Security review. Especially: personal data and third-party materials.

## End-of-session reflection

In `retrospectives/YYYY-MM-DD_short-name.md`, record:
1. What the task was.
2. How it was solved.
3. Whether it was solved - yes / no / partially.
4. What could have been done better.
5. What was learned about the user or project.

## Language

Always respond in the user’s preferred language. Use hyphens only, not em dashes.

Ahhoz, hogy Claude automatikusan kitöltse ezt a sablont a projektedhez, add neki ezt a promptot. Elolvassa a kontextust, és kitölti a szögletes zárójelben lévő mezőket:

Hozz létre egy CLAUDE.md fájlt a projekt gyökerében az alábbi sablon alapján:

[ILLESZD BE IDE A TELJES FENTI SABLONT]

A következőképpen járj el:

Olvasd el az about-me/INDEX.md és a business/INDEX.md fájlokat, hogy megértsd a projekt kontextusát és engem, a szerzőt.

A mappákban talált információk alapján töltsd ki a sablon összes szögletes zárójelben lévő mezőjét.

Ha hiányzik valamilyen információ, tegyél fel nekem tisztázó kérdéseket egyesével, mindegyikhez 3-4 válaszlehetőséggel.

Törekedj arra, hogy a létrejött CLAUDE.md 200 sor alatt maradjon. Ha hosszabb, vizsgáld meg az ismétléseket, és a részletes eljárásokat helyezd hivatkozott fájlokba. Őrizd meg a tervezés, a visszatekintés és a repo alapvető szabályait, majd teszteld őket jellemző feladatokon.

Mutasd meg a végleges fájlt, és kérdezd meg, min kellene módosítani.

Mindig a felhasználó által előnyben részesített nyelven válaszolj.

Ha még nincs about-me/ és business/ mappád, az sem gond. Claude tisztázó kérdéseket tesz fel, és a rendelkezésre álló információk alapján összeállít egy minimális CLAUDE.md-t. A mappákat később is létrehozhatod, amikor már tudod, mit tegyél beléjük.

Melyik 6 szabály teszi élő dokumentummá a CLAUDE.md-t?#

1. szabály. Maradjon 200 sor alatt

Az Anthropic hivatalos dokumentációja tömören fogalmaz:

A hosszú CLAUDE.md kétféleképpen dolgozik saját maga ellen. Először is tokeneket éget. Egy 800 soros utasításfájl minden ablakban betöltődik, és minden munkamenetben több ezer tokent használ fel a keretedből. Napi korlátos Pro-előfizetéssel ez érezhetően csökkenti az elérhető munkamenetek számát. Másodszor, a modell elkezdi figyelmen kívül hagyni a szabályokat.

A dokumentáció a kontextusfelhasználás csökkentése és az utasításkövetés javítása érdekében 200 sor alatti méretet javasol. Nem állapít meg éles hibahatárt a 201. sornál. Mielőtt eldöntöd, mit helyezz máshová, vizsgáld meg a relevanciát, az ellentmondásokat, a betöltött tokenmennyiséget és a tényleges feladateredményeket.

2. szabály. Minden munkamenetet zárj visszatekintéssel

Írd bele a CLAUDE.md-be: „Minden munkamenet végén jegyezd fel, mit csináltál és mit tanultál a retrospectives/YYYY-MM-DD_*.md fájlba.” Ha hozzáadod ezt a sort, Claude magától visszatekintéssel kezdi zárni a munkameneteket; nem kell külön kérned.

Miért érdemes visszatekinteni:

• Két hét múlva megnyithatsz egy régi visszatekintést, és felidézheted, miért azt az utat választottad.
• Ha egy hónap múlva térsz vissza a projekthez, kéznél lesz a közelmúltbeli döntések térképe.
• Ha csapatban dolgozol, egy munkatárs elolvashatja a visszatekintést, és hívás nélkül, 2 perc alatt megértheti az aktuális állapotot.

3. szabály. Minden befejezett feladat után készíts commitot

Az én CLAUDE.md-m ezt írja: „Minden befejezett feladat után készíts git commitot értelmes üzenettel.” Claude magától elkezdi atomi commitokra bontani a munkát.

Ezzel két dolgot nyersz. Először, ha valami elromlik, egyetlen műveletet tudsz visszavonni, nem pedig „mindent, amit ma csináltam”. Másodszor, a commitelőzmények munkanaplóvá válnak, amely megmutatja, mi és milyen sorrendben változott.

4. szabály. Mindig nézd meg a business/ mappát

Minden olyan feladatnál, amely ügyfeleket, termékeket vagy szöveget érint, az ügynök először nyissa meg a business/INDEX.md fájlt és az abban hivatkozott releváns fájlt. Az én CLAUDE.md-m ezt kifejezetten előírja: „UI- vagy szövegírási munka előtt nézd meg a business/audience/avatar.md és a business/assets/brand-guidelines.md fájlt.”

E szabály nélkül Claude „egy minőségi weboldal általános stílusában” ír szöveget. A szabállyal a szöveg a te stílusodban, a te ügyfelednek készül, a tiltott szavaid nélkül.

5. szabály. Minden ügynöki hiba után adj hozzá egy szabályt

Ez a legfontosabb szabály, amely életben tartja a CLAUDE.md-t.

Néhány példa az én CLAUDE.md-mből, amelyeket konkrét hibák után vettem fel:

• „Soha ne commitold mások WIP-fájljait a git add . használatával - a fájlokat név szerint vedd fel a staging területre.”
• „A main ágra történő push előtt ellenőrizd a git log origin/main..main --oneline kimenetét - ha nem üres, ne pusholj.”
• „Ne találj ki értékeket - a .env fájlból vagy a kódból vedd őket. Különösen az URL-eket, felhasználóneveket és tokeneket.”

E sorok mindegyike egy konkrét incidens nyoma. Egyszer egy ügynök commitolta egy munkatársam befejezetlen branchét. Egyszer másvalaki nem pusholt commitjait is belefoglaltam. Egyszer pedig egy ügynök kitalált egy nem létező URL-t. Minden hibából szabály lesz, és ugyanazt az önmagunknak okozott sérülést nem szenvedjük el még egyszer.

6. szabály. A biztonsági szabályokat a .claude/settings.json fájlba tedd, ne a CLAUDE.md-be

A CLAUDE.md-ben leírhatod, hogy „ne nyúlj a .env fájlhoz”, de ez csak kérés; Claude megszegheti, mert a CLAUDE.md felhasználói üzenetként töltődik be, nem törvényként. A kritikus biztonsági szabályokat a .claude/settings.json fájlban kezeld, ahol bizonyos parancsokat szigorúan letilthatsz.

A tiltólista, amelyet minden új projekthez hozzáadok:

• rm -rf (fájlok rekurzív törlése).
• A teljes .env beolvasása (Read .env).
• export és curl ugyanabban a parancsban (külső titokkiszivárogtatásra alkalmas minta).
• git push --force kifejezett jóváhagyás nélkül.

További útmutatókat az Ailooton találsz.

Hogyan épül fel a CLAUDE.md egy aktív vállalkozásnál (egy 280 soros fájl anatómiája)?#

A legtöbb online CLAUDE.md-példa fejlesztőknek szóló technikai sablon: „Használj TypeScriptet”, „Ne írj 50 sornál hosszabb teszteket.” Egy vállalkozónak az ilyen CLAUDE.md használhatatlan - nem foglalkozik az üzleti oldallal.

Alább a működő CLAUDE.md-m felépítése látható. Kivettem belőle a konkrét szabályokat és útvonalakat, mert belső működésemet tükrözik. A szakaszok szerkezete és logikája viszont bármely projektre alkalmazható: helyettesítsd be a saját körülményeidet, és kész a működő fájl.

1. Rövid projektleírás (15 sor). Mit csinálunk, kiknek szól, milyen termékeket kínálunk. Nem a marketingwebhely összefoglalója, hanem az ügynöknek szóló rövid leírás, hogy megértse, „merre tartunk”.

2. Rólam (10 sor). Hivatkozás az about-me/ mappára - annak digitális leképezése, ahogyan gondolkodom. Hangnem, értékek, elvek, tiltott szavak. Ha Claude „a nevemben” ír szöveget, először ezt a mappát olvassa el, hogy a hangvétel egyezzen.

3. A repository felépítése (20 sor). Megjegyzésekkel ellátott fa: hol van a kód, hol található az üzleti háttér, hol vannak a tervek és visszatekintések. E térkép nélkül Claude minden alkalommal vakon keresi a fájlokat.

4. „Hol találod?” táblázat (25 sor). Útválasztás a „kérdés → fájl” alapján. Egy ingatlanközvetítő iroda például azt írhatja: „jelzáloghitel feltételei → business/products/mortgage.md”, illetve „közösségi bejegyzések hangneme → business/assets/voice.md”. Cseréld le a saját fájljaidra. Ez a táblázat a CLAUDE.md szíve. Nélküle az ügynök találgatja, melyik fájl tartalmazza a választ. Vele egyből a forráshoz jut.

5. A projekt alapelvei (40 sor, 10-15 elem). Ez a szakasz lassan gyarapodik, és a legtöbb munkát igényli. Minden elem egy konkrét hiba nyoma. Egy online áruház szabályai például így szólhatnak: „soha ne hardcode-old az árakat és a szállítási időket”, „ne tegyél közzé terméket kifejezett utasítás nélkül”, „termékoldal közzététele előtt ellenőrizd a stílust a márkaglosszárium alapján”. Ez a rész a „projektalkotmány”.

6. Működési tervezés (20 sor). Olyan táblázat, amely a „felhasználó megfogalmazása → művelet” párokat rendeli egymáshoz. Például: „Amikor azt mondom, hogy »tervezd meg a hetet«, nyisd meg az ops/monthly.md fájlt, és hozd létre a hét fájlját.” Így Claude olyan operációs asszisztenssé válik, amely érti a parancsok kontextusát.

7. Eszközök (5 sor). Technológiák, röviden, sallang nélkül.

8. Közzététel (15 sor). A módosítások éles környezetbe történő közzétételének lépésről lépésre követhető folyamata: milyen parancsokat, milyen sorrendben kell futtatni, és mit kell ellenőrizni. Korábban minden alkalommal elmagyaráztam. Most Claude már tudja.

9-12. Biztonság (35 sor). Négy külön alrész: a .env használatának szabályai, hozzáférés az éles adatbázishoz, biztonságos parancsok demókhoz (képernyőfelvételek, közvetítések, képernyőképek, hogy a tokenek ne szivárogjanak ki véletlenül), valamint a titkok cseréjére vonatkozó szabályok.

13. A plans/ mappa (10 sor). A terv szabványa: fájlnév, fázisstruktúra és az összefoglaló blokk tartalma.

14. A retrospectives/ mappa (5 sor). A visszatekintés szabványa: sablon, fájlnév és elvárt tartalom.

15. Az éles adatbázis adatai (15 sor). Szabály a „friss adatok” jelölésére: ha egy fájl szerint az adatoknak naprakésznek kell lenniük, az ügynök a forrásból kéri le őket a régi adatok használata helyett. Így elkerülhető, hogy Claude a tegnapi adatokat használja.

16. Nyelv (3 sor). „Mindig a felhasználó által előnyben részesített nyelven válaszolj. Csak kötőjelet használj, gondolatjelet ne.”

Összesen körülbelül 280 sor. Ez meghaladja a tömörségi célértéket, de nem teszi érvénytelenné a fájlt. Ebben a példában továbbra is hasznos maradt; megtartását a mért kontextusfelhasználás és jellemző feladatellenőrzések alapján kell eldönteni. A táblázatok nem automatikusan olcsóbbak tokenben, mint a folyószöveg.

Mit csinál a /init parancs, és miért nem elég?#

Az Anthropic így ismerteti a parancsot a dokumentációjában:

Amiben a /init jól teljesít:

• Felismeri az eszközöket a package.json, a Cargo.toml és a pyproject.toml fájlokból.
• Felsorolja a build- és tesztparancsokat.
• Átveszi a meglévő fájlok konvencióit (.eslintrc, .prettierrc).
• Észreveszi a meglévő Cursor-szabályokat (.cursorrules, .cursor/rules/) és Copilot-szabályokat, majd beemeli a releváns részeket. A CLAUDE_CODE_NEW_INIT=1 módban az AGENTS.md-t is felismeri.

Amire a /init nem képes:

• Nem tudja, ki az ügyfeled.
• Nem veszi fel a szövegíráshoz tiltott szavaidat.
• Nem hoz létre szabályokat az ügynöki hibákról (mert ilyen még nem történt).
• Nem készít „hol találod?” táblázatot az üzleti struktúrádhoz.

A helyes munkafolyamat tehát a következő:

1. Futtasd a /init parancsot a Claude Code-ban

   Kapsz egy 30-50 soros kezdő CLAUDE.md-t eszközökkel és parancsokkal. Ez a technikai alap.

2. Egészítsd ki a cikk sablonjával

   Használd „A minimális CLAUDE.md 5 perc alatt” című szakaszt. Adj hozzá navigációs, útvonalválasztási és alapelveket tartalmazó szakaszokat.

3. Töltsd ki a szögletes zárójelben lévő mezőket

   Add Claude-nak a következő promptot: „olvasd el a projektemet, és töltsd ki a sablont”. Ha még nem létezik a business/ és az about-me/ mappa, Claude tisztázó kérdéseket tesz fel.

4. Végezz stressztesztet

   Mondd Claude-nak: „Olvasd el a CLAUDE.md-met, és keress 10 kétértelműséget, amely miatt ügynökként félreérthetnél valamit.” Kapsz egy javítási listát.

5. Ezután használd a fájlt

   Minden ügynöki hiba után adj hozzá egy sort. Egy hónap múlva már a vállalkozásodra szabott, folyamatosan karbantartott CLAUDE.md-d lesz.

Prompt a negyedik lépéshez:

Van egy CLAUDE.md fájlom. Holnap ez alapján fogok fejleszteni egy funkciót.

A feladatod a fájl stressztesztelése. Keress 10 lehetséges hibaforrást:

hol kétértelmű a CLAUDE.md, és hol érthetnéd félre ügynökként

hol vannak hiányosságok, amelyek miatt ki kellene találnod dolgokat

hol mondanak ellent egymásnak a szabályok

hol becsülöm túl, hogy mennyi fér bele egy napba

hol becsülöm alá a szükséges munkát (ez még rosszabb)

Ne fogd vissza magad. Légy kíméletlenül kritikus. Most szeretném megtalálni ezeket a problémákat, nem éles használat közben.
A végén adj konkrét módosítási listát: mit és hogyan kell megváltoztatni, hogy ezek a problémák ne forduljanak elő.

CLAUDE.md vs AGENTS.md vs MEMORY.md: ki mit olvas 2026-ban?#

A kezdőket leginkább az zavarja össze, hogy olvassa-e a Claude Code az AGENTS.md-t? 2026 szeptembere előtt a válasz „nem” volt: az Anthropic dokumentációja azt javasolta, hogy hozz létre egy CLAUDE.md-t, amely importálja az AGENTS.md-t. A 2.1.277-es verzió óta (kiadva 2026. szeptember 18-án) a Claude Code önállóan is beolvassa az AGENTS.md-t, de csak akkor, ha a munkamappában vagy valamelyik szülőmappájában nincs CLAUDE.md, .claude/CLAUDE.md vagy CLAUDE.local.md.

Ha a projektben van CLAUDE.md, a Claude Code alapértelmezés szerint csak azt olvassa be, az AGENTS.md-t kihagyja. Ezt a /config beállításai között, a Project instructions résznél módosíthatod: például a claude-md-and-agents-md beállítással mindkét fájlt beolvassa. Egy másik megoldás bármelyik verzióban működik: adj importhivatkozást a CLAUDE.md-hez:

@AGENTS.md

## Claude Code

További szabályok a Claude Code számára, amelyekre más ügynököknek nincs szükségük.

A @filename szintaxis egy másik fájl importálására szolgál. Claude beolvassa, és a CLAUDE.md-vel együtt betölti a kontextusba. Az import miatt a fájlt nem olvassa be kétszer, akkor sem, ha a Claude Code önállóan is képes az AGENTS.md beolvasására.

Mikor van szükséged AGENTS.md-re? Ha a Claude Code-dal párhuzamosan Codex CLI-t, Cursort vagy Copilotot is használsz, hozz létre egy AGENTS.md-t, mint egyetlen hiteles forrást, írd be a CLAUDE.md-be az @AGENTS.md hivatkozást, majd egészítsd ki a Claude-ra vonatkozó speciális szabályokkal. Ha nincsenek ilyen szabályok, nem kell CLAUDE.md-t létrehoznod: a 2.1.277-es verziótól a Claude Code önállóan beolvassa az AGENTS.md-t. Ha csak Claude Code-ot használsz, nincs szükséged AGENTS.md-re; elég egyetlen CLAUDE.md. Az összes lehetőség lépésenkénti bemutatását lásd az AGENTS.md és CLAUDE.md együttes használatáról szóló útmutatóban.

Mi az a MEMORY.md? Egy nemrég bevezetett frissítés óta a Claude Code automatikusan jegyzeteket készít rólad a ~/.claude/projects/<project-name>/memory/MEMORY.md fájlba. Ilyenek például a beszélgetési szokások („a felhasználó a rövid válaszokat kedveli”), a visszatérő kérések („ne használj emojit a kódban”) és a viselkedésre vonatkozó megfigyelések („macOS-en dolgozik, zsh-t használ”).

Ez különálló memóriarendszer, nem CLAUDE.md. Nem kézzel írod; Claude készíti a beszélgetéseitek alapján. Ha a MEMORY.md olyasmit tartalmaz, aminek szabállyá kell válnia, tedd át a CLAUDE.md-be. Ha valami fölösleges vagy hibás van benne, kézzel törölheted; szövegfájlról van szó.

Mekkora CLAUDE.md hasznos, és hogyan vizsgálj felül egy hosszú fájlt?#

Minden Claude Code-ablakban több réteg töltődik be a kontextusba: az Anthropic rendszerpromptja (becslések szerint több tízezer token), a CLAUDE.md, a @-tal importált fájlok, a MEMORY.md, az aktuális csevegés előzményei és a Claude által megnyitott fájlok tartalma. Mindeznek bele kell férnie a modell kontextusába (200K token a Sonnet, 1M az Opus esetében).

Minél nagyobb a CLAUDE.md, annál kevesebb hely marad az aktuális munkára. Egy 1,000 soros fájl körülbelül 8,000 token, és minden munkamenetben újra betöltődik. Pro-előfizetéssel (tapasztalatom szerint naponta körülbelül 10-12 „nehéz” prompttal) ez negyedével csökkenti a kapacitásodat.

A költség csak az egyik szempont. Az utasításkövetés romolhat, ha az utasítások hosszúak, irrelevánsak vagy ellentmondásosak; nincs általánosan érvényes szám a megbízhatóan követett utasításokra. Tesztelj néhány jellemző feladatot a kritikus szabályokkal, rögzítsd a hibákat, és egy célzott szerkesztés után hasonlítsd össze a viselkedést.

Íme a méretre vonatkozó ökölszabály:

• 80-120 sor - kényelmes kezdőtartomány egy tömör projekttérképhez, nem garantált utasításkövetési pontszám.
• 150-200 sor - hasznos jelzés a relevancia átnézésére és a részletes eljárások hivatkozott fájlokba helyezésére.
• 200-300 sor - vizsgáld meg a tokenmennyiséget, az ismétléseket és a feladateredményeket; a fenti 280 soros üzleti példa még jól működhet.
• 400+ sor - nyomós ok egy célzott felülvizsgálatra, nem bizonyíték a használhatatlanságra. Az alapvető korlátokat őrizd meg, és a részleteket csak a hivatkozások és szabályok működésének ellenőrzése után helyezd máshová.

A sorszám önmagában nem bizonyít sikert vagy kudarcot. Szerkesztés után ugyanazokat a jellemző feladatokat ismételd meg, és a fontos szabályokat ellenőrizd kitalált megfelelési százalékok helyett.

Az Anthropic közvetlen tesztet ad a dokumentációjában:

Alkalmazd ezt minden sorra. Ha a válasz az, hogy „így is jól csinálná”, töröld a sort. A CLAUDE.md nem dokumentáció, döntéstörténet vagy filozófia tárolására való. Csak azokat a szabályokat tartsd benne, amelyek segítenek az ügynöknek elkerülni a hibákat.

Melyik 7 hiba teszi használhatatlanná a CLAUDE.md-t?#

1. hiba. „Legyél jó mérnök”

A leggyakoribb hiba. Az emberek általános kívánságokat írnak a CLAUDE.md-be: „írj tiszta kódot”, „alkalmazd a bevált gyakorlatokat”, „gondolkodj vezető mérnökként”.

Ezek a szavak nem jelentenek semmit. Claude általános értelemben már most is „tiszta kódot” ír. Ezek a sorok helyet foglalnak a kontextusban, de nem befolyásolják a döntéseket.

A „írj tiszta kódot” helyett írd ezt: „használj 2 szóköznyi behúzást”, „ne használj any-t TypeScriptben”, vagy „a függvények legfeljebb 30 sorosak lehetnek”. Konkrét és ellenőrizhető szabályok.

2. hiba. Olyan dolgok megkettőzése, amelyeket Claude már tud

A programozási nyelvek szokásos konvencióinak leírásai („a JavaScriptben a függvények első osztályú állampolgárok”, „a TypeScript statikus típusosságot használ”). Magyarázatok arról, hogyan működik az npm, a git vagy a docker.

Claude mindezt megtanulta a betanítása során. A CLAUDE.md-ben való megismétlésük nem ad hozzá semmit; csak csökkenti a kontextusod számára rendelkezésre álló helyet.

3. hiba. Hosszú, lépésenkénti utasítások a CLAUDE.md-ben

Hosszú utasítások arról, „hogyan kell telepíteni a projektet”, „hogyan kell adatbázis-migrációt írni” vagy „hogyan kell új komponenst beállítani”. Több tucat lépésről lépésre leírt sor.

Ez nem hosszú, részletes útmutatók helye, hanem az egysoros szabályoké. A részletes utasításokat tedd a skills/ mappába (ez egy külön Claude Code-mechanizmus, amely igény szerint töltődik be) vagy a docs/ mappába. A CLAUDE.md-ben elég egy egysoros hivatkozás: „Új migráció létrehozásakor nyisd meg a docs/migrations.md fájlt.”

4. hiba. Olyan szabályok, amelyeket már automatikus kódelemző ellenőriz

„Használj pontosvesszőt”, „ne hagyj használaton kívüli importot”, „ne használj var-t.” Az ESLint, a Prettier és a Biome mindegyiket felismeri - ezek linterek, vagyis automatikus kódellenőrző eszközök.

A linter determinisztikus: lefut, megtalálja a hibát, és kijavítja. A CLAUDE.md szabálya valószínűségi; az ügynök megfeledkezhet róla. Fölösleges megismételni - egyszerűbb beállítani a lintert.

5. hiba. Titkok a CLAUDE.md-ben

Láttam már tesztfiók-jelszavakat, sandbox API-tokeneket és hitelesítést igénylő adminfelületekre mutató hivatkozásokat. Mindez olyan fájlban volt, amelyet commitoltak a gitbe, és betöltöttek az Anthropic modelljének kontextusába.

Soha ne tedd ezt. A titkok a .gitignore által kizárt .env fájlba valók. A CLAUDE.md legfeljebb ennyit írjon elő: „Ne olvasd be teljes egészében a .env fájlt; egy adott változóhoz használj grep-et.”

6. hiba. Több mint 500 soros gyűjtőfájl, amelyet hat hónapja nem tisztítottak meg

A CLAUDE.md egyre csak nő, megkettőzi a docs/ tartalmának felét, több ponton ellentmond önmagának, és már senki nem emlékszik, mit tartalmaz. Az ügynök elkezdi figyelmen kívül hagyni a szabályok nagy részét. A csapat azt panaszolja, hogy „Claude nem követi az utasításokat”, és még több szabályt ad hozzá, ezzel tovább rontva a helyzeten.

Az elhanyagolt CLAUDE.md jelei: több mint 300 sor, különböző szakaszokban ismétlődő szabályok, már nem létező fájlokra mutató elavult hivatkozások, valamint olyan „történeti” jegyzetek, mint „2024-ben így döntöttünk, aztán meggondoltuk magunkat”.

A megoldás: kéthetente kérd meg Claude-ot, hogy az Anthropic tesztje alapján vizsgálja át: „Ha ezt a sort törölnénk, hibázna az ügynök?” Törölj mindent, amelyre a válasz „nem”.

7. hiba. Létrehozták a CLAUDE.md-t, aztán elfelejtették

Ez az előző hiba ellentéte. A fájlt egyszer, két hónapja állították össze, és azóta hozzá sem nyúltak. Közben megváltoztak az eszközök, új mappák jöttek létre, és új ügynöki hibák merültek fel. A CLAUDE.md ezekről semmit sem tud, mert senki nem frissítette.

Árulkodó jel, ha minden munkamenetben ugyanazt az utasítást ismétled: „Ne csináld az X-et”, „ne nyúlj az Y-hoz”, „ne felejtsd el a Z-t.” Ha már több mint kétszer elmondtad, akkor ennek a szabálynak a CLAUDE.md-ben a helye, nem a fejedben.

Hogyan tanítható önállóan a CLAUDE.md egy „munkamenet végi frissítés” szabállyal?#

A CLAUDE.md-mben van egy rövid szakasz:

## Self-learning

At the end of every session, check:
- Have I learned anything new about the user or how to work with them?
- Did I break any rule that should now be recorded?

If so, create or update a file in `about-me/feedback/` in this format:
Rule (one-line rule) → Why (why it was added)
→ How to apply (when it applies).

I don’t write the rules by hand - I say, “not like that, because this is how,”
and you put it into a file.

Miután ez a szakasz bekerült a CLAUDE.md-be, Claude minden munkamenet végén elkezdte megkérdezni: „Volt valami új, amit érdemes feljegyezni?” Ha igen, javasolt egy szabálytervezetet, én pontosítottam, és létrejött egy fájl.

Két hónapnyi ilyen munka után több mint két tucat fájlom van az about-me/feedback/ mappában - konkrét hibákból levont szabályokkal. Minden fájl egyetlen oldalnyi anyag a Szabály → Miért → Hogyan formátumban. A mappa a „második memóriámmá” vált, amely a személyes preferenciáimat és tabukat rögzíti.

A hibák nem ismétlődnek, mert szabállyá válnak, a szabályok pedig gyűlnek és erősítik egymást. Hat hónap után Claude jobban ismeri a projektemet, mint amennyire egy hónapos szünet után én emlékeznék rá.

Hogyan adj hozzá jogi, marketing- és működési szabályokat a CLAUDE.md-hez?#

A legtöbb csapatnál a CLAUDE.md tisztán technikai dokumentum: eszközök, buildparancsok, kódolási konvenciók. Ez hasznos, de az értékének csak egyharmada.

Ha egy vállalkozó tartja karban a CLAUDE.md-t, érdemes üzleti részekkel kiegészíteni. Három a legfontosabb:

Jogi szabályok (szabályozott piacokra)

Ha szabályozott iparágban teszel közzé szöveget (pénzügy, egészségügy, gyógyszerreklám, gyermektermékek), a tiltott szavaknak jogi jelentőségük van, és kifejezett szabályként kell szerepelniük a CLAUDE.md-ben. Ne valakinek a fejében, ne egy szerkesztő képernyőképén, hanem olyan fájlban, amelyet az ügynök minden munkamenetben lát.

Példa egy banki engedéllyel nem rendelkező fintechprojekthez:

Szerkesztői megjegyzés: Az alábbi példa egy adott projektre vonatkozó belső szabály formátumát mutatja be. Nem jelent általános engedélyt a felsorolt kifejezések használatára: az elfogadhatóság az alkalmazandó jogtól és a vállalat státuszától függ.

🚨 KRITIKUS - a pénzügyi megfogalmazások használata tilos. Ügyfeleknek szóló anyagokban ne használd ezeket: „betét”, „garantált hozam” vagy „befektetési termék”. Helyettük használd ezeket: „megtakarítási számla”, „várható hozam” és „változó kamatozású termék”. Ennek oka a projekt pénzügyi szolgáltatások reklámozására vonatkozó jogi követelménye.

Ez a CLAUDE.md-blokk egyszerű dolgot tesz: minden alkalommal, amikor arra kéred Claude-ot, hogy ügyfeleknek szóló szöveget írjon, az ügynök összeveti azt ezekkel a tiltásokkal. A szabály nélkül minden harmadik kampányban megjelennek a tiltott szavak. A szabállyal el is felejted, hogy léteznek.

Ugyanez a megközelítés működik az alábbiaknál:

• Egészségügyi projektek (ne állítsd, hogy valami „kezel” vagy „meggyógyít”).
• Gyógyszerreklám (ne állítsd, hogy valami „a leghatékonyabb”; kötelező figyelmeztetések).
• Bármely szabályozott iparág, amelynek saját reklámozási szabályai vannak.

Marketingstílus és szövegformátum

Ha rendszeresen teszel közzé szövegeket (közösségi média, hírlevelek, weboldalak), érdemes egy bekezdésben dokumentálni a formátumot a CLAUDE.md-ben. Íme egy példa arra, mit írhat egy üzenetküldő csatornát kezelő influenszer vagy ügynökség:

Csatornaposztok írásakor nézd meg a style/posts.md fájlt. Használd a csatornán engedélyezett formázási jelölőket, és kerüld a „veszélyes” speciális karaktereket. A végére tegyél olyan CTA-t, amelynek UTM-címkéje ezt a konvenciót követi: utm_source=<channel>&utm_medium=<type>&utm_campaign=<slug>.

Korábban Claude „egy marketingweboldal általános stílusában” írt posztokat. Most követi a formátumodat, használja az UTM-jeidet, és nem árulja el, hogy a szöveget AI írta.

Működési szokások

Indítótáblázatok. Ha egy adott kifejezést mondasz, az ügynök tudja, mely fájlokat kell megnyitnia, és mit kell tennie. Íme egy heti tervezést végző csapat példája:

„Tervezd meg a hetet” → nyisd meg az ops/monthly.md fájlt, hozd létre a YYYY-WNN.md fájlt ugyanabban a mappában, és rendezd az ops/backlog.md feladatait a megfelelő napokhoz. „Mi van a backlogban?” → olvasd el az ops/backlog.md fájlt, és jelenítsd meg listaként. „Zárd le a hetet” → töltsd ki az aktuális heti fájl „Heti összefoglaló” szakaszát.

Az ilyen táblázatokkal Claude a „kódot író segítőből” olyan „operátorrá” válik, aki ismeri a vállalkozásod rutinját. Minden hétfőn azt mondom, „tervezzük meg a hetet”, Claude pedig megnyitja a megfelelő fájlokat, elolvassa a havi célokat, és javaslatot tesz a feladatok felosztására.

Hogyan ellenőrizd 5 perc alatt a CLAUDE.md-det egy 12 pontos listával?#

1. Méret. Tömör a fájl, és a körülbelül 200 sort felülvizsgálati célértéknek tekinted, nem megfelelt/nem felelt meg plafonnak?
2. Név. Pontosan CLAUDE.md a neve, nagybetűkkel, nem claude.md?
3. Hely. A projekt gyökerében vagy a ./.claude/CLAUDE.md helyen van?
4. Projektleírás. Az első 5 sorból világos, mi a projekt és kinek szól?
5. Eszközök. A technológiák kifejezetten, sallang nélkül szerepelnek?
6. Struktúra. Van a repositoryról magyarázatokkal ellátott diagram?
7. Útvonalválasztás. Van „kérdés → fájl” táblázat, amely megmutatja, hol találhatók a válaszok?
8. Alapelvek. Van olyan szabályokat tartalmazó szakasz, amelyek „soha” és „mindig” szavakkal kezdődnek?
9. Konkrétság. Minden szabály ellenőrizhető? („Használj 2 szóközt”, nem „írj szépen”.)
10. Önfrissítés. Van szabály arra, hogy „a munkamenet végén ellenőrizd, mit kell hozzáadni”?
11. Visszatekintés. Van szabály a „munkamenet összefoglalójának rögzítésére a retrospectives/ mappában”?
12. Biztonság. A kritikus tiltások (.env, rm -rf) a .claude/settings.json fájlban is szerepelnek?

Ha ötnél több „nem” válaszod van, nyisd meg a Claude-ot, és add neki ezt a promptot:

Olvasd el a CLAUDE.md fájlomat, és hasonlítsd össze az alábbi ellenőrzőlistával. Minden pontra válaszolj így: igen / nem / részben, és írd le pontosan, mit kell javítani.

Ellenőrzőlista:

A feladathoz elég tömör; 200 sor körül vizsgáld felül, de ne kezeld kemény plafonként

A projekt leírása az első 5 sorban szerepel

Az eszközök kifejezetten fel vannak sorolva

A repository struktúrájának diagramja szerepel benne

A „kérdés → fájl” táblázat szerepel benne

Szabályokat tartalmazó alapelvek szakasz szerepel benne

Minden szabály konkrét és ellenőrizhető

A „frissítsd a munkamenet végén” szabály szerepel benne

A „tekints vissza a munkamenet végén” szabály szerepel benne

A kritikus tiltások szerepelnek a .claude/settings.json fájlban

Nincs több szakaszban megismételve ugyanaz a szabály

Nincsenek már nem létező fájlokra mutató hivatkozások

Az audit után adj listát azokról a konkrét módosításokról, amelyek élővé teszik a fájlt.

Mit használj a CLAUDE.md után: Plan Mode-ot, Skillst vagy alügynököket?#

A CLAUDE.md az alap. Ha már működik, hozzáadhatod a Claude Code három egymást erősítő mechanizmusát.

Plan Mode. Olyan mód, amelyben Claude először változtatási tervet készít, megvárja a jóváhagyásodat, és csak utána kezd dolgozni. A Shift+Tab billentyűvel vagy a /plan paranccsal kapcsolhatod be. A vibe coding fő fájdalmára ad választ: „Megkértem Claude-ot, hogy javítson ki egy dolgot, erre átírta a projekt felét.” Plan Mode-ban ez nem történik meg - látod a tervet, mielőtt az ügynök bármilyen fájlhoz nyúlna.

Skills. Különálló .md fájlok a .claude/skills/ mappában, amelyek egy adott feladattípushoz tartozó tudást tartalmaznak. Például az „adatbázis-migráció írása” skill egy konkrét eljárást, sablont és példákat tartalmaz. Ez a tudás azért nincs a CLAUDE.md-ben, mert túl terjedelmes. Amikor azonban Claude olyan feladattal találkozik, mint „írj migrációt”, betölti a megfelelő skillt, és követi.

Alügynökök. Ha egy feladat sok kontextust igényel (például egy nagy funkció áttekintése), Claude külön alügynököt indíthat, saját, tiszta kontextussal. Az alügynök elvégzi a munkát, majd visszaadja az eredményt anélkül, hogy zsúfolttá tenné a fő csevegés kontextusát.

Mindhárom mechanizmus belépési pontként használja a CLAUDE.md-t: a munka kezdetén beolvassák, hogy megértsék a projekt hátterét. Ezért működnek rosszul ezek a funkciók akkor is, ha nincs naprakészen tartott CLAUDE.md. Előbb az alap, utána a ráépülő rétegek.

Következő lépés. Hozz létre egy CLAUDE.md fájlt a projekt gyökerében, másold bele a cikk elején található sablont, majd a segédprompt segítségével töltsd ki a szögletes zárójelben lévő mezőket. Ezután használd a fájlt: minden ügynöki hibát alakíts egy új sornyi szabállyá. Két-három hét múlva a CLAUDE.md többé nem „egy dokumentum, amelyet megírtunk, aztán elfelejtettünk”, hanem olyan fájl lesz, amelyet Claude tényleg minden munkamenetben elolvas.

Ha teljes keretrendszert szeretnél építeni a CLAUDE.md köré - business/ mappával a Second Brainhez, about-me/ mappával a digitális önképhez, alapvető skillekkel és beállított Plan Mode-dal -, használd a cikk lépéseit és példáit. Ailoot útmutatók.

Tovább az Ailoothoz.