Proje Analizcisi Skill

Çıktılar:

docs/analyze/01-proje-genel-bakis.md
docs/analyze/02-mimari-ve-kod-kalitesi.md
docs/analyze/03-riskler-ve-oneriler.md
docs/analyze/04-api-endpoint-listesi.md (sadece API varsa)

Projeyi sistematik olarak tara, derin analiz yap, bulgularını 3 (API varsa 4) ayrı rapora dönüştür ve docs/analyze/ klasörüne kaydet.

Temel kural: Yüzeysel geçme. Her başlık için gerçekten koda bak, dosyaları oku, örnek ver. Rapor somut bulgular içermeli — genel geçer değerlendirme yapma.

AŞAMA 1 — Proje Keşfi (Önce Bunu Yap)

Analiz başlamadan projeyi tanı. Keşif betiğini çalıştır:

bash ~/.gemini/antigravity/skills/proje-analizcisi/scripts/phase1_discovery.sh

Keşif sonrası şunları not et:

Ana dil(ler) ve framework(ler)
Proje tipi: monolith / microservice / monorepo / library
Paket yöneticisi
Test varlığı: var mı, yaygın mı?
API tipi: REST / GraphQL / gRPC / WebSocket / yok

AŞAMA 2 — Derin Analiz

Her kategoride koda gir, oku, somut bulgular çıkar. Analiz betiğini çalıştır:

bash ~/.gemini/antigravity/skills/proje-analizcisi/scripts/phase2_analysis.sh

Senaryonun çıktılarını dikkatle incele. Betik şunları içerir:

Mimari (klasör yapıları, büyük dosyalar, circular dependency ipuçları)
Kod Kalitesi (TODO'lar, any kullanımı, console.log'lar, tekrar eden kod blokları, hata yönetimi)
Güvenlik (hardcoded secret'ler, .env sızmaları, SQL injection riski, güvensiz paketler, auth middleware)
Performans (N+1 sorgu riski, ağır bundle'lar, önbellek kullanımı, async/await durumları)
Testler (dosyalar ve yapılandırma oranları)
API tespiti (REST endpoint'leri, FastAPI/Django route'ları, GraphQL tipleri, Swagger/OpenAPI dosyaları)

AŞAMA 3 — Rapor Üretimi

docs/analyze/ klasörünü oluştur ve 3 (veya 4) raporu kaydet.

mkdir -p docs/analyze

RAPOR 1: `01-proje-genel-bakis.md`

# Proje Genel Bakış

> Analiz tarihi: [TARIH]
> Analiz eden: Proje Analizcisi Skill v1.0

## Özet Kartı

| Özellik | Değer |
|---------|-------|
| Proje adı | [package.json name veya klasör adı] |
| Proje tipi | [Monolith / Microservice / Monorepo / Library] |
| Ana dil | [TypeScript / Python / Go / ...] |
| Framework | [Hono / FastAPI / Express / Next.js / ...] |
| Paket yöneticisi | [bun / pnpm / yarn / pip / ...] |
| Toplam kaynak dosyası | [N] |
| Toplam kod satırı | [N] |
| Test kapsamı | [Var / Yok / Kısmi] |
| API tipi | [REST / GraphQL / gRPC / Yok] |
| Son commit | [tarih] |
| Aktif geliştirici | [N kişi] |

## Proje Amacı

[package.json description veya README'den özet — kendi cümlelerinle açıkla]

## Klasör Yapısı

[find çıktısından temiz bir ağaç göster, her klasörün amacını bir satırla açıkla]

## Teknoloji Yığını

### Üretim Bağımlılıkları
[Her önemli paketi listele, amacını yaz]

### Geliştirme Araçları
[Test, lint, build araçlarını listele]

## Geliştirme Süreci Göstergeleri

| Gösterge | Değer | Yorum |
|----------|-------|-------|
| Son 3 ay commit | [N] | [aktif / düşük / yok] |
| Test / kaynak oranı | [%N] | [iyi / orta / yetersiz] |
| TODO sayısı | [N] | [temiz / dikkat / sorunlu] |
| Dokümantasyon | [Var / Kısmi / Yok] | |

## Güçlü Yönler

[Gerçekten iyi olan şeyleri yaz — somut, kod referanslı]

## Zayıf Yönler

[Somut sorunlar — "genel olarak kötü" değil, "X dosyasında Y sorunu var" gibi]

RAPOR 2: `02-mimari-ve-kod-kalitesi.md`

# Mimari ve Kod Kalitesi Analizi

## Mimari Değerlendirme

### Katman Yapısı
[Katmanlar var mı? Controller/Service/Repository ayrımı? Somut örnekler ver]

### Bağımlılık Yönetimi
[Circular dependency var mı? Import zinciri mantıklı mı?]

### Modülerlik Skoru
[ ⭐⭐⭐⭐⭐ ] — [gerekçe]

## Kod Kalitesi Metrikleri

| Metrik | Değer | Durum |
|--------|-------|-------|
| En büyük dosya | [dosya adı: N satır] | [✅ / ⚠️ / 🔴] |
| any kullanımı (TS) | [N adet] | [✅ / ⚠️ / 🔴] |
| TODO/FIXME sayısı | [N] | [✅ / ⚠️ / 🔴] |
| console.log (prod) | [N] | [✅ / ⚠️ / 🔴] |
| try/catch oranı | [N try, N catch] | [✅ / ⚠️ / 🔴] |

## Dikkat Gerektiren Dosyalar

[En büyük, en karmaşık, en çok TODO içeren dosyaları listele — neden riskli olduğunu açıkla]

### [dosya-adi.ts] — [N satır]
> Neden dikkat: [açıklama]
> Öneri: [ne yapılmalı]

## Tekrar Eden Kod (DRY İhlalleri)

[Benzer mantık farklı yerlerde mi yazılmış? Somut örnekler]

## Error Handling Kalitesi

[try/catch var mı? Hata mesajları anlamlı mı? Unhandled promise rejection riski?]

## Tip Güvenliği (TypeScript)

[any kullanımı, strict mode açık mı, tip tanımları eksiksiz mi?]

## Genel Kod Kalitesi Skoru

Mimari : [1-10] / 10 Okunabilirlik: [1-10] / 10
Sürdürülebilirlik: [1-10] / 10 Test Kapsamı: [1-10] / 10 ───────────────────────── Genel : [ortalama] / 10


## En İyi Yazılmış Bölümler

[Gerçekten iyi olan kod parçaları — somut örnek ver]

## En Çok İyileştirme Gereken Bölümler

[Somut, öncelikli iyileştirme önerileri — her biri için tahmini efor belirt]

RAPOR 3: `03-riskler-ve-oneriler.md`

# Riskler ve Öneriler

## Risk Matrisi

| Risk | Kategori | Etki | Olasılık | Öncelik |
|------|----------|------|----------|---------|
| [risk adı] | [Güvenlik/Performans/Teknik Borç/Operasyon] | [Yüksek/Orta/Düşük] | [Y/O/D] | [🔴/🟡/🟢] |

## 🔴 Kritik Riskler (Hemen Müdahale)

### [Risk Adı]
**Kategori:** [Güvenlik / Performans / ...]
**Nerede:** [dosya:satır veya modül]
**Sorun:** [somut açıklama]
**Kanıt:** [grep çıktısı veya kod örneği]
**Düzeltme:** [adım adım ne yapılmalı]
**Tahmini Efor:** [1 saat / 1 gün / 1 hafta]

## 🟡 Önemli Riskler (Kısa Vadede Ele Al)

[Aynı format — 3-5 risk]

## 🟢 İyileştirme Önerileri (Uzun Vade)

[Aynı format — 3-5 öneri]

## Güvenlik Analizi

### Pozitif Bulgular
[İyi güvenlik pratikleri — somut]

### Endişe Verici Bulgular
[Somut güvenlik açıkları veya riskler]

## Performans Analizi

### Darboğaz Adayları
[N+1 sorgu, ağır paket, cache eksikliği, async sorunları]

### İyileştirme Fırsatları
[Somut öneriler ve beklenen kazanım]

## Teknik Borç Envanteri

| Borç | Dosya/Modül | Tahmini Efor | Öncelik |
|------|-------------|--------------|---------|
| [açıklama] | [yer] | [efor] | [🔴/🟡/🟢] |

## Önerilen Eylem Planı

### Bu Hafta
1. [en kritik, somut adım]
2. [...]

### Bu Ay
1. [önemli iyileştirmeler]
2. [...]

### Uzun Vade (3-6 Ay)
1. [mimari iyileştirmeler]
2. [...]

## Genel Sağlık Skoru

Güvenlik : [1-10] / 10 Performans : [1-10] / 10 Sürdürülebilirlik: [1-10] / 10 Test Kapsamı : [1-10] / 10 Dokümantasyon: [1-10] / 10 ───────────────────────────── Proje Sağlığı: [ortalama] / 10

RAPOR 4: `04-api-endpoint-listesi.md` (Sadece API Varsa)

# API Endpoint Listesi

> Otomatik tarama ile oluşturulmuştur.
> Tarih: [TARIH]

## Özet

| Metrik | Değer |
|--------|-------|
| Toplam endpoint | [N] |
| GET | [N] |
| POST | [N] |
| PUT/PATCH | [N] |
| DELETE | [N] |
| Auth gerektiren | [N] (tahmini) |
| Dokümante edilmiş | [N] |

## Endpoint Katalogu

### [/api/auth] — Kimlik Doğrulama
| Metot | Path | Açıklama | Auth | Kaynak Dosya |
|-------|------|----------|------|--------------|
| POST | /api/auth/register | Kullanıcı kaydı | ❌ | src/routes/auth.ts:12 |
| POST | /api/auth/login | Giriş | ❌ | src/routes/auth.ts:28 |
| POST | /api/auth/logout | Çıkış | ✅ | src/routes/auth.ts:45 |
| GET | /api/auth/me | Mevcut kullanıcı | ✅ | src/routes/auth.ts:58 |

### [/api/...] — [diğer gruplar]
[aynı format — endpoint'leri gruplandır]

## Auth Gereksinim Analizi

[Hangi endpoint'ler korumalı, hangisi açık? Eksik auth var mı?]

## Eksik Dokümantasyon

[Swagger/OpenAPI tanımı olmayan endpoint'ler]

## Güvenlik Notları

[Rate limit eksik mi? Input validation var mı? CORS ayarı nasıl?]

## Tavsiyeler

[OpenAPI spec üretimi, versiyon stratejisi, eksik endpoint'ler]

AŞAMA 4 — Dosyaları Kaydet

# Klasörü oluştur
mkdir -p docs/analyze

# Raporları kaydet
# (Her raporu ayrı write_file çağrısıyla kaydet)

# Özet göster
echo "✅ Analiz tamamlandı"
echo "📁 docs/analyze/"
ls -la docs/analyze/

Kalite Kontrol

Her raporu kaydetmeden önce şu kontrolleri yap:

□ Genel geçer ifade yok — her cümle somut veri veya bulgua dayalı
□ Kod referansları var — "X dosyası N satır", "Y fonksiyonu Z problemi"
□ Sayısal metrikler gerçek (grep/wc çıktısından)
□ Risk öncelikleri mantıklı — her şey kırmızı değil
□ Öneriler uygulanabilir — "kodu iyileştir" değil, "X yapılmalı"
□ Skorlar gerekçeli — neden 7/10? çünkü...
□ API raporu: her endpoint için kaynak dosya referansı var

Hata Senaryoları

Git repo değilse: → Git istatistiklerini atla, diğer her şeyi analiz et

Çok büyük proje (>50K satır): → Her kategoriden örneklem al, raporda bunu belirt

Test hiç yoksa: → Test kapsamı: 0% olarak raporla, tavsiyeler bölümüne test stratejisi ekle

API tespiti belirsizse: → "API tespit edilemedi" yaz, 4. rapor üretme — şüpheli dosyaları listele

İzin hatası: → Erişilemeyen dosyaları atla, raporda belirt

Ne Zaman Atlarsın

Proje dizini verilmemişse ve kullanıcı sadece genel soru soruyorsa
Analiz edilecek kod yoksa (boş proje, sadece config dosyaları)

proje-analizcisi