Add Turkish (tr) docs and update README (#744)

* Add Turkish (tr) docs and update README

Add a full set of Turkish documentation under docs/tr (agents, changelog, CLAUDE guide, contributing, code of conduct, and many agents/commands/skills/rules files). Update README to include a link to the Turkish docs and increment the supported language count from 5 to 6. This commit adds localized guidance and references to help Turkish-speaking contributors and users.

* Update docs/tr/TROUBLESHOOTING.md

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>

* Update docs/tr/README.md

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>

* docs(tr): fix license link and update readmes

Update Turkish docs: change license badge link to point to repository root (../../LICENSE), increment displayed language count from 5 to 6, and remove two outdated related links from docs/tr/examples/README.md to keep references accurate.

* Update docs/tr/commands/instinct-import.md

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>

* Update docs/tr/commands/checkpoint.md

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>

---------

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
This commit is contained in:
Berkcan Gümüşışık
2026-03-23 01:37:04 +03:00
committed by GitHub
parent bb1efad7c7
commit fd2a8edb53
139 changed files with 26670 additions and 2 deletions

View File

@@ -0,0 +1,62 @@
# Build and Fix
Build ve tip hatalarını minimal, güvenli değişikliklerle aşamalı olarak düzelt.
## Adım 1: Build Sistemini Tespit Et
Projenin build aracını tanımla ve build'i çalıştır:
| İndikatör | Build Komutu |
|-----------|---------------|
| `build` script'i olan `package.json` | `npm run build` veya `pnpm build` |
| `tsconfig.json` (sadece TypeScript) | `npx tsc --noEmit` |
| `Cargo.toml` | `cargo build 2>&1` |
| `pom.xml` | `mvn compile` |
| `build.gradle` | `./gradlew compileJava` |
| `go.mod` | `go build ./...` |
| `pyproject.toml` | `python -m py_compile` veya `mypy .` |
## Adım 2: Hataları Parse Et ve Grupla
1. Build komutunu çalıştır ve stderr'i yakala
2. Hataları dosya yoluna göre grupla
3. Bağımlılık sırasına göre sırala (mantık hatalarından önce import/tipleri düzelt)
4. İlerleme takibi için toplam hataları say
## Adım 3: Düzeltme Döngüsü (Tek Seferde Bir Hata)
Her hata için:
1. **Dosyayı oku** — Hata bağlamını görmek için Read aracını kullan (hatanın etrafında 10 satır)
2. **Teşhis et** — Kök nedeni tanımla (eksik import, yanlış tip, sözdizimi hatası)
3. **Minimal düzelt** — Hatayı çözen en küçük değişiklik için Edit aracını kullan
4. **Build'i yeniden çalıştır** — Hatanın gittiğini ve yeni hata oluşmadığını doğrula
5. **Sonrakine geç** — Kalan hatalarla devam et
## Adım 4: Koruma Önlemleri
Şu durumlarda dur ve kullanıcıya sor:
- Bir düzeltme **çözdüğünden daha fazla hata oluşturuyorsa**
- **Aynı hata 3 denemeden sonra devam ediyorsa** (muhtemelen daha derin bir sorun)
- Düzeltme **mimari değişiklikler gerektiriyorsa** (sadece build düzeltmesi değil)
- Build hataları **eksik bağımlılıklardan** kaynaklanıyorsa (`npm install`, `cargo add`, vb. gerekli)
## Adım 5: Özet
Sonuçları göster:
- Düzeltilen hatalar (dosya yollarıyla)
- Kalan hatalar (varsa)
- Oluşturulan yeni hatalar (sıfır olmalı)
- Çözülmemiş sorunlar için önerilen sonraki adımlar
## Kurtarma Stratejileri
| Durum | Aksiyon |
|-----------|--------|
| Eksik modül/import | Paketin yüklü olup olmadığını kontrol et; install komutu öner |
| Tip uyuşmazlığı | Her iki tip tanımını oku; daha dar olanı düzelt |
| Döngüsel bağımlılık | Import grafiği ile döngüyü tanımla; extraction öner |
| Versiyon çakışması | Versiyon kısıtlamaları için `package.json` / `Cargo.toml` kontrol et |
| Build aracı yanlış yapılandırması | Config dosyasını oku; çalışan varsayılanlarla karşılaştır |
Güvenlik için bir seferde bir hatayı düzelt. Refactoring yerine minimal diff'leri tercih et.

View File

@@ -0,0 +1,74 @@
# Checkpoint Komutu
İş akışınızda bir checkpoint oluşturun veya doğrulayın.
## Kullanım
`/checkpoint [create|verify|list|clear] [isim]`
## Checkpoint Oluştur
Checkpoint oluştururken:
1. Mevcut durumun temiz olduğundan emin olmak için `/verify quick` çalıştır
2. Checkpoint adıyla bir git stash veya commit oluştur
3. Checkpoint'i `.claude/checkpoints.log`'a kaydet:
```bash
echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)" >> .claude/checkpoints.log
```
4. Checkpoint oluşturulduğunu raporla
## Checkpoint'i Doğrula
Bir checkpoint'e karşı doğrularken:
1. Log'dan checkpoint'i oku
2. Mevcut durumu checkpoint ile karşılaştır:
- Checkpoint'ten sonra eklenen dosyalar
- Checkpoint'ten sonra değiştirilen dosyalar
- Şimdiki vs o zamanki test başarı oranı
- Şimdiki vs o zamanki kapsama oranı
3. Raporla:
```
CHECKPOINT KARŞILAŞTIRMASI: $NAME
============================
Değişen dosyalar: X
Testler: +Y geçti / -Z başarısız
Kapsama: +X% / -Y%
Build: [GEÇTİ/BAŞARISIZ]
```
## Checkpoint'leri Listele
Tüm checkpoint'leri şunlarla göster:
- Ad
- Zaman damgası
- Git SHA
- Durum (mevcut, geride, ileride)
## İş Akışı
Tipik checkpoint akışı:
```
[Başlangıç] --> /checkpoint create "feature-start"
|
[Uygula] --> /checkpoint create "core-done"
|
[Test] --> /checkpoint verify "core-done"
|
[Refactor] --> /checkpoint create "refactor-done"
|
[PR] --> /checkpoint verify "feature-start"
```
## Argümanlar
$ARGUMENTS:
- `create <isim>` - İsimlendirilmiş checkpoint oluştur
- `verify <isim>` - İsimlendirilmiş checkpoint'e karşı doğrula
- `list` - Tüm checkpoint'leri göster
- `clear` - Eski checkpoint'leri kaldır (son 5'i tutar)

View File

@@ -0,0 +1,40 @@
# Code Review
Commit edilmemiş değişikliklerin kapsamlı güvenlik ve kalite incelemesi:
1. Değişen dosyaları al: git diff --name-only HEAD
2. Her değişen dosya için şunları kontrol et:
**Güvenlik Sorunları (KRİTİK):**
- Hardcode edilmiş kimlik bilgileri, API anahtarları, token'lar
- SQL injection açıklıkları
- XSS açıklıkları
- Eksik input validasyonu
- Güvenli olmayan bağımlılıklar
- Path traversal riskleri
**Kod Kalitesi (YÜKSEK):**
- 50 satırdan uzun fonksiyonlar
- 800 satırdan uzun dosyalar
- 4 seviyeden fazla iç içe geçme derinliği
- Eksik hata yönetimi
- console.log ifadeleri
- TODO/FIXME yorumları
- Public API'ler için eksik JSDoc
**En İyi Uygulamalar (ORTA):**
- Mutation desenleri (immutable kullanın)
- Kod/yorumlarda emoji kullanımı
- Yeni kod için eksik testler
- Erişilebilirlik sorunları (a11y)
3. Şunları içeren rapor oluştur:
- Önem derecesi: KRİTİK, YÜKSEK, ORTA, DÜŞÜK
- Dosya konumu ve satır numaraları
- Sorun açıklaması
- Önerilen düzeltme
4. KRİTİK veya YÜKSEK sorunlar bulunursa commit'i engelle
Güvenlik açıklıkları olan kodu asla onaylamayın!

365
docs/tr/commands/e2e.md Normal file
View File

@@ -0,0 +1,365 @@
---
description: Playwright ile end-to-end testler oluştur ve çalıştır. Test yolculukları oluşturur, testleri çalıştırır, ekran görüntüleri/videolar/izlemeler yakalar ve artifact'ları yükler.
---
# E2E Komutu
Bu komut, Playwright kullanarak end-to-end testleri oluşturmak, sürdürmek ve yürütmek için **e2e-runner** agent'ını çağırır.
## Bu Komut Ne Yapar
1. **Test Yolculukları Oluştur** - Kullanıcı akışları için Playwright testleri oluştur
2. **E2E Testlerini Çalıştır** - Testleri tarayıcılar arasında yürüt
3. **Artifact'ları Yakala** - Hatalarda ekran görüntüleri, videolar, izlemeler
4. **Sonuçları Yükle** - HTML raporları ve JUnit XML
5. **Dengesiz Testleri Tanımla** - Kararsız testleri karantinaya al
## Ne Zaman Kullanılır
`/e2e` komutunu şu durumlarda kullanın:
- Kritik kullanıcı yolculuklarını test ederken (giriş, ticaret, ödemeler)
- Çok adımlı akışların uçtan uca çalıştığını doğrularken
- UI etkileşimlerini ve navigasyonu test ederken
- Frontend ve backend arasındaki entegrasyonu doğrularken
- Üretime dağıtım için hazırlanırken
## Nasıl Çalışır
e2e-runner agent'ı şunları yapacaktır:
1. **Kullanıcı akışını analiz edecek** ve test senaryolarını tanımlayacak
2. Page Object Model deseni kullanarak **Playwright testi oluşturacak**
3. **Testleri çalıştıracak** (Chrome, Firefox, Safari)
4. Ekran görüntüleri, videolar ve izlemelerle **hataları yakalayacak**
5. Sonuçlar ve artifact'larla **rapor oluşturacak**
6. **Dengesiz testleri tanımlayacak** ve düzeltme önerilerinde bulunacak
## Örnek Kullanım
```
Kullanıcı: /e2e Piyasa arama ve görüntüleme akışını test et
Agent (e2e-runner):
# E2E Test Oluşturma: Piyasa Arama ve Görüntüleme Akışı
## Tanımlanan Test Senaryosu
**Kullanıcı Yolculuğu:** Piyasa Arama → Sonuçları Görüntüle → Piyasaya Tıkla → Detayları Görüntüle
**Test Kapsamı:**
1. Piyasalar sayfasına git
2. Semantik arama yap
3. Arama sonuçlarını doğrula
4. İlk sonuca tıkla
5. Piyasa detay sayfasının yüklendiğini doğrula
6. Grafiğin render olduğunu doğrula
## Oluşturulan Test Kodu
```typescript
// tests/e2e/markets/search-and-view.spec.ts
import { test, expect } from '@playwright/test'
import { MarketsPage } from '../../pages/MarketsPage'
import { MarketDetailsPage } from '../../pages/MarketDetailsPage'
test.describe('Market Search and View Flow', () => {
test('kullanıcı piyasaları arayabilir ve detayları görüntüleyebilir', async ({ page }) => {
// 1. Piyasalar sayfasına git
const marketsPage = new MarketsPage(page)
await marketsPage.goto()
// Sayfanın yüklendiğini doğrula
await expect(page).toHaveTitle(/Markets/)
await expect(page.locator('h1')).toContainText('Markets')
// 2. Semantik arama yap
await marketsPage.searchMarkets('election')
// API yanıtını bekle
await page.waitForResponse(resp =>
resp.url().includes('/api/markets/search') && resp.status() === 200
)
// 3. Arama sonuçlarını doğrula
const marketCards = marketsPage.marketCards
await expect(marketCards.first()).toBeVisible()
const resultCount = await marketCards.count()
expect(resultCount).toBeGreaterThan(0)
// Arama sonuçlarının ekran görüntüsünü al
await page.screenshot({ path: 'artifacts/search-results.png' })
// 4. İlk sonuca tıkla
const firstMarketTitle = await marketCards.first().textContent()
await marketCards.first().click()
// 5. Piyasa detay sayfasının yüklendiğini doğrula
await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/)
const detailsPage = new MarketDetailsPage(page)
await expect(detailsPage.marketName).toBeVisible()
await expect(detailsPage.marketDescription).toBeVisible()
// 6. Grafiğin render olduğunu doğrula
await expect(detailsPage.priceChart).toBeVisible()
// Piyasa adının eşleştiğini doğrula
const detailsTitle = await detailsPage.marketName.textContent()
expect(detailsTitle?.toLowerCase()).toContain(
firstMarketTitle?.toLowerCase().substring(0, 20) || ''
)
// Piyasa detaylarının ekran görüntüsünü al
await page.screenshot({ path: 'artifacts/market-details.png' })
})
test('sonuç olmayan arama boş durumu göstermeli', async ({ page }) => {
const marketsPage = new MarketsPage(page)
await marketsPage.goto()
// Var olmayan piyasayı ara
await marketsPage.searchMarkets('xyznonexistentmarket123456')
// Boş durumu doğrula
await expect(page.locator('[data-testid="no-results"]')).toBeVisible()
await expect(page.locator('[data-testid="no-results"]')).toContainText(
/no.*results|no.*markets/i
)
const marketCount = await marketsPage.marketCards.count()
expect(marketCount).toBe(0)
})
test('aramayı temizleyebilir ve tüm piyasaları tekrar görebilir', async ({ page }) => {
const marketsPage = new MarketsPage(page)
await marketsPage.goto()
// İlk piyasa sayısı
const initialCount = await marketsPage.marketCards.count()
// Arama yap
await marketsPage.searchMarkets('trump')
await page.waitForLoadState('networkidle')
// Filtrelenmiş sonuçları doğrula
const filteredCount = await marketsPage.marketCards.count()
expect(filteredCount).toBeLessThan(initialCount)
// Aramayı temizle
await marketsPage.searchInput.clear()
await page.waitForLoadState('networkidle')
// Tüm piyasaların tekrar gösterildiğini doğrula
const finalCount = await marketsPage.marketCards.count()
expect(finalCount).toBe(initialCount)
})
})
```
## Testleri Çalıştırma
```bash
# Oluşturulan testi çalıştır
npx playwright test tests/e2e/markets/search-and-view.spec.ts
3 worker kullanarak 3 test çalıştırılıyor
[chromium] search-and-view.spec.ts:5:3 user can search markets and view details (4.2s)
[chromium] search-and-view.spec.ts:52:3 search with no results shows empty state (1.8s)
[chromium] search-and-view.spec.ts:67:3 can clear search and see all markets again (2.9s)
3 passed (9.1s)
Oluşturulan artifact'lar:
- artifacts/search-results.png
- artifacts/market-details.png
- playwright-report/index.html
```
## Test Raporu
```
╔══════════════════════════════════════════════════════════════╗
║ E2E Test Sonuçları
╠══════════════════════════════════════════════════════════════╣
║ Durum: ✅ TÜM TESTLER GEÇTİ ║
║ Toplam: 3 test ║
║ Geçti: 3 (%100) ║
║ Başarısız: 0 ║
║ Dengesiz: 0 ║
║ Süre: 9.1s ║
╚══════════════════════════════════════════════════════════════╝
Artifact'lar:
📸 Ekran Görüntüleri: 2 dosya
📹 Videolar: 0 dosya (sadece hatada)
🔍 İzlemeler: 0 dosya (sadece hatada)
📊 HTML Rapor: playwright-report/index.html
Raporu görüntüle: npx playwright show-report
```
✅ E2E test paketi CI/CD entegrasyonuna hazır!
```
## Test Artifact'ları
Testler çalıştığında, şu artifact'lar yakalanır:
**Tüm Testlerde:**
- Zaman çizelgesi ve sonuçlarla HTML Rapor
- CI entegrasyonu için JUnit XML
**Sadece Hatada:**
- Başarısız durumun ekran görüntüsü
- Testin video kaydı
- Hata ayıklama için izleme dosyası (adım adım tekrar)
- Network logları
- Console logları
## Artifact'ları Görüntüleme
```bash
# HTML raporunu tarayıcıda görüntüle
npx playwright show-report
# Belirli izleme dosyasını görüntüle
npx playwright show-trace artifacts/trace-abc123.zip
# Ekran görüntüleri artifacts/ dizinine kaydedilir
open artifacts/search-results.png
```
## Dengesiz Test Tespiti
Bir test aralıklı olarak başarısız olursa:
```
⚠️ DENGESİZ TEST TESPİT EDİLDİ: tests/e2e/markets/trade.spec.ts
Test 10 çalıştırmadan 7'sinde geçti (%70 geçme oranı)
Yaygın başarısızlık:
"'[data-testid="confirm-btn"]' elementi için timeout"
Önerilen düzeltmeler:
1. Açık bekleme ekle: await page.waitForSelector('[data-testid="confirm-btn"]')
2. Timeout'u artır: { timeout: 10000 }
3. Component'te yarış koşullarını kontrol et
4. Elementin animasyon tarafından gizlenmediğini doğrula
Karantina önerisi: Düzeltilene kadar test.fixme() olarak işaretle
```
## Tarayıcı Yapılandırması
Testler varsayılan olarak birden fazla tarayıcıda çalışır:
- ✅ Chromium (Desktop Chrome)
- ✅ Firefox (Desktop)
- ✅ WebKit (Desktop Safari)
- ✅ Mobile Chrome (opsiyonel)
Tarayıcıları ayarlamak için `playwright.config.ts`'yi yapılandırın.
## CI/CD Entegrasyonu
CI pipeline'ınıza ekleyin:
```yaml
# .github/workflows/e2e.yml
- name: Install Playwright
run: npx playwright install --with-deps
- name: Run E2E tests
run: npx playwright test
- name: Upload artifacts
if: always()
uses: actions/upload-artifact@v3
with:
name: playwright-report
path: playwright-report/
```
## PMX'e Özgü Kritik Akışlar
PMX için bu E2E testlerine öncelik verin:
**🔴 KRİTİK (Her Zaman Geçmeli):**
1. Kullanıcı cüzdan bağlayabilir
2. Kullanıcı piyasalara göz atabilir
3. Kullanıcı piyasa arayabilir (semantik arama)
4. Kullanıcı piyasa detaylarını görüntüleyebilir
5. Kullanıcı işlem yapabilir (test fonlarıyla)
6. Piyasa doğru çözülür
7. Kullanıcı fon çekebilir
**🟡 ÖNEMLİ:**
1. Piyasa oluşturma akışı
2. Kullanıcı profil güncellemeleri
3. Gerçek zamanlı fiyat güncellemeleri
4. Grafik render'ı
5. Piyasaları filtreleme ve sıralama
6. Mobil responsive layout
## En İyi Uygulamalar
**YAPIN:**
- ✅ Sürdürülebilirlik için Page Object Model kullanın
- ✅ Selector'lar için data-testid nitelikleri kullanın
- ✅ Rastgele timeout'lar değil, API yanıtlarını bekleyin
- ✅ Kritik kullanıcı yolculuklarını uçtan uca test edin
- ✅ Main'e merge etmeden önce testleri çalıştırın
- ✅ Testler başarısız olduğunda artifact'ları inceleyin
**YAPMAYIN:**
- ❌ Kırılgan selector'lar kullanmayın (CSS sınıfları değişebilir)
- ❌ Uygulama detaylarını test etmeyin
- ❌ Production'a karşı testler çalıştırmayın
- ❌ Dengesiz testleri görmezden gelmeyin
- ❌ Başarısızlıklarda artifact incelemesini atlamayın
- ❌ Her edge case'i E2E ile test etmeyin (unit testler kullanın)
## Önemli Notlar
**PMX için KRİTİK:**
- Gerçek para içeren E2E testleri SADECE testnet/staging'de çalışmalıdır
- Asla production'a karşı ticaret testleri çalıştırmayın
- Finansal testler için `test.skip(process.env.NODE_ENV === 'production')` ayarlayın
- Sadece küçük test fonlarıyla test cüzdanları kullanın
## Diğer Komutlarla Entegrasyon
- Test edilecek kritik yolculukları tanımlamak için `/plan` kullanın
- Unit testler için `/tdd` kullanın (daha hızlı, daha ayrıntılı)
- Entegrasyon ve kullanıcı yolculuk testleri için `/e2e` kullanın
- Test kalitesini doğrulamak için `/code-review` kullanın
## İlgili Agent'lar
Bu komut, ECC tarafından sağlanan `e2e-runner` agent'ını çağırır.
Manuel kurulumlar için, kaynak dosya şurada bulunur:
`agents/e2e-runner.md`
## Hızlı Komutlar
```bash
# Tüm E2E testlerini çalıştır
npx playwright test
# Belirli test dosyasını çalıştır
npx playwright test tests/e2e/markets/search.spec.ts
# Headed modda çalıştır (tarayıcıyı gör)
npx playwright test --headed
# Testi debug et
npx playwright test --debug
# Test kodu oluştur
npx playwright codegen http://localhost:3000
# Raporu görüntüle
npx playwright show-report
```

