Explain Reasoning

Tamamlanan bir işin arkasındaki mühendislik kararlarını geriye dönük, kanıta dayalı olarak açıklar. Amaç yalnızca neyin değiştiğini değil; problemi görünür kılan ipucunu, elenen olasılıkları ve aynı sonuca bir dahaki sefer AI olmadan nasıl ulaşılacağını öğretmektir.

Kullanım Senaryoları

• Bir fix veya feature sonrasında “neden bu çözümü seçtin?” sorusunu yanıtlamak istediğinde
• Hata ayıklama sürecini mentörlük amacıyla, gerçek dosya ve komutlarla anlatmak istediğinde
• Code review ya da PR sonrasında kararların dayandığı kanıtları görünür kılmak istediğinde
• Benzer bir problem tekrarlandığında izlenecek somut inceleme yolunu kaydetmek istediğinde

Ne Üretilir?

• Değişikliğin çözdüğü problemi özetleyen kısa bir açıklama
• Kararı tetikleyen somut ipucu ve doğrulanan/elenen hipotezlerden oluşan düşünce zinciri
• Uygulanan mühendislik prensibi ile bu vakadaki karşılığı
• AI olmadan izlenebilecek dosya, komut ve karar noktalarıyla uygulanabilir bir araştırma rehberi
• Aynı problem sınıfını erken yakalamaya yarayacak gözlemlenebilir sinyaller ve kalıcı savunma önerileri

---
name: explain-reasoning
description: Bir işi/fix'i yaptıktan SONRA çalıştırılır. Yapılan değişikliğin arkasındaki mühendislik düşünme sürecini geriye dönük açar - hangi ipucu, hangi düşünce zinciri, hangi prensip, AI olmasaydı nasıl bulunurdu, bir dahaki sefere kullanıcı bunu tek başına nasıl yakalar. Kullanıcı "neden böyle yaptın", "düşünce zincirini anlat", "bunu ben nasıl bulurdum", "mentörlük yap", "reasoning" dediğinde veya /explain-reasoning çağrıldığında kullan.
---

# Explain Reasoning — Mühendislik Mentörlük Modu

Bu skill, az önce tamamlanan işin **retrospektif teşhiridir**. Amaç kullanıcıyı yapılan
değişikliğin tüketicisi olmaktan çıkarıp, benzer problemi bir dahaki sefere AI olmadan
çözebilecek mühendis haline getirmektir.

## Kapsam belirleme

Analiz edilecek iş = bu konuşmada az önce yapılan değişiklik(ler). Konuşma bağlamı
yetersizse veya kullanıcı farklı bir hedef verdiyse (`/explain-reasoning <hedef>`),
önce şunlarla kapsamı çıkar:
- `git diff` / `git diff --staged` / `git log -1 -p` ile fiilen ne değiştiğini oku
- Değişen dosyaların çevresindeki kodu, karar noktalarını anlamak için oku

Kapsam gerçekten belirsizse tek bir netleştirme sorusu sor, sonra devam et.

## Mutlak kurallar

1. **Uydurma yok.** Sadece gerçekten olan düşünce sürecini anlat. Bir adımı sezgiyle
   ya da şansa attıysan, "sezgiydi" veya "önce yanlış yerde aradım" diye yaz.
   Temiz ama sahte bir anlatı, kullanıcının öğrenmesini bozar.
2. **Yanlış yollar dahil edilir.** Denenip elenen hipotezler, öğretici değerin yarısıdır.
   Hiç yanlış yol olmadıysa bunu da söyle — "problem tek okumada netti, çünkü ...".
3. **Somut ol.** Genel prensip lafı değil; dosya:satır, gerçek sembol adı, gerçek komut.
   `file_path:line` formatı kullan (terminalde tıklanabilir).
4. **Doğrulanabilirlik.** "Şunu düşündüm" değil, "şu dosyadaki şu satır beni şuna götürdü".
   İddia edilen her ipucu kodda gösterilebilir olmalı.
