Vibe-coder-kit code-review

install
source · Clone the upstream repo
git clone https://github.com/omergocmen/vibe-coder-kit
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/omergocmen/vibe-coder-kit "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.agent/skills/code-review" ~/.claude/skills/omergocmen-vibe-coder-kit-code-review && rm -rf "$T"
manifest: .agent/skills/code-review/SKILL.md
source content
<!-- TÜRKÇE AÇIKLAMA ─────────────── Bu skill, yazılan kodun commit'lenmeden veya push'lanmadan önce sistematik biçimde incelenmesini sağlar. Hem "review isteği hazırlama" (requesting) hem de "review feedback'ini yanıtlama" (receiving) süreçlerini kapsar. Kod kalitesi, güvenlik, test coverage, mimari uyum ve dokümantasyon kontrol edilir. NE ZAMAN: Commit öncesi (kendi kendine review), PR açmadan önce, büyük değişikliklerde. ÇIKTI: Review checklist raporu, yanıtlanmış feedback listesi, düzeltilmiş kod. -->

Code Review Skill

İki Mod

Bu skill iki farklı durumda devreye girer:

ModNe ZamanNe Yapar
A — Pre-Commit ReviewCommit öncesi, kendi kendinleChecklist çalıştır, commit'e hazır mı karar ver
B — Feedback ResponseBaşkası review yaptı, feedback geldiHer yorumu sınıflandır, yanıtla, düzelt

MOD A: Pre-Commit Review (Kendi Kendine)

1. Diff'i Çek ve Analiz Et

git diff HEAD          # staged olmayan değişiklikler
git diff --staged      # staged değişiklikler
git diff main...HEAD   # branch'in tüm değişiklikleri

Her değişen dosyayı gözden geçir. PR'da yorum almak istemediğin şeyleri şimdi düzelt.


2. Checklist — Sırayla Uygula

🔴 Kritik (bunlar varsa commit yok)

  • Hardcoded secret, API key, password var mı?
    git grep -i "password\|secret\|api_key\|token" -- '*.ts' '*.js' '*.py' '*.env'
    
  • SQL injection vektörü var mı? (raw query + user input)
  • Authentication veya authorization bypass riski var mı?
  • Testler geçiyor mu?
    npm test
    
  • Build kırılıyor mu?
    npm run build
    
  • Başka modülleri kıran breaking change var mı? (notify et)

🟡 Önemli (bunlar varsa ya düzelt ya bilinçli geç)

  • Yeni public fonksiyon/endpoint'in JSDoc veya tipi var mı?
  • Hata yönetimi yapıldı mı? (try-catch, error boundary, 404/500 handling)
  • Konsola debug log bırakıldı mı? (
    console.log
    ,
    print
    ,
    debugger
    )
  • Yeni env variable varsa
    .env.example
    'a eklendi mi?
  • Herhangi bir TODO veya FIXME bırakıldı mı? (bilinçliyse ticket numarası ekle)
  • Code coverage düştü mü?
    npm test -- --coverage
    
  • Yeni bağımlılık eklendiyse güvenlik kontrolü yapıldı mı?
    npm audit
    

🔵 Kalite (mükemmel kod için)

  • Fonksiyon isimleri ne yaptıklarını anlatıyor mu?
  • Bir fonksiyon birden fazla şey yapıyor mu? (bölmeli)
  • Kod kopyalandı mı? (copy-paste → extract to function)
  • Magic number veya string var mı? (constant'a extract et)
  • Tip kullanımı yeterince katı mı? (
    any
    var mı?)

3. Review Kartı Oluştur

Commit mesajının yanına veya PR açıklamasına eklemek için:

## Self-Review Özeti

**Değişiklik:** <ne yaptım, neden>
**Test Durumu:** ✅ Tüm testler geçiyor / ⚠️ X test skip edildi (gerekçe: ...)
**Checklist:**
  - 🔴 Kritik: Temiz
  - 🟡 Önemli: [varsa not]
  - 🔵 Kalite: [varsa not]

**Özellikle dikkat çekilmek istenen:**
- <reviewer'ın bakmasını istediğin yer>

**Bilinçli atınan kısayollar (deliberate shortcuts):**
- <varsa gerekçesiyle>

MOD B: Feedback Response (Başkasının Review'ı)

1. Her Yorumu Sınıflandır

Gelen her review yorumu için:

[KRITIK]  → Blokerlık eder, merge edilemez — hemen düzelt
[ÖNEMLI]  → Güçlü öneri, iyi gerekçen yoksa uygula
[ÖNERI]   → Takdire bağlı, açık tartışma gerekebilir
[SORU]    → Bilgi isteği — açıkla veya kod ile düzelt
[NIT]     → Küçük stil/isimlendirme, senin tercihine bağlı

2. Her Yorumu Yanıtla

Hiçbir yorum cevapsız bırakılmaz.

Yorum: "Bu fonksiyonun timeout'u yok, servis yanıt vermezse ne olur?"
→ Sınıf: [KRİTİK]
→ Cevap: "Haklısın. 5 saniyelik timeout + retry ekledim. T3 commit'inde görebilirsin."
→ Aksiyon: Düzeltildi ✅

Yorum: "Belki burada Map yerine Set kullanabilirsin"
→ Sınıf: [ÖNERİ]
→ Cevap: "Set burada doğru olur, key'e ihtiyacımız yok. Değiştirdim."
→ Aksiyon: Düzeltildi ✅

Yorum: "Bu isimlendirme bana semantik gelmiyor"
→ Sınıf: [NIT]
→ Cevap: "Anladım mantığını ama `processUserData` yerine `normalizeUserInput` daha açıklayıcı — değiştirdim."
→ Aksiyon: Düzeltildi ✅

3. Düzeltmeleri Grupla ve Commit At

Her düzeltme grubunu ayrı bir commit olarak at (

github
skill commit standardına göre):

# Her düzeltme ayrı commit
git commit -m "fix: add timeout and retry to userService.fetchProfile"
git commit -m "refactor: use Set instead of Map in deduplication logic"
git commit -m "refactor: rename processUserData to normalizeUserInput"

4. Re-Review İste

Tüm düzeltmeler tamamlandığında review'ı güncelle:

## Düzeltme Özeti

Toplam yorum: 8
- Düzeltildi: 7
- Reddedildi (gerekçeyle): 1 → "NIT yorumu: mevcut isimlendirme proje konvansiyonuyla uyumlu"

Önemli değişiklikler:
- Timeout + retry mekanizması eklendi (güvenlik açısından kritik)
- 2 refactor (netlik için)

Re-review için hazır.

Kurallar

  • Kırmızı item varsa commit yok. İstisna yok.
  • "Sonra düzeltilir" yasak. Ya şimdi düzelt ya da ticket aç, ticket numarasını koda ekle.
  • Her review yorumu yanıtlanır. "Tamam" veya sessizlik kabul edilmez — ya "düzelttim" ya "katılmıyorum, çünkü..."
  • Review kendini kandırmak için değil, kodu korumak için. Checklist'i hızlıca geçiştirme.
  • Gelen feedback kişisel değil. Yorum koda yapılıyor, sana değil.