Files
everything-claude-code/docs/tr/AGENTS.md
Berkcan Gümüşışık fd2a8edb53 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>
2026-03-22 15:37:04 -07:00

161 lines
8.9 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Everything Claude Code (ECC) — Agent Talimatları
Bu, yazılım geliştirme için 28 özel agent, 116 skill, 59 command ve otomatik hook iş akışları sağlayan **üretime hazır bir AI kodlama eklentisidir**.
**Sürüm:** 1.9.0
## Temel İlkeler
1. **Agent-Öncelikli** — Alan görevleri için özel agentlara delege edin
2. **Test-Odaklı** — Uygulamadan önce testler yazın, %80+ kapsama gereklidir
3. **Güvenlik-Öncelikli** — Güvenlikten asla taviz vermeyin; tüm girdileri doğrulayın
4. **Değişmezlik** — Her zaman yeni nesneler oluşturun, mevcut olanları asla değiştirmeyin
5. **Çalıştırmadan Önce Planlayın** — Karmaşık özellikleri kod yazmadan önce planlayın
## Mevcut Agentlar
| Agent | Amaç | Ne Zaman Kullanılır |
|-------|---------|-------------|
| planner | Uygulama planlaması | Karmaşık özellikler, yeniden düzenleme |
| architect | Sistem tasarımı ve ölçeklenebilirlik | Mimari kararlar |
| tdd-guide | Test-odaklı geliştirme | Yeni özellikler, hata düzeltmeleri |
| code-reviewer | Kod kalitesi ve sürdürülebilirlik | Kod yazma/değiştirme sonrası |
| security-reviewer | Güvenlik açığı tespiti | Commitlerden önce, hassas kod |
| build-error-resolver | Build/tip hatalarını düzeltme | Build başarısız olduğunda |
| e2e-runner | Uçtan uca Playwright testi | Kritik kullanıcı akışları |
| refactor-cleaner | Ölü kod temizleme | Kod bakımı |
| doc-updater | Dokümantasyon ve codemaps | Dokümanları güncelleme |
| docs-lookup | Dokümantasyon ve API referans araştırması | Kütüphane/API dokümantasyon soruları |
| cpp-reviewer | C++ kod incelemesi | C++ projeleri |
| cpp-build-resolver | C++ build hataları | C++ build başarısızlıkları |
| go-reviewer | Go kod incelemesi | Go projeleri |
| go-build-resolver | Go build hataları | Go build başarısızlıkları |
| kotlin-reviewer | Kotlin kod incelemesi | Kotlin/Android/KMP projeleri |
| kotlin-build-resolver | Kotlin/Gradle build hataları | Kotlin build başarısızlıkları |
| database-reviewer | PostgreSQL/Supabase uzmanı | Şema tasarımı, sorgu optimizasyonu |
| python-reviewer | Python kod incelemesi | Python projeleri |
| java-reviewer | Java ve Spring Boot kod incelemesi | Java/Spring Boot projeleri |
| java-build-resolver | Java/Maven/Gradle build hataları | Java build başarısızlıkları |
| chief-of-staff | İletişim önceliklendirme ve taslaklar | Çok kanallı email, Slack, LINE, Messenger |
| loop-operator | Otonom döngü yürütme | Döngüleri güvenli çalıştırma, takılmaları izleme, müdahale |
| harness-optimizer | Harness yapılandırma ayarlama | Güvenilirlik, maliyet, verimlilik |
| rust-reviewer | Rust kod incelemesi | Rust projeleri |
| rust-build-resolver | Rust build hataları | Rust build başarısızlıkları |
| pytorch-build-resolver | PyTorch runtime/CUDA/eğitim hataları | PyTorch build/eğitim başarısızlıkları |
| typescript-reviewer | TypeScript/JavaScript kod incelemesi | TypeScript/JavaScript projeleri |
## Agent Orkestrasyonu
Agentları kullanıcı istemi olmadan proaktif olarak kullanın:
- Karmaşık özellik istekleri → **planner**
- Yeni yazılan/değiştirilen kod → **code-reviewer**
- Hata düzeltme veya yeni özellik → **tdd-guide**
- Mimari karar → **architect**
- Güvenlik açısından hassas kod → **security-reviewer**
- Çok kanallı iletişim önceliklendirme → **chief-of-staff**
- Otonom döngüler / döngü izleme → **loop-operator**
- Harness yapılandırma güvenilirliği ve maliyeti → **harness-optimizer**
Bağımsız işlemler için paralel yürütme kullanın — birden fazla agenti aynı anda başlatın.
## Güvenlik Kuralları
**HERHANGİ BİR committen önce:**
- Sabit kodlanmış sırlar yok (API anahtarları, şifreler, tokenlar)
- Tüm kullanıcı girdileri doğrulanmış
- SQL injection koruması (parametreli sorgular)
- XSS koruması (sanitize edilmiş HTML)
- CSRF koruması etkin
- Kimlik doğrulama/yetkilendirme doğrulanmış
- Tüm endpointlerde hız sınırlama
- Hata mesajları hassas veri sızdırmıyor
**Sır yönetimi:** Sırları asla sabit kodlamayın. Ortam değişkenlerini veya bir sır yöneticisini kullanın. Başlangıçta gerekli sırları doğrulayın. İfşa edilen sırları hemen döndürün.
**Güvenlik sorunu bulunursa:** DUR → security-reviewer agentini kullan → KRİTİK sorunları düzelt → ifşa edilen sırları döndür → kod tabanını benzer sorunlar için incele.
## Kodlama Stili
**Değişmezlik (KRİTİK):** Her zaman yeni nesneler oluşturun, asla değiştirmeyin. Değişiklikler uygulanmış yeni kopyalar döndürün.
**Dosya organizasyonu:** Az sayıda büyük dosya yerine çok sayıda küçük dosya. Tipik 200-400 satır, maksimum 800. Tipe göre değil, özelliğe/alana göre düzenleyin. Yüksek bağlılık, düşük bağımlılık.
**Hata yönetimi:** Her seviyede hataları ele alın. UI kodunda kullanıcı dostu mesajlar sağlayın. Sunucu tarafında detaylı bağlamı loglayın. Hataları asla sessizce yutmayın.
**Girdi doğrulama:** Sistem sınırlarında tüm kullanıcı girdilerini doğrulayın. Şema tabanlı doğrulama kullanın. Net mesajlarla hızlı başarısız olun. Harici verilere asla güvenmeyin.
**Kod kalite kontrol listesi:**
- Fonksiyonlar küçük (<50 satır), dosyalar odaklı (<800 satır)
- Derin iç içe geçme yok (>4 seviye)
- Düzgün hata yönetimi, sabit kodlanmış değerler yok
- Okunabilir, iyi adlandırılmış tanımlayıcılar
## Test Gereksinimleri
**Minimum kapsama: %80**
Test tipleri (hepsi gereklidir):
1. **Unit testler** — Bireysel fonksiyonlar, yardımcı programlar, bileşenler
2. **Integration testler** — API endpointleri, veritabanı işlemleri
3. **E2E testler** — Kritik kullanıcı akışları
**TDD iş akışı (zorunlu):**
1. Önce test yaz (KIRMIZI) — test BAŞARISIZ olmalı
2. Minimal uygulama yaz (YEŞİL) — test BAŞARILI olmalı
3. Yeniden düzenle (İYİLEŞTİR) — %80+ kapsama doğrula
Başarısızlık sorunlarını giderin: test izolasyonunu kontrol edin → mocklarını doğrulayın → uygulamayı düzeltin (testleri değil, testler yanlış olmadıkça).
## Geliştirme İş Akışı
1. **Planlama** — Planner agentini kullanın, bağımlılıkları ve riskleri belirleyin, aşamalara bölün
2. **TDD** — tdd-guide agentini kullanın, önce testleri yazın, uygulayın, yeniden düzenleyin
3. **İnceleme** — code-reviewer agentini hemen kullanın, KRİTİK/YÜKSEK sorunları ele alın
4. **Bilgiyi doğru yerde yakalayın**
- Kişisel hata ayıklama notları, tercihler ve geçici bağlam → otomatik bellek
- Takım/proje bilgisi (mimari kararlar, API değişiklikleri, runbook'lar) → projenin mevcut doküman yapısı
- Mevcut görev zaten ilgili dokümanları veya kod yorumlarını üretiyorsa, aynı bilgiyi başka yerde çoğaltmayın
-ık bir proje doküman konumu yoksa, yeni bir üst düzey dosya oluşturmadan önce sorun
5. **Commit** — Conventional commits formatı, kapsamlı PR özetleri
## Git İş Akışı
**Commit formatı:** `<type>: <description>` — Tipler: feat, fix, refactor, docs, test, chore, perf, ci
**PR iş akışı:** Tam commit geçmişini analiz edin → kapsamlı özet taslağı oluşturun → test planı ekleyin → `-u` bayrağıyla pushlayın.
## Mimari Desenler
**API yanıt formatı:** Başarı göstergesi, veri yükü, hata mesajı ve sayfalandırma metadatası içeren tutarlı zarf.
**Repository deseni:** Veri erişimini standart arayüz arkasında kapsülleyin (findAll, findById, create, update, delete). İş mantığı depolama mekanizmasına değil, soyut arayüze bağlıdır.
**Skeleton projeleri:** Savaş testinden geçmiş şablonları arayın, paralel agentlarla değerlendirin (güvenlik, genişletilebilirlik, uygunluk), en iyi eşleşmeyi klonlayın, kanıtlanmış yapı içinde yineleyin.
## Performans
**Bağlam yönetimi:** Büyük yeniden düzenlemeler ve çok dosyalı özellikler için bağlam penceresinin son %20'sinden kaçının. Daha düşük hassasiyet gerektiren görevler (tekli düzenlemeler, dokümanlar, basit düzeltmeler) daha yüksek kullanımı tolere eder.
**Build sorun giderme:** build-error-resolver agentini kullanın → hataları analiz edin → artımlı olarak düzeltin → her düzeltmeden sonra doğrulayın.
## Proje Yapısı
```
agents/ — 28 özel subagent
skills/ — 115 iş akışı skillleri ve alan bilgisi
commands/ — 59 slash command
hooks/ — Tetikleyici tabanlı otomasyonlar
rules/ — Her zaman uyulması gereken kurallar (ortak + dile özel)
scripts/ — Platformlar arası Node.js yardımcı programları
mcp-configs/ — 14 MCP sunucu yapılandırması
tests/ — Test paketi
```
## Başarı Metrikleri
- Tüm testler %80+ kapsama ile geçer
- Güvenlik açığı yoktur
- Kod okunabilir ve sürdürülebilirdir
- Performans kabul edilebilirdir
- Kullanıcı gereksinimleri karşılanmıştır