Claude Code’da o‘zgarishlarni qanday bekor qilish mumkin: /rewind va git

Ailoot bilan ishlash bo‘yicha amaliy ma’lumotlar hujjatlarda mavjud.

Claude Code’da bekor qilish nima va nega uchta daraja yetarli emas?#

Claude Code’dan foydalanishni boshlaganimning birinchi haftasida /rewindni yoqdim: u ikki so‘rovda loyihamning autentifikatsiya mantiqini buzib qo‘ydi. Orqaga qaytardim, yengil nafas oldim va ishni davom ettirdim. Bir oy o‘tgach, yana bir vaziyat yuz berdi: sxema migratsiyasini yozayotgan edim, Claude yordam berdi, commit qildim, tarmoqlarni almashtirdim — shunda zarur bir qadamni unutganimni angladim. /rewind yordam bermadi — seans allaqachon boshqacha edi. Oldingi commitga git checkout qilish yordam berdi. Yana bir oy o‘tgach, agentga tasodifan “hammasini oxirgi push holatiga qaytar” dedim, u esa git reset --hard bajarib, uch soatlik ishimni barbod qildi. git reflog meni qutqardi — yo‘q qilingan commitlarning xeshlari hali ham bor edi.

Bu uch voqea turlicha ishlaydigan, turli xatolarni tutib qoladigan va barchasi kerak bo‘ladigan uchta himoya darajasini ko‘rsatadi. Ushbu qo‘llanmada har bir daraja buyruqlari, cheklovlari va misollari bilan tushuntiriladi. Shuningdek, Claude loyihani birinchi urinishdayoq ishdan chiqarmasligi uchun uni oldindan qanday sozlash ko‘rsatiladi.

Bekor qilishning 3 darajasi — nima va qachon:

Keyin har bir darajani ko‘rib chiqamiz: aynan nima qilish, qanday xatolardan ehtiyot bo‘lish va hech narsa buzilmagani uchun bekor qilishga hojat qolmaydigan qilib sozlash.

/rewind’ni qanday chaqirasiz: buyruq bilanmi yoki Esc-Esc bilanmi?#

Har bir javobdan keyin Claude shu seansda tahrirlagan barcha fayllarning suratini avtomatik oladi. Suratlar ~/.claude/file-history/{sessionId}/ ichida saqlanib, 30 kungacha turadi. Suratlar bosqichma-bosqich olinadi — butun fayl emas, faqat holatlar orasidagi farqlar saqlanadi. Odatiy holatda har bir seans uchun 100 tagacha surat saqlanadi. Demak, aksariyat real loyihalarda kun davomida Claude kiritgan barcha o‘zgarishlarning to‘liq tarixi istalgan paytda mavjud bo‘ladi.

Orqaga qaytarish menyusini ochish uchun kiritish maydoni bo‘sh bo‘lganda Escni ikki marta bosing:

[user-input is empty]
> _

[press Esc, Esc]

Rewind to which message?
  1. Create a migration for the User table          (3 files changed)
  2. Add the lastLoginAt field                      (1 file changed)
  3. Rewrite the authorization logic                (5 files changed)
  ...

Kiritish maydonida matn bo‘lsa, Escni ikki marta bosishning birinchi harakati uni tozalab, Up tarixiga saqlaydi. Bu yozishni boshlab qo‘yganingizda, lekin orqaga qaytish kerakligini anglaganingizda foydali. Anthropic’ning rasmiy hujjatlaridan iqtibos:

/rewind buyrug‘i ham xuddi shu ishni qiladi — menyuni ochadi. /checkpoint taxallusi ham ayni joyga olib boradi. Qaysi usul qulayroq ekani odatga bog‘liq. Men Esc Escdan foydalanaman — bu tezroq va qo‘llarimni klaviaturadan olishimga hojat yo‘q.

Rewind menyusidagi 6 rejim: qaysi birini va qachon tanlash kerak?#

