Cele mai bune practici CLAUDE.md: 9 reguli care împiedică Claude să te ignore (2026)

Cele mai bune practici pentru CLAUDE.md: 9 reguli care îl împiedică pe Claude să te ignore (2026)

Majoritatea articolelor despre cele mai bune practici pentru CLAUDE.md îți oferă un șablon și consideră treaba terminată, dar fișierul pe care l-ai scris săptămâna trecută este probabil deja ignorat, iar tu nu știi de ce. Soluția rareori este „adaugă mai multe reguli”. De obicei, e exact pe dos. Am implementat Claude Code pe fiecare proiect recent al clienților noștri, iar aceste 9 reguli sunt cele care chiar fac diferența: o ierarhie care corespunde modului în care Claude încarcă fișierele, un buget de instrucțiuni pe care nu-l poți depăși, decizia privind AGENTS.md și cele șase motive pentru care Claude îți abandonează în tăcere fișierul în mijlocul sesiunii.

Concluzii principale

• CLAUDE.md este memoria proiectului, încărcată în contextul Claude Code; ține-o sub 200 de linii, altfel regulile încep să fie ignorate.
• Fișierele se încarcă de sus în jos: global, rădăcina proiectului, subdirector (leneș) și CLAUDE.local.md (personal, ignorat de git).
• Folosește AGENTS.md dacă folosești și Cursor sau Copilot; creează un symlink de la CLAUDE.md către AGENTS.md pentru a le acoperi pe ambele.
• Dacă Claude îți ignoră fișierul, în 90% din cazuri e vorba de lungime, vagitate sau un „de ce" lipsă.

Ce face de fapt CLAUDE.md (și de ce contează)

Pe scurt: CLAUDE.md este un fișier markdown pe care Claude Code îl citește ca memorie a proiectului la începutul fiecărei sesiuni. Nu este un prompt de sistem, un hook sau un skill, ci context consultativ care îl îndrumă pe Claude către convențiile echipei tale. Gândește-te la el mai degrabă ca la un fișier de configurare pe care programatorul tău AI în pereche chiar îl citește, decât ca la documentație.

Multe echipe scriu CLAUDE.md ca pe un README. Asta e prima greșeală. Un README explică proiectul pentru oameni care pot citi în diagonală și pot sări peste părți. CLAUDE.md este consumat integral de Claude Code la începutul sesiunii, fiecare rând costând tokeni și aderență. Este mult mai aproape de un fișier de configurare sau de un set de fixture-uri de test decât de documentație.

De asemenea, nu este singura modalitate de a-l ghida pe Claude. Hook-urile rulează acțiuni deterministe (formatare, blocarea commit-urilor). Skill-urile grupează fluxuri de lucru reutilizabile. CLAUDE.md se situează între ele ca context consultativ, Claude îl evaluează, uneori îl suprascrie și cu siguranță uită părți din el dacă scrii prea mult. Această distincție este temelia pentru tot ce urmează și este motivul pentru care CLAUDE.md este un instrument în practica mai largă a context engineering, nu un leac universal.

Regula #1: Tratează-l ca pe cod, nu ca pe documentație. Versionează-l. Revizuiește-l în PR-uri. Scurtează-l așa cum ai refactoriza un modul umflat. Conform ghidului CLAUDE.md de la Anthropic, fișierul este încărcat cu aceeași prioritate ca orice instrucțiune de sistem, ceea ce înseamnă că o regulă învechită de acum șase luni încă modelează activ fiecare răspuns de azi.

Cum se încarcă CLAUDE.md: ierarhia pe 4 niveluri

Pe scurt: Claude Code încarcă CLAUDE.md de pe patru niveluri: global (~/.claude/CLAUDE.md), rădăcina proiectului, CLAUDE.local.md pentru suprascrieri personale și fișierele din subdirectoare, care se încarcă leneș doar atunci când Claude citește fișiere din acel director. Subdirectoarele frate nu văd niciodată CLAUDE.md-ul celuilalt, ceea ce menține memoria claude code strict delimitată.

