Forge: Karar Vermeden Koda Geçmeyi Durduran Pipeline

Problem: Skill’ler Çalışıyor, Hafıza Çalışmıyor

Claude Code ile çalışırken her skill kendi işini iyi yapıyor. /court kararları değerlendiriyor, /review kodu inceliyor, /plan yapı çıkarıyor. Ama aralarında bağlantı yok.

Bir karar verdim, iki hafta sonra aynı konuya döndüğümde neden o kararı verdiğimi hatırlamıyorum. Critique’te bulunan bir sorun, üç özellik sonra aynı pattern’de tekrar karşıma çıkıyor. Sprint sonunda neyin işe yaradığını, neyin yaramadığını not almadığım için aynı hataları tekrarlıyorum.

Sorun skill’lerde değil. Sorun skill’lerin oturum bazlı çalışmasında. Bir oturum bitiyor, context kayboluyor, sonraki oturum sıfırdan başlıyor. Diğer yandan, session temelinde yanlış bir bağlam üzerinden de ilerlenmiş olabilir.

Sonuç: Bir Feature’ın Pipeline’dan Geçişi

Teknik detaylara girmeden önce, Forge ile bir feature’ın nasıl ilerlediğini göstermek istiyorum. Diyelim ki yeni bir ödeme entegrasyonu eklemem gerekiyor.

İlk adım pipeline’ın dışında: plan modu ve interactive mode ile bir spec oluşturuyorum. Ne yapılacak, neden yapılacak, kısıtlar ne, hangi dosyalar etkilenecek. Bu spec pipeline’ın girdisi oluyor.

0. Spec hazırlığı (pipeline öncesi)
   -> Plan mode + interactive mode ile spec oluşturuldu
   -> Ne, neden, kısıtlar, etkilenen dosyalar tanımlandı

1. /court paddle-recurring-billing
   Spec'i Gemini, Kimi ve Claude'a gönderdim
   -> Üç farklı perspektiften değerlendirme
   -> Verdict: GO (7.2/10)
   -> forge/decisions/2026-03-05_paddle-recurring-billing.md yazıldı

2. /implement paddle-recurring-billing
   -> Court GO'sunu ve spec'i hafızadan doğruladı
   -> Execution plan yazdı, onayımı bekledi
   -> Worktree'de geliştirdi, test'leri çalıştırdı
   -> forge/active/paddle-recurring-billing_implement.md yazıldı

3. /critique
   -> Git diff'i okudu (implementer'ın self-assessment'ını değil)
   -> 3 MUST_FIX, 2 NICE_TO_HAVE buldu
   -> Verdict: REJECTED
   -> forge/active/paddle-recurring-billing_critique.md yazıldı

