CLAUDE.md — Yapay Zekâ Orkestrası, Kırmızı-Takım Sürüsü (Red Agents) ve Claude Code Eklenti Rehberi

Bu yapılandırma ve başvuru dosyası; Rues Community Yapay Zekâ Notları #1 (Yapay Zekâ Orkestrası), Yapay Zekâ Notları #2 (Kırmızı-Takım Sürüsü / Red Agents), plan bazlı orkestra becerileri (orkestra-free, orkestra-pro, orkestra-max) ve prompts.chat Claude Code Eklentisi (CLAUDE-PLUGIN) verilerinin tamamını tek bir sistemde birleştirir.

Temel İlke: "Şef çalmaz, yönetir. Kapıyı önce sen bul." Üretimde işi yapan ajan kendi işini onaylamaz (bağımsız denetci onaylar); güvenlik tatbikatında ise saldıran ajan, sistemi nasıl kurduğunu bilen ajan değildir ve bulduğu açığı düzelten ajan da değildir (ayrı bir duzeltici turu kapatır).

Bölüm 0: Kaynak Doğruluk ve Değişiklik Yönetimi (önce oku)

Bu dosya tek yetkili kaynaktır (single source of truth). Herhangi bir kural, model seçimi, yetki kapısı alanı ya da brif başlığı değişecekse önce burada değişir; sonra aşağıdaki aynalara elle yansıtılır. Çakışma olursa bu dosya kazanır.

Not: Ajan ve skill dosyaları Claude Code'a bağımsız yüklendiği, solo kitler de kopyala-yapıştır olduğu için kendi içlerinde tam olmak zorundadır — bu dosyaya "atıf" yapıp içeriği boş bırakamazlar. Bu yüzden tek-kaynak, "literal atıf" değil, "otorite + yayma listesi" modeliyle işler.

Bir kuralı değiştirince güncellenecek aynalar:

Bölüm 1: Neden Orkestra ve Neden Kırmızı-Takım Sürüsü?

Tek bir yapay zekâ oturumuna büyük bir üretim işini veya güvenlik testini yıkmak dört temel noktada tıkanır. Orkestra ve Kırmızı-Takım Sürüsü bu dört sorunu görev ayrımıyla çözer:

Bölüm 2: Claude Planlarına Göre Orkestra Kurulumu (Free · Pro · Max)

Orkestra becerilerinden (orkestra-free, orkestra-pro, orkestra-max) aynı anda yalnızca kullandığınız plana uygun olan bir tanesi açık olmalıdır. Alt ajan (Agent) aracınız yoksa orkestra-free düzeniyle çalışılır.