120
docs/tr/commands/eval.md Normal file
View File

@@ -0,0 +1,120 @@
# Eval Komutu
Eval-odaklı geliştirme iş akışını yönet.
## Kullanım
`/eval [define|check|report|list] [feature-name]`
## Eval Tanımla
`/eval define feature-name`
Yeni bir eval tanımı oluştur:
1. Şablonla `.claude/evals/feature-name.md` oluştur:
```markdown
## EVAL: feature-name
Created: $(date)
### Capability Evals
- [ ] [Capability 1 açıklaması]
- [ ] [Capability 2 açıklaması]
### Regression Evals
- [ ] [Mevcut davranış 1 hala çalışıyor]
- [ ] [Mevcut davranış 2 hala çalışıyor]
### Success Criteria
- pass@3 > 90% for capability evals
- pass^3 = 100% for regression evals
```
2. Kullanıcıdan belirli kriterleri doldurmasını iste
## Eval Kontrol Et
`/eval check feature-name`
Bir özellik için eval'ları çalıştır:
1. `.claude/evals/feature-name.md` dosyasından eval tanımını oku
2. Her capability eval için:
- Kriteri doğrulamayı dene
- PASS/FAIL kaydet
- Denemeyi `.claude/evals/feature-name.log` dosyasına kaydet
3. Her regression eval için:
- İlgili test'leri çalıştır
- Baseline ile karşılaştır
- PASS/FAIL kaydet
4. Mevcut durumu raporla:
```
EVAL CHECK: feature-name
========================
Capability: X/Y passing
Regression: X/Y passing
Status: IN PROGRESS / READY
```
## Eval Raporu
`/eval report feature-name`
Kapsamlı eval raporu oluştur:
```
EVAL REPORT: feature-name
=========================
Generated: $(date)
CAPABILITY EVALS
----------------
[eval-1]: PASS (pass@1)
[eval-2]: PASS (pass@2) - required retry
[eval-3]: FAIL - see notes
REGRESSION EVALS
----------------
[test-1]: PASS
[test-2]: PASS
[test-3]: PASS
METRICS
-------
Capability pass@1: 67%
Capability pass@3: 100%
Regression pass^3: 100%
NOTES
-----
[Herhangi bir sorun, edge case veya gözlem]
RECOMMENDATION
--------------
[SHIP / NEEDS WORK / BLOCKED]
```
## Eval'ları Listele
`/eval list`
Tüm eval tanımlarını göster:
```
EVAL DEFINITIONS
================
feature-auth [3/5 passing] IN PROGRESS
feature-search [5/5 passing] READY
feature-export [0/4 passing] NOT STARTED
```
## Argümanlar
$ARGUMENTS:
- `define <name>` - Yeni eval tanımı oluştur
- `check <name>` - Eval'ları çalıştır ve kontrol et
- `report <name>` - Tam rapor oluştur
- `list` - Tüm eval'ları göster
- `clean` - Eski eval loglarını kaldır (son 10 çalıştırmayı tutar)

178
docs/tr/commands/evolve.md Normal file
View File

@@ -0,0 +1,178 @@
---
name: evolve
description: İçgüdüleri analiz et ve evrimleşmiş yapılar öner veya oluştur
command: true
---
# Evolve Komutu
## Uygulama
Plugin root path kullanarak instinct CLI'ı çalıştır:
```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" evolve [--generate]
```
Veya `CLAUDE_PLUGIN_ROOT` ayarlanmamışsa (manuel kurulum):
```bash
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [--generate]
```
İçgüdüleri analiz eder ve ilgili olanları daha üst seviye yapılara kümelendirir:
- **Commands**: İçgüdüler kullanıcı tarafından çağrılan aksiyonları tanımladığında
- **Skills**: İçgüdüler otomatik tetiklenen davranışları tanımladığında
- **Agents**: İçgüdüler karmaşık, çok adımlı süreçleri tanımladığında
## Kullanım
```
/evolve # Tüm içgüdüleri analiz et ve evrimleri öner
/evolve --generate # Ayrıca evolved/{skills,commands,agents} altında dosyalar oluştur
```
## Evrim Kuralları
### → Command (Kullanıcı Tarafından Çağrılan)
İçgüdüler kullanıcının açıkça talep edeceği aksiyonları tanımladığında:
- "Kullanıcı ... istediğinde" hakkında birden fazla içgüdü
- "Yeni X oluştururken" gibi tetikleyicilere sahip içgüdüler
- Tekrarlanabilir bir sıra izleyen içgüdüler
Örnek:
- `new-table-step1`: "veritabanı tablosu eklerken, migration oluştur"
- `new-table-step2`: "veritabanı tablosu eklerken, şemayı güncelle"
- `new-table-step3`: "veritabanı tablosu eklerken, tipleri yeniden oluştur"
→ Oluşturur: **new-table** komutu
### → Skill (Otomatik Tetiklenen)
İçgüdüler otomatik olarak gerçekleşmesi gereken davranışları tanımladığında:
- Pattern-matching tetikleyiciler
- Hata işleme yanıtları
- Kod stili zorlaması
Örnek:
- `prefer-functional`: "fonksiyon yazarken, functional stil tercih et"
- `use-immutable`: "state değiştirirken, immutable pattern kullan"
- `avoid-classes`: "modül tasarlarken, class-based tasarımdan kaçın"
→ Oluşturur: `functional-patterns` skill
### → Agent (Derinlik/İzolasyon Gerektirir)
İçgüdüler izolasyondan fayda sağlayan karmaşık, çok adımlı süreçleri tanımladığında:
- Debugging iş akışları
- Refactoring dizileri
- Araştırma görevleri
Örnek:
- `debug-step1`: "debug yaparken, önce logları kontrol et"
- `debug-step2`: "debug yaparken, başarısız componenti izole et"
- `debug-step3`: "debug yaparken, minimal reproduction oluştur"
- `debug-step4`: "debug yaparken, düzeltmeyi testle doğrula"
→ Oluşturur: **debugger** agent
## Yapılacaklar
1. Mevcut proje bağlamını tespit et
2. Proje + global içgüdüleri oku (ID çakışmalarında proje önceliklidir)
3. İçgüdüleri tetikleyici/domain desenlerine göre grupla
4. Şunları tanımla:
- Skill adayları (2+ içgüdüye sahip tetikleyici kümeleri)
- Command adayları (yüksek güvenli workflow içgüdüleri)
- Agent adayları (daha büyük, yüksek güvenli kümeler)
5. Uygulanabilir durumlarda terfi adaylarını göster (proje -> global)
6. `--generate` geçilirse, dosyaları şuraya yaz:
- Proje kapsamı: `~/.claude/homunculus/projects/<project-id>/evolved/`
- Global fallback: `~/.claude/homunculus/evolved/`
## Çıktı Formatı
```
============================================================
EVOLVE ANALYSIS - 12 instincts
Project: my-app (a1b2c3d4e5f6)
Project-scoped: 8 | Global: 4
============================================================
High confidence instincts (>=80%): 5
## SKILL CANDIDATES
1. Cluster: "adding tests"
Instincts: 3
Avg confidence: 82%
Domains: testing
Scopes: project
## COMMAND CANDIDATES (2)
/adding-tests
From: test-first-workflow [project]
Confidence: 84%
## AGENT CANDIDATES (1)
adding-tests-agent
Covers 3 instincts
Avg confidence: 82%
```
## Bayraklar
- `--generate`: Analiz çıktısına ek olarak evrimleşmiş dosyaları oluştur
## Oluşturulan Dosya Formatı
### Command
```markdown
---
name: new-table
description: Migration, şema güncellemesi ve tip oluşturma ile yeni veritabanı tablosu oluştur
command: /new-table
evolved_from:
- new-table-migration
- update-schema
- regenerate-types
---
# New Table Command
[Kümelenmiş içgüdülere dayalı oluşturulan içerik]
## Steps
1. ...
2. ...
```
### Skill
```markdown
---
name: functional-patterns
description: Functional programming pattern'lerini zorla
evolved_from:
- prefer-functional
- use-immutable
- avoid-classes
---
# Functional Patterns Skill
[Kümelenmiş içgüdülere dayalı oluşturulan içerik]
```
### Agent
```markdown
---
name: debugger
description: Sistematik debugging agent
model: sonnet
evolved_from:
- debug-check-logs
- debug-isolate
- debug-reproduce
---
# Debugger Agent
[Kümelenmiş içgüdülere dayalı oluşturulan içerik]
```

View File

@@ -0,0 +1,183 @@
---
description: Go build hatalarını, go vet uyarılarını ve linter sorunlarını aşamalı olarak düzelt. Minimal, cerrahi düzeltmeler için go-build-resolver agent'ını çağırır.
---
# Go Build and Fix
Bu komut, minimal değişikliklerle Go build hatalarını aşamalı olarak düzeltmek için **go-build-resolver** agent'ını çağırır.
## Bu Komut Ne Yapar
1. **Diagnostics Çalıştır**: `go build`, `go vet`, `staticcheck` yürüt
2. **Hataları Parse Et**: Dosyaya göre grupla ve önem derecesine göre sırala
3. **Aşamalı Düzelt**: Bir seferde bir hata
4. **Her Düzeltmeyi Doğrula**: Her değişiklikten sonra build'i yeniden çalıştır
5. **Özet Raporla**: Neyin düzeltildiğini ve neyin kaldığını göster
## Ne Zaman Kullanılır
`/go-build` komutunu şu durumlarda kullanın:
- `go build ./...` hatalarla başarısız olduğunda
- `go vet ./...` sorunlar raporladığında
- `golangci-lint run` uyarılar gösterdiğinde
- Modül bağımlılıkları bozulduğunda
- Build'i bozan değişiklikleri pull ettikten sonra
## Çalıştırılan Diagnostic Komutları
```bash
# Birincil build kontrolü
go build ./...
# Static analiz
go vet ./...
# Genişletilmiş linting (mevcutsa)
staticcheck ./...
golangci-lint run
# Modül sorunları
go mod verify
go mod tidy -v
```
## Örnek Oturum
```text
Kullanıcı: /go-build
Agent:
# Go Build Çözümü
## İlk Diagnostics
```bash
$ go build ./...
internal/service/user.go:25:15: undefined: UserRepository
internal/handler/api.go:42:9: cannot use x (type string) as type int
internal/handler/api.go:58:2: missing return at end of function
```
Bulunan hatalar: 3
## Düzeltme 1: Tanımsız Tanımlayıcı
Dosya: internal/service/user.go:25
Hata: undefined: UserRepository
Neden: Eksik import
```go
// Import eklendi
import "project/internal/repository"
// Değiştirildi
var repo UserRepository
// Şuna
var repo repository.UserRepository
```
```bash
$ go build ./...
# 2 hata kaldı
```
## Düzeltme 2: Tip Uyuşmazlığı
Dosya: internal/handler/api.go:42
Hata: cannot use x (type string) as type int
```go
// Değiştirildi
count := params.Get("count")
// Şuna
countStr := params.Get("count")
count, _ := strconv.Atoi(countStr)
```
```bash
$ go build ./...
# 1 hata kaldı
```
## Düzeltme 3: Eksik Return
Dosya: internal/handler/api.go:58
Hata: missing return at end of function
```go
func GetUser(id string) (*User, error) {
if id == "" {
return nil, ErrInvalidID
}
user := findUser(id)
// Eksik return eklendi
return user, nil
}
```
```bash
$ go build ./...
# Build başarılı!
```
## Son Doğrulama
```bash
$ go vet ./...
# Sorun yok
$ go test ./...
ok project/internal/service 0.015s
ok project/internal/handler 0.023s
```
## Özet
| Metrik | Sayı |
|--------|-------|
| Düzeltilen build hataları | 3 |
| Düzeltilen vet uyarıları | 0 |
| Değiştirilen dosyalar | 2 |
| Kalan sorunlar | 0 |
Build Durumu: ✅ BAŞARILI
```
## Düzeltilen Yaygın Hatalar
| Hata | Tipik Düzeltme |
|-------|-------------|
| `undefined: X` | Import ekle veya yazım hatasını düzelt |
| `cannot use X as Y` | Tip dönüşümü veya atamayı düzelt |
| `missing return` | Return ifadesi ekle |
| `X does not implement Y` | Eksik metod ekle |
| `import cycle` | Paketleri yeniden yapılandır |
| `declared but not used` | Değişkeni kaldır veya kullan |
| `cannot find package` | `go get` veya `go mod tidy` |
## Düzeltme Stratejisi
1. **Önce build hataları** - Kodun compile edilmesi gerekli
2. **İkinci olarak vet uyarıları** - Şüpheli yapıları düzelt
3. **Üçüncü olarak lint uyarıları** - Stil ve en iyi uygulamalar
4. **Bir seferde bir düzeltme** - Her değişikliği doğrula
5. **Minimal değişiklikler** - Refactor etme, sadece düzelt
## Durdurma Koşulları
Agent şu durumlarda durur ve raporlar:
- Aynı hata 3 denemeden sonra devam ederse
- Düzeltme daha fazla hata oluşturursa
- Mimari değişiklikler gerektirirse
- Harici bağımlılıklar eksikse
## İlgili Komutlar
- `/go-test` - Build başarılı olduktan sonra testleri çalıştır
- `/go-review` - Kod kalitesini incele
- `/verify` - Tam doğrulama döngüsü
## İlgili
- Agent: `agents/go-build-resolver.md`
- Skill: `skills/golang-patterns/`

View File

@@ -0,0 +1,148 @@
---
description: İdiomatic desenler, eşzamanlılık güvenliği, hata yönetimi ve güvenlik için kapsamlı Go kod incelemesi. go-reviewer agent'ını çağırır.
---
# Go Code Review
Bu komut, Go'ya özel kapsamlı kod incelemesi için **go-reviewer** agent'ını çağırır.
## Bu Komut Ne Yapar
1. **Go Değişikliklerini Tanımla**: `git diff` ile değiştirilmiş `.go` dosyalarını bul
2. **Static Analiz Çalıştır**: `go vet`, `staticcheck` ve `golangci-lint` yürüt
3. **Güvenlik Taraması**: SQL injection, command injection, race condition'ları kontrol et
4. **Eşzamanlılık İncelemesi**: Goroutine güvenliğini, channel kullanımını, mutex desenlerini analiz et
5. **İdiomatic Go Kontrolü**: Kodun Go kurallarına ve en iyi uygulamalara uyduğunu doğrula
6. **Rapor Oluştur**: Sorunları önem derecesine göre kategorize et
## Ne Zaman Kullanılır
`/go-review` komutunu şu durumlarda kullanın:
- Go kodu yazdıktan veya değiştirdikten sonra
- Go değişikliklerini commit etmeden önce
- Go kodu içeren pull request'leri incelerken
- Yeni bir Go kod tabanına adapte olurken
- İdiomatic Go desenlerini öğrenirken
## İnceleme Kategorileri
### KRİTİK (Düzeltilmeli)
- SQL/Command injection açıklıkları
- Senkronizasyon olmadan race condition'lar
- Goroutine sızıntıları
- Hardcode edilmiş kimlik bilgileri
- Güvenli olmayan pointer kullanımı
- Kritik yollarda göz ardı edilen hatalar
### YÜKSEK (Düzeltilmeli)
- Bağlamlı hata sarmalama eksikliği
- Hata dönüşleri yerine panic
- Context yayılmıyor
- Deadlock'a neden olan buffersız channel'lar
- Interface yerine getirilmeme hataları
- Eksik mutex koruması
### ORTA (Düşünün)
- İdiomatic olmayan kod desenleri
- Export edilen elementlerde eksik godoc yorumları
- Verimsiz string birleştirme
- Preallocate edilmemiş slice
- Table-driven testler kullanılmamış
## Çalıştırılan Otomatik Kontroller
```bash
# Static analiz
go vet ./...
# Gelişmiş kontroller (kuruluysa)
staticcheck ./...
golangci-lint run
# Race tespiti
go build -race ./...
# Güvenlik açıklıkları
govulncheck ./...
```
## Örnek Kullanım
```text
Kullanıcı: /go-review
Agent:
# Go Kod İnceleme Raporu
## İncelenen Dosyalar
- internal/handler/user.go (değiştirildi)
- internal/service/auth.go (değiştirildi)
## Static Analiz Sonuçları
✓ go vet: Sorun yok
✓ staticcheck: Sorun yok
## Bulunan Sorunlar
[KRİTİK] Race Condition
Dosya: internal/service/auth.go:45
Sorun: Paylaşılan map senkronizasyon olmadan erişiliyor
```go
var cache = map[string]*Session{} // Eşzamanlı erişim!
func GetSession(id string) *Session {
return cache[id] // Race condition
}
```
Düzeltme: sync.RWMutex veya sync.Map kullan
```go
var (
cache = map[string]*Session{}
cacheMu sync.RWMutex
)
func GetSession(id string) *Session {
cacheMu.RLock()
defer cacheMu.RUnlock()
return cache[id]
}
```
[YÜKSEK] Eksik Hata Bağlamı
Dosya: internal/handler/user.go:28
Sorun: Hata bağlam olmadan döndürülüyor
```go
return err // Bağlam yok
```
Düzeltme: Bağlamla sarmala
```go
return fmt.Errorf("get user %s: %w", userID, err)
```
## Özet
- KRİTİK: 1
- YÜKSEK: 1
- ORTA: 0
Öneri: ❌ KRİTİK sorun düzeltilene kadar merge'i engelle
```
## Onay Kriterleri
| Durum | Koşul |
|--------|-----------|
| ✅ Onayla | KRİTİK veya YÜKSEK sorun yok |
| ⚠️ Uyarı | Sadece ORTA sorunlar (dikkatle merge et) |
| ❌ Engelle | KRİTİK veya YÜKSEK sorun bulundu |
## Diğer Komutlarla Entegrasyon
- Testlerin geçtiğinden emin olmak için önce `/go-test` kullanın
- Build hataları oluşursa `/go-build` kullanın
- Commit etmeden önce `/go-review` kullanın
- Go'ya özel olmayan endişeler için `/code-review` kullanın
## İlgili
- Agent: `agents/go-reviewer.md`
- Skills: `skills/golang-patterns/`, `skills/golang-testing/`

268
docs/tr/commands/go-test.md Normal file
View File

