Açık kaynak bir üründe senin adınla bir değişiklik.

Kimler için

• 2 saatte canlı uygulamayı bitirdiysen

  Aynı akışı bu sefer başkasının kodunda yürütüyorsun. Başarısız kalan bir testi gevşetmeyi ya da silmeyi rehber yasaklıyor, ajan sorunu ya çözer ya durup sana getirir. Henüz yapmadıysan önce 2 saatte canlı uygulama.

• Kod yazıyorsan ve ajanla çalışınca kontrolü kaybediyorsan

  Ajan hangi dosyaya dokunabileceğini repo'daki rehberden öğreniyor. Nerede durup sana sorduğunu izle.

• Analist ya da QA mühendisiysen

  Basamak 1 görevleri sana göre, çünkü hiçbirinde kod değişmez. Birinde bir dokümanı koda bakarak düzeltiyorsun, öbür ikisinde bir cümlenin doğru komutu tetikleyip tetiklemediğini ölçen bir eval case'i yazıyorsun.

Üç basamak

1. 01

   Basamak 1'de kod değişmiyor

   Bir dokümandaki yanlışı düzeltiyorsun ya da yeni bir eval case'i ekliyorsun. Yine de npm test koşuyor, çünkü testlerden biri README'deki komut tablosunu plugin'in gerçek komutlarıyla karşılaştırıyor.

   Görevler: #2, #3, #5 · Issue'daki tahmin: 30-45 dakika

2. 02

   Basamak 2'de güvenlik koduna dokunmayan küçük bir değişiklik

   Bir modüldeki hatayı düzeltiyorsun ya da bir komutun talimat metnini değiştiriyorsun. Rehberin trust boundary dediği modüller, yani secret tarayan ya da dışarı bir şey gönderenler, bu basamakta yasak. Kod değişecekse test değişiklikten önce yazılıyor ve kırmızı yanmalı.

   Rehberin dosya kuralına göre bu üç görevin dosyaları Basamak 3'te. Diff'e bakıp Basamak 2'ye koydum, çünkü değişen yer trust boundary'ye değmiyor. Bu not issue'larda da yazılı.

   Görevler: #4, #7, #9 · Issue'daki tahmin: 25-45 dakika

3. 03

   Basamak 3'te yeni bir özellik ya da güvenlik kodunda değişiklik

   Yeni bir komut ya da flag ekliyorsun, ya da Basamak 2'de yasak olan bir dosyayı değiştiriyorsun. İşe başlamadan ne yapılacağında anlaşmak gerekiyor ama bu dört issue'da o kısım hazır. Değişiklik SECURITY.md'deki bir sözü bozuyorsa SECURITY.md aynı PR'da güncelleniyor.

   Görevler: #6, #8, #10, #11 · Issue'daki tahmin: 40-110 dakika, en uzunu #10

On görev

• #2Basamak 1

  Tek bir dosyanın geçmişini soran sıradan bir Türkçe cümleyle yeni bir eval case'i yazıyorsun. Cümle /handbook:mine'ı tetiklememeli. Tetiklerse de o çıktı PR'a olduğu gibi giriyor.

• #3Basamak 1

  Oturumda yeni biten bir işin yapılışını sonraki sefer için saklamak /handbook:learn'ün işi, ama bu durumu ölçen bir case yok. O case'i öncesindeki konuşmayla birlikte ekliyorsun.

• #5Basamak 1

  SECURITY.md, /handbook:share'in neyi okuduğunu anlatırken iki yerde kodun gerisinde kalmış. Kod, MCP server'ın args alanını da tarıyor ve slash command klasörlerini de okuyor. Bu ikisini SECURITY.md'ye ekliyorsun.

• #4Basamak 2

  commands/review.md'nin giriş paragrafı ve tür listesi, git geçmişinden ve demodan gelen taslakları hiç anmıyor. Yalnız bu iki yeri düzeltiyorsun.

• #7Basamak 2

  Symlink ile eklenmiş slash command'lar paylaşım ekranında görünmüyor. Önce bunu yakalayan testi yazıp sonra listeleyen fonksiyonu symlink'i takip edecek hale getiriyorsun.

• #9Basamak 2

  Yolunda changelog geçen her dosya doküman sayıldığı için Liquibase migration'ları ölçümden düşüyor. İki regex'i yalnız gerçek changelog dosyasını yakalayacak kadar daraltıyorsun.

• #6Basamak 3

  İki farklı secret taşıyan bir MCP server reddedilirken ekran birinin türünü öbürünün yeriyle birlikte söylüyor. Tür ile yerin aynı secret'tan gelmesini sağlıyorsun.

• #8Basamak 3

  Review ekranı secret bulduğu dosyanın adını veriyor ama satırını vermiyor. Paylaşım ekranındaki gibi dosya:satır yazdırıyorsun.

• #10Basamak 3

  Skill taslağının doğrulama bölümü repo'nun kendi test komutunu bilmiyor. Repo'daki build dosyalarına bakıp test komutunu çıkaran ve onu modele giden bilgiye ekleyen kodu yazıyorsun. SECURITY.md'ye de bunu söyleyen bir cümle giriyor.