Ro‘yxatdan nuqtani tanlang, shunda amallar menyusiga o‘tasiz. Unda oltita band bor, har biri boshqa ishni bajaradi.

Rejimlarning to‘liq jadvali:

Summarize up to here funksiyasi Claude Code v2.1.139-v2.1.142 versiyalarida, 2026-yil 11–15-may kunlari, 20-haftada chiqarilgan:

Restore va Summarize o‘rtasidagi farq juda muhim. Restore oldingi holatga qaytarib, tanlangan nuqtadan keyin sodir bo‘lgan hamma narsani bekor qiladi. Summarize hech narsani bekor qilmaydi; faqat ixchamlaydi — asl xabarlar sessiya stenogrammasida qoladi, lekin faol kontekstda faqat xulosa qoladi. “Go‘yo bu hech qachon bo‘lmagandek” qilish uchun restore’dan foydalaning. “Saqlab qolish, lekin kontekst joyini band qilmaslik” uchun summarize’dan foydalaning.

Restore conversation yoki Summarize from heredan keyin tanlangan so‘rovning asl matni kiritish maydoniga qaytadi — uni tahrirlab, qayta yuborishingiz mumkin. Summarize up to heredan keyin kiritish maydoni bo‘sh qoladi va suhbat oxirida qolasiz.

/rewind qaysi o‘zgarishlarni bekor QILMAYDI?#

Odamlar duch keladigan asosiy cheklov shu: /rewind yashil belgi ko‘rsatib, “orqaga qaytarish muvaffaqiyatli” deydi, ammo Claude fayllardan ko‘prog‘iga tegib ketgani uchun loyiha hanuz buzilgan bo‘ladi. Uch holatni ko‘rib chiqaylik.

1. Bash buyruqlari kuzatilmaydi. Agar Claude biror yurishda rm file.txt yoki mv old.txt new.txt bajarsa, bu o‘zgarishlar checkpoint’ga kirmaydi. Anthropic hujjatlarida aniq aytilgan:

Demak, Claude bash vositasidan foydalanib faylni o‘zi o‘chirsa, ko‘chirsa yoki nusxalasa, /rewind hamma narsani tiklay olmaydi. git checkout yoki zaxira nusxadan tiklash yordam berishi mumkin, ammo buning uchun ikki tugmani bosishdan ko‘prog‘i kerak bo‘ladi.

2. Tashqi tahrirlar aniqlanmaydi. Faylni VS Code’da qo‘lda ochib tahrirlasangiz yoki ikkinchi Claude seansi ayni fayllarni parallel o‘zgartirsa, birinchi seans bu o‘zgarishlarni ko‘ra olmaydi. Joriy seansda Claude navbatini tugatganida checkpoint surati olinadi. Navbatlar orasida sodir bo‘ladigan ishlar uning mas’uliyatidan tashqarida.

3. Fayllardan tashqaridagi amallar umuman qamrab olinmaydi. npx prisma migrate dev orqali qo‘llangan Prisma migratsiyasi ma’lumotlar bazasi sxemasini o‘zgartiradi — /rewind buni bekor qilmaydi, chunki ma’lumotlar bazasi loyiha fayl tizimidan tashqarida. origin/mainga force-push ham shunday: commit masofaviy serverga yuborilgan va checkpoint uni qaytarib olib kelmaydi. Pul yechgan yoki yozuvni o‘chirgan masofaviy API chaqiruvini faqat o‘sha API’ning o‘z vositalari bilan bekor qilish mumkin.

Qoida: Vazifa loyiha fayllaridan tashqaridagi narsalarga — ma’lumotlar bazasi migratsiyalari, git push, masofaviy API’lar — ta’sir qilsa, har bir tashqi ta’sir uchun alohida qaytarish strategiyasini tayyorlang. /rewind faqat joriy seansdagi mahalliy fayllar tarixini qamrab oladi.

/rewind va git: ular nimasi bilan farq qiladi va nega ikkalasi ham kerak?#