@@ -0,0 +1,268 @@
---
description: Go için TDD iş akışını zorlar. Önce table-driven testler yaz, sonra uygula. go test -cover ile %80+ kapsama doğrula.
---
# Go TDD Komutu
Bu komut, idiomatic Go test desenlerini kullanarak Go kodu için test odaklı geliştirme metodolojisini zorlar.
## Bu Komut Ne Yapar
1. **Tipleri/Interface'leri Tanımla**: Önce fonksiyon imzalarını tasarla
2. **Table-Driven Testler Yaz**: Kapsamlı test senaryoları oluştur (RED)
3. **Testleri Çalıştır**: Testlerin doğru sebepten başarısız olduğunu doğrula
4. **Kodu Uygula**: Geçmek için minimal kod yaz (GREEN)
5. **Refactor Et**: Testleri yeşil tutarken iyileştir
6. **Kapsama Kontrol Et**: %80+ kapsama sağla
## Ne Zaman Kullanılır
`/go-test` komutunu şu durumlarda kullanın:
- Yeni Go fonksiyonları uygularken
- Mevcut koda test kapsama eklerken
- Hataları düzeltirken (önce başarısız test yaz)
- Kritik iş mantığı oluştururken
- Go'da TDD iş akışını öğrenirken
## TDD Döngüsü
```
RED → Başarısız table-driven test yaz
GREEN → Geçmek için minimal kod uygula
REFACTOR → Kodu iyileştir, testler yeşil kalsın
TEKRARLA → Sonraki test senaryosu
```
## Örnek Oturum
````
Kullanıcı: /go-test E-posta adreslerini doğrulamak için bir fonksiyona ihtiyacım var
Agent:
# TDD Oturumu: E-posta Doğrulayıcı
## Adım 1: Interface Tanımla
```go
// validator/email.go
package validator
// ValidateEmail verilen string'in geçerli bir e-posta adresi olup olmadığını kontrol eder.
// Geçerliyse nil, aksi takdirde sorunu açıklayan hata döndürür.
func ValidateEmail(email string) error {
panic("not implemented")
}
```
## Adım 2: Table-Driven Testler Yaz (RED)
```go
// validator/email_test.go
package validator
import (
"testing"
)
func TestValidateEmail(t *testing.T) {
tests := []struct {
name string
email string
wantErr bool
}{
// Geçerli e-postalar
{"basit e-posta", "user@example.com", false},
{"subdomain ile", "user@mail.example.com", false},
{"artı ile", "user+tag@example.com", false},
{"noktalar ile", "first.last@example.com", false},
// Geçersiz e-postalar
{"boş string", "", true},
{"at işareti yok", "userexample.com", true},
{"domain yok", "user@", true},
{"local kısım yok", "@example.com", true},
{"çift at", "user@@example.com", true},
{"boşluklar", "user @example.com", true},
{"tld yok", "user@example", true},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
err := ValidateEmail(tt.email)
if tt.wantErr && err == nil {
t.Errorf("ValidateEmail(%q) = nil; hata bekleniyor", tt.email)
}
if !tt.wantErr && err != nil {
t.Errorf("ValidateEmail(%q) = %v; nil bekleniyor", tt.email, err)
}
})
}
}
```
## Adım 3: Testleri Çalıştır - Başarısızlığı Doğrula
```bash
$ go test ./validator/...
--- FAIL: TestValidateEmail (0.00s)
--- FAIL: TestValidateEmail/basit_e-posta (0.00s)
panic: not implemented
FAIL
```
✓ Testler beklendiği gibi başarısız (panic).
## Adım 4: Minimal Kod Uygula (GREEN)
```go
// validator/email.go
package validator
import (
"errors"
"regexp"
)
var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
var (
ErrEmailEmpty = errors.New("e-posta boş olamaz")
ErrEmailInvalid = errors.New("e-posta formatı geçersiz")
)
func ValidateEmail(email string) error {
if email == "" {
return ErrEmailEmpty
}
if !emailRegex.MatchString(email) {
return ErrEmailInvalid
}
return nil
}
```
## Adım 5: Testleri Çalıştır - Başarıyı Doğrula
```bash
$ go test ./validator/...
PASS
ok project/validator 0.003s
```
✓ Tüm testler geçiyor!
## Adım 6: Kapsama Kontrol Et
```bash
$ go test -cover ./validator/...
PASS
coverage: 100.0% of statements
ok project/validator 0.003s
```
✓ Kapsama: 100%
## TDD Tamamlandı!
````
## Test Desenleri
### Table-Driven Testler
```go
tests := []struct {
name string
input InputType
want OutputType
wantErr bool
}{
{"senaryo 1", input1, want1, false},
{"senaryo 2", input2, want2, true},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got, err := Function(tt.input)
// assertion'lar
})
}
```
### Paralel Testler
```go
for _, tt := range tests {
tt := tt // Yakala
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
// test gövdesi
})
}
```
### Test Yardımcıları
```go
func setupTestDB(t *testing.T) *sql.DB {
t.Helper()
db := createDB()
t.Cleanup(func() { db.Close() })
return db
}
```
## Kapsama Komutları
```bash
# Basit kapsama
go test -cover ./...
# Kapsama profili
go test -coverprofile=coverage.out ./...
# Tarayıcıda görüntüle
go tool cover -html=coverage.out
# Fonksiyona göre kapsama
go tool cover -func=coverage.out
# Race tespiti ile
go test -race -cover ./...
```
## Kapsama Hedefleri
| Kod Türü | Hedef |
|-----------|--------|
| Kritik iş mantığı | 100% |
| Public API'ler | 90%+ |
| Genel kod | 80%+ |
| Oluşturulan kod | Hariç tut |
## TDD En İyi Uygulamaları
**YAPIN:**
- Herhangi bir uygulamadan ÖNCE test yaz
- Her değişiklikten sonra testleri çalıştır
- Kapsamlı kapsama için table-driven testler kullan
- Uygulama detaylarını değil, davranışı test et
- Edge case'leri dahil et (boş, nil, maksimum değerler)
**YAPMAYIN:**
- Testlerden önce uygulama yazma
- RED aşamasını atlama
- Private fonksiyonları doğrudan test etme
- Testlerde `time.Sleep` kullanma
- Dengesiz testleri görmezden gelme
## İlgili Komutlar
- `/go-build` - Build hatalarını düzelt
- `/go-review` - Uygulamadan sonra kodu incele
- `/verify` - Tam doğrulama döngüsünü çalıştır
## İlgili
- Skill: `skills/golang-testing/`
- Skill: `skills/tdd-workflow/`

View File