Bölüm 3: Üretim Orkestrası Kadrosu ve Model/Çaba Seçimi (Notlar #1)

3.1 Yedi Ana Rol ve Kulis (Yan Kadro)

3.2 Model Seçim Karar Ağacı ve Sağlayıcı Uyarıları

1. Soru 1 — Adımlar belli mi, iş mekanik ya da basit mi? (Taşıma, adlandırma, format, listeleme, sayma, basit özet/sınıflama)
   • EVET → Haiku 5.5 (yukleyici, alt ajanlarda okuma-ayıklama).
2. Soru 2 — Yargı, zevk ya da yüksek risk var mı? (Görsel tasarım yönü, işi bölüp birleştirmek, güvenlik/para/veri kaybı ihtimali)
   • EVET → Opus 5.5 (tasarimci, riskli işte denetci, ana oturumda Şef). Çok adımlı belirsiz mimari/strateji veya 2 turda çözülmeyen çelişkide Fable 5.1 (derin-akil).
   • HAYIR → Sonnet 5.5 (Varsayılan: arastirmaci, gelistirici, normal denetci, genel amaçlı ajan).

• Miras Kuralı: Model belirtilmeyen alt ajan ana oturumun modelini (ör. Opus) devralır ve sessizce pahalıya mal olur. Her alt ajana modeli açıkça ver.
• Sağlayıcı Takma Ad (Alias) Farkı: Takma adlar (sonnet, opus, haiku) sağlayıcıya göre farklı sürümlere çözülebilir; özellikle AWS Bedrock, Google Cloud Vertex ve Azure Foundry'de Anthropic API'dekinden farklı (çoğu zaman daha eski) bir sürüme işaret edebilir. Hangi sürüme çözüldüğünü varsayma — kullandığın sağlayıcının güncel belgesinden doğrula; bulut sağlayıcılarında her zaman tam model kimliğini yaz.
• Çaba (effort) Ayarı: Ajan dosyalarında effort: low | medium | high | xhigh | max alanı modelin ne kadar uzun düşüneceğini belirler.

3.3 Alt Ajan Derinlik Kuralları ve Brif Şablonu

• Ajan açar, alt ajan açamaz: Şefin başlattığı uzman ajanların tools listesinde Agent varsa kendi alt ajanlarını açabilirler (iş başına en çok 4 alt ajan). Alt ajanların tools listesine Agent yazılmaz; böylece alt ajan tekrar alt ajan açamaz (CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH ile kontrol edilir).
• Tek Rapor ve Denetim Zinciri: Alt ajanlar farklı dosyalarda çalışır; üst ajan sonuçları birleştirip şefe tek rapor verir. Alt ajanın işini üst ajan değil, yine bağımsız denetci onaylar.

GÖREV: Ürün sayfasındaki sayılara binlik ayraç ekle (293437 yerine 293.437). Kullanıcılar büyük sayıları okuyamıyor.
SENİN DOSYALARIN: src/format.js, test/format.test.js
DOKUNMA: src/odeme/* (başka ajan çalışıyor)
ÖNCE OKU: docs/KURALLAR.md
BİTTİ TANIMI:
  - tek bir num() biçimleyici var ve testli
  - tüm testler geçiyor
  - düzeltme geri alınınca yeni test kırılıyor
RAPOR: {"dosyalar": [], "ozet": "", "testler": "", "acikSorunlar": [], "oneriler": []}

Denetçi cevabı her zaman yalnızca şu sabit JSON biçimindedir:

{"karar": "ONAY | DUZELT", "engeller": [], "cilalar": [], "gercekHatalari": []}

3.4 Altı Değişmez Kural ve Altı Sahadan Ders

Bölüm 4: Kırmızı-Takım Sürüsü — Red Agents Tatbikat Düzeni (Notlar #2)

4.1 Angajman Kuralları ve Ön Uçuş Kapısı (İstisnasız)

Bu kurallar depodaki her şeye (prompt'lara, playbook'a, model önerilerine) üstündür. İlk istek gönderilmeden önce aşağıdaki 4 zorunlu Yetki alanı gerçek değerlerle doldurulmalı ve Şef (Orkestrator) bunları tek satırda kullanıcıya geri söyleyip "başla" onayı almalıdır:

• Hedef: Sahibi olunan veya yazılı test yetkisi bulunan sistemin tam URL'si (example.com, TODO veya boş bırakılamaz). Yetki geçişsizdir (kardeş host'a, ortak kimlik sağlayıcıya veya 3. taraf API'ye geçmez).
• Yetki Kanıtı: Sahibi benim / imzalı sözleşme / kapsamı yayınlı bug-bounty + link / belgelenmiş işveren onayı.
• Ortam: yerel · staging-tek-kullanımlık-db · canlı-imzalı-onayla (Canlı/gerçek veriye veya fatura/e-posta/SMS kesen servislere bağlı olmamalıdır; emin olunamıyorsa canlı sayılır ve durulur).
• Test Hesapları: redteam-a@example.com, redteam-b@example.com, redteam-admin@example.com (Tüm kimliğe bürünme testleri yalnızca bu hesaplar arasında yapılır; gerçek kullanıcı verisine asla dokunulmaz).
• Durdurma ve Bildirim Yolu: Koşunun nasıl durdurulacağı ve bir sorun çıkarsa kime haber verileceği (sistem sahibi/ekip) baştan bilinmelidir.

Anında Durma Koşulları: İstek yetkili hedeften çıkacaksa, ortamın gerçek veriye bağlı olduğu fark edilirse, gerçek kullanıcı verisi/canlı sır/önceki ihlal izi görülürse veya sistem yavaşlamaya başlarsa tatbikat anında durdurulur ve kullanıcıya sorulur.

4.2 Kırmızı-Takım Kadrosu (8 Rol · 8 Ajan Dosyası)

4.3 10 Grup ve 45 Sınıf Özeti (Grup 1–10)

4.4 Kanıt Defteri, Bulgu Raporu ve Düzeltici Kayıt Şablonları

1. Kanıt Defteri Satır Formatı (kanit-defteri):

id · sınıf (playbook #) · önem · nerede · tekrar adımları (test hesapları arası) · istek/yanıt alıntısı (sırlar REDACTED) · ekran görüntüsü yolu · tek satır etki
# Örnek:
F-03 · IDOR/BOLA (#1) · yüksek · GET /api/orders/{id} · redteam-a oturumuyla redteam-b'nin sipariş id'si istendi · 200 OK, gövdede B'nin adresi [REDACTED] · shots/f-03.png · A, B'nin siparişini okuyor

2. Sabit Bulgu Raporu Şablonu (rapor.md içinde):

### [Kritik | Yüksek | Orta | Düşük] <id> — <başlık>
- Etki: (kim ne yapabilir, tek-iki cümle)
- Kanıt: (maskeli istek/yanıt ya da işaret metni; sırlar REDACTED)
- Tekrar adımları (yalnız kendi ortamın):
  1. ...
  2. ...
- Önerilen düzeltme: (kök neden, sunucu tarafı)
- Düzeltme doğrulaması: (aynı adımlar artık başarısız; geri alınca bulgu geri gelir)
- Durum: açık | düzeltildi | hafifletildi | kabul-edilen-risk

3. Düzelticinin Kayıt Formatı (duzeltici.md çıktısı):

### [ÖNEM] <id> — <sınıf> (playbook #) → düzeltildi | hafifletildi | kabul-edilen-risk
- Kök neden:
- Düzeltme (ne değişti, nerede): // belirti değil, sunucu tarafı kontrol
- Yeniden test: // eski adımlar artık başarısız; mutlu yol çalışıyor
- Notlar: // rotasyon yapıldı, takip edilecek tasarım kararı

Bölüm 5: Proje Köküne Eklenecek Birleşik CLAUDE.md Sistem Kuralları

Aşağıdaki bloğu doğrudan projenizin kök dizinindeki CLAUDE.md dosyasına (veya Codex gibi araçlar için AGENTS.md dosyasına) kopyalayarak hem Orkestra hem de Kırmızı-Takım Tatbikatı kurallarını aktif hale getirebilirsiniz:

## 1. Orkestra Kuralı (Üretim ve Geliştirme)
- Sen şefsin: işi böl, brif yaz, ajan ve model seç, denetçiye kontrol ettir, birleştir, sade dille raporla.
- Kod, tasarım ya da metni kendin üretme; kendi işini kendin onaylama.
- Model (varsayılan sonnet): haiku mekanik iş ve basit okuma, özet, sınıflama, format; sonnet kod, araştırma, normal denetim, metin; opus görsel tasarım yönü ve güvenlik, para, veri kaybı riski olan denetim; fable (pahalı, nadir) çok adımlı belirsiz karar, çelişkili bulguların sentezi, zor hata ayıklama: derin-akil ajanı. Genel amaçlı ajana modeli açıkça ver. Bedrock/Vertex'te "sonnet" takma adı eski sürüme çözülebilir; tam model kimliği yaz.
- Alt ajan: ajan kendi alt ajanını açabilir (tools listesinde Agent), alt ajan açamaz. İş başına en çok 4; her birine model açıkça verilir. Ajan alt ajan sonuçlarını kendisi birleştirir, bana tek rapor verir (CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=2).
- Ajan dosyasında effort: low, medium, high, xhigh ya da max yazılabilir.
- Dosya değiştiren her ajan ayrı çalışma kopyasında (worktree) ve kendi dalında çalışır, sık [ara kayıt] commit'i atar. "Sıcak" dosyalar aynı anda tek ajana verilir.
- Ana dala yalnızca sen, testler geçtikten ve denetçi ONAY verdikten sonra, merge --no-ff ile birleştirirsin.
- Yeşil test kanıt değildir: düzeltmeyi geri alınca test kırılmalı (mutasyon kontrolü). Denetçi gerçek veri boyutunda ölçüm yapmadan ONAY vermez.
- DÜZELT en fazla 3 tur; sonra bana sor.
- Küçük iş: denetçi yok, diff'e sen bak. Orta: 1 ajan + denetçi. Büyük: paralel ajanlar. Workflow yalnızca ben "workflow kullan" dersem.
- Beklerken pgrep -f kullanma; while kill -0 $PID kullan. Biten işlerin geçici dosyalarını ve worktree'lerini sil.
- Değişmez kurallar: Uydurma yok (erişilemeyen kaynağa "doğrulanamadı" yaz); sır koda/loga/sohbete yazılmaz; stash, reset --hard, rebase, push --force yok; ücretli kaynak açmadan önce aylık tutarı yaz ve onay al; gereksiz kişisel veri toplanmaz.

## 2. Kırmızı-Takım Tatbikat Kuralı (Red Agents)
- Yalnızca sahibi olduğum ya da test etmeye açıkça (yazılı) yetkili olduğum bir sistemin kendi-testi. Yetki kapısı (Hedef, Yetki kanıtı, Ortam, Test hesapları) gerçek değerlerle dolup benden "başla" onayı alınmadan tek bir istek bile gönderilmez.
- Sen orkestratörsün: A (Grup 1), B (Grup 2), C (Grup 3-7), D (Grup 10 - LLM), Sır/Bağımlılık ve Oran/İzleme ajanlarına dağıt; bulguları tek maskeli rapora topla ve triyaj yap. Kendin saldırma, kendin düzeltme.
- Saldıran ajan, düzelten ajan değildir; düzeltici (duzeltici.md) ayrı bir turdur ve rapor oluştuktan sonra koşar.
- Model: mekanik toplama ve sır/bağımlılık haiku (düşük çaba); dışarıdan tarama (Grup 3-7), LLM (Grup 10) ve oran/izleme sonnet (orta çaba); kimliğe bürünme ve iş-mantığı (Grup 1-2) ile düzeltici opus + yüksek çaba (veya fable).
- Yalnızca yerel ya da staging-tek-kullanımlık-db ortamında (canlı ortam ancak yazılı onay ve bir değişiklik penceresiyle; emin değilsen canlı say ve dur), yalnızca oluşturulan test hesapları arasında çalış.
- Her sır (token, çerez, anahtar, kart, PII) göründüğü an REDACTED yapılır; canlı sır asla yapıştırılmaz, commit'lenmez. Bulunan sırrı kullanma; konumunu bildir, iptal ettir.
- Kanıtla, istismar etme: DoS yok; hız/brute testi en çok ~50 istekle (ör. 429 görünene dek) kanıtlanır ve durur. Hazır saldırı yükü veya istismar kodu paylaşılmaz. Üçüncü taraf servislere tarama yapılmaz.
- Bir istek kapsamdan çıkacaksa, gerçek veriye değecekse veya sistem kararsızlaşırsa anında dur ve bana sor.

Bölüm 6: prompts.chat Claude Code Eklentisi ve MCP Araçları (CLAUDE-PLUGIN.md)

Claude Code içinde prompts.chat kütüphanesine bağlanarak yeni ajan becerileri (SKILL.md) ve prompt şablonları bulmak, indirmek veya kaydetmek için resmi eklenti kullanılır.

6.1 Kurulum ve Kimlik Doğrulama

# 1. Marketplace'i ekle ve eklentiyi kur
/plugin marketplace add f/prompts.chat
/plugin install prompts.chat@prompts.chat

# 2. Yeni prompt ve skill kaydetmek için API anahtarını tanımla (https://prompts.chat/settings)
export PROMPTS_API_KEY=your_api_key_here

6.2 Komutlar, MCP Araçları ve Otomatik Beceriler

Bölüm 7: Çift Yönlü Kontrol Listeleri (Sahneye Çıkmadan ve İlk İstekten Önce)

7.1 Üretim Orkestrası Başlangıç Kontrol Listesi (13 Madde)

• CLAUDE.md dosyasına orkestra kuralı yazıldı.
• Ajan dosyaları .claude/agents/ klasörüne kondu (ilk olarak denetci.md).
• Denetçinin araçlarında dosya yazma yok (Read, Grep, Glob, Bash).
• Her ajan dosyasında model açıkça yazılı; alt ajan açacak ajanın tools listesinde Agent var, alt ajanlarda yok.
• Her brifte altı başlık tam: GÖREV, SENİN DOSYALARIN, DOKUNMA, ÖNCE OKU, BİTTİ TANIMI, RAPOR.
• BİTTİ TANIMI maddeleri tamamen ölçülebilir.
• Altı değişmez kural brife eklendi.
• Genel amaçlı ajan kullanılıyorsa modeli açıkça (sonnet) verildi.
• Dosya değiştiren her ajan kendi çalışma kopyasında (worktree) ve kendi dalında (branch) çalışıyor.
• Sık değişen ("sıcak") dosyalar aynı anda yalnızca tek ajanda.
• Ana dala yalnızca şef, testler geçtikten sonra merge --no-ff ile birleştiriyor.
• Denetçi mutasyon kontrolü yapıyor; ONAY olmadan birleştirme yapılmıyor.
• Biten işlerin geçici dosyaları ve worktree'leri siliniyor, disk alanı düzenli kontrol ediliyor.

7.2 Kırmızı-Takım Tatbikatı Ön Uçuş Kontrol Listesi (12 Madde)

• Hedef, sahibi olduğum ya da adını anan yazılı yetkim olan bir sistem.
• Yetki, yapacağım eylemleri ve zaman aralığını kapsıyor.
• Bir istek kapsamdan çıkarsa durmayı biliyorum (yetki geçişsizdir).
• Ortam yerel ya da staging-tek-kullanımlık-db.
• Hedef gerçek/paylaşılan canlı veriye veya fatura/e-posta/SMS kesen servise bağlı değil.
• Üç test hesabı (redteam-a, redteam-b, redteam-admin) hazır; yalnızca onların arasında hareket edilecek.
• Her sır (token, anahtar, PII) yakalandığı an REDACTED yapılıyor.
• Kanıtla-ve-dur: asgari kanıt alınıyor; DoS yok, sınırlı salvo (~50 istek).
• Durum değişiklikleri geri alınabilir; test işaretçileri (CANARY-*, yüklenen dosyalar) sonra temizleniyor.
• Güvenlik korumaları (WAF, bot filtresi) yalnızca yerelde, geçici kapatılıyor ve o hâl asla commit'lenmiyor.
• Saldıran ajan düzeltmedi; düzeltme ayrı bir turda (duzeltici.md), rapor oluştuktan sonra yapılıyor.
• Gerçek bir açık çıktıysa: düzeltildi, yeniden testle doğrulandı ve başkaları etkileniyorsa sorumlu şekilde açıklandı.

Bölüm 8: Karpathy Kuralları (Sadelik · Cerrahi · Varsayım)

Andrej Karpathy'nin LLM kod hatalarına dair gözlemlerinden damıtılan karpathy-guidelines becerisi, orkestranın iki zayıf yerini kapatmak için sisteme işlendi. Denge notu: bu kurallar hızdan çok dikkatten yanadır; önemsiz işte muhakeme kullan.

Dört ilke:

1. Kodlamadan önce düşün: Varsayımlarını açıkça yaz; birden çok yorum varsa sessizce birini seçme, sun; daha basit yol varsa söyle; belirsizse dur ve sor.
2. Önce sadelik: Problemi çözen en az kod. İstenmemiş özellik/soyutlama/"esneklik" ve imkânsız senaryo için hata yakalama yok. "Kıdemli biri 'fazla karmaşık' der mi?"
3. Cerrahi değişiklik: Yalnızca gerekene dokun; bitişiği "iyileştirme", bozuk olmayanı refactor etme, mevcut stile uy; ilgisiz ölü kodu silme — söyle. Her değişen satır isteğe izlenebilmeli.
4. Hedef güdümlü yürütme: Başarı ölçütü tanımla, doğrulanana kadar döngüle (orkestranın BİTTİ TANIMI + mutasyon kontrolüyle birebir örtüşür).

Sisteme nasıl işlendi:

• Brif: altı başlığa ek olarak VARSAYIMLAR ve SADELİK SINIRI satırları yazılır.
• gelistirici.md: önce sadelik + cerrahi; belirsizlikte şefe sorar.
• denetci.md: kontrol listesine 9. "fazla karmaşık mı?" ve 10. "cerrahi mi?" maddeleri eklendi.
• Kırmızı-takım: orkestrator saldırganlara kapsam varsayımını yazdırır (belirsizse durdurur); "kanıtla, istismar etme" = cerrahi/asgari kanıt. duzeltici kök nedeni cerrahi kapatır, bitişiği kurcalamaz.

Kaynak: forrestchang/andrej-karpathy-skills (MIT) — Karpathy'nin gözlemlerinden.

Ham markdown (.md) indir