| name | mini-prd |
| description | Yeni bir feature için hafif PRD üretir (tam spec-first-feature pipeline'ı değil). docs/SYSTEM.md + hedefli grep ile harmony'yi garanti eder, Entegrasyon bölümünü zorunlu kılar ve docs/prd-{feature}.progress.md ile aktif PRD işaretini kurar. prd-run bittikten sonra test-plan → qa-eval-developer → project-manager (AUTO-GO) → git push → live-test pipeline'ını otomatik tetikler. Tetikleyiciler: prd-guard uyarısı sonrası, "kısa PRD yaz", "mini PRD", "bu küçük feature için spec". |
Mini-PRD
Yeni feature küçükse tam pipeline yerine hafif ama harmony-garantili bir PRD üret.
Uzman-Ajan-Önce Soru Protokolü (LAW — operatöre sormadan önce uzman ajan KARAR VERİR)
Mini-PRD içinde çıkan HER karar/açıklama sorusu önce uzman subagent'a gider; karar onların. Kritik teknik kararlar (auth, compliance, teknoloji seçimi, veri modeli, irreversible mimari) dahil ajan karar verir — operatöre sormaz. Operatöre yalnızca ajan cevap veremediğinde (ürün niyeti / iş kararı / "ne istiyorsun" / kullanıcı-yüzlü isim) soru sorulur.
| Soru tipi | Karar veren |
|---|
| Mimari, tasarım, teknoloji/library seçimi, veri modeli, API şekli, auth, compliance, güvenlik pattern'i | software-architect ajanı |
| Deploy, infra, CI/CD, runtime, observability, secrets, DEPLOY.md | devops-engineer ajanı (devops-expert skill bilgisini kullanır) |
| Ürün niyeti / iş kapsamı / "ne istiyorsun" / kullanıcı-yüzlü isim / fiyat politikası | (ajan cevaplayamaz → operatör) |
Akış: soruyu sınıflandır → teknikse uzman ajan(lar)ı dispatch et (self-contained prompt: SYSTEM.md yolu + repo kökü + soru + kısıtlar; "araştır + ≥2 kanıt + karar + güven" iste; ajan ürün girdisi gerekiyorsa CANNOT-ANSWER döner) → ajan karar verdiyse benimse, kaynağıyla §5 Entegrasyon / karar notuna yaz → ajan CANNOT-ANSWER derse veya ajanlar çelişirse operatöre (ajan analizini ekleyerek) git.
Kapsam: Bu protokol PRD yazımı içindeki kararları kapsar; §6 (remote git) ve §7 (AWS public/silme) çalıştırma-zamanı LAW'ları etkilenmez — onlar uygulama anında hâlâ operatör onayı ister.
Hard Sequence (atlanmaz)
- SYSTEM.md kontrol —
docs/SYSTEM.md var mı?
- Varsa oku.
- Yoksa: feature'ın dokunduğu alanlar için bir kez üret (spec-first-feature Phase 1 mantığı, dar kapsam) →
docs/SYSTEM.md.
- Hedefli grep — feature'ın dokunduğu modülleri (auth + ilgili servis/tablo) grep'le; dosya:satır kanıtı topla. Tam tarama YAPMA.
- Şablonu doldur —
templates/mini-prd.md'yi kopyala → docs/prd-<feature>.md. §5 Entegrasyon'u Adım 2 kanıtıyla doldur (boş alan = fail).
- AC binary mı kontrol et — her AC geçti/kaldı net olmalı (L107).
- Progress dosyası oluştur —
docs/prd-{feature}.progress.md yaz:
---
status: active
prd: docs/prd-<feature>.md
started: <YYYY-MM-DD>
---
## Faz Çıktıları
## Değişiklikler
| Tarih | Dosya | Ne değişti | AC |
|-------|-------|-----------|-----|
## Kararlar
## Dersler
prd-run bu dosyaya tüm faz çıktılarını, değişiklik takibini ve kararları yazar.
Çıktı
docs/prd-<feature>.md (mini-PRD, harmony dolu)docs/prd-{feature}.progress.md (aktif PRD işareti + faz/değişiklik takibi için hazır)- Operatöre: 1 cümle özet + "prd-run ile uygulayalım mı?"
prd-run Sonrası Pipeline (ZORUNLU — implementasyon bittikten sonra)
prd-run tüm fazları tamamladığında aşağıdaki pipeline otomatik devreye girer. Operatör onayı gerekmez — tek kullanıcı aksiyonu git push komutudur (Golden Rule §6).
prd-run bitti
1. /test-plan <feature> → docs/test-plan-<feature>.md
2. qa-eval-developer → testleri yaz + koş → TEST GATE: PASS/FAIL
↓ PASS
3. project-manager → P1-P8 kontrol → AUTO-GO
↓ AUTO-GO
4. Kullanıcı: git push origin <dal>
↓ push sonrası
5. CI → deploy → <proje>-live-test (varsa)
TEST GATE FAIL veya NO-GO durumunda blokör ilgili agent'a handoff edilir, fix sonrası pipeline kaldığı yerden devam eder.
Progress dosyasına (docs/prd-{feature}.progress.md) pipeline tamamlanınca status: delivered eklenir.
Kapsam dışı
Büyük/çok-fazlı feature → spec-first-feature kullan. Mini-PRD tek-fazlık işler için.