@@ -0,0 +1,66 @@
---
name: instinct-export
description: İçgüdüleri proje/global kapsamdan bir dosyaya aktar
command: /instinct-export
---
# Instinct Export Komutu
İçgüdüleri paylaşılabilir bir formata aktarır. Şunlar için mükemmel:
- Takım arkadaşlarıyla paylaşmak
- Yeni bir makineye aktarmak
- Proje konvansiyonlarına katkıda bulunmak
## Kullanım
```
/instinct-export # Tüm kişisel içgüdüleri dışa aktar
/instinct-export --domain testing # Sadece testing içgüdülerini dışa aktar
/instinct-export --min-confidence 0.7 # Sadece yüksek güvenli içgüdüleri dışa aktar
/instinct-export --output team-instincts.yaml
/instinct-export --scope project --output project-instincts.yaml
```
## Yapılacaklar
1. Mevcut proje bağlamını tespit et
2. Seçilen kapsama göre içgüdüleri yükle:
- `project`: sadece mevcut proje
- `global`: sadece global
- `all`: proje + global birleştirilmiş (varsayılan)
3. Filtreleri uygula (`--domain`, `--min-confidence`)
4. YAML formatında dosyaya yaz (veya çıktı yolu verilmediyse stdout'a)
## Çıktı Formatı
Bir YAML dosyası oluşturur:
```yaml
# Instincts Export
# Generated: 2025-01-22
# Source: personal
# Count: 12 instincts
---
id: prefer-functional-style
trigger: "when writing new functions"
confidence: 0.8
domain: code-style
source: session-observation
scope: project
project_id: a1b2c3d4e5f6
project_name: my-app
---
# Prefer Functional Style
## Action
Use functional patterns over classes.
```
## Bayraklar
- `--domain <name>`: Sadece belirtilen domain'i dışa aktar
- `--min-confidence <n>`: Minimum güven eşiği
- `--output <file>`: Çıktı dosya yolu (atlandığında stdout'a yazdırır)
- `--scope <project|global|all>`: Dışa aktarma kapsamı (varsayılan: `all`)

View File

@@ -0,0 +1,114 @@
---
name: instinct-import
description: İçgüdüleri dosya veya URL'den proje/global kapsama aktar
command: true
---
# Instinct Import Komutu
## Uygulama
Plugin root path kullanarak instinct CLI'ı çalıştır:
```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" import <file-or-url> [--dry-run] [--force] [--min-confidence 0.7] [--scope project|global]
```
Veya `CLAUDE_PLUGIN_ROOT` ayarlanmamışsa (manuel kurulum):
```bash
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py import <file-or-url>
```
Yerel dosya yollarından veya HTTP(S) URL'lerinden içgüdüleri içe aktar.
## Kullanım
```
/instinct-import team-instincts.yaml
/instinct-import https://raw.githubusercontent.com/org/repo/main/instincts.yaml
/instinct-import team-instincts.yaml --dry-run
/instinct-import team-instincts.yaml --scope global --force
```
## Yapılacaklar
1. İçgüdü dosyasını al (yerel yol veya URL)
2. Formatı doğrula ve ayrıştır
3. Mevcut içgüdülerle duplikasyon kontrolü yap
4. Yeni içgüdüleri birleştir veya ekle
5. İçgüdüleri inherited dizinine kaydet:
- Proje kapsamı: `~/.claude/homunculus/projects/<project-id>/instincts/inherited/`
- Global kapsam: `~/.claude/homunculus/instincts/inherited/`
## İçe Aktarma İşlemi
```
📥 Importing instincts from: team-instincts.yaml
================================================
Found 12 instincts to import.
Analyzing conflicts...
## New Instincts (8)
These will be added:
✓ use-zod-validation (confidence: 0.7)
✓ prefer-named-exports (confidence: 0.65)
✓ test-async-functions (confidence: 0.8)
...
## Duplicate Instincts (3)
Already have similar instincts:
⚠️ prefer-functional-style
Local: 0.8 confidence, 12 observations
Import: 0.7 confidence
→ Keep local (higher confidence)
⚠️ test-first-workflow
Local: 0.75 confidence
Import: 0.9 confidence
→ Update to import (higher confidence)
Import 8 new, update 1?
```
## Birleştirme Davranışı
Mevcut ID'ye sahip bir içgüdü içe aktarılırken:
- Daha yüksek güvenli içe aktarma güncelleme adayı olur
- Eşit/düşük güvenli içe aktarma atlanır
- `--force` kullanılmadıkça kullanıcı onaylar
## Kaynak İzleme
İçe aktarılan içgüdüler şu şekilde işaretlenir:
```yaml
source: inherited
scope: project
imported_from: "team-instincts.yaml"
project_id: "a1b2c3d4e5f6"
project_name: "my-project"
```
## Bayraklar
- `--dry-run`: İçe aktarmadan önizle
- `--force`: Onay istemini atla
- `--min-confidence <n>`: Sadece eşiğin üzerindeki içgüdüleri içe aktar
- `--scope <project|global>`: Hedef kapsamı seç (varsayılan: `project`)
## Çıktı
İçe aktarma sonrası:
```
✅ Import complete!
Added: 8 instincts
Updated: 1 instinct
Skipped: 3 instincts (equal/higher confidence already exists)
New instincts saved to: ~/.claude/homunculus/instincts/inherited/
Run /instinct-status to see all instincts.
```

View File

@@ -0,0 +1,59 @@
---
name: instinct-status
description: Öğrenilen içgüdüleri (proje + global) güven seviyesiyle göster
command: true
---
# Instinct Status Komutu
Mevcut proje için öğrenilen içgüdüleri ve global içgüdüleri, domain'e göre gruplandırılmış şekilde gösterir.
## Uygulama
Plugin root path kullanarak instinct CLI'ı çalıştır:
```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" status
```
Veya `CLAUDE_PLUGIN_ROOT` ayarlanmamışsa (manuel kurulum):
```bash
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py status
```
## Kullanım
```
/instinct-status
```
## Yapılacaklar
1. Mevcut proje bağlamını tespit et (git remote/path hash)
2. `~/.claude/homunculus/projects/<project-id>/instincts/` konumundan proje içgüdülerini oku
3. `~/.claude/homunculus/instincts/` konumundan global içgüdüleri oku
4. Öncelik kurallarıyla birleştir (ID çakışmasında proje global'i geçersiz kılar)
5. Domain'e göre gruplandırılmış, güven çubukları ve gözlem istatistikleriyle göster
## Çıktı Formatı
```
============================================================
INSTINCT STATUS - 12 total
============================================================
Project: my-app (a1b2c3d4e5f6)
Project instincts: 8
Global instincts: 4
## PROJECT-SCOPED (my-app)
### WORKFLOW (3)
███████░░░ 70% grep-before-edit [project]
trigger: when modifying code
## GLOBAL (apply to all projects)
### SECURITY (2)
█████████░ 85% validate-user-input [global]
trigger: when handling user input
```

View File

@@ -0,0 +1,116 @@
---
description: "Oturumdan yeniden kullanılabilir desenleri çıkar, kaydetmeden önce kaliteyi kendinden değerlendir ve doğru kayıt konumunu belirle (Global vs Proje)."
---
# /learn-eval - Çıkar, Değerlendir, Sonra Kaydet
Herhangi bir skill dosyası yazmadan önce kalite kontrolü, kayıt konumu kararı ve bilgi yerleşimi farkındalığı ile `/learn`'ü genişletir.
## Ne Çıkarılmalı
Şunları arayın:
1. **Hata Çözüm Desenleri** — kök neden + düzeltme + yeniden kullanılabilirlik
2. **Hata Ayıklama Teknikleri** — bariz olmayan adımlar, araç kombinasyonları
3. **Geçici Çözümler** — kütüphane gariplikleri, API sınırlamaları, versiyona özel düzeltmeler
4. **Projeye Özgü Desenler** — kurallar, mimari kararlar, entegrasyon desenleri
## Süreç
1. Çıkarılabilir desenler için oturumu incele
2. En değerli/yeniden kullanılabilir içgörüyü tanımla
3. **Kayıt konumunu belirle:**
- Sor: "Bu desen farklı bir projede faydalı olur mu?"
- **Global** (`~/.claude/skills/learned/`): 2+ projede kullanılabilir genel desenler (bash uyumluluğu, LLM API davranışı, hata ayıklama teknikleri, vb.)
- **Proje** (mevcut projedeki `.claude/skills/learned/`): Projeye özel bilgi (belirli bir config dosyasının gariplikleri, projeye özel mimari kararlar, vb.)
- Emin değilseniz, Global seçin (Global → Proje taşımak tersinden daha kolay)
4. Bu formatı kullanarak skill dosyasını taslak olarak hazırla:
```markdown
---
name: desen-adi
description: "130 karakterin altında"
user-invocable: false
origin: auto-extracted
---
# [Açıklayıcı Desen Adı]
**Çıkarıldı:** [Tarih]
**Bağlam:** [Bunun ne zaman geçerli olduğunun kısa açıklaması]
## Sorun
[Bunun çözdüğü sorun - spesifik olun]
## Çözüm
[Desen/teknik/geçici çözüm - kod örnekleriyle]
## Ne Zaman Kullanılır
[Tetikleyici koşullar]
```
5. **Kalite kontrolü — Kontrol listesi + Bütünsel karar**
### 5a. Gerekli kontrol listesi (dosyaları gerçekten okuyarak doğrula)
Taslağı değerlendirmeden önce **tümünü** yürüt:
- [ ] İçerik örtüşmesini kontrol etmek için anahtar kelimeyle `~/.claude/skills/` ve ilgili proje `.claude/skills/` dosyalarını Grep ile ara
- [ ] Örtüşme için MEMORY.md'yi kontrol et (hem proje hem de global)
- [ ] Mevcut bir skill'e eklemenin yeterli olup olmayacağını düşün
- [ ] Bunun yeniden kullanılabilir bir desen olduğunu, tek seferlik bir düzeltme olmadığını onayla
### 5b. Bütünsel karar
Kontrol listesi sonuçlarını ve taslak kalitesini sentezle, sonra şunlardan **birini** seç:
| Karar | Anlam | Sonraki Aksiyon |
|---------|---------|-------------|
| **Kaydet** | Benzersiz, spesifik, iyi kapsamlı | Adım 6'ya geç |
| **İyileştir sonra Kaydet** | Değerli ama iyileştirme gerekiyor | İyileştirmeleri listele → revize et → yeniden değerlendir (bir kez) |
| **[X]'e Ekle** | Mevcut bir skill'e eklenmelidir | Hedef skill'i ve eklemeleri göster → Adım 6 |
| **Düşür** | Önemsiz, gereksiz veya çok soyut | Gerekçeyi açıkla ve dur |
**Yönlendirici boyutlar** (karar verirken, puanlanmaz):
- **Spesifiklik ve Uygulanabilirlik**: Hemen kullanılabilir kod örnekleri veya komutlar içerir
- **Kapsam Uyumu**: Ad, tetikleyici koşullar ve içerik hizalanmış ve tek bir desene odaklanmış
- **Benzersizlik**: Mevcut skill'lerin kapsamadığı değer sağlar (kontrol listesi sonuçlarına göre)
- **Yeniden Kullanılabilirlik**: Gelecekteki oturumlarda gerçekçi tetikleyici senaryolar mevcut
6. **Karara özel onay akışı**
- **İyileştir sonra Kaydet**: Gerekli iyileştirmeleri + revize edilmiş taslağı + bir yeniden değerlendirmeden sonra güncellenmiş kontrol listesi/kararı sun; revize karar **Kaydet** ise kullanıcı onayından sonra kaydet, aksi takdirde yeni kararı takip et
- **Kaydet**: Kayıt yolunu + kontrol listesi sonuçlarını + 1 satırlık karar gerekçesini + tam taslağı sun → kullanıcı onayından sonra kaydet
- **[X]'e Ekle**: Hedef yolu + eklemeleri (diff formatında) + kontrol listesi sonuçlarını + karar gerekçesini sun → kullanıcı onayından sonra ekle
- **Düşür**: Sadece kontrol listesi sonuçlarını + gerekçeyi göster (onay gerekmiyor)
7. Belirlenen konuma Kaydet / Ekle
## Adım 5 için Çıktı Formatı
```
### Kontrol Listesi
- [x] skills/ grep: örtüşme yok (veya: örtüşme bulundu → detaylar)
- [x] MEMORY.md: örtüşme yok (veya: örtüşme bulundu → detaylar)
- [x] Mevcut skill'e ekleme: yeni dosya uygun (veya: [X]'e eklenmeli)
- [x] Yeniden kullanılabilirlik: onaylandı (veya: tek seferlik → Düşür)
### Karar: Kaydet / İyileştir sonra Kaydet / [X]'e Ekle / Düşür
**Gerekçe:** (Kararııklayan 1-2 cümle)
```
## Tasarım Gerekçesi
Bu versiyon, önceki 5 boyutlu sayısal puanlama rubriğini (Spesifiklik, Uygulanabilirlik, Kapsam Uyumu, Gereksizlik Olmama, Kapsama 1-5 arası puanlanıyor) kontrol listesi tabanlı bütünsel karar sistemiyle değiştirir. Modern frontier modeller (Opus 4.6+) güçlü bağlamsal yargıya sahiptir — zengin niteliksel sinyalleri sayısal skorlara zorlamak nüans kaybettirir ve yanıltıcı toplamlar üretebilir. Bütünsel yaklaşım, modelin tüm faktörleri doğal olarak tartmasına izin vererek daha doğru kaydet/düşür kararları üretirken, açık kontrol listesi kritik hiçbir kontrolün atlanmamasını sağlar.
## Notlar
- Önemsiz düzeltmeleri çıkarmayın (yazım hataları, basit sözdizimi hataları)
- Tek seferlik sorunları çıkarmayın (belirli API kesintileri, vb.)
- Gelecekteki oturumlarda zaman kazandıracak desenlere odaklanın
- Skill'leri odaklı tutun — skill başına bir desen
- Karar Ekle olduğunda, yeni dosya oluşturmak yerine mevcut skill'e ekleyin

70
docs/tr/commands/learn.md Normal file
View File

@@ -0,0 +1,70 @@
# /learn - Yeniden Kullanılabilir Desenleri Çıkar
Mevcut oturumu analiz et ve skill olarak kaydetmeye değer desenleri çıkar.
## Tetikleyici
Önemsiz olmayan bir sorunu çözdüğünüzde, oturum sırasında herhangi bir noktada `/learn` komutunu çalıştırın.
## Ne Çıkarılmalı
Şunları arayın:
1. **Hata Çözüm Desenleri**
- Hangi hata oluştu?
- Kök neden neydi?
- Onu ne düzeltti?
- Bu benzer hatalar için yeniden kullanılabilir mi?
2. **Hata Ayıklama Teknikleri**
- Bariz olmayan hata ayıklama adımları
- İşe yarayan araç kombinasyonları
- Tanılama desenleri
3. **Geçici Çözümler**
- Kütüphane gariplikleri
- API sınırlamaları
- Versiyona özel düzeltmeler
4. **Projeye Özgü Desenler**
- Keşfedilen kod tabanı kuralları
- Verilen mimari kararlar
- Entegrasyon desenleri
## Çıktı Formatı
`~/.claude/skills/learned/[desen-adi].md` konumunda bir skill dosyası oluştur:
```markdown
# [Açıklayıcı Desen Adı]
**Çıkarıldı:** [Tarih]
**Bağlam:** [Bunun ne zaman geçerli olduğunun kısa açıklaması]
## Sorun
[Bunun çözdüğü sorun - spesifik olun]
## Çözüm
[Desen/teknik/geçici çözüm]
## Örnek
[Uygulanabilirse kod örneği]
## Ne Zaman Kullanılır
[Tetikleyici koşullar - bu skill'i neyin etkinleştirmesi gerektiği]
```
## Süreç
1. Çıkarılabilir desenler için oturumu incele
2. En değerli/yeniden kullanılabilir içgörüyü tanımla
3. Skill dosyasını taslak olarak hazırla
4. Kaydetmeden önce kullanıcıdan onay iste
5. `~/.claude/skills/learned/` konumuna kaydet
## Notlar
- Önemsiz düzeltmeleri çıkarmayın (yazım hataları, basit sözdizimi hataları)
- Tek seferlik sorunları çıkarmayın (belirli API kesintileri, vb.)
- Gelecekteki oturumlarda zaman kazandıracak desenlere odaklanın
- Skill'leri odaklı tutun - skill başına bir desen

View File

@@ -0,0 +1,158 @@
# Backend - Backend Odaklı Geliştirme
Backend odaklı iş akışı (Research → Ideation → Plan → Execute → Optimize → Review), Codex liderliğinde.
## Kullanım
```bash
/backend <backend task açıklaması>
```
## Context
- Backend task: $ARGUMENTS
- Codex liderliğinde, Gemini yardımcı referans için
- Uygulanabilir: API tasarımı, algoritma implementasyonu, veritabanı optimizasyonu, business logic
## Rolünüz
**Backend Orkestratör**sünüz, sunucu tarafı görevler için multi-model işbirliğini koordine ediyorsunuz (Research → Ideation → Plan → Execute → Optimize → Review).
**İşbirlikçi Modeller**:
- **Codex** Backend logic, algoritmalar (**Backend otoritesi, güvenilir**)
- **Gemini** Frontend perspektifi (**Backend görüşleri sadece referans için**)
- **Claude (self)** Orkestrasyon, planlama, execution, teslimat
---
## Multi-Model Çağrı Spesifikasyonu
**Çağrı Sözdizimi**:
```
# Yeni session çağrısı
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
Context: <önceki fazlardan proje context'i ve analiz>
</TASK>
OUTPUT: Expected output format
EOF",
run_in_background: false,
timeout: 3600000,
description: "Brief description"
})
# Session devam ettirme çağrısı
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
Context: <önceki fazlardan proje context'i ve analiz>
</TASK>
OUTPUT: Expected output format
EOF",
run_in_background: false,
timeout: 3600000,
description: "Brief description"
})
```
**Role Prompts**:
| Phase | Codex |
|-------|-------|
| Analysis | `~/.claude/.ccg/prompts/codex/analyzer.md` |
| Planning | `~/.claude/.ccg/prompts/codex/architect.md` |
| Review | `~/.claude/.ccg/prompts/codex/reviewer.md` |
**Session Reuse**: Her çağrı `SESSION_ID: xxx` döndürür, sonraki fazlar için `resume xxx` kullan. Phase 2'de `CODEX_SESSION` kaydet, Phase 3 ve 5'te `resume` kullan.
---
## İletişim Yönergeleri
1. Yanıtlara mode etiketi `[Mode: X]` ile başla, ilk `[Mode: Research]`
2. Katı sıra takip et: `Research → Ideation → Plan → Execute → Optimize → Review`
3. Gerektiğinde kullanıcı etkileşimi için `AskUserQuestion` tool kullan (örn., onay/seçim/approval)
---
## Ana İş Akışı
### Phase 0: Prompt Enhancement (İsteğe Bağlı)
`[Mode: Prepare]` - ace-tool MCP mevcutsa, `mcp__ace-tool__enhance_prompt` çağır, **orijinal $ARGUMENTS'ı sonraki Codex çağrıları için enhanced sonuçla değiştir**. Mevcut değilse, `$ARGUMENTS`'ı olduğu gibi kullan.
### Phase 1: Research
`[Mode: Research]` - Requirement'ları anla ve context topla
1. **Code Retrieval** (ace-tool MCP mevcutsa): Mevcut API'leri, veri modellerini, servis mimarisini almak için `mcp__ace-tool__search_context` çağır. Mevcut değilse, built-in tool'ları kullan: dosya keşfi için `Glob`, sembol/API araması için `Grep`, context toplama için `Read`, daha derin keşif için `Task` (Explore agent).
2. Requirement tamamlılık skoru (0-10): >=7 devam et, <7 dur ve tamamla
### Phase 2: Ideation
`[Mode: Ideation]` - Codex liderliğinde analiz
**Codex'i MUTLAKA çağır** (yukarıdaki çağrı spesifikasyonunu takip et):
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/analyzer.md`
- Requirement: Enhanced requirement (veya enhance edilmediyse $ARGUMENTS)
- Context: Phase 1'den proje context'i
- OUTPUT: Teknik fizibilite analizi, önerilen çözümler (en az 2), risk değerlendirmesi
**SESSION_ID'yi kaydet** (`CODEX_SESSION`) sonraki faz yeniden kullanımı için.
Çözümleri çıktıla (en az 2), kullanıcı seçimini bekle.
### Phase 3: Planning
`[Mode: Plan]` - Codex liderliğinde planlama
**Codex'i MUTLAKA çağır** (session'ı yeniden kullanmak için `resume <CODEX_SESSION>` kullan):
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/architect.md`
- Requirement: Kullanıcının seçtiği çözüm
- Context: Phase 2'den analiz sonuçları
- OUTPUT: Dosya yapısı, fonksiyon/sınıf tasarımı, bağımlılık ilişkileri
Claude planı sentezler, kullanıcı onayından sonra `.claude/plan/task-name.md`'ye kaydet.
### Phase 4: Implementation
`[Mode: Execute]` - Kod geliştirme
- Onaylanan planı kesinlikle takip et
- Mevcut proje kod standartlarını takip et
- Hata işleme, güvenlik, performans optimizasyonu sağla
### Phase 5: Optimization
`[Mode: Optimize]` - Codex liderliğinde review
**Codex'i MUTLAKA çağır** (yukarıdaki çağrı spesifikasyonunu takip et):
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/reviewer.md`
- Requirement: Aşağıdaki backend kod değişikliklerini incele
- Context: git diff veya kod içeriği
- OUTPUT: Güvenlik, performans, hata işleme, API uyumu sorunlar listesi
Review geri bildirimlerini entegre et, kullanıcı onayından sonra optimizasyonu çalıştır.
### Phase 6: Quality Review
`[Mode: Review]` - Nihai değerlendirme
- Plana karşı tamamlılığı kontrol et
- Fonksiyonaliteyi doğrulamak için test'leri çalıştır
- Sorunları ve önerileri raporla
---
## Ana Kurallar
1. **Codex backend görüşleri güvenilir**
2. **Gemini backend görüşleri sadece referans için**
3. Harici modellerin **sıfır dosya sistemi yazma erişimi**
4. Claude tüm kod yazma ve dosya operasyonlarını yönetir

View File

@@ -0,0 +1,315 @@
# Execute - Multi-Model İşbirlikçi Execution
Multi-model işbirlikçi execution - Plandan prototype al → Claude refactor edip implement eder → Multi-model audit ve teslimat.
$ARGUMENTS
---
## Ana Protokoller
- **Dil Protokolü**: Tool/model'lerle etkileşimde **İngilizce** kullan, kullanıcıyla kendi dilinde iletişim kur
- **Kod Egemenliği**: Harici modellerin **sıfır dosya sistemi yazma erişimi**, tüm değişiklikler Claude tarafından
- **Dirty Prototype Refactoring**: Codex/Gemini Unified Diff'i "dirty prototype" olarak değerlendir, production-grade koda refactor edilmeli
- **Stop-Loss Mekanizması**: Mevcut faz çıktısı doğrulanana kadar bir sonraki faza geçme
- **Ön Koşul**: Sadece kullanıcı `/ccg:plan` çıktısına açıkça "Y" cevabı verdikten sonra çalıştır (eksikse, önce onay al)
---
## Multi-Model Çağrı Spesifikasyonu
**Çağrı Sözdizimi** (parallel: `run_in_background: true` kullan):
```
# Session devam ettirme çağrısı (önerilen) - Implementation Prototype
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Requirement: <task description>
Context: <plan content + target files>
</TASK>
OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
})
# Yeni session çağrısı - Implementation Prototype
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Requirement: <task description>
Context: <plan content + target files>
</TASK>
OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
})
```
**Audit Çağrı Sözdizimi** (Code Review / Audit):
```
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Scope: Audit the final code changes.
Inputs:
- The applied patch (git diff / final unified diff)
- The touched files (relevant excerpts if needed)
Constraints:
- Do NOT modify any files.
- Do NOT output tool commands that assume filesystem access.
</TASK>
OUTPUT:
1) A prioritized list of issues (severity, file, rationale)
2) Concrete fixes; if code changes are needed, include a Unified Diff Patch in a fenced code block.
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
})
```
**Model Parametre Notları**:
- `{{GEMINI_MODEL_FLAG}}`: `--backend gemini` kullanırken, `--gemini-model gemini-3-pro-preview` ile değiştir (trailing space not edin); codex için boş string kullan
**Role Prompts**:
| Phase | Codex | Gemini |
|-------|-------|--------|
| Implementation | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/frontend.md` |
| Review | `~/.claude/.ccg/prompts/codex/reviewer.md` | `~/.claude/.ccg/prompts/gemini/reviewer.md` |
**Session Reuse**: `/ccg:plan` SESSION_ID sağladıysa, context'i yeniden kullanmak için `resume <SESSION_ID>` kullan.
**Background Task'leri Bekle** (max timeout 600000ms = 10 dakika):
```
TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
```
**ÖNEMLİ**:
- `timeout: 600000` belirtilmeli, aksi takdirde varsayılan 30 saniye erken timeout'a neden olur
- 10 dakika sonra hala tamamlanmamışsa, `TaskOutput` ile polling'e devam et, **ASLA process'i öldürme**
- Bekleme timeout nedeniyle atlanırsa, **MUTLAKA `AskUserQuestion` çağırarak kullanıcıya beklemeye devam etmek veya task'i öldürmek isteyip istemediğini sor**
---
## Execution Workflow
**Execute Task**: $ARGUMENTS
### Phase 0: Planı Oku
`[Mode: Prepare]`
1. **Input Tipini Tanımla**:
- Plan dosya yolu (örn., `.claude/plan/xxx.md`)
- Doğrudan task açıklaması
2. **Plan İçeriğini Oku**:
- Plan dosya yolu sağlandıysa, oku ve ayrıştır
- Çıkar: task tipi, implementation adımları, anahtar dosyalar, SESSION_ID
3. **Pre-Execution Onayı**:
- Input "doğrudan task açıklaması" veya plan `SESSION_ID` / anahtar dosyalar eksikse: önce kullanıcıyla onay al
- Kullanıcının plana "Y" cevabı verdiğini onaylayamazsan: devam etmeden önce tekrar onay al
4. **Task Tipi Routing**:
| Task Type | Detection | Route |
|-----------|-----------|-------|
| **Frontend** | Pages, components, UI, styles, layout | Gemini |
| **Backend** | API, interfaces, database, logic, algorithms | Codex |
| **Fullstack** | Hem frontend hem de backend içerir | Codex ∥ Gemini parallel |
---
### Phase 1: Hızlı Context Retrieval
`[Mode: Retrieval]`
**ace-tool MCP mevcutsa**, hızlı context retrieval için kullan:
Plandaki "Key Files" listesine göre, `mcp__ace-tool__search_context` çağır:
```
mcp__ace-tool__search_context({
query: "<plan içeriğine dayalı semantik sorgu, anahtar dosyalar, modüller, fonksiyon adları dahil>",
project_root_path: "$PWD"
})
```
**Retrieval Stratejisi**:
- Planın "Key Files" tablosundan hedef yolları çıkar
- Semantik sorgu oluştur: giriş dosyaları, bağımlılık modülleri, ilgili tip tanımları
- Sonuçlar yetersizse, 1-2 recursive retrieval ekle
**ace-tool MCP mevcut DEĞİLSE**, fallback olarak Claude Code built-in tool'ları kullan:
1. **Glob**: Planın "Key Files" tablosundan hedef dosyaları bul (örn., `Glob("src/components/**/*.tsx")`)
2. **Grep**: Codebase genelinde anahtar semboller, fonksiyon adları, tip tanımlarını ara
3. **Read**: Tam context toplamak için keşfedilen dosyaları oku
4. **Task (Explore agent)**: Daha geniş keşif için, `Task`'ı `subagent_type: "Explore"` ile kullan
**Retrieval Sonrası**:
- Alınan kod snippet'lerini organize et
- Implementation için tam context'i onayla
- Phase 3'e geç
---
### Phase 3: Prototype Edinimi
`[Mode: Prototype]`
**Task Tipine Göre Route Et**:
#### Route A: Frontend/UI/Styles → Gemini
**Limit**: Context < 32k token
1. Gemini'yi çağır (`~/.claude/.ccg/prompts/gemini/frontend.md` kullan)
2. Input: Plan içeriği + alınan context + hedef dosyalar
3. OUTPUT: `Unified Diff Patch ONLY. Strictly prohibit any actual modifications.`
4. **Gemini frontend tasarım otoritesidir, CSS/React/Vue prototype'ı nihai görsel temeldir**
5. **UYARI**: Gemini'nin backend logic önerilerini yoksay
6. Plan `GEMINI_SESSION` içeriyorsa: `resume <GEMINI_SESSION>` tercih et
#### Route B: Backend/Logic/Algorithms → Codex
1. Codex'i çağır (`~/.claude/.ccg/prompts/codex/architect.md` kullan)
2. Input: Plan içeriği + alınan context + hedef dosyalar
3. OUTPUT: `Unified Diff Patch ONLY. Strictly prohibit any actual modifications.`
4. **Codex backend logic otoritesidir, mantıksal akıl yürütme ve debug yeteneklerinden faydalan**
5. Plan `CODEX_SESSION` içeriyorsa: `resume <CODEX_SESSION>` tercih et
#### Route C: Fullstack → Parallel Çağrılar
1. **Parallel Çağrılar** (`run_in_background: true`):
- Gemini: Frontend kısmını ele al
- Codex: Backend kısmını ele al
2. `TaskOutput` ile her iki modelin tam sonuçlarını bekle
3. Her biri `resume` için plandan ilgili `SESSION_ID`'yi kullanır (eksikse yeni session oluştur)
**Yukarıdaki `Multi-Model Çağrı Spesifikasyonu`'ndaki `ÖNEMLİ` talimatları takip et**
---
### Phase 4: Code Implementation
`[Mode: Implement]`
**Kod Egemenliği olarak Claude şu adımları çalıştırır**:
1. **Diff Oku**: Codex/Gemini'nin döndürdüğü Unified Diff Patch'i ayrıştır
2. **Mental Sandbox**:
- Diff'in hedef dosyalara uygulanmasını simüle et
- Mantıksal tutarlılığı kontrol et
- Potansiyel çakışmaları veya yan etkileri tanımla
3. **Refactor ve Temizle**:
- "Dirty prototype"'ı **yüksek okunabilir, sürdürülebilir, enterprise-grade koda** refactor et
- Gereksiz kodu kaldır
- Projenin mevcut kod standartlarına uygunluğu sağla
- **Gerekli olmadıkça yorum/doküman oluşturma**, kod kendi kendini açıklamalı
4. **Minimal Kapsam**:
- Değişiklikler sadece requirement kapsamıyla sınırlı
- Yan etkiler için **zorunlu gözden geçirme**
- Hedefli düzeltmeler yap
5. **Değişiklikleri Uygula**:
- Gerçek değişiklikleri çalıştırmak için Edit/Write tool'larını kullan
- **Sadece gerekli kodu değiştir**, kullanıcının diğer mevcut fonksiyonlarını asla etkileme
6. **Self-Verification** (şiddetle önerilir):
- Projenin mevcut lint / typecheck / test'lerini çalıştır (minimal ilgili kapsama öncelik ver)
- Başarısız olursa: önce regresyonları düzelt, sonra Phase 5'e geç
---
### Phase 5: Audit ve Teslimat
`[Mode: Audit]`
#### 5.1 Otomatik Audit
**Değişiklikler yürürlüğe girdikten sonra, MUTLAKA hemen parallel call** Codex ve Gemini'yi Code Review için:
1. **Codex Review** (`run_in_background: true`):
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/reviewer.md`
- Input: Değiştirilen Diff + hedef dosyalar
- Odak: Güvenlik, performans, hata işleme, logic doğruluğu
2. **Gemini Review** (`run_in_background: true`):
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/reviewer.md`
- Input: Değiştirilen Diff + hedef dosyalar
- Odak: Erişilebilirlik, tasarım tutarlılığı, kullanıcı deneyimi
`TaskOutput` ile her iki modelin tam review sonuçlarını bekle. Context tutarlılığı için Phase 3 session'larını yeniden kullanmayı tercih et (`resume <SESSION_ID>`).
#### 5.2 Entegre Et ve Düzelt
1. Codex + Gemini review geri bildirimlerini sentezle
2. Güven kurallarına göre değerlendir: Backend Codex'i takip eder, Frontend Gemini'yi takip eder
3. Gerekli düzeltmeleri çalıştır
4. Gerektiğinde Phase 5.1'i tekrarla (risk kabul edilebilir olana kadar)
#### 5.3 Teslimat Onayı
Audit geçtikten sonra, kullanıcıya rapor et:
```markdown
## Execution Complete
### Change Summary
| File | Operation | Description |
|------|-----------|-------------|
| path/to/file.ts | Modified | Description |
### Audit Results
- Codex: <Passed/Found N issues>
- Gemini: <Passed/Found N issues>
### Recommendations
1. [ ] <Önerilen test adımları>
2. [ ] <Önerilen doğrulama adımları>
```
---
## Ana Kurallar
1. **Kod Egemenliği** Tüm dosya değişiklikleri Claude tarafından, harici modellerin sıfır yazma erişimi
2. **Dirty Prototype Refactoring** Codex/Gemini çıktısı taslak olarak değerlendirilir, refactor edilmeli
3. **Güven Kuralları** Backend Codex'i takip eder, Frontend Gemini'yi takip eder
4. **Minimal Değişiklikler** Sadece gerekli kodu değiştir, yan etki yok
5. **Zorunlu Audit** Değişikliklerden sonra multi-model Code Review yapılmalı
---
## Kullanım
```bash
# Plan dosyasını çalıştır
/ccg:execute .claude/plan/feature-name.md
# Task'i doğrudan çalıştır (context'te zaten tartışılmış planlar için)
/ccg:execute implement user authentication based on previous plan
```
---
## /ccg:plan ile İlişki
1. `/ccg:plan` plan + SESSION_ID oluşturur
2. Kullanıcı "Y" ile onaylar
3. `/ccg:execute` planı okur, SESSION_ID'yi yeniden kullanır, implementation'ı çalıştırır

View File