Anthropic hujjatlarida bu juftlik bevosita bayon qilingan:

Farqlar bitta jadvalda:

Ularning birgalikda ishlash qoidasi oddiy: “bu ishlayapti va buni yo‘qotishni xohlamayman” degan holatga yetganingizda, git commit qiling. Commitlar orasida /rewindga tayaning — u darhol ishlaydi, commit xabarini talab qilmaydi va git tarixini oraliq holatlar bilan to‘ldirmaydi. Ish tugaganda commit qiling — yaxshisi, mazmunli va yaxlit commit.

Nega bitta /rewind butun vazifani qamrab olmaydi?#

Claude’dan “orqaga qaytar” deb so‘raganda git reset --hard nega xavfli?#

“Joriy holatni saqla va oxirgi push holatiga qaytar” degan so‘rov quyidagi buyruqlarga olib kelishi mumkin:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # saqlanmagan o‘zgarishlarni saqladi
git reset --hard 35eb731                                                # d63695e..882e618 commitlarini yo‘q qildi

Birinchi buyruq to‘g‘ri edi — u commit qilinmagan o‘zgarishlarni stash’da saqladi. Ikkinchisi buzuvchi bo‘ldi: u tarmoqni 35eb731 commitiga qayta yozdi va u bilan 882e618 orasidagi barcha commitlar yetim qoldi. Odatiy holatda yetim commitlar git gc ishga tushguncha .git/objects/ ichida qoladi; bu odatda ikki hafta ichida avtomatik yuz beradi. Ammo o‘sha payt nima qilishni bilmagan bo‘lsangiz, vaqt sizga qarshi ishlay boshlagan edi.

Mantiq oddiy: oddiy tildagi “orqaga qaytar”, “oldingi holatga bor”, “tikla”, “qaytar” va “bekor qil” iboralari “ortga qarash” yoki “xavfsiz joyga qaytish”ni anglatadi. Ular “tarixni yo‘q qilish” degani emas. git reset --hard buyrug‘i tarixni yo‘q qiladi — tarmoqni qayta yozadi va commitlarni HEAD’dan yetib boriladiganlar qatoridan olib tashlaydi. Xavfsiz muqobil — git checkout <commit>: u ajratilgan HEAD yaratib, tarmoqlarga tegmasdan eski holatni ko‘rish imkonini beradi.

Amaliy asosiy xulosa — har qanday jiddiy vazifadan, ayniqsa bir nechta faylni refaktorlashdan oldin joriy holatni git commit qilish. Bitta commit Claude’ning istalgan xatosini ishni yo‘qotmasdan bitta git checkout . buyrug‘i bilan bartaraf etish imkonini beradi.

Halokatli resetdan keyin git reflog qanday qutqaradi?#

Halokatli reset’dan keyin darhol git reflog ishlating:

git reflog

Natija quyidagicha ko‘rinadi:

35eb731 HEAD@{0}: reset: moving to 35eb731
882e618 HEAD@{1}: commit: middleware refactoring complete
d63695e HEAD@{2}: commit: leaveRemove method finalized
1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled
35eb731 HEAD@{4}: pull origin main

HEAD@{1} dan HEAD@{3} gacha bo‘lganlar aynan o‘sha “yo‘q qilingan” commitlardir. Ular git’ning mahalliy obyektlar omboridan yo‘qolmagan; shunchaki tarmoq orqali ularga yetib borib bo‘lmaydigan bo‘lgan. Ularni tiklash uchun:

# Oxirgi “yo‘q qilingan” commitdan tarmoq yarating
git branch recovered-work 882e618

# Yoki to‘g‘ridan-to‘g‘ri o‘ting
git reset --hard 882e618

Shundan keyin tarmoq falokatgacha bo‘lgan butun tarixni yana o‘z ichiga oladi.

Reflog cheklovlari:

1. Faqat mahalliy. Reflog .git/logs/HEAD ichida saqlanadi; masofaviy omborda bo‘lmaydi. Force-push qilib, keyin mahalliy ombor nusxasini o‘chirsangiz, reflog ham papka bilan birga yo‘qoladi.
2. Odatiy holatda 90 kun. Eski yozuvlar git gc tomonidan o‘chirib yuborilishi mumkin. Buni git config gc.reflogExpire 200.days.ago bilan sozlashingiz mumkin.
3. HEAD’da hech qachon bo‘lmagan narsani qamramaydi. Agar commit faqat stash’da bo‘lib, stash yo‘q qilingan bo‘lsa, reflog uning ichki tarixini emas, faqat stash’ning eng so‘nggi holatini ko‘rsatadi.

Jamoa qoidasi: falokat yuz bergan zahoti git gc --aggressive ishlatmang. Avval reflog yordamida vaziyatni tekshirib, ishni tiklang; qolgan hamma ishni keyin qiling. Kerakli barcha narsalar push qilinganiga ishonch hosil qilmaguningizcha mahalliy ombor klonini ham o‘chirmang.

CLAUDE.md orqali loyihani buzuvchi git buyruqlaridan qanday himoyalaysiz?#

Zaiflik shundaki, Claude’da odatiy holatda himoya konteksti yo‘q. U “orqaga qaytar”ni git reset --hard deb talqin qiladi, chunki texnik jihatdan bu yaroqli usul. Himoyani loyihaning tizim so‘rovi fayli bo‘lgan CLAUDE.md ichiga joylashtiring.

Minimal qoida (CLAUDE.md faylingizga qo‘shing):

## Git xavfsizlik protokoli

- Men bu amallarni ochiq so‘ramagunimcha, HECH QACHON buzuvchi git buyruqlarini (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) bajarmang. Ruxsatsiz buzuvchi amallar foyda bermaydi va ish yo‘qolishiga olib kelishi mumkin.
- “orqaga qaytar”, “oldingi holatga bor”, “tikla”, “qaytar”, “bekor qil” deganimda, buni KO‘RIB CHIQISH buyruqlari sifatida talqin qiling: `git log`, `git diff`, `git checkout <commit>` (ajratilgan HEAD yaratadi) yoki `git stash`dan (o‘zgarishlarni saqlaydi) foydalaning.
- Quyidagi holatlarning HAR BIRIDA buyruqni bajarishdan oldin tasdiqni so‘rang:
  - Tarmoqdagi HEAD holatini boshqa commitga o‘zgartiradi
  - Commit tarixini o‘zgartiradi
  - Commit qilinmagan ishni yo‘qotishi mumkin
  - --hard, --force, --aggressive bayroqlarini o‘z ichiga oladi
- Har qanday buzuvchi buyruqdan oldin raqamlangan taqqoslashni ko‘rsating:
  - XAVFSIZ: vaqtincha ko‘rish uchun `git checkout <commit>`dan foydalanish
  - BUZUVCHI: butunlay yo‘q qilish uchun `git reset --hard`dan foydalanish
- Bajarishdan oldin mening aniq tanlovimni kuting.

Jamoa uchun kengaytirilgan qoida (ombor ildizidagi CLAUDE.mdga qo‘shing):

## Git ish jarayoni qoidalari

- Ishlaydigan bosqichda commit qiling. WIP’dan oldin `git status` va `git diff` ni ko‘ring, faqat ko‘rilgan nomli fayllarni `git add -- path/to/file` bilan stage qiling, so‘ng staged diff’ni tekshiring. Taymer butun daraxtni stage qilish ruxsati emas, ko‘rik eslatmasi.
- Claude commitlari uchun hech qachon `git add .` yoki `git add -A` ishlatmang. Faqat `git status` + `git diff`dan keyin fayllarni nomi bilan belgilang.
- `main` tarmog‘iga `git push --force` qilishdan oldin to‘xtab, mendan so‘rang. Funksional tarmoqlarda oldingi versiyani yo‘qotishga roziligimga amin bo‘lsangizgina, ehtiyotkorlik bilan force-push qiling.
- Birlashtirish ziddiyatlarini hal qilayotganda darhol “ours” yoki “theirs”ni tanlamang — avval ikkala variantni ko‘rsating, keyin men qaror qilaman.
- `.gitignore` ichida `.env*`, `.claude/personal/`, `node_modules/`, `dist/` bo‘lishi shart. Bular yo‘q bo‘lsa, qo‘shing.

