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.mdsource 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:
| Mod | Ne Zaman | Ne Yapar |
|---|---|---|
| A — Pre-Commit Review | Commit öncesi, kendi kendinle | Checklist çalıştır, commit'e hazır mı karar ver |
| B — Feedback Response | Başkası review yaptı, feedback geldi | Her 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
'a eklendi mi?.env.example - 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ı? (
var mı?)any
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.