@@ -0,0 +1,158 @@
# Frontend - Frontend Odaklı Geliştirme
Frontend odaklı iş akışı (Research → Ideation → Plan → Execute → Optimize → Review), Gemini liderliğinde.
## Kullanım
```bash
/frontend <UI task açıklaması>
```
## Context
- Frontend task: $ARGUMENTS
- Gemini liderliğinde, Codex yardımcı referans için
- Uygulanabilir: Component tasarımı, responsive layout, UI animasyonları, stil optimizasyonu
## Rolünüz
**Frontend Orkestratör**sünüz, UI/UX görevleri için multi-model işbirliğini koordine ediyorsunuz (Research → Ideation → Plan → Execute → Optimize → Review).
**İşbirlikçi Modeller**:
- **Gemini** Frontend UI/UX (**Frontend otoritesi, güvenilir**)
- **Codex** Backend perspektifi (**Frontend görüşleri sadece referans için**)
- **Claude (self)** Orkestrasyon, planlama, execution, teslimat
---
## Multi-Model Çağrı Spesifikasyonu
**Çağrı Sözdizimi**:
```
# Yeni session çağrısı
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
Context: <önceki fazlardan proje context'i ve analiz>
</TASK>
OUTPUT: Expected output format
EOF",
run_in_background: false,
timeout: 3600000,
description: "Brief description"
})
# Session devam ettirme çağrısı
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
Context: <önceki fazlardan proje context'i ve analiz>
</TASK>
OUTPUT: Expected output format
EOF",
run_in_background: false,
timeout: 3600000,
description: "Brief description"
})
```
**Role Prompts**:
| Phase | Gemini |
|-------|--------|
| Analysis | `~/.claude/.ccg/prompts/gemini/analyzer.md` |
| Planning | `~/.claude/.ccg/prompts/gemini/architect.md` |
| Review | `~/.claude/.ccg/prompts/gemini/reviewer.md` |
**Session Reuse**: Her çağrı `SESSION_ID: xxx` döndürür, sonraki fazlar için `resume xxx` kullan. Phase 2'de `GEMINI_SESSION` kaydet, Phase 3 ve 5'te `resume` kullan.
---
## İletişim Yönergeleri
1. Yanıtlara mode etiketi `[Mode: X]` ile başla, ilk `[Mode: Research]`
2. Katı sıra takip et: `Research → Ideation → Plan → Execute → Optimize → Review`
3. Gerektiğinde kullanıcı etkileşimi için `AskUserQuestion` tool kullan (örn., onay/seçim/approval)
---
## Ana İş Akışı
### Phase 0: Prompt Enhancement (İsteğe Bağlı)
`[Mode: Prepare]` - ace-tool MCP mevcutsa, `mcp__ace-tool__enhance_prompt` çağır, **orijinal $ARGUMENTS'ı sonraki Gemini çağrıları için enhanced sonuçla değiştir**. Mevcut değilse, `$ARGUMENTS`'ı olduğu gibi kullan.
### Phase 1: Research
`[Mode: Research]` - Requirement'ları anla ve context topla
1. **Code Retrieval** (ace-tool MCP mevcutsa): Mevcut component'leri, stilleri, tasarım sistemini almak için `mcp__ace-tool__search_context` çağır. Mevcut değilse, built-in tool'ları kullan: dosya keşfi için `Glob`, component/stil araması için `Grep`, context toplama için `Read`, daha derin keşif için `Task` (Explore agent).
2. Requirement tamamlılık skoru (0-10): >=7 devam et, <7 dur ve tamamla
### Phase 2: Ideation
`[Mode: Ideation]` - Gemini liderliğinde analiz
**Gemini'yi MUTLAKA çağır** (yukarıdaki çağrı spesifikasyonunu takip et):
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/analyzer.md`
- Requirement: Enhanced requirement (veya enhance edilmediyse $ARGUMENTS)
- Context: Phase 1'den proje context'i
- OUTPUT: UI fizibilite analizi, önerilen çözümler (en az 2), UX değerlendirmesi
**SESSION_ID'yi kaydet** (`GEMINI_SESSION`) sonraki faz yeniden kullanımı için.
Çözümleri çıktıla (en az 2), kullanıcı seçimini bekle.
### Phase 3: Planning
`[Mode: Plan]` - Gemini liderliğinde planlama
**Gemini'yi MUTLAKA çağır** (session'ı yeniden kullanmak için `resume <GEMINI_SESSION>` kullan):
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/architect.md`
- Requirement: Kullanıcının seçtiği çözüm
- Context: Phase 2'den analiz sonuçları
- OUTPUT: Component yapısı, UI akışı, stillendirme yaklaşımı
Claude planı sentezler, kullanıcı onayından sonra `.claude/plan/task-name.md`'ye kaydet.
### Phase 4: Implementation
`[Mode: Execute]` - Kod geliştirme
- Onaylanan planı kesinlikle takip et
- Mevcut proje tasarım sistemi ve kod standartlarını takip et
- Responsiveness, accessibility sağla
### Phase 5: Optimization
`[Mode: Optimize]` - Gemini liderliğinde review
**Gemini'yi MUTLAKA çağır** (yukarıdaki çağrı spesifikasyonunu takip et):
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/reviewer.md`
- Requirement: Aşağıdaki frontend kod değişikliklerini incele
- Context: git diff veya kod içeriği
- OUTPUT: Accessibility, responsiveness, performans, tasarım tutarlılığı sorunlar listesi
Review geri bildirimlerini entegre et, kullanıcı onayından sonra optimizasyonu çalıştır.
### Phase 6: Quality Review
`[Mode: Review]` - Nihai değerlendirme
- Plana karşı tamamlılığı kontrol et
- Responsiveness ve accessibility doğrula
- Sorunları ve önerileri raporla
---
## Ana Kurallar
1. **Gemini frontend görüşleri güvenilir**
2. **Codex frontend görüşleri sadece referans için**
3. Harici modellerin **sıfır dosya sistemi yazma erişimi**
4. Claude tüm kod yazma ve dosya operasyonlarını yönetir

View File

@@ -0,0 +1,268 @@
# Plan - Multi-Model İşbirlikçi Planlama
Multi-model işbirlikçi planlama - Context retrieval + Dual-model analiz → Adım adım implementation planı oluştur.
$ARGUMENTS
---
## Ana Protokoller
- **Dil Protokolü**: Tool/model'lerle etkileşimde **İngilizce** kullan, kullanıcıyla kendi dilinde iletişim kur
- **Zorunlu Parallel**: Codex/Gemini çağrıları `run_in_background: true` kullanmalı (ana thread'i bloke etmemek için tek model çağrılarında bile)
- **Kod Egemenliği**: Harici modellerin **sıfır dosya sistemi yazma erişimi**, tüm değişiklikler Claude tarafından
- **Stop-Loss Mekanizması**: Mevcut faz çıktısı doğrulanana kadar bir sonraki faza geçme
- **Sadece Planlama**: Bu komut context okumaya ve `.claude/plan/*` plan dosyalarına yazmaya izin verir, ancak **ASLA production kodu değiştirmez**
---
## Multi-Model Çağrı Spesifikasyonu
**Çağrı Sözdizimi** (parallel: `run_in_background: true` kullan):
```
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Requirement: <enhanced requirement>
Context: <retrieved project context>
</TASK>
OUTPUT: Step-by-step implementation plan with pseudo-code. DO NOT modify any files.
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
})
```
**Model Parametre Notları**:
- `{{GEMINI_MODEL_FLAG}}`: `--backend gemini` kullanırken, `--gemini-model gemini-3-pro-preview` ile değiştir (trailing space not edin); codex için boş string kullan
**Role Prompts**:
| Phase | Codex | Gemini |
|-------|-------|--------|
| Analysis | `~/.claude/.ccg/prompts/codex/analyzer.md` | `~/.claude/.ccg/prompts/gemini/analyzer.md` |
| Planning | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/architect.md` |
**Session Reuse**: Her çağrı `SESSION_ID: xxx` döndürür (genellikle wrapper tarafından çıktılanır), sonraki `/ccg:execute` kullanımı için **MUTLAKA kaydet**.
**Background Task'leri Bekle** (max timeout 600000ms = 10 dakika):
```
TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
```
**ÖNEMLİ**:
- `timeout: 600000` belirtilmeli, aksi takdirde varsayılan 30 saniye erken timeout'a neden olur
- 10 dakika sonra hala tamamlanmamışsa, `TaskOutput` ile polling'e devam et, **ASLA process'i öldürme**
- Bekleme timeout nedeniyle atlanırsa, **MUTLAKA `AskUserQuestion` çağırarak kullanıcıya beklemeye devam etmek veya task'i öldürmek isteyip istemediğini sor**
---
## Execution Workflow
**Planlama Görevi**: $ARGUMENTS
### Phase 1: Tam Context Retrieval
`[Mode: Research]`
#### 1.1 Prompt Enhancement (İLK önce çalıştırılmalı)
**ace-tool MCP mevcutsa**, `mcp__ace-tool__enhance_prompt` tool'unu çağır:
```
mcp__ace-tool__enhance_prompt({
prompt: "$ARGUMENTS",
conversation_history: "<son 5-10 konuşma turu>",
project_root_path: "$PWD"
})
```
Enhanced prompt'u bekle, **orijinal $ARGUMENTS'ı tüm sonraki fazlar için enhanced sonuçla değiştir**.
**ace-tool MCP mevcut DEĞİLSE**: Bu adımı atla ve tüm sonraki fazlar için orijinal `$ARGUMENTS`'ı olduğu gibi kullan.
#### 1.2 Context Retrieval
**ace-tool MCP mevcutsa**, `mcp__ace-tool__search_context` tool'unu çağır:
```
mcp__ace-tool__search_context({
query: "<enhanced requirement'a dayalı semantik sorgu>",
project_root_path: "$PWD"
})
```
- Doğal dil kullanarak semantik sorgu oluştur (Where/What/How)
- **ASLA varsayımlara dayalı cevap verme**
**ace-tool MCP mevcut DEĞİLSE**, fallback olarak Claude Code built-in tool'ları kullan:
1. **Glob**: Pattern'e göre ilgili dosyaları bul (örn., `Glob("**/*.ts")`, `Glob("src/**/*.py")`)
2. **Grep**: Anahtar semboller, fonksiyon adları, sınıf tanımlarını ara (örn., `Grep("className|functionName")`)
3. **Read**: Tam context toplamak için keşfedilen dosyaları oku
4. **Task (Explore agent)**: Daha derin keşif için, codebase genelinde aramak üzere `Task`'ı `subagent_type: "Explore"` ile kullan
#### 1.3 Tamamlılık Kontrolü
- İlgili sınıflar, fonksiyonlar, değişkenler için **tam tanımlar ve imzalar** elde etmeli
- Context yetersizse, **recursive retrieval** tetikle
- Çıktıya öncelik ver: giriş dosyası + satır numarası + anahtar sembol adı; belirsizliği çözmek için gerekli olduğunda minimal kod snippet'leri ekle
#### 1.4 Requirement Alignment
- Requirement'larda hala belirsizlik varsa, kullanıcı için yönlendirici sorular **MUTLAKA** çıktıla
- Requirement sınırları net olana kadar (eksiklik yok, fazlalık yok)
### Phase 2: Multi-Model İşbirlikçi Analiz
`[Mode: Analysis]`
#### 2.1 Input'ları Dağıt
**Parallel call** Codex ve Gemini (`run_in_background: true`):
**Orijinal requirement**'ı (önceden belirlenmiş görüşler olmadan) her iki modele dağıt:
1. **Codex Backend Analysis**:
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/analyzer.md`
- Odak: Teknik fizibilite, mimari etki, performans değerlendirmeleri, potansiyel riskler
- OUTPUT: Çok perspektifli çözümler + artı/eksi analizi
2. **Gemini Frontend Analysis**:
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/analyzer.md`
- Odak: UI/UX etkisi, kullanıcı deneyimi, görsel tasarım
- OUTPUT: Çok perspektifli çözümler + artı/eksi analizi
`TaskOutput` ile her iki modelin tam sonuçlarını bekle. **SESSION_ID'yi kaydet** (`CODEX_SESSION` ve `GEMINI_SESSION`).
#### 2.2 Cross-Validation
Perspektifleri entegre et ve optimizasyon için iterate et:
1. **Consensus tanımla** (güçlü sinyal)
2. **Divergence tanımla** (değerlendirme gerektirir)
3. **Tamamlayıcı güçlü yönler**: Backend logic Codex'i takip eder, Frontend design Gemini'yi takip eder
4. **Mantıksal akıl yürütme**: Çözümlerdeki mantıksal boşlukları elimine et
#### 2.3 (İsteğe Bağlı ama Önerilen) Dual-Model Plan Taslağı
Claude'un sentezlenmiş planındaki eksiklik riskini azaltmak için, her iki modelin de "plan taslakları" çıktılamasını parallel yaptır (yine **dosya değiştirmesine izin verilmez**):
1. **Codex Plan Draft** (Backend otoritesi):
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/architect.md`
- OUTPUT: Adım adım plan + pseudo-code (odak: data flow/edge cases/error handling/test strategy)
2. **Gemini Plan Draft** (Frontend otoritesi):
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/architect.md`
- OUTPUT: Adım adım plan + pseudo-code (odak: information architecture/interaction/accessibility/visual consistency)
`TaskOutput` ile her iki modelin tam sonuçlarını bekle, önerilerindeki anahtar farkları kaydet.
#### 2.4 Implementation Planı Oluştur (Claude Final Version)
Her iki analizi sentezle, **Adım Adım Implementation Planı** oluştur:
```markdown
## Implementation Plan: <Task Name>
### Task Type
- [ ] Frontend (→ Gemini)
- [ ] Backend (→ Codex)
- [ ] Fullstack (→ Parallel)
### Technical Solution
<Codex + Gemini analizinden sentezlenmiş optimal çözüm>
### Implementation Steps
1. <Step 1> - Beklenen teslim edilen
2. <Step 2> - Beklenen teslim edilen
...
### Key Files
| File | Operation | Description |
|------|-----------|-------------|
| path/to/file.ts:L10-L50 | Modify | Description |
### Risks and Mitigation
| Risk | Mitigation |
|------|------------|
### SESSION_ID (for /ccg:execute use)
- CODEX_SESSION: <session_id>
- GEMINI_SESSION: <session_id>
```
### Phase 2 End: Plan Teslimi (Execution Değil)
**`/ccg:plan` sorumlulukları burada biter, MUTLAKA şu aksiyonları çalıştır**:
1. Tam implementation planını kullanıcıya sun (pseudo-code dahil)
2. Planı `.claude/plan/<feature-name>.md`'ye kaydet (requirement'tan feature adını çıkar, örn., `user-auth`, `payment-module`)
3. **Kalın metinle** prompt çıktıla (MUTLAKA gerçek kaydedilen dosya yolunu kullan):
---
**Plan oluşturuldu ve `.claude/plan/actual-feature-name.md` dosyasına kaydedildi**
**Lütfen yukarıdaki planı inceleyin. Şunları yapabilirsiniz:**
- **Planı değiştir**: Neyin ayarlanması gerektiğini söyleyin, planı güncelleyeceğim
- **Planı çalıştır**: Aşağıdaki komutu yeni bir oturuma kopyalayın
```
/ccg:execute .claude/plan/actual-feature-name.md
```
---
**NOT**: Yukarıdaki `actual-feature-name.md` gerçek kaydedilen dosya adıyla değiştirilmelidir!
4. **Mevcut yanıtı hemen sonlandır** (Burada dur. Daha fazla tool çağrısı yok.)
**KESINLIKLE YASAK**:
- Kullanıcıya "Y/N" sor sonra otomatik çalıştır (execution `/ccg:execute`'un sorumluluğudur)
- Production koduna herhangi bir yazma operasyonu
- `/ccg:execute`'u veya herhangi bir implementation aksiyonunu otomatik çağır
- Kullanıcııkça değişiklik talep etmediğinde model çağrılarını tetiklemeye devam et
---
## Plan Kaydetme
Planlama tamamlandıktan sonra, planı şuraya kaydet:
- **İlk planlama**: `.claude/plan/<feature-name>.md`
- **İterasyon versiyonları**: `.claude/plan/<feature-name>-v2.md`, `.claude/plan/<feature-name>-v3.md`...
Plan dosyası yazma, planı kullanıcıya sunmadan önce tamamlanmalı.
---
## Plan Değişiklik Akışı
Kullanıcı plan değişikliği talep ederse:
1. Kullanıcı geri bildirimine göre plan içeriğini ayarla
2. `.claude/plan/<feature-name>.md` dosyasını güncelle
3. Değiştirilmiş planı yeniden sun
4. Kullanıcıyı tekrar gözden geçirmeye veya çalıştırmaya davet et
---
## Sonraki Adımlar
Kullanıcı onayladıktan sonra, **manuel** olarak çalıştır:
```bash
/ccg:execute .claude/plan/<feature-name>.md
```
---
## Ana Kurallar
1. **Sadece plan, implementation yok** Bu komut hiçbir kod değişikliği çalıştırmaz
2. **Y/N prompt'ları yok** Sadece planı sun, kullanıcının sonraki adımlara karar vermesine izin ver
3. **Güven Kuralları** Backend Codex'i takip eder, Frontend Gemini'yi takip eder
4. Harici modellerin **sıfır dosya sistemi yazma erişimi**
5. **SESSION_ID Devri** Plan sonunda `CODEX_SESSION` / `GEMINI_SESSION` içermeli (`/ccg:execute resume <SESSION_ID>` kullanımı için)

View File

@@ -0,0 +1,191 @@
# Workflow - Multi-Model İşbirlikçi Geliştirme
Multi-model işbirlikçi geliştirme iş akışı (Research → Ideation → Plan → Execute → Optimize → Review), akıllı yönlendirme ile: Frontend → Gemini, Backend → Codex.
Kalite kontrol noktaları, MCP servisleri ve multi-model işbirliği ile yapılandırılmış geliştirme iş akışı.
## Kullanım
```bash
/workflow <task açıklaması>
```
## Context
- Geliştirilecek görev: $ARGUMENTS
- Kalite kontrol noktalarıyla 6 fazlı yapılandırılmış iş akışı
- Multi-model işbirliği: Codex (backend) + Gemini (frontend) + Claude (orkestrasyon)
- MCP servis entegrasyonu (ace-tool, isteğe bağlı) gelişmiş yetenekler için
## Rolünüz
**Orkestratör**sünüz, multi-model işbirlikçi sistemi koordine ediyorsunuz (Research → Ideation → Plan → Execute → Optimize → Review). Deneyimli geliştiriciler için kısa ve profesyonel iletişim kurun.
**İşbirlikçi Modeller**:
- **ace-tool MCP** (isteğe bağlı) Code retrieval + Prompt enhancement
- **Codex** Backend logic, algoritmalar, debugging (**Backend otoritesi, güvenilir**)
- **Gemini** Frontend UI/UX, görsel tasarım (**Frontend uzmanı, backend görüşleri sadece referans için**)
- **Claude (self)** Orkestrasyon, planlama, execution, teslimat
---
## Multi-Model Çağrı Spesifikasyonu
**Çağrı sözdizimi** (parallel: `run_in_background: true`, sequential: `false`):
```
# Yeni session çağrısı
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
Context: <önceki fazlardan proje context'i ve analiz>
</TASK>
OUTPUT: Expected output format
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
})
# Session devam ettirme çağrısı
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Requirement: <enhanced requirement (veya enhance edilmediyse $ARGUMENTS)>
Context: <önceki fazlardan proje context'i ve analiz>
</TASK>
OUTPUT: Expected output format
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
})
```
**Model Parametre Notları**:
- `{{GEMINI_MODEL_FLAG}}`: `--backend gemini` kullanırken, `--gemini-model gemini-3-pro-preview` ile değiştir (trailing space not edin); codex için boş string kullan
**Role Prompts**:
| Phase | Codex | Gemini |
|-------|-------|--------|
| Analysis | `~/.claude/.ccg/prompts/codex/analyzer.md` | `~/.claude/.ccg/prompts/gemini/analyzer.md` |
| Planning | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/architect.md` |
| Review | `~/.claude/.ccg/prompts/codex/reviewer.md` | `~/.claude/.ccg/prompts/gemini/reviewer.md` |
**Session Reuse**: Her çağrı `SESSION_ID: xxx` döndürür, sonraki fazlar için `resume xxx` subcommand kullan (not: `resume`, `--resume` değil).
**Parallel Çağrılar**: Başlatmak için `run_in_background: true` kullan, sonuçları `TaskOutput` ile bekle. **Bir sonraki faza geçmeden önce tüm modellerin dönmesini MUTLAKA bekle**.
**Background Task'leri Bekle** (max timeout 600000ms = 10 dakika kullan):
```
TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
```
**ÖNEMLİ**:
- `timeout: 600000` belirtilmeli, aksi takdirde varsayılan 30 saniye erken timeout'a neden olur.
- 10 dakika sonra hala tamamlanmamışsa, `TaskOutput` ile polling'e devam et, **ASLA process'i öldürme**.
- Bekleme timeout nedeniyle atlanırsa, **MUTLAKA `AskUserQuestion` çağırarak kullanıcıya beklemeye devam etmek veya task'i öldürmek isteyip istemediğini sor. Asla doğrudan öldürme.**
---
## İletişim Yönergeleri
1. Yanıtlara mode etiketi `[Mode: X]` ile başla, ilk `[Mode: Research]`.
2. Katı sıra takip et: `Research → Ideation → Plan → Execute → Optimize → Review`.
3. Her faz tamamlandıktan sonra kullanıcı onayı iste.
4. Skor < 7 veya kullanıcı onaylamadığında zorla durdur.
5. Gerektiğinde kullanıcı etkileşimi için `AskUserQuestion` tool kullan (örn., onay/seçim/approval).
## Harici Orkestrasyon Ne Zaman Kullanılır
İş paralel worker'lar arasında bölünmesi gerektiğinde harici tmux/worktree orkestrasyonu kullan; bu worker'ların izole git state'i, bağımsız terminalleri veya ayrı build/test çalıştırması gerekir. Hafif analiz, planlama veya review için in-process subagent'ları kullan; burada ana session tek yazar olarak kalır.
```bash
node scripts/orchestrate-worktrees.js .claude/plan/workflow-e2e-test.json --execute
```
---
## Execution Workflow
**Task Açıklaması**: $ARGUMENTS
### Phase 1: Research & Analysis
`[Mode: Research]` - Requirement'ları anla ve context topla:
1. **Prompt Enhancement** (ace-tool MCP mevcutsa): `mcp__ace-tool__enhance_prompt` çağır, **orijinal $ARGUMENTS'ı tüm sonraki Codex/Gemini çağrıları için enhanced sonuçla değiştir**. Mevcut değilse, `$ARGUMENTS`'ı olduğu gibi kullan.
2. **Context Retrieval** (ace-tool MCP mevcutsa): `mcp__ace-tool__search_context` çağır. Mevcut değilse, built-in tool'ları kullan: dosya keşfi için `Glob`, sembol araması için `Grep`, context toplama için `Read`, daha derin keşif için `Task` (Explore agent).
3. **Requirement Tamamlılık Skoru** (0-10):
- Hedef netliği (0-3), Beklenen sonuç (0-3), Kapsam sınırları (0-2), Kısıtlamalar (0-2)
- ≥7: Devam et | <7: Dur, açıklayıcı sorular sor
### Phase 2: Solution Ideation
`[Mode: Ideation]` - Multi-model parallel analiz:
**Parallel Çağrılar** (`run_in_background: true`):
- Codex: Analyzer prompt kullan, teknik fizibilite, çözümler, riskler çıktıla
- Gemini: Analyzer prompt kullan, UI fizibilite, çözümler, UX değerlendirmesi çıktıla
`TaskOutput` ile sonuçları bekle. **SESSION_ID'yi kaydet** (`CODEX_SESSION` ve `GEMINI_SESSION`).
**Yukarıdaki `Multi-Model Çağrı Spesifikasyonu`'ndaki `ÖNEMLİ` talimatları takip et**
Her iki analizi sentezle, çözüm karşılaştırması çıktıla (en az 2 seçenek), kullanıcı seçimini bekle.
### Phase 3: Detailed Planning
`[Mode: Plan]` - Multi-model işbirlikçi planlama:
**Parallel Çağrılar** (`resume <SESSION_ID>` ile session devam ettir):
- Codex: Architect prompt + `resume $CODEX_SESSION` kullan, backend mimarisi çıktıla
- Gemini: Architect prompt + `resume $GEMINI_SESSION` kullan, frontend mimarisi çıktıla
`TaskOutput` ile sonuçları bekle.
**Yukarıdaki `Multi-Model Çağrı Spesifikasyonu`'ndaki `ÖNEMLİ` talimatları takip et**
**Claude Sentezi**: Codex backend planı + Gemini frontend planını benimsle, kullanıcı onayından sonra `.claude/plan/task-name.md`'ye kaydet.
### Phase 4: Implementation
`[Mode: Execute]` - Kod geliştirme:
- Onaylanan planı kesinlikle takip et
- Mevcut proje kod standartlarını takip et
- Önemli kilometre taşlarında geri bildirim iste
### Phase 5: Code Optimization
`[Mode: Optimize]` - Multi-model parallel review:
**Parallel Çağrılar**:
- Codex: Reviewer prompt kullan, güvenlik, performans, hata işleme üzerine odaklan
- Gemini: Reviewer prompt kullan, accessibility, tasarım tutarlılığı üzerine odaklan
`TaskOutput` ile sonuçları bekle. Review geri bildirimlerini entegre et, kullanıcı onayından sonra optimizasyonu çalıştır.
**Yukarıdaki `Multi-Model Çağrı Spesifikasyonu`'ndaki `ÖNEMLİ` talimatları takip et**
### Phase 6: Quality Review
`[Mode: Review]` - Nihai değerlendirme:
- Plana karşı tamamlılığı kontrol et
- Fonksiyonaliteyi doğrulamak için test'leri çalıştır
- Sorunları ve önerileri raporla
- Nihai kullanıcı onayı iste
---
## Ana Kurallar
1. Faz sırası atlanamaz (kullanıcııkça talimat vermedikçe)
2. Harici modellerin **sıfır dosya sistemi yazma erişimi**, tüm değişiklikler Claude tarafından
3. Skor < 7 veya kullanıcı onaylamadığında **zorla durdur**

View File

@@ -0,0 +1,231 @@
---
description: Multi-agent iş akışları için sıralı ve tmux/worktree orkestrasyon rehberi.
---
# Orchestrate Komutu
Karmaşık görevler için sıralı agent iş akışı.
## Kullanım
`/orchestrate [workflow-type] [task-description]`
## Workflow Tipleri
### feature
Tam özellik implementasyon iş akışı:
```
planner -> tdd-guide -> code-reviewer -> security-reviewer
```
### bugfix
Bug araştırma ve düzeltme iş akışı:
```
planner -> tdd-guide -> code-reviewer
```
### refactor
Güvenli refactoring iş akışı:
```
architect -> code-reviewer -> tdd-guide
```
### security
Güvenlik odaklı review:
```
security-reviewer -> code-reviewer -> architect
```
## Execution Pattern
İş akışındaki her agent için:
1. **Agent'ı çağır** önceki agent'tan gelen context ile
2. **Çıktıyı topla** yapılandırılmış handoff dokümanı olarak
3. **Sonraki agent'a geçir** zincirde
4. **Sonuçları topla** nihai rapora
## Handoff Doküman Formatı
Agent'lar arasında, handoff dokümanı oluştur:
```markdown
## HANDOFF: [previous-agent] -> [next-agent]
### Context
[Yapılanların özeti]
### Findings
[Anahtar keşifler veya kararlar]
### Files Modified
[Dokunulan dosyaların listesi]
### Open Questions
[Sonraki agent için çözülmemiş öğeler]
### Recommendations
[Önerilen sonraki adımlar]
```
## Örnek: Feature Workflow
```
/orchestrate feature "Add user authentication"
```
Çalıştırır:
1. **Planner Agent**
- Requirement'ları analiz eder
- Implementation planı oluşturur
- Bağımlılıkları tanımlar
- Çıktı: `HANDOFF: planner -> tdd-guide`
2. **TDD Guide Agent**
- Planner handoff'unu okur
- Önce test'leri yazar
- Test'leri geçirmek için implement eder
- Çıktı: `HANDOFF: tdd-guide -> code-reviewer`
3. **Code Reviewer Agent**
- Implementation'ı gözden geçirir
- Sorunları kontrol eder
- İyileştirmeler önerir
- Çıktı: `HANDOFF: code-reviewer -> security-reviewer`
4. **Security Reviewer Agent**
- Güvenlik denetimi
- Güvenlik açığı kontrolü
- Nihai onay
- Çıktı: Final Report
## Nihai Rapor Formatı
```
ORCHESTRATION REPORT
====================
Workflow: feature
Task: Add user authentication
Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer
SUMMARY
-------
[Bir paragraf özet]
AGENT OUTPUTS
-------------
Planner: [özet]
TDD Guide: [özet]
Code Reviewer: [özet]
Security Reviewer: [özet]
FILES CHANGED
-------------
[Değiştirilen tüm dosyaların listesi]
TEST RESULTS
------------
[Test geçti/başarısız özeti]
SECURITY STATUS
---------------
[Güvenlik bulguları]
RECOMMENDATION
--------------
[SHIP / NEEDS WORK / BLOCKED]
```
## Parallel Execution
Bağımsız kontroller için, agent'ları parallel çalıştır:
```markdown
### Parallel Phase
Eş zamanlı çalıştır:
- code-reviewer (kalite)
- security-reviewer (güvenlik)
- architect (tasarım)
### Merge Results
Çıktıları tek rapora birleştir
```
Ayrı git worktree'leri olan harici tmux-pane worker'ları için, `node scripts/orchestrate-worktrees.js plan.json --execute` kullan. Built-in orkestrasyon pattern'i in-process kalır; helper uzun süren veya cross-harness session'lar için.
Worker'ların ana checkout'tan kirli veya izlenmeyen yerel dosyaları görmesi gerektiğinde, plan dosyasına `seedPaths` ekle. ECC sadece seçilen bu yolları `git worktree add`'den sonra her worker worktree'sine overlay eder; bu branch'ı izole tutarken devam eden yerel script'leri, planları veya dokümanları gösterir.
```json
{
"sessionName": "workflow-e2e",
"seedPaths": [
"scripts/orchestrate-worktrees.js",
"scripts/lib/tmux-worktree-orchestrator.js",
".claude/plan/workflow-e2e-test.json"
],
"workers": [
{ "name": "docs", "task": "Orkestrasyon dokümanlarını güncelle." }
]
}
```
Canlı bir tmux/worktree session için kontrol düzlemi snapshot'ı dışa aktarmak için şunu çalıştır:
```bash
node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json
```
Snapshot session aktivitesi, tmux pane metadata'sı, worker state'leri, hedefleri, seed overlay'leri ve son handoff özetlerini JSON formatında içerir.
## Operatör Command-Center Handoff
İş akışı birden fazla session, worktree veya tmux pane'e yayıldığında, nihai handoff'a bir kontrol düzlemi bloğu ekle:
```markdown
CONTROL PLANE
-------------
Sessions:
- aktif session ID veya alias
- her aktif worker için branch + worktree yolu
- uygulanabilir durumlarda tmux pane veya detached session adı
Diffs:
- git status özeti
- dokunulan dosyalar için git diff --stat
- merge/çakışma risk notları
Approvals:
- bekleyen kullanıcı onayları
- onay bekleyen bloke adımlar
Telemetry:
- son aktivite timestamp'i veya idle sinyali
- tahmini token veya cost drift
- hook'lar veya reviewer'lar tarafından bildirilen policy olayları
```
Bu planner, implementer, reviewer ve loop worker'larını operatör yüzeyinden anlaşılır tutar.
## Argümanlar
$ARGUMENTS:
- `feature <description>` - Tam özellik iş akışı
- `bugfix <description>` - Bug düzeltme iş akışı
- `refactor <description>` - Refactoring iş akışı
- `security <description>` - Güvenlik review iş akışı
- `custom <agents> <description>` - Özel agent dizisi
## Özel Workflow Örneği
```
/orchestrate custom "architect,tdd-guide,code-reviewer" "Caching katmanını yeniden tasarla"
```
## İpuçları
1. **Karmaşık özellikler için planner ile başla**
2. **Merge'den önce her zaman code-reviewer dahil et**
3. **Auth/ödeme/PII için security-reviewer kullan**
4. **Handoff'ları kısa tut** - sonraki agent'ın ihtiyaç duyduğu şeye odaklan
5. **Gerekirse agent'lar arasında doğrulama çalıştır**

115
docs/tr/commands/plan.md Normal file
View File

@@ -0,0 +1,115 @@
---
description: Gereksinimleri yeniden ifade et, riskleri değerlendir ve adım adım uygulama planı oluştur. Herhangi bir koda dokunmadan önce kullanıcı ONAYINI BEKLE.
---
# Plan Komutu
Bu komut, herhangi bir kod yazmadan önce kapsamlı bir uygulama planı oluşturmak için **planner** agent'ını çağırır.
## Bu Komut Ne Yapar
1. **Gereksinimleri Yeniden İfade Et** - Neyin inşa edilmesi gerektiğini netleştir
2. **Riskleri Tanımla** - Potansiyel sorunları ve engelleri ortaya çıkar
3. **Adım Planı Oluştur** - Uygulamayı fazlara ayır
4. **Onay Bekle** - İlerlemeden önce kullanıcı onayı alınmalıdır
## Ne Zaman Kullanılır
`/plan` komutunu şu durumlarda kullanın:
- Yeni bir özelliğe başlarken
- Önemli mimari değişiklikler yaparken
- Karmaşık refactoring üzerinde çalışırken
- Birden fazla dosya/component etkilenecekken
- Gereksinimler belirsiz veya muğlak olduğunda
## Nasıl Çalışır
Planner agent'ı şunları yapacaktır:
1. İsteği **analiz edecek** ve gereksinimleri net şekilde yeniden ifade edecek
2. Belirli, uygulanabilir adımlarla **fazlara ayıracak**
3. Componentler arası **bağımlılıkları tanımlayacak**
4. **Riskleri değerlendirecek** ve potansiyel engelleri belirleyecek
5. **Karmaşıklığı tahmin edecek** (Yüksek/Orta/Düşük)
6. **Planı sunacak** ve açık onayınızı bekleyecek
## Örnek Kullanım
```
Kullanıcı: /plan Piyasalar çözüldüğünde gerçek zamanlı bildirimler eklemeye ihtiyacım var
Agent (planner):
# Uygulama Planı: Gerçek Zamanlı Piyasa Çözüm Bildirimleri
## Gereksinim Yeniden İfadesi
- Kullanıcılar takip ettikleri piyasalar çözüldüğünde bildirim alsın
- Birden fazla bildirim kanalını destekle (uygulama içi, e-posta, webhook)
- Bildirimlerin güvenilir bir şekilde iletilmesini sağla
- Piyasa sonucunu ve kullanıcının pozisyon sonucunu içer
## Uygulama Fazları
### Faz 1: Database Şeması
- Kolonlarla bildirimler tablosu ekle: id, user_id, market_id, type, status, created_at
- Kanal tercihleri için user_notification_preferences tablosu ekle
- Performans için user_id ve market_id üzerinde indexler oluştur
### Faz 2: Bildirim Servisi
- lib/notifications.ts'de bildirim servisi oluştur
- BullMQ/Redis kullanarak bildirim kuyruğu uygula
- Başarısız teslimatlar için yeniden deneme mantığı ekle
- Bildirim şablonları oluştur
### Faz 3: Entegrasyon Noktaları
- Piyasa çözüm mantığına bağlan (durum "resolved" olduğunda)
- Piyasada pozisyonu olan tüm kullanıcıları sorgula
- Her kullanıcı için bildirimleri kuyruğa ekle
### Faz 4: Frontend Componentleri
- Header'da NotificationBell componenti oluştur
- NotificationList modal'ı ekle
- Supabase subscriptions ile gerçek zamanlı güncellemeler uygula
- Bildirim tercihleri sayfası ekle
## Bağımlılıklar
- Redis (kuyruk için)
- E-posta servisi (SendGrid/Resend)
- Supabase real-time subscriptions
## Riskler
- YÜKSEK: E-posta teslimatı (SPF/DKIM gerekli)
- ORTA: Piyasa başına 1000+ kullanıcı ile performans
- ORTA: Piyasalar sık çözülürse bildirim spam'i
- DÜŞÜK: Real-time subscription yükü
## Tahmini Karmaşıklık: ORTA
- Backend: 4-6 saat
- Frontend: 3-4 saat
- Test: 2-3 saat
- Toplam: 9-13 saat
**ONAY BEKLENİYOR**: Bu planla ilerleyelim mi? (evet/hayır/değiştir)
```
## Önemli Notlar
**KRİTİK**: Planner agent, planı "evet" veya "ilerle" veya benzeri olumlu bir yanıtla açıkça onaylayana kadar herhangi bir kod **YAZMAYACAK**.
Değişiklik istiyorsanız, şu şekilde yanıt verin:
- "değiştir: [değişiklikleriniz]"
- "farklı yaklaşım: [alternatif]"
- "faz 2'yi atla ve önce faz 3'ü yap"
## Diğer Komutlarla Entegrasyon
Planlamadan sonra:
- Test odaklı geliştirme ile uygulamak için `/tdd` kullanın
- Build hataları oluşursa `/build-fix` kullanın
- Tamamlanan uygulamayı gözden geçirmek için `/code-review` kullanın
## İlgili Agent'lar
Bu komut, ECC tarafından sağlanan `planner` agent'ını çağırır.
Manuel kurulumlar için, kaynak dosya şurada bulunur:
`agents/planner.md`

272
docs/tr/commands/pm2.md Normal file
View File

@@ -0,0 +1,272 @@
# PM2 Init
Projeyi otomatik analiz et ve PM2 servis komutları oluştur.
**Komut**: `$ARGUMENTS`
---
## İş Akışı
1. PM2'yi kontrol et (yoksa `npm install -g pm2` ile yükle)
2. Servisleri (frontend/backend/database) tanımlamak için projeyi tara
3. Config dosyaları ve bireysel komut dosyaları oluştur
---
## Servis Tespiti
| Tip | Tespit | Varsayılan Port |
|------|-----------|--------------|
| Vite | vite.config.* | 5173 |
| Next.js | next.config.* | 3000 |
| Nuxt | nuxt.config.* | 3000 |
| CRA | package.json'da react-scripts | 3000 |
| Express/Node | server/backend/api dizini + package.json | 3000 |
| FastAPI/Flask | requirements.txt / pyproject.toml | 8000 |
| Go | go.mod / main.go | 8080 |
**Port Tespit Önceliği**: Kullanıcı belirtimi > .env > config dosyası > script argümanları > varsayılan port
---
## Oluşturulan Dosyalar
```
project/
├── ecosystem.config.cjs # PM2 config
├── {backend}/start.cjs # Python wrapper (geçerliyse)
└── .claude/
├── commands/
│ ├── pm2-all.md # Hepsini başlat + monit
│ ├── pm2-all-stop.md # Hepsini durdur
│ ├── pm2-all-restart.md # Hepsini yeniden başlat
│ ├── pm2-{port}.md # Tekli başlat + logs
│ ├── pm2-{port}-stop.md # Tekli durdur
│ ├── pm2-{port}-restart.md # Tekli yeniden başlat
│ ├── pm2-logs.md # Tüm logları göster
│ └── pm2-status.md # Durumu göster
└── scripts/
├── pm2-logs-{port}.ps1 # Tekli servis logları
└── pm2-monit.ps1 # PM2 monitor
```
---
## Windows Konfigürasyonu (ÖNEMLİ)
### ecosystem.config.cjs
**`.cjs` uzantısı kullanmalı**
```javascript
module.exports = {
apps: [
// Node.js (Vite/Next/Nuxt)
{
name: 'project-3000',
cwd: './packages/web',
script: 'node_modules/vite/bin/vite.js',
args: '--port 3000',
interpreter: 'C:/Program Files/nodejs/node.exe',
env: { NODE_ENV: 'development' }
},
// Python
{
name: 'project-8000',
cwd: './backend',
script: 'start.cjs',
interpreter: 'C:/Program Files/nodejs/node.exe',
env: { PYTHONUNBUFFERED: '1' }
}
]
}
```
**Framework script yolları:**
| Framework | script | args |
|-----------|--------|------|
| Vite | `node_modules/vite/bin/vite.js` | `--port {port}` |
| Next.js | `node_modules/next/dist/bin/next` | `dev -p {port}` |
| Nuxt | `node_modules/nuxt/bin/nuxt.mjs` | `dev --port {port}` |
| Express | `src/index.js` veya `server.js` | - |
### Python Wrapper Script (start.cjs)
```javascript
const { spawn } = require('child_process');
const proc = spawn('python', ['-m', 'uvicorn', 'app.main:app', '--host', '0.0.0.0', '--port', '8000', '--reload'], {
cwd: __dirname, stdio: 'inherit', windowsHide: true
});
proc.on('close', (code) => process.exit(code));
```
---
## Komut Dosyası Şablonları (Minimal İçerik)
### pm2-all.md (Hepsini başlat + monit)
````markdown
Tüm servisleri başlat ve PM2 monitör aç.
```bash
cd "{PROJECT_ROOT}" && pm2 start ecosystem.config.cjs && start wt.exe -d "{PROJECT_ROOT}" pwsh -NoExit -c "pm2 monit"
```
````
### pm2-all-stop.md
````markdown
Tüm servisleri durdur.
```bash
cd "{PROJECT_ROOT}" && pm2 stop all
```
````
### pm2-all-restart.md
````markdown
Tüm servisleri yeniden başlat.
```bash
cd "{PROJECT_ROOT}" && pm2 restart all
```
````
### pm2-{port}.md (Tekli başlat + logs)
````markdown
{name} ({port}) başlat ve logları aç.
```bash
cd "{PROJECT_ROOT}" && pm2 start ecosystem.config.cjs --only {name} && start wt.exe -d "{PROJECT_ROOT}" pwsh -NoExit -c "pm2 logs {name}"
```
````
### pm2-{port}-stop.md
````markdown
{name} ({port}) durdur.
```bash
cd "{PROJECT_ROOT}" && pm2 stop {name}
```
````
### pm2-{port}-restart.md
````markdown
{name} ({port}) yeniden başlat.
```bash
cd "{PROJECT_ROOT}" && pm2 restart {name}
```
````
### pm2-logs.md
````markdown
Tüm PM2 loglarını göster.
```bash
cd "{PROJECT_ROOT}" && pm2 logs
```
````
### pm2-status.md
````markdown
PM2 durumunu göster.
```bash
cd "{PROJECT_ROOT}" && pm2 status
```
````
### PowerShell Scripts (pm2-logs-{port}.ps1)
```powershell
Set-Location "{PROJECT_ROOT}"
pm2 logs {name}
```
### PowerShell Scripts (pm2-monit.ps1)
```powershell
Set-Location "{PROJECT_ROOT}"
pm2 monit
```
---
## Ana Kurallar
1. **Config dosyası**: `ecosystem.config.cjs` (.js değil)
2. **Node.js**: Bin yolunu doğrudan belirt + interpreter
3. **Python**: Node.js wrapper script + `windowsHide: true`
4. **Yeni pencere aç**: `start wt.exe -d "{path}" pwsh -NoExit -c "command"`
5. **Minimal içerik**: Her komut dosyası sadece 1-2 satır açıklama + bash bloğu
6. **Doğrudan çalıştırma**: AI ayrıştırması gerekmez, sadece bash komutunu çalıştır
---
## Çalıştır
`$ARGUMENTS`'a göre init'i çalıştır:
1. Servisleri taramak için projeyi tara
2. `ecosystem.config.cjs` oluştur
3. Python servisleri için `{backend}/start.cjs` oluştur (geçerliyse)
4. `.claude/commands/` dizininde komut dosyaları oluştur
5. `.claude/scripts/` dizininde script dosyaları oluştur
6. **Proje CLAUDE.md'yi PM2 bilgisiyle güncelle** (aşağıya bakın)
7. **Terminal komutlarıyla tamamlama özetini göster**
---
## Post-Init: CLAUDE.md'yi Güncelle
Dosyalar oluşturulduktan sonra, projenin `CLAUDE.md` dosyasına PM2 bölümünü ekle (yoksa oluştur):
````markdown
## PM2 Services
| Port | Name | Type |
|------|------|------|
| {port} | {name} | {type} |
**Terminal Commands:**
```bash
pm2 start ecosystem.config.cjs # İlk seferinde
pm2 start all # İlk seferinden sonra
pm2 stop all / pm2 restart all
pm2 start {name} / pm2 stop {name}
pm2 logs / pm2 status / pm2 monit
pm2 save # Process listesini kaydet
pm2 resurrect # Kaydedilen listeyi geri yükle
```
````
**CLAUDE.md güncelleme kuralları:**
- PM2 bölümü varsa, değiştir
- Yoksa, sona ekle
- İçeriği minimal ve temel tut
---
## Post-Init: Özet Göster
Tüm dosyalar oluşturulduktan sonra, çıktı:
```
## PM2 Init Complete
**Services:**
| Port | Name | Type |
|------|------|------|
| {port} | {name} | {type} |
**Claude Commands:** /pm2-all, /pm2-all-stop, /pm2-{port}, /pm2-{port}-stop, /pm2-logs, /pm2-status
**Terminal Commands:**
## İlk seferinde (config dosyasıyla)
pm2 start ecosystem.config.cjs && pm2 save
## İlk seferinden sonra (basitleştirilmiş)
pm2 start all # Hepsini başlat
pm2 stop all # Hepsini durdur
pm2 restart all # Hepsini yeniden başlat
pm2 start {name} # Tekli başlat
pm2 stop {name} # Tekli durdur
pm2 logs # Logları göster
pm2 monit # Monitor paneli
pm2 resurrect # Kaydedilen process'leri geri yükle
**İpucu:** Basitleştirilmiş komutları etkinleştirmek için ilk başlatmadan sonra `pm2 save` çalıştırın.
```

View File

@@ -0,0 +1,80 @@
# Refactor Clean
Her adımda test doğrulaması ile ölü kodu güvenle tanımla ve kaldır.
## Adım 1: Ölü Kodu Tespit Et
Proje türüne göre analiz araçlarını çalıştır:
| Araç | Ne Bulur | Komut |
|------|--------------|---------|
| knip | Kullanılmayan export'lar, dosyalar, bağımlılıklar | `npx knip` |
| depcheck | Kullanılmayan npm bağımlılıkları | `npx depcheck` |
| ts-prune | Kullanılmayan TypeScript export'ları | `npx ts-prune` |
| vulture | Kullanılmayan Python kodu | `vulture src/` |
| deadcode | Kullanılmayan Go kodu | `deadcode ./...` |
| cargo-udeps | Kullanılmayan Rust bağımlılıkları | `cargo +nightly udeps` |
Hiçbir araç yoksa, sıfır import'lu export'ları bulmak için Grep kullanın:
```
# Export'ları bul, sonra herhangi bir yerde import edilip edilmediklerini kontrol et
```
## Adım 2: Bulguları Kategorize Et
Bulguları güvenlik katmanlarına göre sırala:
| Katman | Örnekler | Aksiyon |
|------|----------|--------|
| **GÜVENLİ** | Kullanılmayan yardımcılar, test yardımcıları, dahili fonksiyonlar | Güvenle sil |
| **DİKKAT** | Component'ler, API route'ları, middleware | Dinamik import'ları veya harici tüketicileri olmadığını doğrula |
| **TEHLİKE** | Config dosyaları, giriş noktaları, tip tanımları | Dokunmadan önce araştır |
## Adım 3: Güvenli Silme Döngüsü
Her GÜVENLİ öğe için:
1. **Tam test paketini çalıştır** — Baseline oluştur (tümü yeşil)
2. **Ölü kodu sil** — Cerrahi kaldırma için Edit aracını kullan
3. **Test paketini yeniden çalıştır** — Hiçbir şeyin bozulmadığını doğrula
4. **Testler başarısız olursa** — Hemen `git checkout -- <file>` ile geri al ve bu öğeyi atla
5. **Testler geçerse** — Sonraki öğeye geç
## Adım 4: DİKKAT Öğelerini İdare Et
DİKKAT öğelerini silmeden önce:
- Dinamik import'ları ara: `import()`, `require()`, `__import__`
- String referansları ara: route isimleri, config'lerdeki component isimleri
- Public paket API'sinden export edilip edilmediğini kontrol et
- Harici tüketici olmadığını doğrula (yayınlanmışsa bağımlıları kontrol et)
## Adım 5: Duplikatları Birleştir
Ölü kodu kaldırdıktan sonra şunları ara:
- Neredeyse aynı fonksiyonlar (%80'den fazla benzer) — birinde birleştir
- Gereksiz tip tanımları — birleştir
- Değer eklemeyen wrapper fonksiyonlar — inline yap
- Amacı olmayan re-export'lar — yönlendirmeyi kaldır
## Adım 6: Özet
Sonuçları raporla:
```
Ölü Kod Temizliği
──────────────────────────────
Silindi: 12 kullanılmayan fonksiyon
3 kullanılmayan dosya
5 kullanılmayan bağımlılık
Atlandı: 2 öğe (testler başarısız)
Kazanç: ~450 satır kaldırıldı
──────────────────────────────
Tüm testler geçiyor ✅
```
## Kurallar
- **Önce testleri çalıştırmadan asla silmeyin**
- **Bir seferde bir silme** — Atomik değişiklikler geri almayı kolaylaştırır
- **Emin değilseniz atlayın** — Üretimi bozmaktansa ölü kodu tutmak daha iyidir
- **Temizlerken refactor etmeyin** — Endişeleri ayırın (önce temizle, sonra refactor et)

View File

@@ -0,0 +1,293 @@
---
description: Claude Code session geçmişini, aliasları ve session metadata'sını yönet.
---
# Sessions Komutu
Claude Code session geçmişini yönet - `~/.claude/sessions/` dizininde saklanan session'ları listele, yükle, alias ata ve düzenle.
## Kullanım
`/sessions [list|load|alias|info|help] [options]`
## Aksiyonlar
### List Sessions
Tüm session'ları metadata, filtreleme ve sayfalama ile göster.
Bir swarm için operatör-yüzey context'e ihtiyacınız olduğunda `/sessions info` kullanın: branch, worktree yolu ve session güncelliği.
```bash
/sessions # Tüm session'ları listele (varsayılan)
/sessions list # Yukarıdakiyle aynı
/sessions list --limit 10 # 10 session göster
/sessions list --date 2026-02-01 # Tarihe göre filtrele
/sessions list --search abc # Session ID'ye göre ara
```
**Script:**
```bash
node -e "
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
const path = require('path');
const result = sm.getAllSessions({ limit: 20 });
const aliases = aa.listAliases();
const aliasMap = {};
for (const a of aliases) aliasMap[a.sessionPath] = a.name;
console.log('Sessions (showing ' + result.sessions.length + ' of ' + result.total + '):');
console.log('');
console.log('ID Date Time Branch Worktree Alias');
console.log('────────────────────────────────────────────────────────────────────');
for (const s of result.sessions) {
const alias = aliasMap[s.filename] || '';
const metadata = sm.parseSessionMetadata(sm.getSessionContent(s.sessionPath));
const id = s.shortId === 'no-id' ? '(none)' : s.shortId.slice(0, 8);
const time = s.modifiedTime.toTimeString().slice(0, 5);
const branch = (metadata.branch || '-').slice(0, 12);
const worktree = metadata.worktree ? path.basename(metadata.worktree).slice(0, 18) : '-';
console.log(id.padEnd(8) + ' ' + s.date + ' ' + time + ' ' + branch.padEnd(12) + ' ' + worktree.padEnd(18) + ' ' + alias);
}
"
```
### Load Session
Session içeriğini yükle ve göster (ID veya alias ile).
```bash
/sessions load <id|alias> # Session yükle
/sessions load 2026-02-01 # Tarihe göre (no-id session'lar için)
/sessions load a1b2c3d4 # Short ID ile
/sessions load my-alias # Alias adıyla
```
**Script:**
```bash
node -e "
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
const id = process.argv[1];
// Önce alias olarak çözümlemeyi dene
const resolved = aa.resolveAlias(id);
const sessionId = resolved ? resolved.sessionPath : id;
const session = sm.getSessionById(sessionId, true);
if (!session) {
console.log('Session not found: ' + id);
process.exit(1);
}
const stats = sm.getSessionStats(session.sessionPath);
const size = sm.getSessionSize(session.sessionPath);
const aliases = aa.getAliasesForSession(session.filename);
console.log('Session: ' + session.filename);
console.log('Path: ~/.claude/sessions/' + session.filename);
console.log('');
console.log('Statistics:');
console.log(' Lines: ' + stats.lineCount);
console.log(' Total items: ' + stats.totalItems);
console.log(' Completed: ' + stats.completedItems);
console.log(' In progress: ' + stats.inProgressItems);
console.log(' Size: ' + size);
console.log('');
if (aliases.length > 0) {
console.log('Aliases: ' + aliases.map(a => a.name).join(', '));
console.log('');
}
if (session.metadata.title) {
console.log('Title: ' + session.metadata.title);
console.log('');
}
if (session.metadata.started) {
console.log('Started: ' + session.metadata.started);
}
if (session.metadata.lastUpdated) {
console.log('Last Updated: ' + session.metadata.lastUpdated);
}
if (session.metadata.project) {
console.log('Project: ' + session.metadata.project);
}
if (session.metadata.branch) {
console.log('Branch: ' + session.metadata.branch);
}
if (session.metadata.worktree) {
console.log('Worktree: ' + session.metadata.worktree);
}
" "$ARGUMENTS"
```
### Create Alias
Session için akılda kalıcı bir alias oluştur.
```bash
/sessions alias <id> <name> # Alias oluştur
/sessions alias 2026-02-01 today-work # "today-work" adlı alias oluştur
```
**Script:**
```bash
node -e "
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
const sessionId = process.argv[1];
const aliasName = process.argv[2];
if (!sessionId || !aliasName) {
console.log('Usage: /sessions alias <id> <name>');
process.exit(1);
}
// Session dosya adını al
const session = sm.getSessionById(sessionId);
if (!session) {
console.log('Session not found: ' + sessionId);
process.exit(1);
}
const result = aa.setAlias(aliasName, session.filename);
if (result.success) {
console.log('✓ Alias created: ' + aliasName + ' → ' + session.filename);
} else {
console.log('✗ Error: ' + result.error);
process.exit(1);
}
" "$ARGUMENTS"
```
### Remove Alias
Mevcut bir alias'ı sil.
```bash
/sessions alias --remove <name> # Alias'ı kaldır
/sessions unalias <name> # Yukarıdakiyle aynı
```
**Script:**
```bash
node -e "
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
const aliasName = process.argv[1];
if (!aliasName) {
console.log('Usage: /sessions alias --remove <name>');
process.exit(1);
}
const result = aa.deleteAlias(aliasName);
if (result.success) {
console.log('✓ Alias removed: ' + aliasName);
} else {
console.log('✗ Error: ' + result.error);
process.exit(1);
}
" "$ARGUMENTS"
```
### Session Info
Session hakkında detaylı bilgi göster.
```bash
/sessions info <id|alias> # Session detaylarını göster
```
**Script:** (yukarıdaki Load Session script'i ile aynı yapı)
### List Aliases
Tüm session aliaslarını göster.
```bash
/sessions aliases # Tüm aliasları listele
```
**Script:**
```bash
node -e "
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
const aliases = aa.listAliases();
console.log('Session Aliases (' + aliases.length + '):');
console.log('');
if (aliases.length === 0) {
console.log('No aliases found.');
} else {
console.log('Name Session File Title');
console.log('─────────────────────────────────────────────────────────────');
for (const a of aliases) {
const name = a.name.padEnd(12);
const file = (a.sessionPath.length > 30 ? a.sessionPath.slice(0, 27) + '...' : a.sessionPath).padEnd(30);
const title = a.title || '';
console.log(name + ' ' + file + ' ' + title);
}
}
"
```
## Operatör Notları
- Session dosyaları header'da `Project`, `Branch` ve `Worktree`'yi sürdürür, böylece `/sessions info` parallel tmux/worktree çalıştırmalarını ayırt edebilir.
- Command-center tarzı izleme için, `/sessions info`, `git diff --stat` ve `scripts/hooks/cost-tracker.js` tarafından yayılan cost metriklerini birleştirin.
## Argümanlar
$ARGUMENTS:
- `list [options]` - Session'ları listele
- `--limit <n>` - Gösterilecek max session (varsayılan: 50)
- `--date <YYYY-MM-DD>` - Tarihe göre filtrele
- `--search <pattern>` - Session ID'de ara
- `load <id|alias>` - Session içeriğini yükle
- `alias <id> <name>` - Session için alias oluştur
- `alias --remove <name>` - Alias'ı kaldır
- `unalias <name>` - `--remove` ile aynı
- `info <id|alias>` - Session istatistiklerini göster
- `aliases` - Tüm aliasları listele
- `help` - Bu yardımı göster
## Örnekler
```bash
# Tüm session'ları listele
/sessions list
# Bugünkü session için alias oluştur
/sessions alias 2026-02-01 today
# Session'ı alias ile yükle
/sessions load today
# Session bilgisini göster
/sessions info today
# Alias'ı kaldır
/sessions alias --remove today
# Tüm aliasları listele
/sessions aliases
```
## Notlar
- Session'lar `~/.claude/sessions/` dizininde markdown dosyaları olarak saklanır
- Aliaslar `~/.claude/session-aliases.json` dosyasında saklanır
- Session ID'leri kısaltılabilir (ilk 4-8 karakter genellikle yeterince benzersizdir)
- Sık referans verilen session'lar için aliasları kullanın

View File

@@ -0,0 +1,80 @@
---
description: Tercih ettiğiniz paket yöneticisini yapılandırın (npm/pnpm/yarn/bun)
disable-model-invocation: true
---
# Paket Yöneticisi Kurulumu
Bu proje veya global olarak tercih ettiğiniz paket yöneticisini yapılandırın.
## Kullanım
```bash
# Mevcut paket yöneticisini tespit et
node scripts/setup-package-manager.js --detect
# Global tercihi ayarla
node scripts/setup-package-manager.js --global pnpm
# Proje tercihini ayarla
node scripts/setup-package-manager.js --project bun
# Mevcut paket yöneticilerini listele
node scripts/setup-package-manager.js --list
```
## Tespit Önceliği
Hangi paket yöneticisinin kullanılacağını belirlerken, şu sıra kontrol edilir:
1. **Environment variable**: `CLAUDE_PACKAGE_MANAGER`
2. **Proje config**: `.claude/package-manager.json`
3. **package.json**: `packageManager` alanı
4. **Lock dosyası**: package-lock.json, yarn.lock, pnpm-lock.yaml veya bun.lockb varlığı
5. **Global config**: `~/.claude/package-manager.json`
6. **Fallback**: İlk mevcut paket yöneticisi (pnpm > bun > yarn > npm)
## Yapılandırma Dosyaları
### Global Yapılandırma
```json
// ~/.claude/package-manager.json
{
"packageManager": "pnpm"
}
```
### Proje Yapılandırması
```json
// .claude/package-manager.json
{
"packageManager": "bun"
}
```
### package.json
```json
{
"packageManager": "pnpm@8.6.0"
}
```
## Environment Variable
Tüm diğer tespit yöntemlerini geçersiz kılmak için `CLAUDE_PACKAGE_MANAGER` ayarlayın:
```bash
# Windows (PowerShell)
$env:CLAUDE_PACKAGE_MANAGER = "pnpm"
# macOS/Linux
export CLAUDE_PACKAGE_MANAGER=pnpm
```
## Tespiti Çalıştır
Mevcut paket yöneticisi tespit sonuçlarını görmek için şunu çalıştırın:
```bash
node scripts/setup-package-manager.js --detect
```

View File

@@ -0,0 +1,174 @@
---
name: skill-create
description: Kodlama desenlerini çıkarmak ve SKILL.md dosyaları oluşturmak için yerel git geçmişini analiz et. Skill Creator GitHub App'ın yerel versiyonu.
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
---
# /skill-create - Yerel Skill Oluşturma
Repository'nizin git geçmişini analiz ederek kodlama desenlerini çıkarın ve Claude'a ekibinizin uygulamalarını öğreten SKILL.md dosyaları oluşturun.
## Kullanım
```bash
/skill-create # Mevcut repo'yu analiz et
/skill-create --commits 100 # Son 100 commit'i analiz et
/skill-create --output ./skills # Özel çıktı dizini
/skill-create --instincts # continuous-learning-v2 için instinct'ler de oluştur
```
## Ne Yapar
1. **Git Geçmişini Parse Eder** - Commit'leri, dosya değişikliklerini ve desenleri analiz eder
2. **Desenleri Tespit Eder** - Tekrarlayan iş akışlarını ve kuralları tanımlar
3. **SKILL.md Oluşturur** - Geçerli Claude Code skill dosyaları oluşturur
4. **İsteğe Bağlı Instinct'ler Oluşturur** - continuous-learning-v2 sistemi için
## Analiz Adımları
### Adım 1: Git Verilerini Topla
```bash
# Dosya değişiklikleriyle son commit'leri al
git log --oneline -n ${COMMITS:-200} --name-only --pretty=format:"%H|%s|%ad" --date=short
# Dosyaya göre commit sıklığını al
git log --oneline -n 200 --name-only | grep -v "^$" | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -20
# Commit mesaj desenlerini al
git log --oneline -n 200 | cut -d' ' -f2- | head -50
```
### Adım 2: Desenleri Tespit Et
Bu desen türlerini ara:
| Desen | Tespit Yöntemi |
|---------|-----------------|
| **Commit kuralları** | Commit mesajlarında regex (feat:, fix:, chore:) |
| **Dosya birlikte değişimleri** | Her zaman birlikte değişen dosyalar |
| **İş akışı dizileri** | Tekrarlanan dosya değişim desenleri |
| **Mimari** | Klasör yapısı ve isimlendirme kuralları |
| **Test desenleri** | Test dosya konumları, isimlendirme, kapsama |
### Adım 3: SKILL.md Oluştur
Çıktı formatı:
```markdown
---
name: {repo-name}-patterns
description: {repo-name}'den çıkarılan kodlama desenleri
version: 1.0.0
source: local-git-analysis
analyzed_commits: {count}
---
# {Repo Name} Desenleri
## Commit Kuralları
{tespit edilen commit mesaj desenleri}
## Kod Mimarisi
{tespit edilen klasör yapısı ve organizasyon}
## İş Akışları
{tespit edilen tekrarlayan dosya değişim desenleri}
## Test Desenleri
{tespit edilen test kuralları}
```
### Adım 4: Instinct'ler Oluştur (--instincts varsa)
continuous-learning-v2 entegrasyonu için:
```yaml
---
id: {repo}-commit-convention
trigger: "bir commit mesajı yazarken"
confidence: 0.8
domain: git
source: local-repo-analysis
---
# Conventional Commits Kullan
## Aksiyon
Commit'leri şu öneklerle başlat: feat:, fix:, chore:, docs:, test:, refactor:
## Kanıt
- {n} commit analiz edildi
- {percentage}% conventional commit formatını takip ediyor
```
## Örnek Çıktı
Bir TypeScript projesinde `/skill-create` çalıştırmak şunları üretebilir:
```markdown
---
name: my-app-patterns
description: my-app repository'sinden kodlama desenleri
version: 1.0.0
source: local-git-analysis
analyzed_commits: 150
---
# My App Desenleri
## Commit Kuralları
Bu proje **conventional commits** kullanıyor:
- `feat:` - Yeni özellikler
- `fix:` - Hata düzeltmeleri
- `chore:` - Bakım görevleri
- `docs:` - Dokümantasyon güncellemeleri
## Kod Mimarisi
```
src/
├── components/ # React componentleri (PascalCase.tsx)
├── hooks/ # Özel hook'lar (use*.ts)
├── utils/ # Yardımcı fonksiyonlar
├── types/ # TypeScript tip tanımları
└── services/ # API ve harici servisler
```
## İş Akışları
### Yeni Bir Component Ekleme
1. `src/components/ComponentName.tsx` oluştur
2. `src/components/__tests__/ComponentName.test.tsx`'de testler ekle
3. `src/components/index.ts`'den export et
### Database Migration
1. `src/db/schema.ts`'yi değiştir
2. `pnpm db:generate` çalıştır
3. `pnpm db:migrate` çalıştır
## Test Desenleri
- Test dosyaları: `__tests__/` dizinleri veya `.test.ts` eki
- Kapsama hedefi: 80%+
- Framework: Vitest
```
## GitHub App Entegrasyonu
Gelişmiş özellikler için (10k+ commit, ekip paylaşımı, otomatik PR'lar), [Skill Creator GitHub App](https://github.com/apps/skill-creator) kullanın:
- Yükle: [github.com/apps/skill-creator](https://github.com/apps/skill-creator)
- Herhangi bir issue'da `/skill-creator analyze` yorumu yap
- Oluşturulan skill'lerle PR alın
## İlgili Komutlar
- `/instinct-import` - Oluşturulan instinct'leri import et
- `/instinct-status` - Öğrenilen instinct'leri görüntüle
- `/evolve` - Instinct'leri skill'ler/agent'lara kümelendir
---
*[Everything Claude Code](https://github.com/affaan-m/everything-claude-code)'un bir parçası*

328
docs/tr/commands/tdd.md Normal file
View File

@@ -0,0 +1,328 @@
---
description: Test odaklı geliştirme (TDD) iş akışını zorlar. Interface'leri tasarla, ÖNCE testleri oluştur, sonra minimal kodu uygula. %80+ kod kapsama oranı sağla.
---
# TDD Komutu
Bu komut, test odaklı geliştirme metodolojisini zorlamak için **tdd-guide** agent'ını çağırır.
## Bu Komut Ne Yapar
1. **Interface'leri Tasarla** - Önce tip/interface'leri tanımla
2. **Önce Testleri Oluştur** - Başarısız testler yaz (RED)
3. **Minimal Kod Uygula** - Geçmek için yeterli kodu yaz (GREEN)
4. **Refactor Et** - Testleri yeşil tutarken kodu iyileştir (REFACTOR)
5. **Kapsama Oranını Doğrula** - %80+ test kapsama oranı sağla
## Ne Zaman Kullanılır
`/tdd` komutunu şu durumlarda kullanın:
- Yeni özellikler uygularken
- Yeni fonksiyonlar/componentler eklerken
- Hataları düzeltirken (önce hatayı tekrar eden test yaz)
- Mevcut kodu refactor ederken
- Kritik iş mantığı oluştururken
## Nasıl Çalışır
tdd-guide agent'ı şunları yapacaktır:
1. Giriş/çıkışlar için **interface'leri tanımla**
2. **BAŞARISIZ olacak testleri yaz** (çünkü kod henüz yok)
3. **Testleri çalıştır** ve doğru sebepten başarısız olduklarını doğrula
4. Testleri geçirmek için **minimal uygulama yaz**
5. **Testleri çalıştır** ve geçtiklerini doğrula
6. Testleri yeşil tutarken kodu **refactor et**
7. **Kapsama oranını kontrol et** ve %80'in altındaysa daha fazla test ekle
## TDD Döngüsü
```
RED → GREEN → REFACTOR → TEKRARLA
RED: Başarısız bir test yaz
GREEN: Geçmek için minimal kod yaz
REFACTOR: Kodu iyileştir, testleri geçmeye devam et
TEKRARLA: Bir sonraki özellik/senaryo
```
## Örnek Kullanım
```
Kullanıcı: /tdd Piyasa likidite skorunu hesaplamak için bir fonksiyona ihtiyacım var
Agent (tdd-guide):
# TDD Oturumu: Piyasa Likidite Skoru Hesaplayıcı
## Adım 1: Interface Tanımla (SCAFFOLD)
```typescript
// lib/liquidity.ts
export interface MarketData {
totalVolume: number
bidAskSpread: number
activeTraders: number
lastTradeTime: Date
}
export function calculateLiquidityScore(market: MarketData): number {
// TODO: Uygulama
throw new Error('Not implemented')
}
```
## Adım 2: Başarısız Test Yaz (RED)
```typescript
// lib/liquidity.test.ts
import { calculateLiquidityScore } from './liquidity'
describe('calculateLiquidityScore', () => {
it('likit piyasa için yüksek skor döndürmeli', () => {
const market = {
totalVolume: 100000,
bidAskSpread: 0.01,
activeTraders: 500,
lastTradeTime: new Date()
}
const score = calculateLiquidityScore(market)
expect(score).toBeGreaterThan(80)
expect(score).toBeLessThanOrEqual(100)
})
it('az likit piyasa için düşük skor döndürmeli', () => {
const market = {
totalVolume: 100,
bidAskSpread: 0.5,
activeTraders: 2,
lastTradeTime: new Date(Date.now() - 86400000) // 1 gün önce
}
const score = calculateLiquidityScore(market)
expect(score).toBeLessThan(30)
expect(score).toBeGreaterThanOrEqual(0)
})
it('edge case\'i idare etmeli: sıfır hacim', () => {
const market = {
totalVolume: 0,
bidAskSpread: 0,
activeTraders: 0,
lastTradeTime: new Date()
}
const score = calculateLiquidityScore(market)
expect(score).toBe(0)
})
})
```
## Adım 3: Testleri Çalıştır - Başarısızlığı Doğrula
```bash
npm test lib/liquidity.test.ts
FAIL lib/liquidity.test.ts
✕ should return high score for liquid market (2 ms)
Error: Not implemented
1 test failed, 0 passed
```
✅ Testler beklendiği gibi başarısız. Uygulamaya hazır.
## Adım 4: Minimal Kod Uygula (GREEN)
```typescript
// lib/liquidity.ts
export function calculateLiquidityScore(market: MarketData): number {
// Sıfır hacim edge case'ini idare et
if (market.totalVolume === 0) {
return 0
}
// Bileşen skorlarını hesapla (0-100 ölçeği)
const volumeScore = Math.min(market.totalVolume / 1000, 100)
const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0)
const traderScore = Math.min(market.activeTraders / 10, 100)
// Son aktivite bonusu
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0)
// Ağırlıklı ortalama
const score = (
volumeScore * 0.4 +
spreadScore * 0.3 +
traderScore * 0.2 +
recencyScore * 0.1
)
return Math.min(Math.max(score, 0), 100) // 0-100 arası sınırla
}
```
## Adım 5: Testleri Çalıştır - Başarıyı Doğrula
```bash
npm test lib/liquidity.test.ts
PASS lib/liquidity.test.ts
✓ should return high score for liquid market (3 ms)
✓ should return low score for illiquid market (2 ms)
✓ should handle edge case: zero volume (1 ms)
3 tests passed
```
✅ Tüm testler geçiyor!
## Adım 6: Refactor Et (IYILEŞTIR)
```typescript
// lib/liquidity.ts - Sabitler ve daha iyi okunabilirlik ile refactor edildi
const WEIGHTS = {
VOLUME: 0.4,
SPREAD: 0.3,
TRADERS: 0.2,
RECENCY: 0.1,
} as const
const SCALE_FACTORS = {
VOLUME: 1000,
SPREAD: 1000,
TRADERS: 10,
RECENCY_PENALTY: 10,
} as const
function clamp(value: number, min: number, max: number): number {
return Math.min(Math.max(value, min), max)
}
export function calculateLiquidityScore(market: MarketData): number {
if (market.totalVolume === 0) return 0
const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100)
const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100)
const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100)
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100)
const weightedScore =
volumeScore * WEIGHTS.VOLUME +
spreadScore * WEIGHTS.SPREAD +
traderScore * WEIGHTS.TRADERS +
recencyScore * WEIGHTS.RECENCY
return clamp(weightedScore, 0, 100)
}
```
## Adım 7: Testlerin Hala Geçtiğini Doğrula
```bash
npm test lib/liquidity.test.ts
PASS lib/liquidity.test.ts
✓ should return high score for liquid market (3 ms)
✓ should return low score for illiquid market (2 ms)
✓ should handle edge case: zero volume (1 ms)
3 tests passed
```
✅ Refactoring tamamlandı, testler hala geçiyor!
## Adım 8: Kapsama Oranını Kontrol Et
```bash
npm test -- --coverage lib/liquidity.test.ts
File | % Stmts | % Branch | % Funcs | % Lines
---------------|---------|----------|---------|--------
liquidity.ts | 100 | 100 | 100 | 100
Coverage: 100% ✅ (Hedef: 80%)
```
✅ TDD oturumu tamamlandı!
```
## TDD En İyi Uygulamaları
**YAPIN:**
- ✅ Herhangi bir uygulamadan ÖNCE testi yazın
- ✅ Testleri çalıştırın ve uygulamadan önce başarısız olduklarını doğrulayın
- ✅ Testleri geçirmek için minimal kod yazın
- ✅ Testler yeşil olduktan sonra refactor edin
- ✅ Edge case'leri ve hata senaryolarını ekleyin
- ✅ %80+ kapsama hedefleyin (kritik kod için %100)
**YAPMAYIN:**
- ❌ Testlerden önce uygulama yazmayın
- ❌ Her değişiklikten sonra testleri çalıştırmayı atlamayın
- ❌ Aynı anda çok fazla kod yazmayın
- ❌ Başarısız testleri görmezden gelmeyin
- ❌ Uygulama detaylarını test etmeyin (davranışı test edin)
- ❌ Her şeyi mock'lamayın (integration testleri tercih edin)
## Dahil Edilecek Test Türleri
**Unit Tests** (Fonksiyon seviyesi):
- Happy path senaryoları
- Edge case'ler (boş, null, maksimum değerler)
- Hata koşulları
- Sınır değerleri
**Integration Tests** (Component seviyesi):
- API endpoint'leri
- Database operasyonları
- Dış servis çağrıları
- Hook'lu React componentleri
**E2E Tests** (`/e2e` komutunu kullanın):
- Kritik kullanıcı akışları
- Çok adımlı süreçler
- Full stack entegrasyon
## Kapsama Gereksinimleri
- **Minimum %80** tüm kod için
- **%100 gerekli**:
- Finansal hesaplamalar
- Kimlik doğrulama mantığı
- Güvenlik açısından kritik kod
- Temel iş mantığı
## Önemli Notlar
**ZORUNLU**: Testler uygulamadan ÖNCE yazılmalıdır. TDD döngüsü:
1. **RED** - Başarısız test yaz
2. **GREEN** - Geçmek için uygula
3. **REFACTOR** - Kodu iyileştir
RED aşamasını asla atlamayın. Testlerden önce asla kod yazmayın.
## Diğer Komutlarla Entegrasyon
- Ne inşa edileceğini anlamak için önce `/plan` kullanın
- Testlerle uygulamak için `/tdd` kullanın
- Build hataları oluşursa `/build-fix` kullanın
- Uygulamayı gözden geçirmek için `/code-review` kullanın
- Kapsama oranını doğrulamak için `/test-coverage` kullanın
## İlgili Agent'lar
Bu komut, ECC tarafından sağlanan `tdd-guide` agent'ını çağırır.
İlgili `tdd-workflow` skill'i de ECC ile birlikte gelir.
Manuel kurulumlar için, kaynak dosyalar şurada bulunur:
- `agents/tdd-guide.md`
- `skills/tdd-workflow/SKILL.md`

View File

@@ -0,0 +1,69 @@
# Test Coverage
Test coverage'ını analiz et, eksiklikleri tanımla ve 80%+ coverage'a ulaşmak için eksik test'leri oluştur.
## Adım 1: Test Framework'ünü Tespit Et
| Gösterge | Coverage Komutu |
|-----------|-----------------|
| `jest.config.*` veya `package.json` jest | `npx jest --coverage --coverageReporters=json-summary` |
| `vitest.config.*` | `npx vitest run --coverage` |
| `pytest.ini` / `pyproject.toml` pytest | `pytest --cov=src --cov-report=json` |
| `Cargo.toml` | `cargo llvm-cov --json` |
| `pom.xml` JaCoCo ile | `mvn test jacoco:report` |
| `go.mod` | `go test -coverprofile=coverage.out ./...` |
## Adım 2: Coverage Raporunu Analiz Et
1. Coverage komutunu çalıştır
2. Çıktıyı ayrıştır (JSON summary veya terminal çıktısı)
3. **80% coverage'ın altındaki** dosyaları listele, en kötüden başlayarak sırala
4. Her yetersiz coverage'lı dosya için şunları tanımla:
- Test edilmemiş fonksiyonlar veya metodlar
- Eksik branch coverage (if/else, switch, error yolları)
- Payda'yı şişiren dead code
## Adım 3: Eksik Test'leri Oluştur
Her yetersiz coverage'lı dosya için, bu önceliği takip ederek test'ler oluştur:
1. **Happy path** — Geçerli input'larla temel fonksiyonalite
2. **Hata işleme** — Geçersiz input'lar, eksik veri, network hataları
3. **Edge case'ler** — Boş diziler, null/undefined, sınır değerleri (0, -1, MAX_INT)
4. **Branch coverage** — Her if/else, switch case, ternary
### Test Oluşturma Kuralları
- Test'leri kaynak kodun yanına yerleştir: `foo.ts``foo.test.ts` (veya proje konvansiyonu)
- Projeden mevcut test pattern'lerini kullan (import stili, assertion kütüphanesi, mocking yaklaşımı)
- Harici bağımlılıkları mock'la (veritabanı, API'ler, dosya sistemi)
- Her test bağımsız olmalı — test'ler arasında paylaşılan değişken state olmamalı
- Test'leri açıklayıcı isimlendirin: `test_create_user_with_duplicate_email_returns_409`
## Adım 4: Doğrula
1. Tam test suite'ini çalıştır — tüm test'ler geçmeli
2. Coverage'ı yeniden çalıştır — iyileşmeyi doğrula
3. Hala 80%'in altındaysa, kalan boşluklar için Adım 3'ü tekrarla
## Adım 5: Raporla
Öncesi/sonrası karşılaştırmasını göster:
```
Coverage Report
──────────────────────────────
File Before After
src/services/auth.ts 45% 88%
src/utils/validation.ts 32% 82%
──────────────────────────────
Overall: 67% 84% ✅
```
## Odak Alanları
- Karmaşık branching'e sahip fonksiyonlar (yüksek cyclomatic complexity)
- Hata işleyiciler ve catch blokları
- Codebase genelinde kullanılan utility fonksiyonları
- API endpoint handler'ları (request → response akışı)
- Edge case'ler: null, undefined, empty string, empty array, zero, negatif sayılar

View File

@@ -0,0 +1,84 @@
# Update Documentation
Dokümanları codebase ile senkronize et, truth-of-source dosyalarından oluştur.
## Adım 1: Truth Kaynaklarını Tanımla
| Kaynak | Oluşturur |
|--------|-----------|
| `package.json` scripts | Mevcut komutlar referansı |
| `.env.example` | Environment variable dokümanı |
| `openapi.yaml` / route dosyaları | API endpoint referansı |
| Kaynak kod export'ları | Public API dokümanı |
| `Dockerfile` / `docker-compose.yml` | Altyapı kurulum dokümanları |
## Adım 2: Script Referansı Oluştur
1. `package.json`'ı oku (veya `Makefile`, `Cargo.toml`, `pyproject.toml`)
2. Tüm script'leri/komutlarııklamalarıyla birlikte çıkar
3. Bir referans tablosu oluştur:
```markdown
| Command | Description |
|---------|-------------|
| `npm run dev` | Hot reload ile development server'ı başlat |
| `npm run build` | Type checking ile production build |
| `npm test` | Coverage ile test suite'ini çalıştır |
```
## Adım 3: Environment Dokümanı Oluştur
1. `.env.example`'ı oku (veya `.env.template`, `.env.sample`)
2. Tüm değişkenleri amaçlarıyla birlikte çıkar
3. Zorunlu vs isteğe bağlı olarak kategorize et
4. Beklenen format ve geçerli değerleri dokümante et
```markdown
| Variable | Required | Description | Example |
|----------|----------|-------------|---------|
| `DATABASE_URL` | Yes | PostgreSQL bağlantı string'i | `postgres://user:pass@host:5432/db` |
| `LOG_LEVEL` | No | Log detay seviyesi (varsayılan: info) | `debug`, `info`, `warn`, `error` |
```
## Adım 4: Contributing Guide'ı Güncelle
`docs/CONTRIBUTING.md`'yi şunlarla oluştur veya güncelle:
- Development environment kurulumu (ön koşullar, kurulum adımları)
- Mevcut script'ler ve amaçları
- Test prosedürleri (nasıl çalıştırılır, nasıl yeni test yazılır)
- Kod stili zorlama (linter, formatter, pre-commit hook'ları)
- PR gönderim kontrol listesi
## Adım 5: Runbook'u Güncelle
`docs/RUNBOOK.md`'yi şunlarla oluştur veya güncelle:
- Deployment prosedürleri (adım adım)
- Health check endpoint'leri ve izleme
- Yaygın sorunlar ve düzeltmeleri
- Rollback prosedürleri
- Uyarı ve eskalasyon yolları
## Adım 6: Güncellik Kontrolü
1. 90+ gün değiştirilmemiş doküman dosyalarını bul
2. Son kaynak kod değişiklikleriyle çapraz referans yap
3. Manuel gözden geçirme için potansiyel güncel olmayan dokümanları işaretle
## Adım 7: Özeti Göster
```
Documentation Update
──────────────────────────────
Updated: docs/CONTRIBUTING.md (scripts table)
Updated: docs/ENV.md (3 new variables)
Flagged: docs/DEPLOY.md (142 days stale)
Skipped: docs/API.md (no changes detected)
──────────────────────────────
```
## Kurallar
- **Tek truth kaynağı**: Her zaman koddan oluştur, oluşturulan bölümleri asla manuel düzenleme
- **Manuel bölümleri koru**: Sadece oluşturulan bölümleri güncelle; elle yazılmış prose'u bozulmamış bırak
- **Oluşturulan içeriği işaretle**: Oluşturulan bölümlerin etrafında `<!-- AUTO-GENERATED -->` marker'ları kullan
- **İstenmeyen doküman oluşturma**: Sadece komut açıkça talep ederse yeni doküman dosyaları oluştur

View File

@@ -0,0 +1,59 @@
# Verification Komutu
Mevcut kod tabanı durumu üzerinde kapsamlı doğrulama çalıştır.
## Talimatlar
Doğrulamayı tam olarak bu sırayla yürüt:
1. **Build Kontrolü**
- Bu proje için build komutunu çalıştır
- Başarısız olursa, hataları raporla ve DUR
2. **Tip Kontrolü**
- TypeScript/tip denetleyicisini çalıştır
- Tüm hataları dosya:satır ile raporla
3. **Lint Kontrolü**
- Linter'ı çalıştır
- Uyarıları ve hataları raporla
4. **Test Paketi**
- Tüm testleri çalıştır
- Geçti/başarısız sayısını raporla
- Kapsama yüzdesini raporla
5. **Console.log Denetimi**
- Kaynak dosyalarda console.log ara
- Konumları raporla
6. **Git Durumu**
- Commit edilmemiş değişiklikleri göster
- Son commit'ten beri değiştirilen dosyaları göster
## Çıktı
Özet bir doğrulama raporu üret:
```
DOĞRULAMA: [GEÇTİ/BAŞARISIZ]
Build: [TAMAM/BAŞARISIZ]
Tipler: [TAMAM/X hata]
Lint: [TAMAM/X sorun]
Testler: [X/Y geçti, Z% kapsama]
Gizli: [TAMAM/X bulundu]
Loglar: [TAMAM/X console.log]
PR için Hazır: [EVET/HAYIR]
```
Herhangi bir kritik sorun varsa, düzeltme önerileriyle listele.
## Argümanlar
$ARGUMENTS şunlar olabilir:
- `quick` - Sadece build + tipler
- `full` - Tüm kontroller (varsayılan)
- `pre-commit` - Commit'ler için ilgili kontroller
- `pre-pr` - Güvenlik taraması artı tam kontroller