• #11Basamak 3

  Kaynak projesi silinmiş bir ders adayı, review hangi klasörden koşulduysa o projeye yazılıyor. Bu durumda eklemeyi reddeden kontrolü yazıyorsun.

Görevleri GitHub'da aç

Başlamadan önce

• GitHub hesabı

  TeamHandbook'u kendi hesabına fork'layıp değişikliği oraya gönderiyorsun. PR oradan açılıyor.

• git'te adın ve e-postan tanımlı

  git config user.name ve git config user.email boş dönmemeli, çünkü bazı testler gerçekten commit atıyor. İkisi boşsa altı test dosyası birden kırmızı yanıyor.

• Node 22 ya da üstü ve npm

  npm Node'la birlikte geliyor.

• GitHub CLI (gh)

  Ajan branch'i fork'una gönderip PR'ı bununla açıyor ama ikisinden önce sana soruyor. Kurduktan sonra terminalde gh auth login yaz.

• Claude Code

  Kurulu ve giriş yapılmış olmalı. Ücretini senin ödediğin bir Claude aboneliği ya da Anthropic API key'i gerekiyor. Basamak 1'de eval case'ini bir kez koşmak bir dolardan az tutuyor ve ajan koşmadan önce onayını istiyor.

Fork'unu klonladığın klasörde bu dört komutu sırayla koş. Ortamın hazır olup olmadığını son satırlar söylüyor.

1. npm install

   Sonunda 4 vulnerabilities (2 moderate, 2 critical) gibi bir audit özeti çıkıyor. Ona dokunma ve npm audit fix koşturma, çünkü sabitlenmiş versiyonları değiştiriyor.

2. npm run build

   Build çıktısını dist/'e yazıyor. Ardından git status --porcelain boş dönmeli.

3. npm run typecheck

   Hata yoksa yalnız > tsc --noEmit satırı çıkıyor.

4. npm test

   En uzun süren komut bu. Özette Test Files N passed (N) ve Tests N passed (N) çıkmalı. failed hiçbir yerde geçmiyorsa ortam hazır.

Issue'dan merge'e

Adım adım

1. 01

   Repo'yu fork'la ve kur

   TeamHandbook'un GitHub sayfasında Fork'a bas. Fork'unu klonladıktan sonra klasörde yukarıdaki dört komutu sırayla koş. npm test altı dosyada birden kırmızı yanarsa başka bir şeye dokunmadan git config ayarına bak.

   Ekranda npm test özetinde Test Files N passed (N).

2. 02

   Ajana görevi ver

   Klasörde claude yaz ve ilk cümlen "AI_CONTRIBUTING.md'yi oku, sonra #5'i yap" olsun. Numarayı kendi görevinle değiştir. Repo'da arama yaparken evals/tutma/ klasörünü dışarıda bırakmasını söyle, çünkü eval suite'inin saklı yarısı orada ve okunduktan sonra geri alınamıyor.

   Ekranda ajanın sırayla açtığı dosyalar, ardından açtığı branch.

3. 03

   Önce hatayı gör

   Kod değişiyorsa ajan önce testi yazıp koşuyor ve test kırmızı yanıyor. #7'de bu komut npx vitest run src/lib/commands.test.ts -t "symbolic link". #4 ve #5'te kod değişmediği için issue'daki grep bugün eski cümleyi buluyor ve değişiklikten sonra boş dönmeli.

   Ekranda kırmızı test satırı ya da bugünkü satırı gösteren grep çıktısı.

4. 04

   Ajan değişikliği yapıyor

   src/ değiştiyse ajan npm run build koşup yeni dist/'i de commit'e koyuyor. Ardından npm test ve npm run typecheck koşuyor. Tek hata Timeout calling "onTaskUpdate" olursa makine meşgul demektir ve biraz bekleyip tekrar koşman yeterli.

   Ekranda Tests N passed (N) ile biten ve failed geçmeyen bir özet.

5. 05

   PR'ı ajan açıyor

   Branch'i fork'una göndermeden ve PR'ı açmadan önce sana soruyor. Doğrulama çıktısını kendi gözünle görmeden ona PR açtırma. Commit mesajı da PR açıklaması da İngilizce.

   Ekranda PR açıklamasının sonunda "Agent-assisted contribution (optional)" başlıklı üç satır.

6. 06

   Review ve mergeben basarım

   PR'ını ben okuyorum. Fork'tan gelen ilk PR'da CI'ın her koşusunu benim onaylamam gerekiyor, o yüzden kontroller bir süre boş görünürse bekle. Bir şey istersem PR'a yazıyorum ve ajan düzeltmeyi senin onayınla aynı branch'e gönderiyor.

   Ekranda önce boş, sonra yeşil kontroller, en sonda PR'ın üstünde "Merged".

Paylaşacağın link

PR merge edilince linkini buraya yapıştır.

Bundan sonra

• TeamHandbook'u kendi ekibinde kur

  Katkı verdiğin plugin'i kendi Claude Code'una kur ve sorduğunda user scope'u seç. Ekibinin skill repo'sunu /handbook:init ile aç.

  TeamHandbook
• Ekibin için bir oturum

  Ekibinin aynı akışı kendi kodunda denemesini istiyorsan Birlikte çalışalım sayfasına geç.

  Birlikte çalışalım