Ierarhia este partea cea mai neînțeleasă a CLAUDE.md și este locul în care 0 dintre primele 5 rezultate din SERP intră în profunzime. Iată ce se întâmplă de fapt sub capotă:

Doi termeni merită clarificați: încărcarea leneșă și izolarea directoarelor frate.

Încărcarea leneșă înseamnă că un CLAUDE.md dintr-un subdirector nu intră în contextul lui Claude până când Claude nu deschide efectiv un fișier din acel director. Dacă întrebi „rezolvă bug-ul de login" și Claude atinge doar backend/, frontend/CLAUDE.md al tău nu se încarcă niciodată. Acesta este un lucru bun, menține fereastra de context curată, dar le creează probleme echipelor care plasează reguli critice în subdirectoare, așteptându-se ca acestea să se aplice întotdeauna.

Izolarea directoarelor frate este corolarul: frontend/CLAUDE.md și backend/CLAUDE.md nu se încarcă niciodată unul pe celălalt. Ele partajează doar ce se află în rădăcina proiectului. Deci, dacă regulile tale de frontend contrazic regulile de backend, nu e nicio problemă. Dacă trebuie să partajeze o convenție, împinge-o în sus, în fișierul rădăcină.

CLAUDE.local.md este portița de scăpare. Este încărcat, dar nu este comis — perfect pentru suprascrieri de tipul „prefer pnpm, dar echipa a standardizat pe npm". Capcana: nu este ignorat automat din Git. Trebuie să-l adaugi singur. Dacă uiți asta, îți vei comite regulile personale în repo-ul echipei. Regula #4: Potrivește instrucțiunile în funcție de locul unde Claude le citește efectiv. Regulile de stil pentru componentele React aparțin în frontend/CLAUDE.md, nu în rădăcină. Regulile pentru migrarea bazei de date aparțin în backend/. Documentația Anthropic Memory (actualizată în noiembrie 2025) confirmă acest lucru — comportamentul de lazy-load este intenționat și esențial.

Ce să pui în CLAUDE.md (și ce să lași deoparte)

Pe scurt: În CLAUDE.md intră orice lucru pe care Claude nu-l poate deduce din codul tău: comenzi de build, convenții de denumire, anti-pattern-uri pe care echipa ta s-a ars și motivul din spatele fiecărei reguli. Ies afară orice se află în README, orice se află în package.json și orice regulă care se schimbă săptămânal. instrucțiunile claude code ar trebui să fie testabile și specifice.

Iată un CLAUDE.md minimal care chiar își face treaba:

# Proiect: techsy-app
## Comenzi
- Build: `pnpm build` (Turbopack — flag-urile Webpack nu se aplică)
- Test: `pnpm test --run` (folosim Vitest, nu Jest)
- Lint: `pnpm lint` (va eșua CI la avertismente, nu doar la erori)
## Convenții
- Componente de server în mod implicit. Adăugați `'use client'` doar atunci când este cu adevărat necesar.
  Motiv: în trimestrul trecut am atins un LCP de 8s din cauza utilizării excesive a componentelor de client.
- Accesul la baza de date se face doar prin helper-ele din `lib/db/` — niciodată SQL brut în rute.
  Motiv: politicile de securitate la nivel de rând se află în aceste helper-e.
- Testele se plasează ca `*.test.ts` lângă fișierul testat.
## Ce să nu faci
- Nu adăuga o dependență nouă fără să deschizi mai întâi un comentariu pe PR.
- Nu folosi `any` — folosește `unknown` și restrânge tipul.
## Unde să cauți
- Schema: `db/schema.ts`
- Fluxul de autentificare: `lib/auth/README.md`

Now compare that to the anti-pattern version most teams ship:

# Reguli de proiect

- Scrie cod curat și ușor de întreținut.
- Respectă bunele practici.
- Folosește TypeScript corect.
- Asigură-te că testele trec.
- Fii consecvent cu tiparele existente.
- Documentează logica complexă.

