# Claude Code’da Spec Kit’ni 2026-yilda sozlash: so‘rovlar o‘rniga spetsifikatsiyalar
> Claude Code’da GitHub Spec Kit’ni sozlash: 4 bosqich — Specify, Plan, Tasks, Implement. Improvised vibe coding o‘rniga qanday yondashuvni qo‘llash mumkin.
Source: https://ailoot.ai/blog/uz/spec-kit-claude-code-spec-driven-development/
Canonical: https://ailoot.ai/blog/uz/spec-kit-claude-code-spec-driven-development/
Language: uz
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-219
Revision: sha256-6dd872158f4ffd7eff501a5b16f7643e7e3aed872eaca22ea016171f8042eb84
Asosiy xulosa
Spec Kit — GitHub vositasi bo‘lib, u topshiriq spetsifikatsiyasini tabiiy tilda yozish imkonini beradi. Shundan so‘ng Claude Code reja tuzadi, uni vazifalarga ajratadi va kod yozadi. Bu nazariya emas: 8 oyda GitHub’da 107 000 yulduz to‘plandi, AWS shu metodologiya bilan dori kashf etish loyihasini bir necha oy o‘rniga 3 haftada yaratdi. Ushbu qo‘llanmada o‘rnatish, andozalar, ish jarayonining 4 bosqichi yakuniy tekshiruv bilan birga, shuningdek uni CLAUDE.md bilan ulash ko‘rib chiqiladi.
[Ailoot hujjatlari](https://ailoot.ai/docs/) — xizmatdan foydalanish bo‘yicha ma’lumotnoma materiallari.
## 2026-yil mayida vibe coding’ga nima bo‘ldi?
Asosiy xulosa
GitHub Spec Kit 8 oy ichida 107 000 yulduz yig‘di, AWS esa bitta funksiyada 80+ soat tejalganini qayd etgan amaliy misolni e’lon qildi. May oyining haftalik trendi: improvizatsiya o‘rniga spetsifikatsiya.
Bir yil o‘tib, 2026-yil 4-fevralda u retrospektiv mavzudagi postlar turkumini e’lon qildi:
Sequoia Ascent 2026’dagi chiqishida u buni yanada aniq ifodaladi: “Vibe coding hammaning dasturiy ta’minot bo‘yicha qila oladigan ishlar darajasini ko‘taradi. Agentic engineering esa professional ishlab chiqish sifat mezonini saqlab qoladi.” Shu sahnaning o‘zida u sohani tanitgan yana bir jumlani aytdi: “Vibe coding sababli zaifliklar kiritishga haqqingiz yo‘q. Avvalgidek, dasturiy ta’minotingiz uchun baribir siz javobgarsiz.”
Ikki voqea parallel ravishda yuz berdi. 2025-yil sentabrida GitHub [Spec Kit](https://github.com/github/spec-kit) vositasini chiqardi — u 8 oy ichida 107 000 yulduz to‘pladi. 2026-yil fevralida AWS [dori kashf etish bo‘yicha batafsil amaliy misolni](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) e’lon qilib, “biznes mantiqining 95% spetsifikatsiyadan yaratildi, 80+ soat tejaldi” deb xabar berdi.
2026-yil mayining oxiriga kelib, ingliz tilidagi axborot makonida umumiy qarash shakllandi: ish usuli sifatidagi vibe coding — boshlang‘ich daraja. Keyingi bosqich — Spec-Driven Development. Ushbu qo‘llanmada yondashuvni qanday o‘rnatish va qo‘llash tushuntiriladi.
## Spec Kit va Spec-Driven Development nima?
Asosiy xulosa
Spec-Driven Development (SDD) AI agent bilan ishlashdagi odatiy yondashuvni ostin-ustun qiladi. Ilgari kod haqiqat manbai, spetsifikatsiya esa unga ilova qilingan hujjatlar edi. Endi spetsifikatsiya haqiqat manbai bo‘lib, kod uning yakuniy bosqichi — amalga oshirilishiga aylanadi. Spec Kit — GitHub’ning CLI vositasi bo‘lib, 4 bosqichni (Specify, Plan, Tasks, Implement) va yakuniy Converge tekshiruvini Claude Code, Cursor, Copilot va 30+ boshqa agentlarda ishlatishga tayyor buyruqlarga aylantiradi.
Metodologiyaning asosiy g‘oyasi GitHub’ning rasmiy hujjatlaridagi bir jumlada ifodalangan:
Spec-Driven Development iyerarxiyani o‘zgartiradi: spetsifikatsiyalar kodga xizmat qilmaydi — kod spetsifikatsiyalarga xizmat qiladi. Spetsifikatsiya asosiy artefaktga, kod esa uning muayyan til va freymvorkdagi ifodasiga aylanadi.
— GitHub Spec Kit hujjatlari, https://github.com/github/spec-kit/blob/main/spec-driven.md
Amalda bu 4 bosqichda amalga oshadi (Spec Kit yana bitta, nol-bosqichni — quyida tasvirlangan konstitutsiyani — qo‘shadi):
1. **Specify** — tabiiy tilda nimani xohlayotganingizni spetsifikatsiya qilib yozing. NIMA qilish kerak va NEGA. QANDAY emas.
2. **Plan** — agent spetsifikatsiyani olib, texnik reja tuzadi: qaysi texnologiyalar, qanday arxitektura va qaysi komponentlar.
3. **Tasks** — agent rejani bog‘liqliklari bo‘lgan aniq, tekshiriladigan vazifalarga ajratadi.
4. **Implement** — agent (yoki uning yordamchi agentlari) vazifalarni bajarib, kod yozadi.
Implement’dan keyin Spec Kit’ning joriy versiyasida **Converge** deb ataladigan tekshiruv bosqichi bor: agent tayyor kodni spetsifikatsiya, reja va vazifalar bilan solishtiradi, so‘ng o‘tkazib yuborilgan narsalarni `tasks.md` fayliga qo‘shadi. Converge “Converged” deb javob berguncha Implement va Converge’ni takrorlang.
Har bir bosqich repodagi alohida markdown fayli bilan ifodalanadi. Claude Code’da har bir bosqich alohida slash-buyruq: `/speckit-specify`, `/speckit-plan`, `/speckit-tasks`, `/speckit-implement`, tekshiruv esa `/speckit-converge`. Spec Kit hujjatlarida shu buyruqlar nuqta bilan (`/speckit.specify`) yozilgan, ammo Claude Code’da Spec Kit ularni skill sifatida o‘rnatadi va ular defis bilan chaqiriladi. Istalgan bosqichda nimadir noto‘g‘ri ketsa, markdown faylini tahrir qiling va keyingi bosqichni qayta ishga tushiring.
Spec Kit — SDD’ning muayyan amalga oshirilgan ko‘rinishi. 2026-yil mayida u turli AI agentlari bilan 30 dan ortiq integratsiyaga ega edi. Bitta repo ichida Spec Kit Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose va yana o‘nlab agentlarda bir xil ishlaydi.
| Spec Kit bosqichi | Slash-buyruq | Repodagi artefakt |
|----|----|----|
| Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` |
| Specify | `/speckit-specify` | `specs/###-feature/spec.md` |
| Clarify (ixtiyoriy) | `/speckit-clarify` | `spec.md` ichidagi tahrirlar |
| Plan | `/speckit-plan` | `specs/###-feature/plan.md` |
| Checklist (ixtiyoriy) | `/speckit-checklist` | talablar sifatini tekshirish ro‘yxati |
| Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` |
| Analyze (ixtiyoriy) | `/speckit-analyze` | spetsifikatsiya, reja va vazifalar bo‘yicha hisobot |
| Implement | `/speckit-implement` | loyihadagi kod |
| Converge | `/speckit-converge` | “Converged” xulosasi yoki `tasks.md` ichidagi yangi vazifalar |
Demak, ish yakunida repoda faqat kod emas, balki uning spetsifikatsiyasi, rejasi va vazifalari ham bo‘ladi. Bir oy o‘tib loyihaga qaytsangiz, `spec.md`ni o‘qib, nima qilinganini va nega qilinganini tushunasiz. Bu endi “vibe coding kod borligini unutadi” degani emas — bu loyihaning ishchi xotirasi.
## Kod yozmaydigan vibe coder’ga bu nega kerak?
Asosiy xulosa
Vibe coder’ning asosiy og‘riqli nuqtasi — oldindan aytib bo‘lmaslik. Bugun agent siz uchun 20 daqiqada ishlaydigan funksiyani yaratadi; ertaga esa shunga o‘xshash topshiriqda chigallashgan kod chiqaradi. Spec Kit bu beqarorlik manbai — noaniq yozilgan topshiriqni — yo‘q qiladi. Andoza yordamida spetsifikatsiya yozsangiz, agent aniq haqiqat manbaiga ega bo‘lgani uchun izchil ishlaydi. Bundan tashqari, repoda bir oy o‘tib qaytishingiz mumkin bo‘lgan doimiy artefakt qoladi.
Spec Kit rejalashtirishni alohida bosqichlarda 4 ta slash-buyruq bilan rasmiylashtiradi. Mantiq: “puxta o‘ylab chiqish”ni “amalga oshirish”dan ajrating, shunda ular turli kontekst oynalarida bajariladi. Har bir bosqich oldingisi bilan to‘lib ketmagan toza kontekstga ega bo‘ladi.
Vibe coder uchun uchta aniq foyda:
- **Oldindan aytib bo‘lish.** Agentga “elektron pochta tasdig‘i bilan ro‘yxatdan o‘tish formasini yarat” desangiz, u o‘zi 10 ta tafsilotni taxmin qiladi — va ulardan uchtasini siz xohlagan narsaga nisbatan noto‘g‘ri topadi. User Stories, Acceptance Scenarios va har bir noaniq joydagi `[NEEDS CLARIFICATION]` belgilari bor `spec.md` bo‘lsa, taxmin qilishga o‘rin qolmaydi.
- **Loyiha xotirasi.** Bir oy o‘tib agent bilan chatda nimalarni muhokama qilganingizni eslay olmaysiz. Ammo `spec.md`, `plan.md` va `tasks.md` kod bilan birga `specs/###-feature/` papkasida repoda turadi. Ular nafaqat nima qilinganini, balki nega qilinganini ham ko‘rsatadi.
- **Ko‘lamni kengaytirish.** 1-2 ta faylli funksiya uchun farq zo‘rg‘a bilinadi. 20 ta fayl va 5 ta ma’lumot obyektiga ega funksiya uchun farq “4 soatdan keyin hammasini qayta yozish” bilan “4 soatdan keyin hammasi asosiy tarmoqqa qo‘shilgan” o‘rtasidagi farqdir. AWS Kiro TargetID loyihasida spetsifikatsiyadan biznes mantiqining 95% avtomatlashtirilganini ko‘rsatdi.
Vibe coding’ning asosiy xayoli — boshida tezroq ko‘rinishidir. Yarim soatda prototip tayyor. Ammo bir haftaga borib prototip buziladi va uni tashlab yuborish osonroq bo‘ladi. Spec-Driven Development boshida biroz ko‘proq vaqt oladi (yarim soat o‘rniga bir soat), ammo bir haftadan keyin ham o‘sha repoda ishlayotgan bo‘lasiz.
## Claude Code’da Spec Kit’ni qanday o‘rnatish mumkin (4 qadam)
Asosiy xulosa
Spec Kit Astral’ning Python paket menejeri uv orqali o‘rnatiladi. Buyruqning o‘zi bir satr. O‘rnatgandan so‘ng repoga o‘ting, `--integration claude` bayrog‘i bilan `specify init`ni ishga tushiring (yoki agentlar ro‘yxatidan Claude Code’ni tanlang), natijada konstitutsiya, spetsifikatsiya, reja va vazifalar andozalari, shuningdek bevosita Claude Code ichidagi `/speckit-*` buyruqlari bilan tayyor tuzilma hosil bo‘ladi. uv oldindan o‘rnatilgan bo‘lsa o‘rnatish 5 daqiqa, uni boshidan o‘rnatsangiz 10 daqiqa oladi.
**1-qadam. uv’ni o‘rnating.** Buni faqat bir marta qilish kerak; u tizimingizda qoladi.
```bash
# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
```
uv o‘rnatilganini tekshiring:
```bash
uv --version
```
**2-qadam. Spec Kit’ni o‘rnating.** Bitta buyruq:
```bash
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
```
Tekshiring:
```bash
specify --version
```
**3-qadam. Repoda boshlang‘ich sozlashni bajaring.** Loyiha papkangizga o‘ting (yoki yangisini yarating) va ishga tushiring:
```bash
specify init --here --integration claude
```
`--integration claude` bayrog‘i Claude Code’ni bevosita tanlaydi. Usiz Spec Kit agentni interaktiv ro‘yxatdan tanlashni so‘raydi, shuningdek skript turini ham so‘rashi mumkin (macOS va Linux uchun `sh` holicha qoldiring). Papka bo‘sh bo‘lmasa, Spec Kit o‘z fayllarini siznikilar bilan birlashtirishini ogohlantiradi: avval ishingizni commit qiling, keyin buyruqni `--force` bayrog‘i bilan takrorlang.
Shundan so‘ng repoda quyidagilar paydo bo‘ladi:
```
.specify/
memory/
constitution.md # loyiha qoidalari, /speckit-constitution tomonidan to‘ldiriladi
scripts/
templates/
spec-template.md
plan-template.md
tasks-template.md
.claude/
skills/
speckit-constitution/SKILL.md
speckit-specify/SKILL.md
speckit-clarify/SKILL.md
speckit-plan/SKILL.md
speckit-checklist/SKILL.md
speckit-tasks/SKILL.md
speckit-analyze/SKILL.md
speckit-implement/SKILL.md
speckit-converge/SKILL.md
speckit-taskstoissues/SKILL.md
```
**4-qadam. Claude Code’ni oching va slash-buyruqlarni tekshiring.** Buni o‘sha papkada ishga tushiring:
```bash
claude
```
Sessiyada `/speckit` deb yozing — takliflarda `speckit-*` buyruqlari paydo bo‘lishi kerak. Ko‘rinmasa, `.claude/skills/`ni qayta o‘qishi uchun Claude Code’ni qayta ishga tushiring. Loyiha ildizida `CLAUDE.md` allaqachon bo‘lsa, Spec Kit uni o‘z holicha qoldiradi — u `.specify/memory/constitution.md` bilan yonma-yon ishlaydi.
Spec Kit Claude Code’siz ham ishlaydi (u 30+ agentni qo‘llab-quvvatlaydi), ammo ushbu qo‘llanma aynan Claude bilan sozlashni yoritadi. Agar darhol ikkita vositani o‘rnatmoqchi bo‘lsangiz, [CLAUDE.md’ni sozlash](https://ailoot.ai/blog/uz/claude-md-template/) va [Claude Code’dagi Plan Mode](https://ailoot.ai/blog/uz/claude-code-plan-mode/) bo‘yicha alohida qo‘llanmalarga qarang.
Spec Kit — “agent bilan ishlash shartnomasi”ning birinchi qurilish bo‘lagi. To‘liq sozlama uch narsani o‘z ichiga oladi: AI klon (Skills va subagentlar ko‘rinishidagi metodologiyangiz), Second Brain (agent har safar qaytadigan `business/` tuzilmasi) va kontekst muhandisligi (Spec Kit, Plan Mode, /compact). Bular AI gallyutsinatsiyalarining oldini oladigan uch ustundir.
## Birinchi spetsifikatsiyani qanday yozish mumkin (Specify)
Asosiy xulosa
Spec Kit funksiyani erkin shaklda tasvirlashingizni so‘raydi, keyin esa andoza yordamida bu tavsifni `spec.md` fayliga kengaytiradi: P1/P2/P3 ustuvorliklariga ega User Stories, Given/When/Then formatidagi Acceptance Scenarios, Functional Requirements (FR-001, FR-002 va hokazo) hamda o‘lchanadigan natijalarga ega Success Criteria. Agent nimagadir ishonchi komil bo‘lmagan joylarga `[NEEDS CLARIFICATION: ...]` belgisini qo‘shadi — Plan bosqichiga o‘tishdan oldin ularga javob berasiz.
Claude Code’da quyidagini yozing:
```
/speckit-specify
```
Shunda agent funksiyaning tavsifini so‘raydi. Bu bosqichda texnik jargon ishlatmay, oddiy tilda yozing:
```
Ilovamda ro‘yxatdan o‘tish formasi kerak. Foydalanuvchi elektron pochta
va parolni kiritadi, tasdiqlash xatini oladi va tasdiqlagandan so‘ng
boshqaruv paneliga o‘tadi. Tasdiqlash 48 soatda tugaydi. Email hali
tasdiqlanmagan bo‘lsa, shu muddatdan keyin 5 daqiqa ichida hisobni o‘chiring;
tasdiqlangan hisobni hech qachon o‘chirmang.
```
Bu misolda o‘chirishga ruxsat etilgan kechikish 48 soatdan keyin 5 daqiqa deb aniqlashtirildi. Haqiqiy mahsulotda Plan’dan oldin shu tolerantlikni tasdiqlang. Aynan 48 soat talabi kuchliroq dizayn va test talab qiladi. Agent `specs/001-registration/spec.md` tuzadi; unda quyidagiga o‘xshash tuzilma bo‘ladi:
```markdown
# Funksiya spetsifikatsiyasi: Foydalanuvchini ro‘yxatdan o‘tkazish
**Funksiya tarmog‘i**: `001-registration`
**Yaratilgan**: 2026-05-31
**Holat**: Qoralama
**Kiritilgan matn**: Foydalanuvchi tavsifi: "Menga ro‘yxatdan o‘tish formasi..."
## Foydalanuvchi ssenariylari va sinov *(majburiy)*
### Asosiy foydalanuvchi tarixi
Yangi foydalanuvchi sifatida, elektron pochta tasdig‘i bilan hisob
ro‘yxatdan o‘tkazmoqchiman,
shunda tasdiqlangan shaxs bilan boshqaruv paneliga kira olaman.
### Qabul qilish ssenariylari
1. **Agar** ro‘yxatdan o‘tish sahifasida bo‘lsam,
**Qachon** yaroqli elektron pochta va parolni yuborsam,
**Unda** 1 daqiqa ichida tasdiqlash xati olaman.
2. **Agar** tasdiqlash havolasini 48 soat ichida bossam,
**Qachon** boshqaruv paneliga kirsam,
**Unda** profilimda elektron pochtam tasdiqlanganini ko‘raman.
3. **Agar** 48 soat chegarasida tasdiqlamagan bo‘lsam,
**Qachon** keyingi 5 daqiqada cleanup bajarilsa,
**Unda** hisobim o‘chib, email qayta ro‘yxat uchun bo‘shaydi.
4. **Agar** hisobim hali 48 soatga yetmagan yoki tasdiqlangan bo‘lsa,
**Qachon** cleanup bajarilsa,
**Unda** hisob o‘chirilmaydi.
## Talablar *(majburiy)*
### Funksional talablar
- **FR-001**: Tizim ro‘yxatdan o‘tishni qabul qilishi SHART: [ANIQLASHTIRISH KERAK:
faqat email/parolmi yoki SSO/OAuth ham bormi?]
- **FR-002**: Tizim 60 soniya ichida tasdiqlash xatini yuborishi SHART
- **FR-003**: Tasdiqlash 48 soatda tugashi SHART; hali tasdiqlanmagan
hisob shu muddatdan 5 daqiqa kechiktirmay o‘chirilishi SHART;
tasdiqlangan hisob o‘chirilmasligi SHART
- **FR-004**: Tizim ro‘yxatdan o‘tishga oid barcha urinishlarni [ANIQLASHTIRISH
KERAK: jurnallar qancha saqlanadi — 30 kun, 90 kun, abadiymi?] muddat davomida qayd etishi SHART
### Asosiy obyektlar
- Foydalanuvchi: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at
## Muvaffaqiyat mezonlari *(majburiy)*
- **SC-001**: Tasdiqlash xatlarining 95% 60 soniya ichida yetkaziladi (p95)
- **SC-002**: Tasdiqlangan hisoblarning tasodifiy o‘chirilishi 0 ta
- **SC-004**: 48 soatdan oldin o‘chirish yo‘q; sinov yuklamasida har mos
tasdiqlanmagan hisob 48 soat 5 daqiqagacha o‘chiriladi
- **SC-003**: Ro‘yxatdan o‘tishni yakunlash darajasi > 60% (forma ochilishidan boshqaruv paneligacha)
```
`[NEEDS CLARIFICATION: ...]` belgilariga e’tibor bering. Spec Kit agent sizning matningizdan aniq javob ololmagan joylarga ataylab shularni qo‘shadi. Plan bosqichiga o‘tishdan oldin `spec.md` ichida ularga qo‘lda javob berishingiz yoki `/speckit-clarify`ni ishga tushirishingiz kerak; bunda agent noaniq nuqtalarni birma-bir ko‘rib chiqib, muloqot davomida savollar beradi.
Spec Kit’da ichki `/speckit-clarify` buyrug‘i og‘zaki “menga savollar ber” iborasining o‘rnini bosadi. Natija bir xil: `spec.md` ichida `[NEEDS CLARIFICATION]` belgilari qolmaguncha Plan’ga o‘tmaysiz.
`spec.md`da texnologiyalar bo‘lmasligi kerak. React, Postgres, Prisma yoki Redis tilga olinmaydi. Spetsifikatsiya tizim foydalanuvchi va biznes nuqtayi nazaridan nima qilishini tasvirlaydi. Texnologiyalar to‘plami keyingi bosqichda tanlanadi.
## Plan bosqichida Claude nima qiladi?
Asosiy xulosa
`/speckit-plan` buyrug‘i tayyor spetsifikatsiyani olib, texnik reja tuzadi: qaysi texnologiyalardan foydalanish, qanday arxitektura, qaysi modullar, ma’lumot obyektlari va API shartnomalari kerak. Reja `specs/###-feature/plan.md` fayliga yoziladi, shartnomalar alohida `contracts/` papkasiga eksport qilinadi, ma’lumotlar modeli esa `data-model.md` ichiga tushadi. Bu bosqichda Claude CLAUDE.md va konstitutsiyadan texnologiyalar to‘plamingizni biladi, shu sabab reja “hammasini Rust’da qayta yozaylik” deb taklif qilmay, mavjud loyihaga mos keladi.
`spec.md` tayyor bo‘lgach, ishga tushiring:
```
/speckit-plan
```
Ixtiyoriy ravishda buyruqqa texnologiyalar bo‘yicha ko‘rsatmalarni bevosita qo‘shing:
```
/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email
```
Claude uchta manbani o‘qiydi: `spec.md`, `CLAUDE.md` (yoki `memory/constitution.md`) va repodagi mavjud kod. Natijada taxminan quyidagi tuzilishga ega `plan.md` hosil bo‘ladi:
```markdown
# Amalga oshirish rejasi: Foydalanuvchini ro‘yxatdan o‘tkazish
## Texnik kontekst
- Freymvork: Next.js 14 App Router
- Ma’lumotlar bazasi: Prisma orqali PostgreSQL
- Elektron pochta: Resend (bitta uzatish kanali)
- Tekshirish: umumiy lib ichidagi Zod sxemasi
- Autentifikatsiya: credentials provayderli NextAuth.js
## Arxitektura qarorlari
### 1. Tokenlarni saqlash
Tokenlar JWT’da emas, DB’da saqlanadi (ConfirmationToken jadvali).
Sabab: elektron pochta qayta ro‘yxatdan o‘tganda server tomonida bekor qilish kerak.
### 2. Xatlarni yetkazish
Ro‘yxatdan o‘tgandan darhol keyin ishga tushadigan cron `/api/cron/send-confirmation` orqali asinxron.
Qayta urinishlarni Resend boshqaradi.
### 3. Avtomatik o‘chirish cron’i
`/api/cron/cleanup-unconfirmed` har daqiqada ishlasin. Faqat
`created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL`
satrlarni o‘chiring. Aniqlashtirilgan misol ko‘pi bilan 5 daqiqa kechikishni
ruxsat etadi. Scheduler kechikishi va tugallash vaqtini shu chegara bilan
sinang; o‘tgan chegarani muvaffaqiyatli kunlik cleanup emas, xato deb yozing.
## Ma’lumotlar modeli
Qarang: data-model.md
## API shartnomalari
Qarang: contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation
## Amalga oshirish bosqichlari
1. Ma’lumotlar bazasi migratsiyasi (Prisma sxemasi + migratsiya fayli)
2. API yo‘llari (3 ta endpoint)
3. UI: ro‘yxatdan o‘tish formasi + tasdiqlash muvaffaqiyati sahifasi
4. Cron vazifalari (yuborish + tozalash)
5. Elektron pochta andozasi
6. Integratsion sinovlar
```
`data-model.md` obyektlar va ularning o‘zaro munosabatlarini tasvirlaydi. `contracts/` API shartnomalari uchun qoliplarni (OpenAPI YAML yoki TypeScript so‘rov/javob turlari) o‘z ichiga oladi. Bu kod emas — Claude keyinchalik haqiqiy yo‘llarga aylantiradigan maqsad bayonidir.
Plan bosqichining asosiy afzalligi — toza kontekst. Claude spetsifikatsiya va amalga oshirishni bir paytda yodda tutishga urinmaydi. Avval puxta o‘ylab, qarorni faylga yozadi, keyin davom etadi.
Keyingi ixtiyoriy buyruq — `/speckit-analyze`. U Tasks bosqichidan keyin, Implement’dan oldin ishga tushiriladi: `spec.md + plan.md + tasks.md` to‘plamidagi ziddiyatlarni ko‘rib chiqadi hamda spetsifikatsiyaning barcha talablari reja va vazifalarda qamrab olinganini tekshiradi. U fayllarni tahrirlamaydi, faqat hisobot chiqaradi. Aslida bu amalga oshirishdan oldingi rasmiy aql tekshiruvidir.
## Ishni vazifalarga qanday ajratish mumkin (Tasks)
Asosiy xulosa
`/speckit-tasks` buyrug‘i rejani aniq vazifalarga ajratadi. Har bir vazifada bog‘liqliklar, taxminiy vaqt va “parallel bajarish mumkin” yoki “qat’iy ketma-ket” belgisi bo‘ladi. Natija — `[ ] T-001: ...` belgilash ro‘yxati formatidagi `tasks.md`. Keyin bu vazifalarni `/speckit-implement` bilan bajarishga berishingiz yoki `/speckit-taskstoissues` orqali GitHub Issues’ga aylantirishingiz mumkin — ularni jamoa yoki bir nechta parallel Claude Code sessiyalari orasida taqsimlash mumkin.
`spec.md` va `plan.md` tayyor bo‘lgach, ishga tushiring:
```
/speckit-tasks
```
Claude rejani `tasks.md` fayliga kengaytiradi:
```markdown
# Vazifalar: Foydalanuvchini ro‘yxatdan o‘tkazish
## 1-bosqich: Ma’lumotlar bazasi (bog‘liqlik yo‘q)
- [ ] T-001: prisma/schema.prisma fayliga User modelini qo‘shish (parallel bajarish mumkin)
- [ ] T-002: prisma/schema.prisma fayliga ConfirmationToken modelini qo‘shish (T-001 dan keyin)
- [ ] T-003: `add-user-registration` migratsiyasini yaratish (T-002 dan keyin)
## 2-bosqich: API shartnomalari (bog‘liqlik yo‘q)
- [ ] T-004: shared/validation/auth.ts ichida Zod sxemalarini yaratish
- [ ] T-005: shared/types/auth.ts ichida TypeScript turlarini belgilash (T-004 dan keyin)
## 3-bosqich: Yo‘llar (1+2-bosqichga bog‘liq)
- [ ] T-006: POST /api/auth/register’ni amalga oshirish
- [ ] T-007: POST /api/auth/confirm’ni amalga oshirish
- [ ] T-008: GET /api/auth/resend-confirmation’ni amalga oshirish
## 4-bosqich: UI (3-bosqich bilan parallel)
- [ ] T-009: forma bilan /register sahifasini yaratish
- [ ] T-010: /register/confirm/[token] sahifasini yaratish
- [ ] T-011: /register/success sahifasini yaratish
## 5-bosqich: Cron va integratsiya (3+4-bosqichga bog‘liq)
- [ ] T-012: /api/cron/send-confirmation cron’i
- [ ] T-013: /api/cron/cleanup-unconfirmed cron’i
- [ ] T-014: registration-confirmation.tsx elektron xat andozasi
- [ ] T-015: Integratsion sinovlar (Playwright): 48h dan sal oldin, aynan
48h da, 48h 5m gacha o‘chirish, kechikkan job xatosi va tasdiqlangan
hisoblarni himoyalash
## Eslatmalar
- T-001, T-004, T-009-T-011 parallel bajarilishi mumkin (turli fayllar)
- T-002 T-001 bilan zid (bir xil fayl: schema.prisma) — ketma-ket bajaring
- T-006 uchun T-003 (qo‘llangan migratsiya) va T-005 (turlar) kerak
```
`parallel-safe` va `after T-NNN` belgilariga e’tibor bering. Bu keyinchalik bir nechta bosqichni parallel bajarishga imkon beradigan bog‘liqlik grafigidir. Spec Kit tezlashtirish yondashuvi aynan shu mexanizmga asoslanadi: ayrim vazifalarni bir vaqtning o‘zida beshta turli Claude Code sessiyasiga berish mumkin, boshqalari esa qat’iy ketma-ket bajarilishi kerak.
Spec Kit buni qutidan chiqqan holida bitta buyruq bilan avtomatik bajaradi.
Ixtiyoriy `/speckit-taskstoissues` buyrug‘i `tasks.md`ni olib, ro‘yxatdagi vazifalardan GitHub Issues yaratadi; har birida `spec.md`ga havola bo‘ladi. Bu jamoada ishlasangiz yoki GitHub Projects orqali jarayonni kuzatmoqchi bo‘lsangiz foydali.
## Subagentlar bilan qanday amalga oshirish mumkin (Implement)
Asosiy xulosa
Yakuniy `/speckit-implement` bosqichi amalga oshirishni boshlaydi. Claude `tasks.md` bo‘ylab yuqoridan pastga yurib, bajarilgan vazifalarni `[x]` bilan belgilaydi. Bir vaqtning o‘zida bir nechta parallel Claude Code sessiyasini ishga tushirishingiz mumkin — har bir sessiyaga bittadan bosqich. Har bir sessiya ichida Claude turli ishlar uchun subagentlarni ishga tushiradi: kodni ko‘rib chiquvchi, tekshiruvlarni bajaruvchi sinovchi va README yozuvchi. Bu Opus 4.8 taqdim etilganda Anthropic yozgan “1000 ta parallel subagent” yondashuvi — Spec Kit’da bu alohida mahsulot emas, oddiy ish rejimi.
```
/speckit-implement
```
Claude `tasks.md`dagi birinchi vazifadan boshlaydi. Har bir vazifa kichik sikldan o‘tadi: tegishli fayllarni o‘qish, diff yozish, sinovlarni ishga tushirish, `[x]` belgisini qo‘yish. Zarur bo‘lganda subagentlar avtomatik chaqiriladi: kodni ko‘rib chiqish uchun bittasi, linter’ni ishga tushirish uchun bittasi, regressiyalarni tekshirish uchun yana bittasi.
Qoidalar haqida esa u alohida shunday deydi:
Spec Kit’da bu sikl rasmiylashtirilgan. Haqiqat manbai sifatida `spec.md`, texnik qarorlar uchun `plan.md` va belgilash ro‘yxati sifatida `tasks.md` bor. Claude istalgan bosqichda yo‘ldan chiqsa, spetsifikatsiyaga qaytib: “Bu FR-003 talabiga mos emas; qayta bajaring”, deysiz. “Muhokama qilganlarimizni yodda tut...” deb boshlanadigan uzun so‘rovlar kerak emas — butun tarix fayllarda saqlanadi.
Agar [Opus 4.8’dagi Dynamic Workflows](https://ailoot.ai/blog/uz/claude-code-dynamic-workflows/) ulangan bo‘lsa, Spec Kit’ni to‘liq avtomatik rejimga o‘tkazishingiz mumkin: bitta `/speckit-implement` buyrug‘i bilan Claude ishni parallellashtiradi, natijalarni birlashtiradi va tekshiradi. Bir vaqtda eng ko‘pi bilan 1000 ta subagent ishlashi mumkin. Ko‘p funksiyalar uchun 10-30 tasi yetarli.
Barcha `[x]` kataklari belgilanganida va keyingi bo‘limdagi tekshiruv “Converged” deb javob berganida, PR’ni (yoki vazifalar ko‘p bo‘lsa bir nechta PR’ni) ko‘rib chiqib, birlashtirasiz. Artefaktlar — `spec.md`, `plan.md`, `tasks.md` — funksiyaning hujjatlari sifatida repoda qoladi. Bir yildan keyin mantiqni koddan teskari tahlil qilishga to‘g‘ri kelmaydi.
## Agent hech narsani o‘tkazib yubormaganini qanday tekshirish mumkin (Converge)
Asosiy xulosa
Implement’dan keyin Spec Kit’ning joriy versiyasida `/speckit-converge` deb ataladigan tekshiruv bosqichi bor. Agent tayyor kodni `spec.md`, `plan.md` va `tasks.md` bilan solishtiradi. Hammasi mos kelsa, “Converged” deb javob beradi va fayllarga tegmaydi. Kamchilik topsa, ularni `tasks.md` faylining oxiriga yangi vazifalar sifatida qo‘shadi. Keyin `/speckit-implement`ni qayta ishga tushirib, undan so‘ng `/speckit-converge`ni yana bajarasiz — “Converged” javobi chiqquncha.
```
/speckit-converge
```
Avval agent topganlarini jiddiylik darajalari bilan jamlaydi, so‘ng ikki natijadan birini beradi. “Converged” — kamchilik yo‘q, `tasks.md` baytma-bayt o‘zgarishsiz qoladi va ko‘rib chiqishga o‘tishingiz mumkin. “Tasks appended” — kamchiliklar topilgan, `tasks.md`dagi Convergence bo‘limiga qo‘shilgan va agent ularning sonini aytadi.
Converge kodni tahrirlamaydi yoki o‘chirmaydi; uning yagona yozuvi — `tasks.md` ichidagi yangi vazifalar. Shuning uchun uni bemalol ishga tushirish mumkin, lekin faqat `/speckit-implement` joriy `tasks.md`ni bajarib bo‘lgandan keyin. Har bir keyingi tekshiruvda kamroq kamchilik topiladi.
## Spec Kit CLAUDE.md va Plan Mode’dan nimasi bilan farq qiladi?
Asosiy xulosa
Bu vositalarni solishtirganda tez-tez beriladigan savol. Qisqa javob: CLAUDE.md agentning “mehnat shartnomasi”, butun loyiha uchun yagona haqiqat manbai. Plan Mode — muayyan so‘rovdan oldingi bir martalik rejalashtirish. Spec Kit esa bitta funksiyaning to‘liq hayot sikli: tavsifdan boshlab amalga oshirishgacha, repodagi artefaktlar bilan. Ular bir-birining o‘rnini bosmaydi; uch qatlamli tizim bo‘lib birlashadi: umumiy kontekst (CLAUDE.md) → loyiha konteksti (Spec Kit konstitutsiyasi) → funksiya konteksti (spec.md + plan.md + tasks.md).
Ularni 5 xususiyat bo‘yicha solishtiring:
| Xususiyat | CLAUDE.md | Plan Mode | Spec Kit |
|----|----|----|----|
| Qachon ishlaydi | Har bir sessiyada | So‘rov bo‘yicha (Shift+Tab yoki /plan) | Slash-buyruq orqali /speckit-* |
| Amal qilish muddati | Butun loyiha | Bitta sessiya | Bitta funksiya |
| Qayerda joylashadi | Repo ildizida | Claude kontekstida | `specs/###-feature/*` |
| Nimalarni saqlaydi | Texnologiyalar to‘plami, qoidalar, atamalar | Joriy reja + kuzatuvlar | spec + plan + tasks + contracts |
| Andoza | Erkin shakl (repo qoidalari) | Yo‘q | Tuzilmali markdown |
| Eng mos vazifasi | Loyiha qoidalari va texnologiyalar to‘plami | Katta o‘zgarishdan oldin qayta tekshirish | NIMA’dan KODgacha bo‘lgan to‘liq funksiya sikli |
Spec Kit atamalarida bu `.specify/memory/constitution.md` bo‘ladi. Dastlabki sozlash vaqtida Spec Kit mavjud CLAUDE.md’ni konstitutsiya uchun asos qilib olishi yoki uning yonida alohida fayl yaratishi mumkin. Men odatda CLAUDE.md’ni umumiy “shartnoma” sifatida saqlayman (texnologiyalar to‘plami, atamalar lug‘ati, joylashtirish protokoli), Spec Kit konstitutsiyasini esa shu ish jarayoniga xos qoidalar uchun ishlataman — masalan, “barcha formalar Zod orqali tekshiriladi; qo‘lda tekshiruv yo‘q.”
Plan Mode bilan bog‘liqligi oddiyroq. Plan Mode — bitta sessiya ichida “kod yozishdan oldin rejalashtirish”ning tezkor rejimi. U kichik o‘zgarishlar uchun yaxshi ishlaydi (xatoni tuzatish, funksiyani qayta tashkil qilish). Katta funksiya uchun Plan Mode yutqazadi, chunki bitta sessiyaning kontekst oynasi 3000 satrlik reja uchun juda kichik — jonli mashg‘ulotda bevosita tushuntirganimdek:
Spec Kit — kontekst muhandisligining amaliy vositasi. U “arxitektura dasturxoni”ni chatdan fayllarga ko‘chiradi. Spec.md repoda qoladi va har bir yangi Claude sessiyasi uni yana o‘qiydi — o‘zingizni takrorlashingiz shart emas.
Katta loyiha uchun sozlama:
1. **CLAUDE.md** — texnologiyalar to‘plami, atamalar lug‘ati, nimalarni qilmaslik kerakligi. U ildizda turadi.
2. **.specify/memory/constitution.md** — Spec Kit uchun, shu ish jarayoniga xos qoidalar.
3. **specs/001-feature-A/spec.md, plan.md, tasks.md** — birinchi funksiya.
4. **specs/002-feature-B/spec.md, plan.md, tasks.md** — ikkinchi funksiya.
5. Kundalik ish uchun tayyor vazifalarda `/speckit-implement` yoki o‘zgarishdan oldin tezkor qayta tekshiruvda `/plan`.
## Haqiqiy hayotdagi qaysi misollar samara beryapti?
Aniq misollar:
- **AWS Kiro — dori kashf etish agenti.** 2026-yil 18-fevral sanali [AWS Industries blog posti](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/)da jamoa TargetID loyihasini tasvirlaydi. Uch dasturchi, uch hafta, dori kashf etish agenti. Maqoladagi raqamlar: Kiro biznes mantiqi kodining 95% dan ortig‘ini yaratib, 80 soatdan ko‘proq ishlab chiqish vaqtini tejagan. Shuningdek: “Kiro yozgan README hujjatlari taxminan 8 soat tejadi” va “prompt berib, tuzatishning takroriy sikllari 40% kamroq bo‘ldi.”
- **Rackspace Technology.** O‘sha AWS blogida Rackspace shunday xabar beradi: “taxminiy 52 haftalik ishni atigi 3 haftada yakunladik”, “samaradorlik 90% ga oshdi”. Bu endi kichik funksiya emas — to‘liq korporativ loyiha.
- **GitHub Spec Kit’ning o‘sishi.** 2026-yil 7-may holatiga ko‘ra, repoda 93 000 yulduz bor edi; 31-mayga kelib esa 107 000 bo‘ldi. Uch haftada +14 000 yulduz. Bu o‘sish sur’ati yondashuv bozordagi ulushini oshirayotganining aniq belgisidir.
O‘quvchi uchun bu yondashuv nazariya emasligini anglatadi: jiddiy jamoalar uni ishlab chiqarish muhitida allaqachon qo‘llamoqda.
## Spec Kit qachon MOS KELMAYDI?
Asosiy xulosa
Spec Kit hamma joyga ham mos kelavermaydi. Uning qo‘llash maqsadga muvofiq bo‘lmagan uchta aniq holati bor: kichik tahrirlar (xatoni tuzatish, o‘zgaruvchi nomini o‘zgartirish), tajribalar va prototiplar (nimani xohlayotganingizni bilmaslikning o‘zi vibe coding’ning maqsadi bo‘lgan holatlar), shuningdek, holatlari murakkab eski kod (spetsifikatsiya yozib tugatishingizdan oldin eskirib qoladigan vaziyat). Bu holatlarni jiddiy tanqid qiluvchilar bor. Spetsifikatsiyalar yordam bermaydigan vaziyatlarda vaqtni behuda sarflamaslik uchun dalillarni bilib qo‘ygan ma’qul.
**Mos kelmaydigan holat #1 — kichik tahrirlar.** Agar vazifa “o‘zgaruvchi nomini o‘zgartirish”, “matndagi xatoni tuzatish” yoki “log qo‘shish” bo‘lsa, Specify → Plan → Tasks bosqichlaridan o‘tish tahrirning o‘zidan ko‘proq vaqt oladi. Kichik tahrirlar uchun Plan Mode yoki Claude Code’da to‘g‘ridan-to‘g‘ri ko‘rsatma berish tezroq.
**Mos kelmaydigan holat #2 — jonli tajribalar.** Hali nimani xohlayotganingizni bilmasangiz va interfeysni “sinab ko‘rishingiz” yoki “ish beradimi-yo‘qmi” deb ko‘rish uchun prototipni tezda yig‘ishingiz kerak bo‘lsa, spetsifikatsiyaning foydasi yo‘q. Bunday vaziyatda qiymatning o‘zi improvizatsiyada. “G‘oya bilan o‘ynash” bosqichida improvizatsiya yordam beradi, spetsifikatsiya emas.
**Mos kelmaydigan holat #3 — holatlari murakkab eski kod.** Biznes mantiqi tez o‘zgarsa, spetsifikatsiyalarni yangilab borish og‘ir yuk bo‘ladi.
Yana bir xavf — nazorat bor degan soxta taassurot. Tuzilmalar tartibli, ammo agentlar ko‘pincha ko‘rsatmalarni e’tiborsiz qoldiradi yoki shablonlarga haddan tashqari so‘zma-so‘z amal qiladi. Natijada tuzilishi to‘g‘ri, ammo aynan sizning repozitoriyingizga mos kelmaydigan kod chiqadi — spetsifikatsiya agent uni siz ko‘zlagandek tushunganini kafolatlamaydi.
2026-yil aprelida soha tahlilchilari waterfall usulidan ogohlantirdi: kod yozishdan oldin katta hajmli spetsifikatsiya tayyorlash — 200 sahifalik talablar davrida sohani allaqachon bir bor inqirozga olib kelgan yo‘l. O‘shandan beri muhandislar bu yondashuvga ehtiyotkorlik bilan qaraydi va bunday ehtiyotkorlik o‘rinli.
**Bunday vaziyatda nima qilish kerak.** Oddiy qoida taklif qilaman: funksiyaning hajmini spetsifikatsiya yozishga ketadigan vaqt bilan solishtiring. Agar funksiyani amalga oshirishga 2 soatdan kam vaqt ketsa, spetsifikatsiya yozmang — Plan Mode tezroq. Agar funksiya bir hafta talab qilsa, Spec Kit’dan albatta foydalaning; taxminan bir soatlik spetsifikatsiya tayyorlash xarajati vaqt tejalishi hisobiga besh baravar qoplanadi. 2 soatdan bir haftagacha bo‘lsa, o‘zingiz qaror qiling. Shaxsan men yarim kunlik funksiyalar uchun ham spetsifikatsiya yozaman, chunki repozitoriydagi hujjat tejalgan 30 daqiqadan qadrliroq.
## Keyin nima qilish kerak: Spec Kit’ni loyihangizga qanday qo‘shish mumkin?
Asosiy xulosa
Eng oson birinchi qadam — Spec Kit’ni mavjud loyihaning hammasida emas, yangi kichik funksiyada sinab ko‘rish. Uni o‘rnating, repozitoriyda ishga tushiring, bir funksiya uchun `/speckit-specify` buyrug‘ini bajaring va yaratilgan artefaktlarni ko‘ring. Bir-ikki haftadan so‘ng qachon unga o‘tish, qachon esa tezkor ko‘rsatmalardan foydalanish kerakligini his qila boshlaysiz. To‘liq metodologiya CLAUDE.md + Spec Kit + Skills + subagents’ni birlashtiradi.
Keyingi 7 kun uchun aniq reja:
- **1-kun.** uv va Spec Kit’ni o‘rnating (5–10 daqiqa). Claude Code’da `/speckit-*` buyruqlari paydo bo‘lganini tekshiring. Ularni mavjud loyihada sinab ko‘rmang — yangisidan boshlang.
- **2-kun.** Yaratmoqchi bo‘lgan haqiqiy funksiyani tanlang. Erkin shakldagi tavsif bilan `/speckit-specify` buyrug‘ini bajaring. `spec.md` faylini ochib o‘qing va har bir `[NEEDS CLARIFICATION]` belgisiga javob bering. Plan bosqichiga shoshilmang.
- **3-kun.** Texnologiyalar to‘plamingiz haqida ko‘rsatmalar bilan `/speckit-plan` buyrug‘ini bajaring. `plan.md` faylini, ayniqsa Architecture Decisions bo‘limini o‘qing. Biror joyi mos kelmasa, qo‘lda tahrir qiling.
- **4–5-kun.** Avval `/speckit-tasks`, so‘ng spetsifikatsiya, reja va vazifalarni o‘zaro tekshirish uchun `/speckit-analyze`, undan keyin `/speckit-implement` buyrug‘ini bajaring. Claude `tasks.md` faylida `[x]` belgilarini qanday qo‘yayotganini kuzating. Qaysidir joyda to‘xtab qolishi mumkin — bu odatiy. `spec.md` fayliga qaytib, talabni aniqlashtiring va `/speckit-implement` buyrug‘ini aniq vazifa bilan qayta ishga tushiring. Vazifalar tugagach, `/speckit-converge` buyrug‘ini bajaring; “Converged” javobini olguningizcha Implement va Converge ketma-ketligini takrorlang.
- **6–7-kun.** PR’ni (yoki bir nechta PR’ni) ko‘rib chiqing va birlashtiring. `spec.md` hamda `plan.md` fayllarini o‘qing — ular kelgusi yil davomida funksiya hujjatlari bo‘lib xizmat qiladi.
Parallel ravishda o‘qish uchun tavsiya etiladigan materiallar:
- [2026-yilda CLAUDE.md’ni qanday sozlash kerak](https://ailoot.ai/blog/uz/claude-md-template/) — Spec Kit konstitutsiyasining asosi.
- [Claude Code’dagi Plan Mode](https://ailoot.ai/blog/uz/claude-code-plan-mode/) — kichik vazifalar uchun tezkor muqobil.
- [2026-yilda kontekst muhandisligi](https://ailoot.ai/blog/uz/context-engineering/) — Spec Kit nima uchun ishlashini tushuntiradi.
- [Skills, Subagents, MCP yoki Plugins](https://ailoot.ai/blog/uz/skills-subagents-mcp-plugins-claude-code/) — ish jarayoningiz uchun Spec Kit’ga nimalar qo‘shish haqida.
- [Claude Code’dagi Dynamic Workflows](https://ailoot.ai/blog/uz/claude-code-dynamic-workflows/) — Implement bosqichida ko‘plab subagentlarni bir vaqtda qanday ishga tushirish haqida.
### Manbalar
- [GitHub Spec Kit — repozitoriy](https://github.com/github/spec-kit)
- [GitHub Spec Kit — rasmiy hujjatlar](https://github.github.com/spec-kit/)
- [Spec-Driven Development — metodologiyaning rasmiy matni](https://github.com/github/spec-kit/blob/main/spec-driven.md)
- [Spec shabloni — GitHub](https://github.com/github/spec-kit/blob/main/templates/spec-template.md)
- [AWS Industries Blog — Spetsifikatsiyadan ishlab chiqarishgacha: Kiro’ning dori kashf etish agenti (2026-yil 18-fevral)](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/)
- [Claude Code hujjatlari — Subagents](https://code.claude.com/docs/en/sub-agents)
- [Claude Code hujjatlari — Skills](https://code.claude.com/docs/en/skills)
- [Claude Code hujjatlari — Commands](https://code.claude.com/docs/en/commands)
To‘liq kontekst bilan ishlash jarayoni: AI klon + Second Brain + kontekst muhandisligi.
Ko‘proq materiallarni [Ailoot](https://ailoot.ai/) saytida topasiz.
## Ko‘p beriladigan savollar
### Kunlik cleanup nega 48 soatlik o‘chirishga yetmaydi?
Hisob muddati kunlik ishdan sal keyin yetsa, deyarli yana bir kun kutishi mumkin. Spetsifikatsiyada ruxsat etilgan kechikishni aniqlang, mos jadval tanlang, 48 soat chegarasi va maksimal kechikishni sinang.
### plan.md spec.md’ga zid bo‘lsa, nima qilaman?
Amalga oshirishdan oldin talabga qaytib, ziddiyatni hal qiling. Spetsifikatsiya, reja, vazifalar va qabul tekshiruvlarini birga yangilang. Analyze va amalga oshirish testlarida bir xil kelishilgan xulqni tekshiring.
## Ailoot · Kompaniya va uning loyihalar portfeli
Ailoot to‘plangan faoliyat tajribasi, keng mijozlar bazasi, barqaror xizmat va doimiy KPI nazoratiga tayanadi.
Kompaniya va uning loyihalar portfeli: millionlab mijozlar; oylik sotuvlar hajmi milliardlarda.
Ailoot bu faoliyat tajribasini mijozlar mahsulotlari, agentlar, ilovalar va avtomatlashtirishlarda AI imkoniyatlariga API orqali kirishni ta’minlashda qo‘llaydi.