Bu bloklarni qo‘shganingizdan keyin, “oxirgi push holatiga qaytar” degan ibora shunday javobga olib keladi:

Men 3 ta commit qilinmagan fayl va oxirgi pushdan oldinda turgan 4 ta commitni ko‘ryapman. Ikkita variant:

1. XAVFSIZ: push holatini ko‘rish uchun git checkout <last-push-hash> orqali view-last-push tarmog‘ini yarataman — barcha ishni saqlayman, push qilingan holatni esa vaqtincha ko‘rsataman.
2. BUZUVCHI: git reset --hard <last-push-hash> — 4 ta commit va commit qilinmagan o‘zgarishlarni butunlay yo‘q qilaman. Ularni faqat 90 kun ichida git reflog orqali tiklash mumkin. Qaysi birini tanlaysiz?

Bu — yo‘qolgan to‘rt soat o‘rniga yarim daqiqalik suhbat.

Claude Code’da bekor qilishning 5 usuli qanday va to‘g‘risini qanday tanlash mumkin?#

“Claude buzib qo‘ydi, zudlik bilan tiklashim kerak” degan holatda ushbu zinapoyadan eng pastidan boshlab harakat qiling. Har doim 1-darajadan boshlang.

1-daraja. /rewind — seans ichida darhol bekor qilish.

Esc Esc bosing yoki /rewind yozing. Buzilishdan oldingi nuqtani tanlang. Rejimni tanlang (odatda Restore code and conversation). Bir soniyadan so‘ng o‘tmishga qaytasiz va boshidan boshlashingiz mumkin. “Claude noto‘g‘ri ish qildi” holatlarining 80%ini qamrab oladi.

2-daraja. git checkout . — commit qilinmagan barcha o‘zgarishlarni bekor qilish.

git diff                    # avval aslida nima o‘zgarganini ko‘ring
git checkout .              # barcha fayllardagi commit qilinmagan o‘zgarishlarni bekor qilish
# yoki tanlab:
git checkout -- path/to/file.ts   # faqat bitta fayl

/rewind ishlamaganida (masalan, Claude fayllarga bash orqali tegsa) yoki seans tarixidan tashqaridagi o‘zgarishlarni bekor qilish kerak bo‘lsa foydali. Commit qilinmagan barcha o‘zgarishlar butunlay yo‘qoladi. Bundan afsuslanishingiz mumkin bo‘lsa, avval git stashni bajaring (2.5-darajaga qarang).

2.5-daraja. git stash — o‘zgarishlarni javonga qo‘yish.

git stash save "might still need this"
# toza holatga qaytish (o‘zgarishlarsiz)
# ...
# fikringizdan qaytsangiz — stash'dan tiklang:
git stash pop

“Abadiy yo‘qotish” va “o‘z holicha qoldirish” o‘rtasidagi yaxshi murosadir. Uni ochiqchasiga tozalamaguningizcha stash mahalliy holda qoladi.

3-daraja. git checkout <commit> — tarixni yo‘qotmasdan eski commitga qaytish.

git log --oneline               # to‘g‘ri commit xeshini toping, masalan, abc1234
git checkout abc1234            # ajratilgan HEAD — hech narsani o‘zgartirmay ko‘rish
# holat ma’qul bo‘lsa, undan tarmoq yarating:
git checkout -b recovery abc1234
# qaytish:
git checkout main

Bu xavfsiz “vaqtinchalik qaytish”dir. Ajratilgan HEAD tarmoqni o‘zgartirmaydi; maindagi (yoki qaysi tarmoqda bo‘lgan bo‘lsangiz, o‘sha yerdagi) joriy ishingiz butun qoladi. Shu holat ustida ishlamoqchi bo‘lsangiz, tarmoq yarating.

