Carte
Best practices for Claude Code
de Anthropic (documentația Claude Code) · 2026 · 3 fișe de lectură
3 fișe
Best practices for Claude Code · 2026
După două corecții ratate: /clear și un prompt mai bun, nu a treia corecție.
Cele cinci tipare. Sesiunea «chiuvetă»: sarcini fără legătură în același context, fiecare lăsând reziduuri — /clear între ele. Corecția la nesfârșit: după două corecții ratate, contextul e plin de abordări eșuate și fiecare răspuns e mai prost — /clear și un prompt nou care încorporează ce ai învățat, nu o a treia corecție. CLAUDE.md supra-specificat: reguli pe care Claude le ignoră fiindcă se pierd în zgomot — taie, sau transformă regula în hook. Încredere fără verificare: cod care «pare bine» și e greșit — teste, scripturi, capturi. Explorare infinită: «investighează» fără scop umple fereastra cu sute de fișiere — scop îngust sau un subagent care întoarce doar concluzia. Tweak-urile de productivitate din același ghid, în ordinea în care le folosești: Esc oprește fără să piardă contextul; Esc Esc sau /rewind întoarce conversația, codul sau ambele la un punct de control (fiecare prompt creează unul) și poate rezuma doar o porțiune; /compact cu instrucțiuni alege ce supraviețuiește; /btw pentru întrebări laterale care nu intră în istoric; /rename ca sesiunile să fie ramuri de lucru; /usage arată ce consumă limitele; /permissions și sandbox pentru mai puține întreruperi; o linie de stare cu consumul de context. Ghidul se încheie cu antidotul la rețete: când o sesiune a mers bine, observă ce a mers — promptul, contextul, modul — și de ce.
“O sesiune curată cu un prompt mai bun bate aproape întotdeauna o sesiune lungă cu corecții acumulate.”
Best practices for Claude Code · 2026
Dacă poți descrie diff-ul într-o propoziție, sari peste plan; altfel, explorează și planifică întâi.
Fluxul recomandat are patru faze. Explorează: în plan mode (Shift+Tab până apare «plan mode on», sau --permission-mode plan la pornire) Claude citește și răspunde, dar nu modifică nimic — poți lăsa să investigheze fără teama unei editări premature. Planifică: cere un plan concret și, cu Ctrl+G, deschide-l în editorul tău înainte să continue. Implementează: ieși din plan mode și lasă-l să codeze verificând față de plan. Comite: mesaj descriptiv, pull request. Costul e real — planificarea adaugă o tură întreagă — de aceea regula din citat: pentru un typo, un log sau o redenumire, direct la cod. Pentru funcționalități mari, ghidul propune «interviul până la specificație»: îi ceri să te intervieveze cu întrebări până acoperiți implementarea, interfața, cazurile-limită, apoi scrie o specificație și pornești o sesiune nouă, curată, doar pentru execuție. Specificațiile utile numesc fișierele și interfețele, spun explicit ce e în afara scopului și se termină cu o verificare cap-coadă. Promptul bun e specific: fișierul, scenariul care eșuează, ce înseamnă «reparat», un exemplu de pattern existent de urmat. Referințe cu @fișier în loc de descrieri, imagini lipite în loc de «arată cam așa», URL-uri la documentație în loc de presupuneri.
“Planificarea e cea mai utilă când nu ești sigur de abordare, când schimbarea atinge mai multe fișiere sau când nu cunoști codul modificat. Dacă poți descrie diff-ul într-o propoziție, sari peste plan.”
Best practices for Claude Code · 2026
Dovezi, nu afirmații: ieșirea testului, comanda rulată, captura comparată.
Ghidul numește asta cel mai important lucru pe care îl poți face pentru calitate. O verificare e orice întoarce un «trecut / picat» citibil în conversație: o suită de teste, codul de ieșire al unui build, un linter, un script care compară ieșirea cu un fixture, o captură de ecran față de un design. Există patru trepte de rigoare. Prima: în prompt («rulează testele și iterează până trec»). A doua: /goal — un evaluator separat re-verifică rezultatul după fiecare tură și împinge înapoi dacă nu e atins. A treia: un hook Stop, un script determinist care blochează încheierea turei până trece; după opt blocări consecutive Claude Code renunță, ca o verificare imposibilă să nu țină sesiunea ostatică. A patra: un subagent de verificare sau un workflow dinamic în care un alt model încearcă să infirme rezultatul. Cere dovezi, nu afirmații: ieșirea testului, comanda rulată și ce a întors, captura comparată. Ghidul o spune direct: dacă nu poți verifica, nu livra. Iar pentru revizuire, cere semnalarea doar a ceea ce afectează corectitudinea — un recenzor căruia îi ceri lacune va găsi întotdeauna lacune.
“Dă-i lui Claude o verificare pe care o poate rula: teste, un build, o captură de ecran de comparat. E diferența dintre o sesiune pe care o supraveghezi și una de la care poți pleca.”