5a2453e167
* feat: add council-multi-model skill (heterogeneous Codex review) Rebased onto latest main to resolve the merge conflict (the branch had gone DIRTY as main advanced). Trimmed to just the skill files (no top-level README/AGENTS edits), mirroring the merged #2381. Previously reviewed favorably by greptile/coderabbit/daltino. * feat: add Entry B (independent parallel propose + aggregate, MoA-style) alongside Entry A (review) Splits the skill into two entries depending on what already exists: Entry A (unchanged) reviews an existing draft. New Entry B has every voice (Claude x3 + Codex if available) answer the same question fully independently and in parallel, then aggregates without collapsing disagreement or blending incompatible approaches into one hybrid. For the heaviest decisions the two chain: B first, then A's review step on the aggregation -- with an explicit honesty caveat when Codex already proposed in B and so cannot independently judge the result. * feat: prefer Codex MCP tool over the SDK script when available mcp__codex__codex is now the primary path for both Entry A's heterogeneous review and Entry B's independent proposal -- zero relay, talks directly to OpenAI's backend, no temp file or shell escaping needed. The openai-codex SDK script becomes the fallback for sessions without that MCP tool configured; behavior and guardrails (read-only, verbatim quoting, explicit 'absent' labeling) are unchanged. * fix: register council-multi-model install path * docs: sync skill catalog count * fix: publish council-multi-model skill * fix: harden council multi-model fallback * docs: sync remaining skill count * fix: narrow multi-model council to bounded review * fix: address council adapter review feedback * fix(council-multi-model): enforce tool-less Codex review * fix(council-multi-model): close Codex tool boundary --------- Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
8.9 KiB
Everything Claude Code (ECC) — Agent Talimatları
Bu, yazılım geliştirme için 68 özel agent, 287 skill, 94 command ve otomatik hook iş akışları sağlayan üretime hazır bir AI kodlama eklentisidir.
Sürüm: 2.2.0
Temel İlkeler
- Agent-Öncelikli — Alan görevleri için özel agentlara delege edin
- Test-Odaklı — Uygulamadan önce testler yazın, %80+ kapsama gereklidir
- Güvenlik-Öncelikli — Güvenlikten asla taviz vermeyin; tüm girdileri doğrulayın
- Değişmezlik — Her zaman yeni nesneler oluşturun, mevcut olanları asla değiştirmeyin
- Ç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):
- Unit testler — Bireysel fonksiyonlar, yardımcı programlar, bileşenler
- Integration testler — API endpointleri, veritabanı işlemleri
- E2E testler — Kritik kullanıcı akışları
TDD iş akışı (zorunlu):
- Önce test yaz (KIRMIZI) — test BAŞARISIZ olmalı
- Minimal uygulama yaz (YEŞİL) — test BAŞARILI olmalı
- 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ışı
- Planlama — Planner agentini kullanın, bağımlılıkları ve riskleri belirleyin, aşamalara bölün
- TDD — tdd-guide agentini kullanın, önce testleri yazın, uygulayın, yeniden düzenleyin
- İnceleme — code-reviewer agentini hemen kullanın, KRİTİK/YÜKSEK sorunları ele alın
- 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
- Açık bir proje doküman konumu yoksa, yeni bir üst düzey dosya oluşturmadan önce sorun
- 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/ — 68 özel subagent
skills/ — 287 iş akışı skillleri ve alan bilgisi
commands/ — 94 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