4-daraja. git reset --hard <commit> — tarmoqni ma’lum nuqtaga qaytarish.

⚠️ Buzuvchi. Ko‘rsatilgan xeshdan keyingi commitlar yetim qoladi.

git reflog                                  # joriy holat xeshini yozib oling
git reset --hard abc1234                    # tarmoqni qayta yozish
# xato topdingizmi? reflog orqali qayting:
git reset --hard HEAD@{1}                   # resetdan oldingi holatga

Faqat oldindagi commitlar kerak emasligiga amin bo‘lsangiz foydalaning. Va fikringizdan qaytsangiz qayerga qaytishni bilish uchun resetdan OLDIN doim git reflogni tekshiring.

5-daraja. git reflog + tiklash — halokatli vaziyat.

Kimdir (Claude, siz yoki hamkasbingiz) allaqachon git reset --hard yoki force-push qilib, ishni yo‘qotgan. Nima qilish kerak?

git reflog                                          # falokatdan oldingi oxirgi xeshni qidiring
git branch recovered HEAD@{N}                       # undan tarmoq yarating
git checkout recovered                              # unga o‘ting
git diff main                                       # joriy holat bilan solishtiring
git checkout main && git merge recovered            # ishonchingiz komil bo‘lsa, main’ga tiklang

Agar reflog allaqachon tozalangan bo‘lsa (odatda 90 kundan keyin), oxirgi chora — .git/objects/ ichidagi osilib qolgan commitlarni ko‘rsatadigan git fsck --lost-found buyrug‘i. Bu deyarli arxeologiya, lekin ba’zan yordam beradi.

Darajani tanlash qoidasi:

Bekor qilishga hojat qolmasligi uchun loyihani qanday himoyalash mumkin?#

1-qoida. Har 30 daqiqada commit qiling.

“Vazifa tugadi” deb kutmang. Ishlaydigan har qanday oraliq qadamni commit qiling. Commit xabarlari qanday bo‘lishidan qat’i nazar, asosiysi Claude (yoki siz) bitta git checkout buyrug‘i bilan ishlaydigan holatga qayta olishingizdir.

# vazifa boshida
git status                        # staged va unstaged yo‘llarni ko‘ring
git diff                          # tahrirlarni tekshiring
# Misolni haqiqatan tekshirilgan fayl yo‘liga almashtiring.
git add -- path/to/file.ts
git diff --cached                 # commit tarkibini tasdiqlang
git commit -m "wip: starting User schema migration"

# 30 daqiqadan keyin (yoki birinchi ishlaydigan takrorlashdan so‘ng)
git status
git diff
git add -- path/to/file.ts         # haqiqiy tekshirilgan yo‘l; wildcard emas
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# vazifa oxirida — mazmunli commit
git reset --soft HEAD~2           # uchta wip commitni bittaga birlashtiring
git commit -m "feat(auth): add lastLoginAt field to User table"

PostToolUse eslatmasi qo‘shsangiz, ko‘rik va aniq yo‘l staging qoidasini saqlang. Taymerni tekshirilmagan auto-commit’ga aylantirmang: begona tahrir yoki avval staged fayl commit’ga kirishi mumkin.

2-qoida. Minimal .gitignore.

Loyiha ildizida quyidagi satrlar bo‘lishi shart:

# maxfiy ma’lumotlar
.env
.env.local
.env.*.local

# mahalliy Claude Code sozlamalari (jamoa omboriga push qilinmaydi)
.claude/personal/
.claude/sessions/
.claude/file-history/

# bog‘liqliklar va yig‘ish natijalari
node_modules/
dist/
.next/
build/