4. /implement (tekrar, critique feedback'i ile)
   -> MUST_FIX'leri çözdü
   -> Yeni critique: PASS

5. /retro paddle-recurring-billing
   -> "Paddle webhook signature doğrulaması her zaman ilk adım olmalı"
      pattern'ini core-rules/workflow.md'ye yazdı
   -> Mevcut kurallarla çelişki kontrolü yaptı
   -> Active notları archive'a taşıdı

Her adım önceki adımların çıktısını hafızadan okudu. Hiçbir skill sıfırdan başlamadı. Retro’da çıkan pattern, gelecekteki her Paddle implementasyonunda critique tarafından kontrol edilecek.

Neden Yeni Bir Şey

Bu sorunu çözmenin mevcut yolları var. Ama her birinin benim geliştirme akışımda bir sınırı var.

Enterprise SDLC Araçları

Jira, Linear, Notion workflow’ları. Takım bazlı tasarlanmış, solo geliştirici için overhead’i yüksek. Ticket açmak, board yönetmek, status güncellemek gibi işler tek kişide değer üretmek yerine sürtünme yaratıyor. Zaten Obsidian temelinde çalışan bir bilgi yönetim sistemim var, üstüne ayrı bir proje yönetim aracı eklemek iki farklı kaynak arasında senkronizasyon yükü demek. Ancak, elbette MCP ile kolay bir şekilde dahil edilebilir.

Multi-Agent Sistemleri

Birden fazla agent’ın birbirini tetiklediği otonom sistemler. Teoride güçlü ama solo bağlamda iki sorun var: kontrol kaybı ve debug zorluğu. Bir agent hatalı çıktı ürettiğinde diğer agent’lar bunu girdi olarak kullanıyor, hata zinciri oluşuyor. Tek kişi bu zinciri izleyip düzeltmekte zorlanabilir.

Manuel Not Tutma

Her kararı, her review’u elle not almak. İşe yarıyor ama disiplin gerektiriyor ve yapısal değil. Notlar arasında bağlantı kurmak, çelişkileri tespit etmek, eskimiş bilgiyi temizlemek manuel süreçler. Zamanla not yığını büyüyor ama kullanılabilirliği düşüyor. Elbette remote çalışırken sürekli not taşımak ve notları güncel tutabilmek de bir noktadan sonra oldukça efor gerektirebiliyor.

Yaklaşım	Güçlü Yön	Zayıf Yön (solo bağlam)
Enterprise SDLC	Yapısal, izlenebilir	Tek kişi için overhead
Multi-agent	Otonom, paralel	Kontrol kaybı, debug zorluğu
Manuel notlar	Basit, sıfır bağımlılık	Yapısal değil, bakımı zor
Forge	Yapısal, hafızalı, human-in-the-loop	Claude Code bağımlılığı

Tercih: Dört Skill, Ortak Hafıza, Human-in-the-Loop

Forge’un tasarım prensipleri:

• Human-in-the-loop. Her adımı ben tetikliyorum. Skill’ler birbirini çağırmaz, dinamik yönlendirme yok. Tahmin edilebilirlik, akıllılıktan önce gelir.
• Hafıza, handoff’un yerini alır. Skill’ler birbirine context geçirmiyor. Ortak bir Obsidian vault’una yazıyor ve okuyor. Herhangi bir skill, herhangi bir önceki karara erişebiliyor.
• Adversarial review zorunlu. Critique “her şey iyi görünüyor” diyemez. Minimum bulgu sayısı yapısal olarak zorlanıyor.
• Retro hafızayı budayıyor. Bilgi tabanı sonsuza kadar büyümüyor. Kalıcı pattern’ler çıkarılıyor, geri kalan arşivleniyor.
• Sıralı, paralel değil. Solo bağlam. Bir anda bir skill, tam dikkat, bölünmüş context maliyeti yok.

Pipeline

Spec hazırlığı pipeline’ın dışında yapılır. Plan modu ve interactive mode ile ne yapılacağı, neden yapılacağı ve kısıtlar tanımlanır. Ortaya çıkan spec, court’un girdisi olur.

spec (pipeline öncesi, plan + interactive mode)
  -> court (değerlendir)
    -> implement (geliştir)
      -> critique (sorgula)
        -> retro (konsolide et)
          -> court (sonraki karar...)

Critique REJECTED döndürürse implement’e geri dönülüyor. Bu döngü PASS alınana kadar tekrar edebilir.

SPEC -> DECIDED -> IMPLEMENTING -> CRITIQUING -> PASS/REJECTED -> RETRO -> ARCHIVED
                       ^                |
                       |   REJECTED     |
                       +----------------+

Court: Değerlendirme

Pipeline’ın giriş noktası. Hazırlanan spec burada değerlendiriliyor. Sekiz kriter üzerinden puanlama: Benefit, Necessity, Burden, Conflict, Performance, Security, Bottleneck, Currency.

Gemini ve Kimi MCP’leri üzerinden çoklu perspektif sağlanıyor. Her AI farklı bir bakış açısıyla aynı spec’i değerlendiriyor. Sonuç: GO, DEFER veya KILL.

Karar, gerekçeleri ve muhalefetiyle birlikte forge/decisions/ klasörüne yazılıyor. İleride herhangi bir skill bu kararı okuyabilir.

Implement: Geliştirme

Court GO verdikten sonra geliştirme başlıyor. Ama önce bir gate var:

1. Court kararını hafızadan oku ve GO olduğunu doğrula
2. Spec’i hafızadan oku
3. Execution plan yaz ve kullanıcı onayı bekle
4. Onay geldikten sonra worktree’de geliştir
5. Test’leri çalıştır
6. Hafıza notunu yaz (değişiklikler, dosyalar, kararlar, test sonuçları)
7. Commit message taslağı sun

--hotfix flag’i ile court atlanabiliyor. Ama bu karar hafızaya yazılıyor ve retro’da audit ediliyor: “Bu hotfix court’tan geçmeli miydi?”

Critique: Adversarial Review

Implement bittikten sonra çalışıyor. Bir senior auditor gibi kodu inceliyor. Yapısal kurallar:

• “Her şey iyi görünüyor” yasak
• Minimum 2 risk, 1 performans sorunu, 1 edge case zorunlu
• Her bulgu dosya:satır referansı ile
• Implementer’ın self-assessment’ını okumadan önce git diff’ten kendi görüşünü oluştur
• Her bulgu MUST_FIX veya NICE_TO_HAVE olarak sınıflandır
• Mimari değişiklik önerme, mimari court’un işi

Stack’e özel kontroller: Django için N+1, select_related eksikliği. React için hook kuralları, dependency array’ler. PostgreSQL için index eksikliği, JSONB sorguları.

Pre-mortem analizi: “Bu kod production’a gitti, bir şey bozuldu. Ne bozuldu?” 10x yük, kötü niyetli input, dış servis çökmesi, 6 ay sonra context kaybı.

Verdict: Herhangi bir MUST_FIX varsa REJECTED. Yoksa PASS.

Retro: Konsolidasyon

Feature tamamlandıktan sonra çalışıyor. Üç iş yapıyor:

Pattern çıkarma: Implement ve critique döngüsünden kalıcı kurallar çıkarıyor. “Paddle webhook’larında signature doğrulaması her zaman ilk adım olmalı” gibi. Bu kurallar stack bazlı dosyalara yazılıyor: core-rules/react.md, core-rules/django.md, core-rules/postgres.md, core-rules/workflow.md.

Çelişki kontrolü: Yeni pattern mevcut bir kuralla çelişirse bunu tespit ediyor. Otomatik çözmüyor, bana sunuyor: mevcut kuralı koru, yenisiyle değiştir, veya her ikisini bağlam bazlı kapsamla.

Temizlik: 30 günden eski active notları tespit edip arşiv veya silme önerisi sunuyor. Bilgi tabanı büyümez, budanır. Append değil upsert.

Hafıza Yapısı

Tüm skill’ler ortak bir Obsidian vault’una yazıyor ve okuyor. basic-memory MCP ¹ üzerinden erişim sağlanıyor.

forge/
  decisions/        <- /court çıktıları (ADR'ler)
  active/           <- /implement ve /critique notları (devam eden iş)
  core-rules/       <- /retro'dan çıkan kalıcı pattern'ler
    react.md
    django.md
    postgres.md
    workflow.md
  archive/          <- tamamlanan iş, /retro tarafından taşınır

Dosya adlandırma: YYYY-MM-DD_[feature-name]_[stage].md

Her not frontmatter’ında durum bilgisi taşıyor: status: DECIDED, status: IMPLEMENTING, status: CRITIQUING, verdict: PASS. Herhangi bir skill herhangi bir notun durumunu sorgulayabilir.

Bu yaklaşım, Karpathy’nin sonradan önerdiği LLM Wiki pattern’i² ile örtüşüyor: raw sources + LLM tarafından maintained markdown wiki + workflow şeması. Forge’un skill-shared vault ve status frontmatter modeli aynı fikrin skill-driven uygulaması.

Ekosistem

Forge tek başına çalışır ama tam potansiyeline diğer araçlarla ulaşıyor.

Araç	Forge’daki Rolü	Zorunlu mu?
decision-gate 3	Court skill’i, pipeline girişi	Evet (court için)
dnomia-knowledge 1	Ortak hafıza katmanı	Hayır (auto-memory fallback var)
mcp-code-search 4	Critique için codebase analizi	Hayır (grep/glob yeterli)
chief-of-staff 5	Upstream görev triajı	Hayır (manuel seçim yeterli)
edit-guard 6	Implement sırasında güvenli dosya düzenleme	Hayır (3+ edit kuralı yeterli)

Bağlama göre hangi kombinasyon mantıklı:

Bağlam	Önerilen stack
Hızlı feature (< 1 gün)	forge + decision-gate
Yeni proje kurulumu	forge + decision-gate + dnomia-knowledge + mcp-code-search
Günlük operasyon	chief-of-staff + forge + dnomia-knowledge
Büyük refactoring	forge + mcp-code-search + edit-guard
Minimal (sadece pipeline)	forge tek başına (auto-memory fallback)

Neyi Bilinçli Olarak Reddettik

Forge’un tasarımı sırasında Gemini ve Kimi’den gelen öneriler arasında reddedilenler de var. Her biri iyi bir fikir ama benim kısıtlarıma uymadı.

Öneri	Kaynak	Neden reddedildi
Event-driven mimari	Kimi	Sıralı pipeline için over-engineering
State machine sınıfı	Kimi	Markdown + folder yapısı yeterli
70 agent persona	agency-agents 7	Solo dev için 4 skill, 70 agent değil
Dinamik yönlendirme	Gemini + agency-agents	Human-in-the-loop, AI değil
Kural DAG’ı (YAML)	Kimi	Markdown + çelişki kontrolü daha basit
Ayrı /metrics skill	Kimi	Erken optimizasyon, ihtiyaç organik çıksın
”sınırlı mühendis” persona 8	Gemini	Yapısal kısıtlamalar, roleplay’den güvenilir

Forge Ne Yapmaz

• Otonom agent zincirleme yok. Skill’ler birbirini çağırmaz.
• Gerçek zamanlı agent müzakeresi yok. Sıralı pipeline, debate simulator değil.
• Dinamik yönlendirme yok. Pipeline sırası sabit.
• Karmaşık state yönetimi yok. State hafıza notlarında, veritabanında değil.
• Enterprise SDLC değil. 4 skill, 70 agent değil. Tek kişi ürün çıkarsın diye tasarlandı.

Kurulum

git clone https://github.com/ceaksan/forge.git
cd forge
./install.sh

install.sh skill’leri ~/.claude/skills/forge/ altına symlink’liyor. Güncelleme otomatik.

# Kullanım
/court [konu]                    # Değerlendirme
/implement [feature-name]        # Geliştirme
/implement --hotfix [açıklama]   # Hızlı düzeltme, court atlanır
/critique                        # Adversarial review
/retro [feature-name]            # Konsolidasyon

Kapanış

Forge herkes için doğru çözüm değil. Takım bazlı projelerde Jira veya Linear workflow’ları daha uygun. Basit bug fix’ler için pipeline overhead’i gereksiz.

Benim durumumda tek başıma çalışırken kararların gerekçelerini, review bulgularını ve öğrenimleri oturumlar arasında taşıyacak bir yapıya ihtiyacım vardı. Forge bu yapı. Dört skill, ortak hafıza, human-in-the-loop.

Proje açık kaynak olarak GitHub’da yayınlandı ⁹.

Forge’un daha geniş bağlamda nasıl konumlandığını Context Engineering Ekosistemi yazısında ele aldım.

Footnotes

1. dnomia-knowledge: basic-memory MCP yapılandırması ve Obsidian vault entegrasyonu ↩ ↩²
2. Karpathy, LLM Wiki. Forge’un yayımlanmasından birkaç hafta sonra paylaşılan, persistent ve LLM tarafından bakımı yapılan markdown wiki önerisi; RAG alternatifi olarak üç-katman (sources, wiki, schema) mimarisi. ↩
3. decision-gate: Çoklu AI perspektifli değerlendirme tribunal’ı ↩
4. mcp-code-search: Yerel semantik kod arama MCP sunucusu ↩
5. chief-of-staff: Günlük iş akışını hazırlayan yerel AI asistan ↩
6. edit-guard: Claude Code dosya düzenleme güvenlik eklentisi ↩
7. agency-agents: 70+ agent prompt koleksiyonu, NEXUS orkestrasyon sistemi ↩
8. Gemini, /critique skill’ine “sinirli mühendis” (angry engineer) persona atamayı önerdi. Fikir: agent kızgın bir mühendis gibi davranırsa daha sert review yapar. Reddedildi çünkü roleplay tutarsız sonuç veriyor. Bunun yerine yapısal kısıtlamalar (zorunlu bulgu çıktısı, pre-mortem analizi) tercih edildi. ↩
9. Forge GitHub deposu ↩

Versiyon Bilgisi

v0.3.0Repo →

Changelog

v0.3.02026-03-19dnomia-knowledge entegrasyonu, trace-informed review, prompt-optimize köprüleme

v0.2.02026-02-15Hybrid swarm critique tasarımı, review pipeline iyileştirmeleri

v0.1.02026-01-15İlk sürüm: prompt optimization pipeline

Önemli Noktalar

• 01 Skill'ler arası hafıza paylaşımı, her adımın önceki kararlara erişimini sağlar
• 02 Adversarial review zorunlu: critique en az 2 risk, 1 performans sorunu, 1 edge case bulmak zorunda
• 03 Retro, bilgi tabanını büyütmek yerine budayarak kalıcı pattern'lere dönüştürür
• 04 Human-in-the-loop: her adım insan onayı ile ilerler, skill'ler birbirini tetiklemez

Sık Sorulan Sorular (FAQ)

+ Forge nedir?

Solo geliştiriciler için tasarlanmış, memory-backed bir karar-teslim pipeline'ı. Claude Code skill'leri olarak çalışan dört adım: değerlendirme (court), geliştirme (implement), adversarial review (critique) ve bilgi konsolidasyonu (retro). Spec hazırlığı pipeline öncesinde plan modu ve interactive mode ile yapılır. Her adım ortak bir Obsidian vault'una yazar ve okur.

+ Forge ile normal code review arasındaki fark ne?

Normal code review izole çalışır, önceki kararları bilmez. Forge'un critique skill'i pipeline-aware: court kararını ve implement notunu hafızadan okur. Ayrıca zorunlu adversarial output var, 'looks good' demek yapısal olarak yasak. Minimum 4 bulgu zorunlu.

+ Forge otonom bir agent sistemi mi?

Hayır. Human-in-the-loop: insan her adımı manuel tetikler. Skill'ler birbirini çağırmaz, dinamik yönlendirme yok. Tahmin edilebilirlik, akıllılıktan önce gelir. State, ortak hafızada (Obsidian vault) tutulur, veritabanında değil.

+ Hangi projelerle entegre çalışıyor?

decision-gate (court skill'i), dnomia-knowledge (hafıza katmanı), mcp-code-search (critique için kod analizi), chief-of-staff (upstream görev triajı) ve edit-guard (güvenli dosya düzenleme). Hiçbiri zorunlu değil, forge tek başına da çalışır.

+ Retro ne yapar?

Tamamlanan özelliklerden kalıcı pattern'ler çıkarır, mevcut kurallarla çelişki kontrolü yapar, 30 günden eski notları temizlik için sunar. Bilgi tabanı büyümez, budanır. Append değil upsert mantığıyla çalışır.