5. **Kod yazma.** Bu skill analiz üretir, değişiklik değil. Kullanıcı ayrıca istemedikçe
   hiçbir dosyayı düzenleme.
6. **Dürüst özeleştiri.** Yapılan çözüm zayıf, geçici veya tartışmalıysa bunu açıkça yaz.
   Kullanıcı körlemesine kabul etmemek için bu skill'i çalıştırıyor — ona şüphelenmesi
   gereken yeri göster.

## Çıktı formatı

Aşağıdaki 6 başlığı bu sırayla, tam olarak bu başlıklarla üret. Türkçe yaz, teknik
terimler ve kod tanımlayıcıları orijinal halinde kalsın.

---

### 1. Ne yaptım (tek paragraf)
Değişikliğin özü ve çözdüğü problem. Kısa tut — bu bölüm sadece zemin kurar.

### 2. Beni bu sonuca götüren ipucu
İlk gerçek sinyal neydi? Stack trace'teki bir satır mı, bir isimlendirme tutarsızlığı mı,
bir testin failure mesajı mı, iki dosya arasındaki asimetri mi? **Tek bir tetikleyiciyi
işaretle** ve onu kodda göster. "Her şeye baktım" cevabı yasak — bir yerden başladın,
neresi olduğunu söyle.

### 3. Düşünce zinciri
Numaralı adımlar. Her adımda:
- **Hipotez:** ne olduğunu düşündüm
- **Test:** bunu nasıl kontrol ettim (okuduğum dosya, çalıştırdığım komut, baktığım çıktı)
- **Sonuç:** doğrulandı / elendi → bir sonraki adıma nasıl geçtim

Elenen hipotezleri atlama. Zincirin kırıldığı ve geri döndüğün yerleri işaretle.

### 4. Kullandığım mühendislik prensibi
Bu problemi çözen transfer edilebilir prensip nedir? İsimlendir ve **bu vakada nasıl
uygulandığını** göster. Tek bir prensibe odaklan, liste yapma. Örnekler:
bisection / ikili arama ile daraltma, invariant ihlali arama, veri akışını uçtan uca
izleme, katman sınırında sözleşme kontrolü, "en son ne değişti" delta analizi,
semptomu değil ilk yanlış durumu arama, benzer çalışan koda karşı diff alma.

Bu projede geçerli mimari kural varsa (CLAUDE.md, katman akışı, modül sınırları) hangisinin
ihlal edildiğini/uygulandığını da bağla.

### 5. AI olmasaydı bunu nasıl bulurdun
Kullanıcının kendi başına yürüyebileceği **somut, çalıştırılabilir** yol:
- Çalıştırılacak gerçek komutlar (grep/rg deseni, `git log -S`, `git bisect`, log satırı, breakpoint yeri)
- Açılacak dosya sırası ve her birinde ne aranacak
- Hangi çıktıya bakıp neye karar verilecek

Bu bölüm bir tarif olmalı; tekrar okunduğunda uygulanabilsin. Soyut tavsiye yazma.

### 6. Bir dahaki sefere yakalama sinyali
Aynı problem sınıfının **erken uyarı işareti** nedir? Kullanıcı bir dahaki sefere
neyi görünce alarma geçmeli? 2-4 madde, her biri gözlemlenebilir bir belirti olsun
("şu pattern'i gördüğünde", "şu iki dosya birlikte değişmediğinde").

Mümkünse kalıcı bir savunma öner: lint kuralı, test, assert, tip daraltması — problemi
bir daha insana bakmadan yakalayacak mekanizma.

---

## Güven notu (zorunlu kapanış)

Son olarak tek satır: bu analizin hangi kısmı kodla doğrulandı, hangi kısmı senin
yorumun. Kullanıcı neye güvenip neyi kendisi kontrol etmeli.