Men .claude/personal/ papkasini shaxsiy tajribalarim va qaydlarim uchun saqlayman, u umumiy omborga kiritilmasligi kerak. .claude/sessions/ va .claude/file-history/ papkalari Claude Code’ning mahalliy xotirasidir; ular omborga tegishli emas, ko‘p joy egallaydi va muayyan mashinaga bog‘langan.

3-qoida. Tajribalarni alohida tarmoqda bajaring.

Vazifa katta bo‘lsa (10+ faylni refaktorlash, yangi ma’lumotlar bazasiga o‘tish, modulni qayta yozish), uni asosiy tarmoqda bajarmang:

git checkout -b experiment/auth-rewrite
# ishlang, har 30 daqiqada commit qiling
# ishlasa:
git checkout main
git merge experiment/auth-rewrite
# ishlamasa:
git checkout main
git branch -D experiment/auth-rewrite     # tarmoqni o‘chirish
# tamom, asosiy tarmoq butun qoladi

Bu oddiy odat “Claude loyihani vayron qildi” holatini “Claude bitta tarmoqni vayron qildi, men uni o‘chirdim va boshidan boshladik” holatiga aylantiradi.

4-qoida. Xavfli amallardan oldin git tag ishlating.

Ma’lumotlar bazasi migratsiyasi, katta refaktorlash yoki bog‘liqliklarni yangilashdan oldin teg yarating:

git tag pre-prisma-migration-v2
# ishlang
# nimadir noto‘g‘ri ketsa:
git reset --hard pre-prisma-migration-v2
# yoki shunchaki ko‘ring:
git checkout pre-prisma-migration-v2

Teg — reflog tozalanganidan keyin ham yo‘qotmaydigan commitga nomlangan ko‘rsatkich.

Keyingi mavzu: bekor qilish kontekst muhandisligiga qanday kiradi?#

Bekor qilishning bu uch darajasi buzilish yuz berganda holatni tiklash ko‘nikmasining infratuzilmasidir. Bu ko‘nikmaning o‘zi tor doirada. Ammo boshqa kontekst muhandisligi vositalari bilan qo‘shilganda, u yanada muhim narsaga aylanadi.

Plan Mode kodni darhol yozishga ruxsat bermaydi — avval reja, keyin tasdiq, so‘ng bajarish keladi. Bu profilaktik bekor qilishdir: reja oldindan ko‘rib chiqilgani uchun keyin bekor qilishingizga to‘g‘ri keladigan narsani yozmaysiz. Batafsil ma’lumotni Claude Code’dagi Plan Mode qo‘llanmasidan o‘qing.

CLAUDE.md Claude odatda amal qiladigan qoidalarni belgilaydi, jumladan, yuqorida ko‘rib chiqqan Git xavfsizlik protokolini. Bu buzuvchi buyruqlardan profilaktik himoyadir.

Ikkinchi miya Claude’ga seanslar oralig‘ida loyiha xotirasini beradi — u qanday kod borligini, biznes mantiqi nimadan iboratligini va avval qanday kelishuvlar qilinganini biladi. Xotira qancha ko‘p bo‘lsa, noto‘g‘ri ish qilish ehtimoli shuncha kam.

Skills va subagentlar — metodologiyangizning koddagi ifodasidir. To‘g‘ri git ish jarayoni Skill’ga kiritilgan bo‘lsa, hech bir subagent tasdiqsiz git reset --hard bajarmaydi.

Bularning barchasi birgalikda Kontekst muhandisligidir. So‘rov vaqtida emas, undan oldin kontekstni boshqaring. Batafsil ma’lumotni kontekst muhandisligi nima maqolasidan o‘qing.

Bekor qilish — oxirgi himoya chizig‘i. Plan Mode + CLAUDE.md + Ikkinchi miya + Skills — dastlabki to‘rtta himoya chizig‘i. Ular sozlangan bo‘lsa, bekor qilish kam va tez-tez emas. Sozlanmagan bo‘lsa, bu kundalik odatga aylanadi.

Rejalarni tuzish tugagan joydan bekor qilish boshlanadi.

Ailoot’ni oching.