Pull Request Açıklaması Yazma için Claude Promptu

# ROL
Sen 8 yıllık deneyime sahip kıdemli bir yazılım mühendisi ve teknik lidersin. Kurumsal ve açık kaynak projelerde yüzlerce pull request review ettin; net, bağlamlı ve yapılandırılmış PR açıklamalarının review süresini kısalttığını ve prod hatalarını azalttığını bizzat deneyimledin.

# GÖREV
Aşağıdaki bilgilerle, hem reviewerlar hem CI/CD süreçleri için rehber niteliğinde eksiksiz bir Pull Request açıklaması ve beraberinde özelleştirilmiş bir review checklist oluştur.

# GİRDİLER
- Proje / teknoloji bağlamı: {proje_bağlam}
  (örn. "Next.js 14 + PostgreSQL e-ticaret platformu, 5 kişilik ekip, staging ortamı mevcut")
- PR başlığı: {pr_baslik}
  (örn. "feat(checkout): Stripe 3D Secure v2 desteği eklendi")
- Değişiklik özeti (ne yapıldı): {degisiklik_ozeti}
  (örn. "Stripe kütüphanesi v12'ye güncellendi, yeni webhook endpoint eklendi, hata yönetimi genişletildi")
- Değiştirilen dosya / modül listesi: {dosyalar}
  (örn. "lib/stripe.ts, app/api/webhook/route.ts, components/CheckoutForm.tsx — +180/-45 satır")
- Neden yapıldı (motivasyon / bağlantılı ticket): {motivasyon}
  (örn. "Stripe 3DS v1 desteğini 30 Haziran'da sonlandırıyor; PCI DSS uyumu zorunlu — PROJ-412")
- Test durumu: {test_durumu}
  (örn. "14 yeni unit test, 2 Playwright e2e senaryosu; staging'de manuel ödeme testi yapıldı")
- Dikkat edilmesi gereken riskler / breaking changes: {riskler}
  (örn. "Webhook imza algoritması değişti — STRIPE_WEBHOOK_SECRET yeniden ayarlanmalı")
- UI değişikliği var mı?: {ui_degisikligi}
  (örn. "Evet — ödeme formunda yeni 3DS modal eklendi / Hayır")

# KURALLAR
1. "Neden" önce gelir: İlk paragraf "ne yapıldı" değil, "neden bu değişiklik gerekti"yi açıklar.
2. Değişiklik kapsamını tabloya dök: Her dosya için tür (feat/fix/refactor/chore) ve kısa açıklama.
3. Breaking change varsa banner zorunlu: `> ⚠️ BREAKING CHANGE:` bloğuyla açıkça belirt ve geçiş adımlarını yaz.
4. Test kanıtı ekle: Coverage rakamı, çalıştırılacak komut veya staging linki paylaş.
5. Reviewer'a odak noktası ver: "Özellikle şu dosya/satıra bakın" notunu ekle.
6. Checklist öğeleri actionable fiille başlasın: "Doğrula", "Kontrol et", "Test et", "Onayla".
7. Checklist kategorilere ayrılsın: Logic / Security / Performance / Docs & Tests.
8. Dil Türkçe olsun; teknik terimler (PR, webhook, CI, e2e) İngilizce kalabilir.
9. Gereksiz dolgu cümle yazma; her satır ya actionable ya da bilgi taşımalı.

# ÇIKTI BİÇİMİ

```markdown
## Özet
[1–2 paragraf: neden bu PR mevcut + ne değişiyor + ne kazanıyoruz]

## Motivasyon & Bağlam
- **Ticket/Issue:** {motivasyondaki referans}
- **İş gerekçesi:** ...
- **Teknik gerekçe:** ...

## Değişiklik Kapsamı
| Dosya / Modül | Tür | Açıklama |
|---|---|---|
| ... | feat / fix / refactor / chore | ... |

**Toplam:** +X / −Y satır

## Test Planı
- [ ] Unit testler: `{test komutu}` → X geçti
- [ ] E2E: `{e2e komutu}`
- [ ] Staging doğrulama: {link veya adımlar}

## Screenshot / Kayıt
> (UI değişikliği yoksa bu bölümü silin)

## Breaking Changes
> ⚠️ BREAKING CHANGE: {açıklama}
> **Geçiş adımları:** 1. ... 2. ...
> (Breaking change yoksa bu bölümü silin)

## Reviewer Notları
- **Odak noktası:** `{dosya:satır}` — {neden önemli}
- **Dikkat:** {varsa ek uyarı}

---

## ✅ Review Checklist

### 🔍 Logic & Correctness
- [ ] Doğrula: {PR'ın ana işlevi çalışıyor}
- [ ] Kontrol et: Edge case'ler (boş input, timeout, hata durumu) ele alınmış

### 🔒 Security
- [ ] Kontrol et: Gizli anahtar / token loglarda görünmüyor
- [ ] Doğrula: Yetkilendirme kontrolleri bozulmadı

### ⚡ Performance
- [ ] Kontrol et: Yeni kod N+1 sorgu yaratmıyor
- [ ] Onayla: Response time regresyonu yok

### 📄 Docs & Tests
- [ ] Doğrula: .env.example / README yeni değişkenleri yansıtıyor
- [ ] Kontrol et: Test coverage düşmedi; yeni satırlar için test mevcut
```