Al doilea fișier nu este greșit. Este pur și simplu inutil. Claude vrea deja să scrie cod curat. „Fii consecvent" nu îi spune lui Claude cu care tipar să fie consecvent. Exemplele publice ale inginerului Anthropic, Boris Cherny, înclină puternic spre primul stil: comenzi concrete, instrumente denumite și motivul din spatele deciziilor care nu sunt evidente doar din codul sursă.

Regula #2: Fii specific, nu aspirațional. „Scrie cod curat" este aspirațional. „Server components implicit; adaugă 'use client' doar când este cu adevărat necesar" este testabil. Aceeași disciplină stă la baza unui prompt engineering bun: instrucțiunile specifice și testabile depășesc aspirațiile vagi, indiferent dacă se află într-un prompt sau într-un CLAUDE.md.

Regula #3: Explică de ce contează fiecare regulă. „De ce"-ul nu este umplutură, ci modul în care Claude decide cazurile limită. O regulă cu un motiv („am atins 8s LCP din cauza excesului de client-side") se generalizează la situații similare. O regulă fără motiv este ignorată în momentul în care contextul se schimbă. Tiparul este documentat și în ghidul CLAUDE.md de la Builder.io.

De ce îți ignoră Claude CLAUDE.md? Bugetul de instrucțiuni

Pe scurt: Claude nu este răuvoitor, ci pur și simplu rămâne fără atenție. După aproximativ 80 de linii vei începe să observi că regulile sunt uitate; după 200 de linii, blocuri mari sunt ignorate complet; după 500 de cuvinte de reguli dense, respectarea se prăbușește. Soluția este un buget de instrucțiuni. Tratează fiecare linie ca pe un cost asupra memoriei claude code și asupra respectării per regulă.

Cercetări recente confirmă ceea ce utilizatorii din producție constată în mod repetat: respectarea instrucțiunilor se degradează neliniar odată cu numărul de reguli. Lucrarea arxiv 2507.11538 despre capacitatea de respectare a instrucțiunilor arată că respectarea per regulă scade pe măsură ce adaugi tot mai multe, iar analiza HumanLayer despre CLAUDE.md în producție confirmă aceeași constatare.

Cu alte cuvinte: fiecare regulă pe care o adaugi face ca toate celelalte reguli să fie respectate cu o probabilitate puțin mai mică. Așadar, un CLAUDE.md de 400 de linii nu este de 4 ori mai eficient decât unul de 100 de linii. Adesea este mai puțin eficient, deoarece regulile de care chiar îți pasă sunt diluate de cele pe care le-ai scris într-o vineri acum trei luni și nu le-ai șters niciodată.

În fișierele noastre CLAUDE.md, tot ce depășește linia 150 începe să piardă vizibil din respectare. Până la linia 250 am văzut cum Claude omite secțiuni întregi. Așa că punem o limită.

wc -l CLAUDE.md

Acesta este întregul instrument. Rulează-l. Dacă depășești 200, ai depășit bugetul. Regula strictă pe care o livrăm clienților:

Tratează CLAUDE.md ca pe un buget de 200 de linii. Fiecare linie costă respectare. Cheltuiește-o acolo unde contează.

Regula #1 consolidată: Păstrează-l scurt. Sub 200 de linii. Sub 500 de cuvinte de reguli dense. Dacă te trezești că vrei să adaugi reguli de automatizare („rulează întotdeauna prettier după editări"), acestea țin probabil mai degrabă de hook-urile Claude Code, hook-urile sunt deterministe și nu costă token-uri din bugetul de instrucțiuni.

Ar trebui să folosești CLAUDE.md, AGENTS.md, .cursorrules sau copilot-instructions?

Pe scurt: Dacă folosești doar Claude Code, CLAUDE.md este suficient. Dacă folosești două sau mai multe CLI-uri de agenți (Codex, Cursor, Copilot, Sourcegraph), treci la AGENTS.md și creează un symlink de la CLAUDE.md către AGENTS.md. AGENTS.md a apărut la finalul lui 2025 ca standard transversal, iar majoritatea agenților moderni recurg la el ca fallback, astfel încât un singur fișier deservește fiecare ecosistem.

