Adversarial Code Reviewer

Description

Üç düşmanca gözlemci kişiliği (Saboteur, New Hire, Security Auditor) aracılığıyla gerçek perspektif değişimini zorlayan adversarial code review yeteneği. Her kişiliğin en az bir sorun bulması GEREKİR — hiçbir "LGTM" kaçamaz. Bulgular ciddiyete göre sınıflandırılır ve birden fazla kişilik tarafından yakalandığında çapraz olarak yükseltilir.

Features

• Üç adversarial kişilik — Saboteur (üretim kırılmaları), New Hire (bakım kolaylığı), Security Auditor (OWASP-temelli)
• Zorunlu bulgular — Her kişiliğin en az bir sorun ortaya koyması gerekir, damga basılmış incelemeleri ortadan kaldırır
• Ciddiyeti yükseltme — 2+ kişilik tarafından yakalanan sorunlar bir ciddiyeti seviyesi yükseltilir
• Self-review tuzak kırıcı — Paylaşılan zihinsel model kör noktalarını aşmak için somut teknikler
• Yapılandırılmış kararlar — BLOCK / CONCERNS / CLEAN net merge rehberliği ile

Usage

/adversarial-review              # Review staged/unstaged changes
/adversarial-review --diff HEAD~3  # Review last 3 commits
/adversarial-review --file src/auth.ts  # Review a specific file

Examples

Example: Merge Öncesi PR İncelemesi

/adversarial-review --diff main...HEAD

Tüm üç kişilikten gelen, tekilleştirilmiş ve ciddiyete göre sıralanmış bulgularla yapılandırılmış bir rapor üretir ve BLOCK/CONCERNS/CLEAN kararıyla sonlanır.

Bu Yeteneğin Çözdüğü Problem

Claude yazdığı kodu (veya yeni okuduğu kodu) incelediğinde, yazar ile aynı mental modeli, varsayımları ve kör noktaları paylaşır. Bu, yeni bir insan gözlemcinin hemen işaret edeceği koda dair "Looks good to me" incelemeleri üretir. Kullanıcılar bunu AI-destekli geliştirmenin en büyük hayal kırıklıklarından biri olarak bildirmiştir.

Bu yeteneği, adversarial kişilikleri benimsemeyi zorlayarak — her birinin farklı öncelikleri, farklı endişeleri ve "kötü kod"un farklı tanımları vardır — gerçek bir perspektif değişimini sağlar.

Table of Contents

1. Quick Start
2. Review Workflow
3. The Three Personas
4. Severity Classification
5. Output Format
6. Anti-Patterns
7. When to Use This

Quick Start

/adversarial-review              # Review staged/unstaged changes
/adversarial-review --diff HEAD~3  # Review last 3 commits
/adversarial-review --file src/auth.ts  # Review a specific file

Review Workflow

Step 1: Değişiklikleri Toplayın

İstifadeye bağlı olarak neleri inceleyeceğinizi belirleyin:

• Argüman yok: git diff (unstaged) + git diff --cached (staged) komutlarını çalıştırın. Her ikisi de boşsa, git diff HEAD~1 (son commit) komutunu çalıştırın.
• --diff <ref>: git diff <ref> komutunu çalıştırın.
• --file <path>: Dosyanın tamamını okuyun. İncelemeleri yalnızca değişikliklere değil, tam dosyaya odaklayın.

Hiçbir değişiklik bulunamazsa, durdurun ve rapor edin: "Nothing to review."

Step 2: Tam Bağlamı Okuyun

Diffteki her dosya için:

1. Tam dosyayı okuyun (yalnızca değiştirilen satırları değil) — hatalar yeni kodun mevcut kodla etkileşim şeklinde saklanır.
2. Değişikliğin amacını belirleyin: hata düzeltme, yeni feature, refactor, config değişikliği, test.
3. CLAUDE.md, .editorconfig, linting konfigleri veya mevcut desenlerden herhangi bir proje kuralı not edin.

Step 3: Üç Kişiliği de Çalıştırın

Her kişiliği sırayla yürütün. Her kişiliğin en az bir bulgu üretmesi GEREKİR. Bir kişiliğin hiçbir sorun bulamaması, yeterince bakmadığını gösterir — geri dönün ve tekrar bakın.

ÖNEMLİ: Bulguları yumuşatmayın. Belirsiz kalmayın. "Bu muhtemelen iyi olabilir ama..." demeyin — ya bir sorun vardır ya da yoktur. Doğrudan olun.

Step 4: Tekilleştirin ve Sentezleyin

Üç kişiliğin de rapor etmesinden sonra:

1. Yinelenen bulguları birleştirin (birden fazla kişilik tarafından yakalanan aynı sorun).
2. 2+ kişilik tarafından yakalanan bulguları sonraki ciddiyeti seviyesine yükseltin.
3. Son yapılandırılmış çıktıyı üretin.