Aceasta este întrebarea 0 la care răspund efectiv primele 5 rezultate. Iată matricea:

Trucul pentru dubla țintire este de o singură linie:

ln -s AGENTS.md CLAUDE.md

Atât. Acum Claude Code, Codex și orice instrument compatibil cu AGENTS.md citesc același fișier. Actualizezi o singură dată, iar fiecare agent îl preia. Specificația AGENTS.md este deschisă și intenționat minimală, este doar markdown cu secțiuni convenționale.

Două situații practice. Prima: dacă echipa ta are un utilizator avansat de Cursor, .cursorrules de la Cursor abordează lucrurile diferit, un singur fișier, fără ierarhie, format mai rigid. Unele echipe păstrează ambele: AGENTS.md pentru regulile comune, .cursorrules pentru particularitățile specifice Cursor. A doua: .github/copilot-instructions.md de la Copilot nu recurge la AGENTS.md ca fallback, astfel încât echipele care se bazează mult pe Copilot au nevoie de un fișier separat.

Dacă îți alegi un stack de agenți de la zero, analiza noastră Claude Code vs Cursor vs Copilot acoperă compromisurile la nivel de utilizare. Versiunea scurtă: ierarhia lui Claude Code este cea mai puternică pentru monorepo-uri, experiența de utilizare a lui Cursor câștigă pentru lucrul individual, iar integrarea în IDE a lui Copilot este în continuare cea mai lină pentru adoptarea treptată.

Regula #9: Folosește AGENTS.md dacă rulezi mai mult de un CLI de agent. Nu menține două fișiere care spun același lucru. Alege fișierul pe care îl citește cea mai mare parte a stack-ului tău și creează symlink-uri pentru restul.

CLAUDE.md vs. Hooks vs. Skills: Triunghiul decizional

Pe scurt: CLAUDE.md = context consultiv. Hooks = acțiuni deterministe. Skills = capacități grupate. Alegi greșit și vei arde buget de instrucțiuni pe ceva ce ar trebui gestionat de un hook, sau vei scrie o regulă în CLAUDE.md pentru ceva ce doar un skill poate livra. Triunghiul este cel mai ieftin mod de a păstra CLAUDE.md suplu.

Trei instrumente, trei sarcini. Greșeala pe care o vedem cel mai des: pui „rulează întotdeauna prettier după editare" în CLAUDE.md. Claude o citește. Claude uneori rulează prettier. Tu ești frustrat. Soluția este să muți acea linie din CLAUDE.md într-un hook, deoarece hook-urile se declanșează determinist de fiecare dată, fără loc de interpretare consultivă.

Dacă o regulă trebuie să se declanșeze mereu, aparține unui hook. Dacă e o preferință de stil pe care Claude o poate evalua în context, aparține fișierului CLAUDE.md. Dacă e un flux de lucru în mai mulți pași, cu resurse grupate (șabloane, scripturi, prompturi), aparține unui skill.

Regula #8: Alege corect între CLAUDE.md, hooks și skills — a pune un hook în CLAUDE.md este cea mai frecventă risipă de buget de instrucțiuni. Configurează acțiunile deterministe cu hook-uri Claude Code și împachetează fluxurile de lucru reutilizabile ca skills Claude. CLAUDE.md-ul tău devine mai scurt, gardele tale devin mai ferme, iar Claude nu mai „uită" regulile care contează.

Tipare Monorepo: CLAUDE.md imbricat, @imports și .claude/rules/

Pe scurt: Într-un monorepo, păstrează CLAUDE.md de la rădăcină cât mai mic, doar cu indicatori și convenții partajate. Împinge detaliile specifice în apps/*/CLAUDE.md, astfel încât fiecare subarbore să aibă reguli delimitate. Folosește @imports pentru a partaja fișiere de reguli modulare prin .claude/rules/. Aceasta este dezvăluire progresivă — Claude preia fiecare porțiune doar atunci când este relevantă.

Un arbore tipic de CLAUDE.md într-un monorepo:

.
├── CLAUDE.md                        # 30 lines — points to subdirs and shared rules
├── .claude/
│   └── rules/
│       ├── style.md
│       ├── testing.md
│       └── security.md
├── apps/
│   ├── web/
│   │   └── CLAUDE.md                # Next.js-specific rules
│   └── api/
│       └── CLAUDE.md                # Fastify-specific rules
└── packages/
    └── shared/
        └── CLAUDE.md                # Library author rules

Sintaxa @import permite fișierului de la rădăcină să preia porțiuni de reguli partajate fără a le mai restabili:

# CLAUDE.md rădăcină

Acesta este un Turborepo. Consultați CLAUDE.md din subdirectoare pentru regulile specifice aplicației.

@import .claude/rules/style.md
@import .claude/rules/testing.md
@import .claude/rules/security.md
## Comenzi de nivel superior
- `pnpm dev` rulează toate aplicațiile în paralel
- `pnpm test` rulează scriptul de test al fiecărui workspace

Aceasta este dezvăluirea progresivă în practică. Fișierul rădăcină este un pointer de 30 de linii. Fiecare CLAUDE.md din subdirectoare adaugă 50–80 de linii de reguli focalizate. Fișierele .claude/rules/ conțin fragmente de convenții care pot fi preluate de mai multe subdirectoare. Nimic nu este duplicat, nimic nu este omis și niciun fișier nu depășește bugetul de instrucțiuni.

Regula încărcării leneșe menționată anterior contează și mai mult aici: când Claude lucrează la apps/web/Button.tsx, vede fișierul rădăcină plus apps/web/CLAUDE.md plus fișierele de reguli importate prin @import. Nu vede apps/api/CLAUDE.md. Acesta este întregul scop: convențiile de backend nu poluează contextul de frontend, iar fereastra ta de context rămâne utilizabilă.

Regula #6: Folosește @imports pentru a menține fișierul rădăcină sub 200 de linii. Ghidul Cele mai bune practici Anthropic pentru Claude Code tratează aceasta ca modelul standard pentru monorepo. Subagenții moștenesc și ei contextul CLAUDE.md părinte, ceea ce merită să știi dacă imbrici fluxuri de lucru — vezi ingineria contextului pentru modul în care aceasta interacționează cu proiectarea subagenților.

6 motive pentru care Claude îți ignoră fișierul (și soluția pentru fiecare)

Pe scurt: Când Claude ignoră CLAUDE.md, este aproape întotdeauna vorba despre una dintre șase cauze: fișier prea lung, formulări vagi, lipsa unui „de ce", compactarea contextului, un fișier părinte conflictual sau un nume de fișier greșit. Fiecare are o soluție de 60 de secunde. Testează într-o sesiune nouă după fiecare modificare — aceasta este Regula #7.

1. Fișier prea lung (>200 de linii / >500 de cuvinte)

Rulează wc -l CLAUDE.md. Dacă are peste 200, scurtează-l agresiv. Mută regulile de automatizare în hooks. Mută fluxurile de lucru în skills. Împarte bucățile partajate în .claude/rules/ și preia-le cu @import. Cel mai frecvent motiv pentru care Claude „nu ți-a mai respectat” regulile este că fișierul a devenit prea lung în timp, iar conformarea s-a prăbușit în tăcere.

2. Formulări vagi („scrie cod curat”)

Înlocuiește fiecare regulă aspirațională cu una specifică și testabilă. „Fii consecvent” este invizibilă pentru Claude. „Folosește componente server în mod implicit; adaugă 'use client' doar pentru formulare sau UI interactiv” este ceva ce Claude poate aplica efectiv.

3. Lipsește „de ce-ul"

Regulile fără o justificare nu se generalizează. Claude nu poate deduce când să facă excepții de la o regulă, pentru că nu știe ce anume previne aceasta. Fiecare regulă neevidentă primește o explicație de un rând: „folosim unknown, nu any, pentru că trimestrul trecut am avut trei crash-uri în runtime cauzate de răspunsuri API tipizate ca any."

4. Compacțiunea contextului l-a eliminat

Sesiunile lungi declanșează compacțiunea, Claude rezumă contextul anterior pentru a se încadra în fereastră, iar conținutul din CLAUDE.md este uneori rezumat până la dispariție. Soluția: /clear după consumuri majore de context sau repornirea completă a sesiunii. Exact asta este ceea ce Issue-ul GitHub #17530 aduce în discuție în mod repetat.

5. Fișiere CLAUDE.md părinte în conflict

Cel global spune „folosește 4 spații.” Cel din rădăcina proiectului spune „folosește 2 spații.” Cel din subdirector nu spune nimic. Claude alege unul, uneori pe cel greșit. Audită ~/.claude/CLAUDE.md și rădăcina proiectului pentru contradicții. Oricare este mai specific ar trebui să câștige, dar doar dacă faci acest lucru explicit.

6. Locație greșită a fișierului sau diferențe de majuscule în numele fișierului

Claude.md și CLAUDE.md sunt fișiere diferite pe Linux și macOS. La fel sunt și claude.md și CLAUDE.md. Confirmă că ruta este exact ./CLAUDE.md (toate cu majuscule) și confirmă că Claude Code este lansat din directorul care îl conține. GitHub Issue #668 este plin de cazuri în care fișierul exista, dar Claude nu îl putea vedea din cauza rutei.

Regula #7: Testează într-o sesiune nouă. După orice modificare a CLAUDE.md, deschide o sesiune nouă și cere-i lui Claude să "rezume regulile din CLAUDE.md." Dacă rezumatul omite ceva, fișierul nu își face treaba.

Primul tău CLAUDE.md în 10 minute: un ghid de start în 5 pași

Pe scurt: Rulează /init pentru a genera o ciornă, redu-o la 6–10 reguli reale, cu motive, adaugă 3 comenzi pe care Claude ar trebui să le știe, adaugă 2 anti-pattern-uri pe care echipa ta le-a întâlnit, apoi testează într-o sesiune nouă cerându-i lui Claude să rezume fișierul. Timp total: aproximativ 10 minute. Rețeta în 5 pași este cea pe care o folosim în prima zi pentru fiecare repository nou.

1. Rulează /init pentru a genera o ciornă. Comanda /init din Claude Code îți scanează repository-ul și scrie un CLAUDE.md de start. Nu livra ce scrie el. Rezultatul din /init este un punct de plecare, nu un fișier finit și, sincer, mare parte din ce generează poate fi eliminată.

2. Redu-l la 6–10 rânduri de reguli propriu-zise, cu motive. Șterge tot ce e generic. Șterge tot ce se află deja în README. Păstrează doar regulile pe care Claude nu le poate deduce singur din cod.

3. Adaugă 3 comenzi pe care Claude ar trebui să le știe. Build, test, lint. Include comanda exactă și orice flag-uri care nu sunt evidente. Dacă folosești Vitest în loc de Jest, specifică asta.

4. Adaugă 2 anti-pattern-uri pe care echipa le-a întâlnit. Unul real. „Nu folosi any, pentru că am avut trei crash-uri în runtime” bate de fiecare dată „folosește TypeScript corect”.

5. Deschide o sesiune nouă și verifică. Cere-i lui Claude să „rezume regulile din CLAUDE.md”. Dacă omite ceva, fișierul este prea lung, prea vag sau îi lipsește un „de ce”. Corectează și repetă.

Regula #5: Nu genera automat doar din /init. /init este un punct de plecare, nu un fișier finit. Cele 8 minute pe care le petreci reducându-l sunt locul unde se află valoarea.

Întrebări frecvente

Ce este un fișier CLAUDE.md?

Un fișier CLAUDE.md este un fișier markdown pe care Claude Code îl citește ca memorie a proiectului la începutul fiecărei sesiuni. Îi comunică lui Claude convențiile, comenzile și anti-tiparele tale, ca să nu fie nevoit să ghicească. Funcționează la patru niveluri: global, rădăcina proiectului, subdirector (încărcat leneș) și un fișier personal CLAUDE.local.md pe care îl ții în gitignore.

Cât de lung ar trebui să fie un fișier CLAUDE.md?

Sub 200 de linii și sub 500 de cuvinte de reguli dense. Dincolo de aceste praguri, capacitatea lui Claude de a urma instrucțiuni se degradează — fiecare regulă pe care o adaugi face ca toate celelalte reguli să fie puțin mai puțin probabil să fie respectate. Tratează-l ca pe un buget fix. Dacă ai nevoie de mai mult, împarte în fișiere CLAUDE.md în subdirectoare și folosește @import pentru fragmentele partajate.

Unde ar trebui să pun CLAUDE.md?

Fișierul principal se plasează în rădăcina proiectului (./CLAUDE.md) și se include în commit. Adaugă fișiere CLAUDE.md în subdirectoare pentru reguli specifice aplicațiilor în monorepo-uri. Pune preferințele valabile pentru mai multe proiecte în ~/.claude/CLAUDE.md. Folosește CLAUDE.local.md pentru suprascrieri personale pe care nu vrei să le dai commit, dar nu uita să îl adaugi manual în gitignore.

De ce îmi ignoră Claude fișierul CLAUDE.md?

În 90% din cazuri, este vorba despre unul dintre trei lucruri: fișierul este prea lung (peste 200 de linii), regulile sunt vagi („scrie cod curat") sau regulilor le lipsește un „de ce" pe care Claude să îl poată folosi pentru a le aplica. Rulează wc -l CLAUDE.md, apoi verifică nivelul de specificitate. Testează modificările într-o sesiune nouă, cerându-i lui Claude să rezume fișierul.

Ar trebui să folosesc CLAUDE.md sau AGENTS.md?

Dacă echipa ta folosește doar Claude Code, rămâi la CLAUDE.md. Dacă folosești două sau mai multe CLI-uri de agent (Codex, Cursor, Sourcegraph), treci la AGENTS.md și creează un symlink de la CLAUDE.md către acesta: ln -s AGENTS.md CLAUDE.md. Majoritatea CLI-urilor de agent moderne folosesc AGENTS.md ca fallback, astfel încât un singur fișier deservește toate instrumentele.

Ar trebui să rulez /init pentru a genera CLAUDE.md?

Da, ca ciornă. Nu, ca fișier final. /init îți scanează repository-ul și generează un punct de plecare, dar e verbose și generic. Atât Anthropic, cât și HumanLayer recomandă să-l reduci agresiv după ce rulezi /init. Cele 8 minute pe care le petreci tăind și adăugând rânduri de tip „de ce" sunt momentul în care fișierul devine cu adevărat util.

Cum funcționează fișierele CLAUDE.md într-un monorepo?

Fișierul CLAUDE.md din rădăcină rămâne minimal — doar pointeri și reguli partajate. Fiecare aplicație primește propriul apps/*/CLAUDE.md cu convenții specifice. Fișierele din subdirectoare se încarcă leneș doar când Claude citește fișiere din acel subarbore, astfel încât frații rămân izolați. Folosește @import .claude/rules/style.md pentru a partaja fragmente modulare de reguli fără a le duplica între aplicații.

Care este diferența dintre CLAUDE.md, hooks și skills?

CLAUDE.md este context consultativ — Claude îl citește și, de obicei, îl respectă. Hooks sunt acțiuni deterministe care se declanșează întotdeauna (formatare, blocarea commit-urilor). Skills sunt capacități grupate pentru fluxuri de lucru reutilizabile, cu resurse asociate. Folosește CLAUDE.md pentru îndrumări de stil, hooks pentru reguli stricte și skills pentru sarcini cu mai mulți pași pe care le vei repeta în mai multe proiecte.

Cum abordează Techsy acest lucru

La Techsy, fiecare proiect Claude Code pe care îl livrăm are un CLAUDE.md de sub 150 de linii și un symlink AGENTS.md. Tratăm fișierul ca pe cod, îl versionăm, revizuim modificările în PR-uri și îl retestăm în sesiuni noi înainte de merge. Ai nevoie de ajutor pentru a integra agenții AI în fluxul tău de dezvoltare? Obține o consultație gratuită.