The Three Personas

Persona 1: The Saboteur

Mindset: "Bu kodu üretimde kırmaya çalışıyorum."

Priorities:

• Doğrulanmamış input
• Tutarsız olabilecek state
• Senkronizasyon olmadan eşzamanlı erişim
• İstisnai durumları yiyen veya yanıltıcı sonuçlar döndüren error path'leri
• Veri formatı, boyutu veya kullanılabilirliğine ilişkin ihlal edilebilecek varsayımlar
• Off-by-one hatalar, integer overflow, null/undefined dereference'ları
• Resource leak'leri (file handle'lar, bağlantılar, subscription'lar, listener'lar)

Review Process:

1. Değiştirilen her function/method için şu soruyu sorun: "Bu fonksiyona gönderebileceğim en kötü input nedir?"
2. Her external call için şu soruyu sorun: "Bu başarısız olursa, time out'a uğrarsa veya çöp döndürürse?"
3. Her state mutation için şu soruyu sorun: "Bu iki kez çalışırsa? Eşzamanlı olarak? Hiç?"
4. Her conditional için şu soruyu sorun: "İkinci branch de yanlışsa?"

En az bir sorun bulmanız GEREKİR. Kod gerçekten kusursuzsa, güvendiği en kırılgan varsayımı not edin.

---

Persona 2: The New Hire

Mindset: "Bu takıma az önce katıldım. Altı ay sonra, orijinal yazardan sıfır bağlam olmadan bu kodu anlayıp değiştirmem gerekiyor."

Priorities:

• Niyeti iletmeyen isimler (data ne anlama geliyor? process() ne yapıyor?)
• 3+ dosyayı okumayı gerektiren logik
• Magic number'lar, magic string'ler, açıklaması yapılmamış constantlar
• Birden fazla şey yapan function'lar (isim X diyor ama aynı zamanda Y ve Z de yapıyor)
• Okuyucuyu call chain'lerde takip etmeye zorlayan eksik type bilgisi
• Çevre kodunun veya proje kuralının stiliyle tutarsızlık
• İmplementasyon detaylarını test eden davranış yerine test eden test'ler
• Ne yapıldığını açıklayan (gereksiz) açıklamalar yerine neden açıklayan (yararlı) açıklamalar

Review Process:

1. Değiştirilen her function'u, hiçbir zaman codebase görmemiş gibi okuyun. İsim, parametreler ve gövdeden tek başına ne yaptığını anlayabilir misiniz?
2. Bir code path'ini end-to-end izleyin. Kaç dosya açmanız gerekiyor?
3. Kontrol edin: yeni bir katılımcı benzer bir feature'ı nereye ekleyeceğini bilir mi?
4. "Yazar okuyucu'nun bilmeyeceği bir şey biliyordu" unsurlarını arayın — koda gömülü örtük bilgi.

En az bir sorun bulmanız GEREKİR. Kod kristal berraksa, yeni gelenlerin kafa karışması için en olası noktayı not edin.

---

Persona 3: The Security Auditor

Mindset: "Bu kod saldırı altına alınacak. İşim saldırganın önüne bulmakken açığı bulmak."

OWASP-Temelli Kontrol Listesi:

Kategori	Neye Bakılmalı
Injection	SQL, NoSQL, OS command, LDAP — user input'ı parameterizasyon olmadan bir sorgu veya komuta ulaştıran herhangi bir yer
Broken Auth	Hardcoded kimlik bilgileri, yeni endpoint'lerde eksik auth kontrolü, session token'ları URL veya log'larda
Data Exposure	Error message'larında, log'larda veya API response'larında hassas veriler; rest veya transit'te eksik encryption
Insecure Defaults	Debug modu açık bırakıldı, permissive CORS, wildcard izinleri, default şifreler
Missing Access Control	IDOR (A kullanıcısı B'nin verilerine erişebilir mi?), eksik role kontrolü, privilege escalation path'leri
Dependency Risk	Bilinen CVE'leri olan yeni dependency'ler, vulnerable versiyonlara sabitlenen, gereksiz transitive dependency'ler
Secrets	API key'leri, token'lar, şifreler kodda, config'de veya comment'lerde — hatta "temporary" olanlar bile

Review Process:

1. Kodun geçtiği her trust boundary'yi belirleyin (user input, API call'ları, database, file system, environment variable'ları).
2. Her boundary için: input validate edildi mi? Output sanitize edildi mi? En az privilege prensibi izlendi mi?
3. Kontrol edin: kimliği doğrulanmış bir kullanıcı bu değişiklik aracılığıyla privilege'i yükseltebilir mi?
4. Kontrol edin: bu değişiklik yeni bir saldırı yüzeyi açığa çıkartıyor mu?

En az bir sorun bulmanız GEREKİR. Kodun security yüzeyi yoksa, en yakın security-ilgili varsayımı not edin.

Severity Classification

Severity	Tanım	Gerekli Action
CRITICAL	Veri kaybına, security ihlâline veya production kesintisine neden olacak. Merge'den önce düzeltilmelidir.	Merge'i engelle.
WARNING	Edge case'lerde hatalara neden olması muhtemeldir, performansı düşürebilir veya gelecekteki maintainer'ları kafa karıştırabilir. Merge'den önce düzeltilmesi gerekir.	Düzelt veya risk'i açıkça kabul et.
NOTE	Style sorunu, küçük iyileştirme fırsat'ı veya dokümantasyon boşluğu. Düzeltmek güzeldir.	Yazarın takdiri.

Promotion kuralı: 2+ kişilik tarafından işaretlenen bulgu bir seviye yükseltilir (NOTE, WARNING olur; WARNING, CRITICAL olur).

Output Format

İncelemenizi şu şekilde yapılandırın:

## Adversarial Review: [nelerin incelendiğine dair kısa açıklama]

**Scope:** [incelenen dosyalar, değiştirilen satırlar, değişiklik türü]
**Verdict:** BLOCK / CONCERNS / CLEAN

### Critical Findings
[Varsa — merge'i engelle]

### Warnings
[Düzeltilmesi gereken öğeler]

### Notes
[Düzeltilmesi güzel olan öğeler]

### Summary
[2-3 cümle: genel risk profili nedir? Düzeltilmesi gereken en önemli tek şey nedir?]

Verdict tanımları:

• BLOCK — 1+ CRITICAL bulgusu. Çözülünceye kadar merge etmeyin.
• CONCERNS — Kritik olmayan ama 2+ warning'i vardır. Risk altında merge edin.
• CLEAN — Yalnızca note'lar. Merge'e güvenlidir.

Anti-Patterns

Bu Yeteneğin NE Olduğu DEĞİL

Anti-Pattern	Neden Yanlış
"LGTM, no issues found"	Hiçbir şey bulamamanız yeterince bakmadığınız anlamına gelir. Her değişikliğin en az bir riski, varsayımı veya iyileştirme fırsat'ı vardır.
Yalnızca kozmetik bulgular	Whitespace/formatting raporlarken null dereference kaçırmak hiç inceme yapmamaktan daha kötüdür. Substance önce, style sonra.
Punches çekmek	"Bu muhtemelen küçük bir endişe olabilir..." — Hayır. Doğrudan olun. "Bu, user undefined olduğunda NullPointerException fırlatacak."
Diffi tekrar söylemek	"Bu function, authentication işlemek için eklendi" bulgu değildir. Authentication'ı işlemede NE YANLIŞ?
Test boşluklarını yoksaymak	Yeni kod testler olmadan bir bulgudur. Her zaman. Testler opsiyonel değildir.
Yalnızca değiştirilen satırları incelemek	Hatalar yeni kodun mevcut kodla etkileşim şeklinde yaşanır. Tam dosyayı okuyun.

The Self-Review Trap

Muhtemelen yazdığınız veya yeni okuduğunuz kodu inceliyorsunuz. Beyin ağırlıklarınız bu kodu üreten aynı mental modeli oluşturmuştur. Doğal olarak beklentilerinizle eşleştiği için doğru görünecek.

Bu deseni kırmak için:

1. Kodu bottom-up okuyun (son function'tan başlayıp geriye doğru gidin).
2. Her function için, gövdeyi okumadan önce kontratını ifade edin. Gövde eşleşiyor mu?
3. Aksi kanıtlanana kadar her variable null/undefined olabileceğini varsayın.
4. Her external call başarısız olacak diye varsayın.
5. Şu soruyu sorun: "Bu değişikliği tamamen silersem, ne kırılır?" — cevap "hiçbir şey" ise, değişiklik gereksiz olabilir.

When to Use This

• Herhangi bir PR merge'den önce — özellikle insan gözlemcisi olmayan self-authored PR'ler
• Uzun bir coding sessionundan sonra — yorgunluk kör noktalar üretir; bu yetenek bunu telafi eder
• Claude "looks good" dediğinde — kolay bir onay aldıysanız, ikinci fikir için bu yeteneği çalıştırın
• Security-sensitive kodda — auth, payments, data access, API endpoint'leri
• Bir şey "garip geliyor"se — o içgüdüye güvenin ve adversarial review çalıştırın

Cross-References

• İlgili: engineering-team/senior-security — derin security analizi
• İlgili: engineering-team/code-reviewer — genel code quality review
• Tamamlayıcı: ra-qm-team/ — quality management workflow'ları