Chief of Staff: Günlük İş Akışını Hazırlayan Yerel AI Asistan

Problem: Bilgi Toplama, Karar Verme Değil

Her sabah aynı döngü: bilgisayarın başına oturuyorum ama ilk yarım saati karar vermek yerine bilgi toplamakla geçiriyorum. Gmail’de hangi e-postalar gelmiş, takvimde bugün ne var, hangi projede sorun çıkmış, dünden kalan görevler ne durumda, takip ettiğim kaynaklarda neler yayınlanmış.

Bunların hiçbiri zor değil. Ama dağınıklar. Beş farklı araç, beş farklı sekme, beş farklı bağlam geçişi. Ve henüz gerçek işe başlamamışken kognitif yük birikiyor.

Bu problemi çözmek için Chief of Staff’ı geliştirdim: gece çalışan, verileri toplayan, sınıflandıran ve sabah hazır bir brifing olarak sunan yerel bir AI asistan.

Sonuç: Her Sabah Beni Karşılayan Brifing

Teknik detaylara girmeden önce, sistemin ürettiği çıktıyı göstermek istiyorum. Her sabah Obsidian’ı açtığımda beni şuna benzer bir Daily Note karşılıyor:

# 2026-03-09

## Calendar

- 10:00-11:00 Client X toplantısı (Calendly) **prep needed**
- 14:00-14:30 Deploy review
- Free: 07:00-10:00, 11:00-14:00, 14:30-18:00

## Project Status

- OK: leetty, ceaksan
- validough: 3 errors (Neon connection timeout)

## Feed Highlights

- [Interesting Article](https://example.com) (Tech Blog) ~5min
- [Another Post](https://example.com) (Dev Weekly) ~3min

## Classified Tasks

### DISPATCH (AI handles)

- [ ] Client A e-posta yanıtı, toplantı onayı #email
- [ ] Blog araştırma notu #content

### PREP (80% ready, you finish)

- [ ] Client Y hosting migration yanıtı, taslak hazır #email
- [ ] validough Neon timeout, özet + çözüm yönü #dev

### YOURS (your brain needed)

- [ ] Client X toplantı hazırlığı
- [ ] leetty checkout akışı düzeltmesi #dev

### SKIP (not today)

- [ ] validough onboarding sihirbazı, P3

## Carried Over

- [ ] [P2] Blog yazısı yayını, 2 gündür bekliyor

Takvim, proje durumları, sınıflandırılmış görevler, önceki günlerden taşınan işler. Hepsi tek yerde, toplanmış ve sıralanmış durumda. Ben sadece onaylıyorum veya düzeltiyorum, sonra işe başlıyorum.

Seçeneklere Genel Bakış

Bu tür bir otomasyonu kurmanın birden fazla yolu var. Her yaklaşımın kendine göre güçlü ve zayıf yönleri mevcut.

Tam Otonom Agent Sistemleri

Bir görevi tanımlayıp agent’ın baştan sona çözmesini bekleyen sistemler. Teoride çekici, pratikte sorunlu. Çoğu zaman agent bir döngüye giriyor, maliyetler kontrolsüz artıyor ve sonuç tahmin edilemiyor. Solo girişimci bağlamında kontrol kaybı kabul edilemez bir risk.

No-Code Otomasyon Platformları

Sürükle-bırak arayüzlerle servisler arası bağlantı kuran platformlar. Bulut servisleri arasındaki entegrasyonlarda güçlüler. Ancak yerel dosya sistemine erişim (Obsidian vault’um gibi), özelleştirilmiş sınıflandırma mantığı veya LLM entegrasyonu söz konusu olduğunda ya sınırlarına dayanıyorlar ya da karmaşık workaround’lar gerektiriyorlar.

AI Asistan Platformları

Yapılandırılabilir AI asistan servisleri. E-posta taslağı oluşturma, takvim yönetimi gibi görevlerde kullanışlılar. Ancak veriler onların sunucularından geçiyor. Danışmanlık yaptığım müşterilerin verileri ve kendi projelerim için bu bir gizlilik riski. Ayrıca aylık abonelik maliyetleri oluşuyor ve özelleştirme seçenekleri sınırlı kalıyor.

Agent Framework’leri

Geliştirici odaklı framework’ler, agent iş akışlarını kod ile tanımlamayı sağlıyor. Güçlü ve esnek araçlar. Ancak benim durumum için birkaç sorun var:

• Güvenlik ve gizlilik: Hem kendi hem de müşterilerimin verileri söz konusu
• Maliyet: Kullanmadığım özelliklerin altyapı yükü
• Genel rutin yokluğu: Danışmanlık ve kendi projelerim arasında genel bir rutine indirgenebilecek bir iş akışı yok. Sohbet üzerinden görev atamak benim çalışma biçimime uymuyor
• Overengineering riski: Kullanılmayan bir ton özellik yerine amaca yönelik bir akış daha optimize ve kontrol edilebilir

Kendi Çözümünü Yaz

Cron job’lar, Python script’leri ve API çağrılarıyla kendi pipeline’ını kurmak. En esnek yaklaşım ama en fazla geliştirme zamanı gerektiren de bu. Her şeyi sıfırdan yazmak yerine, mevcut araçları orkestre eden bir katman daha verimli olabilir.

Yerel / Açık Kaynak Model Alternatifleri

Ollama gibi araçlarla Llama, Mistral veya Qwen modellerini yerel olarak çalıştırmak mümkün. Bulut bağımlılığı yok, veri dışarı çıkmıyor. Ancak şu an için bu modellerin tool calling ve uzun bağlam yönetimi kapasiteleri sınırlı. Basit sınıflandırma görevleri için yeterli olabilirler ama karmaşık orkestrasyon için henüz olgunlaşmamış durumdalar. İlerleyen dönemde bu denge değişebilir.

Yaklaşım	Güçlü Yön	Zayıf Yön (benim kısıtlarım için)
Tam otonom agent	Minimum müdahale	Kontrol kaybı, maliyet belirsizliği
No-code otomasyon	Hızlı kurulum	Yerel dosya erişimi zayıf, LLM entegrasyonu sınırlı
AI asistan platformu	Kullanıma hazır	Gizlilik riski, sınırlı özelleştirme
Agent framework	Esnek, güçlü	Overengineering, gereksiz karmaşıklık
Kendi script’lerin	Tam kontrol	Geliştirme süresi, bakım yükü
Yerel modeller	Gizlilik, maliyet yok	Tool calling ve bağlam yönetimi henüz sınırlı

Benim Tercihim: Lightweight ve Amaca Yönelik

Bu seçenekleri değerlendirdikten sonra kendi çözümümü yazmaya karar verdim. Ancak tamamen sıfırdan değil.

Zaten farklı ihtiyaçlar için geliştirdiğim mini servisler vardı. Bilgi yönetimi için kendi knowledge base MCP sunucum ¹, web’den veri çekmek için kendi scraper’ım, codebase’lerde arama yapmak için kendi semantic code search MCP sunucum ². Bunların her biri bağımsız çalışıyor, MCP veya API olarak erişilebiliyor. Tasarım tokenları, geometrik desen üretimi, e-ticaret operasyonları gibi farklı alanlarda da benzer mini servislerim mevcut.

Bu ekosistemi hem kendi projelerimi geliştirmek hem de geliştirici ile kullanıcı arasındaki olası sorunları fark etmek için kullanıyorum. Kendi ürünlerimi günlük olarak kullanmak, geri bildirim döngüsünü kısaltıyor.

Eksik olan şey bir orkestrasyon katmanıydı. Mevcut parçaları bir araya getiren, gece çalışan, sabah hazır bir brifing üreten bir akış. Chief of Staff bu katman.

Tercihimin arkasındaki prensipler:

• Lightweight: Kullanmadığım özelliklerin yükünü taşımak istemiyorum. Gereken durumlar için o duruma özel ilerlemek daha uygun
• Local-first: Verilerim benim bilgisayarımda kalıyor. Müşteri verilerimin üçüncü parti sunuculara gitmesi kabul edilemez
• Taşınabilir: Yanımda taşıyabileceğim, powerbank ile besleyebileceğim bir çözüm istiyorum. Tek bir bilgisayara bağlı kalmak istemiyorum
• Gözden geçirilebilir: Akışı sürekli gözden geçirmek, ayarlamak ve kontrol etmek istiyorum. Set-and-forget bir sistem değil, aktif olarak yönettiğim bir araç
• Maliyet kontrolü: Her adımın maliyeti önceden belirli, sürpriz fatura yok

Neden Claude Code

Model seçiminde şu kriterleri değerlendirdim:

Kriter	Claude Code	GPT + API	Gemini + API	Yerel Model (Ollama)
MCP desteği	Native, built-in	Yok (özel entegrasyon gerekir)	Yok	Yok (deneysel)
Non-interactive mod	claude -p	API call yazılmalı	API call yazılmalı	ollama run
Budget kontrolü	--max-budget-usd flag	Manuel takip	Manuel takip	Maliyet yok
Tool calling	Güçlü	Güçlü	Güçlü	Sınırlı
Gmail/Calendar erişimi	MCP connector (OAuth yok)	OAuth + API key gerekir	OAuth + API key gerekir	Manuel entegrasyon
Yerel çalışma	Evet (CLI)	Hayır (API)	Hayır (API)	Evet

Claude Code’un en belirleyici avantajı MCP connector’lar. Gmail ve Google Calendar verilerine Claude’un built-in MCP bağlantıları üzerinden erişiyorum. Google Cloud Console’da proje oluşturmak, OAuth credential yönetmek, API key’leri saklamak gibi bir süreç yok. Claude Code’da /mcp ile bir kez bağlanıyorum, sonrası otomatik.

claude -p (non-interactive mode) ile prompt dosyasını verip çalıştırıyorum. --max-budget-usd flag’i ile her çalıştırmanın maksimum maliyetini belirliyorum. Bu, cron job veya launchd ile gece otomatik çalıştırmayı mümkün kılıyor.

# Gece pipeline'ı
claude -p prompts/collect.md --max-budget-usd 2.00    # Veri toplama
claude -p prompts/classifier.md --max-budget-usd 1.50  # Sınıflandırma

Ancak önemli bir nokta: sistem model-agnostic tasarlandı. Prompt dosyaları düz markdown, veri katmanı SQLite, collector’lar Python script’leri. Claude Code’a bağımlılık sadece MCP connector’lar ve claude -p çağrıları. Prompt dosyalarını Ollama üzerinden Llama veya Mistral ile çalıştırmak teknik olarak mümkün. MCP connector’lar yerine doğrudan Gmail API ve Google Calendar API kullanılabilir (ek OAuth kurulumu gerekir). İleride yerel modellerin tool calling kapasitesi yeterli seviyeye geldiğinde bu geçiş daha kolay olacak.

Sistem Mimarisi

Chief of Staff üç bağımsız katmandan oluşuyor. Her katman tek başına değer üretir, birbirlerine bağımlı değiller.

              Claude Code (claude -p)
              ┌───────────────────────────────-───┐
              │  MCP Connector'lar                │
              │  ┌──────────┐  ┌─────────────-─┐  │
              │  │  Gmail   │  │  Google       │  │
              │  │  MCP     │  │  Calendar MCP │  │
              │  └────┬─────┘  └──────┬────────┘  │
              └───────┼───────────────┼───────────┘
                      │               │
    ┌─────────────────┼───────────────┼─────────-─────────┐
    │                 ▼               ▼                   │
    │  ┌─────────────────────────────────────────────-─┐  │
    │  │              cos.db (SQLite)                  │  │
    │  │              Tek doğru kaynak                 │  │
    │  └─────────────────────┬───────────────-───────-─┘  │
    │                        │                            │
    │  ┌──────────┐  ┌───────▼────────┐  ┌──────────--─┐  │
    │  │  Feed    │  │   Renderer     │  │  Task       │  │
    │  │Collector │  │  SQLite → MD   │  │ Collector.  │  │
    │  │ (Python) │  │  (Python)      │  │ (Python)    │  │
    │  └──────────┘  └───────┬────────┘  └──────────--─┘  │
    └────────────────────────┼────────────────────────-───┘
                             │
                  ┌──────────▼──────────┐
                  │ Classifier (Sonnet) │
                  └──────────┬──────────┘
                             │
                  ┌──────────▼──────────┐
                  │  Morning Sweep      │
                  │  (Opus + subagent)  │
                  └──────────┬──────────┘
                             │
                  ┌──────────▼──────────┐
                  │  Day Block (Sonnet) │
                  └─────────────────────┘

Katman 1: Gece Toplama

Sabah 06:00’da launchd ile otomatik çalışıyor. Tek bir claude -p oturumu Gmail ve Calendar verilerini MCP üzerinden topluyor, SQLite’a yazıyor. Ardından Python script’leri sırayla çalışıyor:

Kaynak	Yöntem	Ne Topluyor
Gmail	MCP connector	Son 24 saatteki aksiyona geçirilebilir e-postalar
Google Calendar	MCP connector	Bugün ve yarının etkinlikleri, tüm takvimlerden
RSS beslemeleri	Python (Miniflux REST API)	Okunmamış feed girdileri
Obsidian görevleri	Python (dosya tarama)	Tamamlanmamış görevler
Proje sağlığı	Python (özel script’ler)	Proje durumu, hata sayısı, son deploy

Bir kaynak başarısız olursa diğerleri çalışmaya devam ediyor. Daily Note’ta başarısız kaynak için uyarı gösteriliyor.

Katman 1.5: Gece Sınıflandırma

Toplama bittikten sonra Claude Sonnet bekleyen öğeleri sınıflandırıyor:

Sınıf	Anlam	Örnek
DISPATCH	AI tamamen halledebilir	Toplantı onay yanıtı, araştırma notu
PREP	AI %80’ini yapar, ben bitiririm	Karmaşık e-posta taslağı, hata analizi
YOURS	Benim beynim gerekli	Strateji kararları, fiyatlandırma, canlı toplantılar
SKIP	Bugün değil	Düşük öncelik

Sınıflandırma gece yapılıyor. Sabah oturduğumda sıralanmış plan hazır bekliyor.

Katman 2: Sabah Taraması

İsteğe bağlı, ben tetikliyorum. Claude Opus sınıflandırılmış planı gösteriyor, onaylıyorum veya düzeltiyorum. Onaylanan DISPATCH ve PREP görevleri için subagent’lar paralel çalışıyor:

Agent	Kapsam	Güvenlik
Email Agent	Gmail taslağı oluşturur (MCP)	Asla göndermez
Dev Prep Agent	Hata özeti + çözüm yönü	Salt okunur
Content Agent	Blog taslağı, araştırma notu	Sadece belirli klasörlere yazar
Calendar Agent	Toplantı hazırlık notu	Salt okunur

Katman 3: Gün Planı

Sabah taramasından sonra tetikleniyor. Kalan YOURS ve PREP görevlerini takvimdeki boş bloklara yerleştiriyor. Ayrı bir “AI Plan” Google Calendar’ına yazıyor, ana takvime karışmıyor.

Veri Katmanı: SQLite

Tüm veri SQLite’ta. Obsidian sadece görüntüleme katmanı, veritabanı değil.

-- Domain tabloları (kaynak bazlı)
CREATE TABLE emails (
    id TEXT PRIMARY KEY,
    thread_id TEXT,
    subject TEXT,
    sender TEXT,
    snippet TEXT,
    labels TEXT,           -- JSON array
    received_at TEXT NOT NULL,
    raw_payload JSON
);

-- İş kuyruğu (pipeline yaşam döngüsü)
CREATE TABLE work_queue (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    domain_type TEXT NOT NULL,  -- email, event, task, health, feed
    domain_id TEXT NOT NULL,
    priority TEXT,              -- P1, P2, P3, P4
    status TEXT NOT NULL DEFAULT 'pending',
    content_hash TEXT,
    collected_at TEXT NOT NULL DEFAULT (datetime('now')),
    UNIQUE(domain_type, domain_id)
);

-- Sınıflandırmalar (audit trail)
CREATE TABLE classifications (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    queue_id INTEGER NOT NULL,
    category TEXT NOT NULL,     -- dispatch, prep, yours, skip
    reason TEXT,
    model TEXT,
    FOREIGN KEY (queue_id) REFERENCES work_queue(id)
);

Domain tabloları (emails, events, tasks, health_checks, feeds) kaynak bazlı yapılandırılmış veri tutuyor. work_queue her öğenin pipeline’daki durumunu izliyor. classifications her sınıflandırma kararının gerekçesini ve hangi modelle yapıldığını kaydediyor. content_hash ile aynı içerik tekrar sınıflandırılmıyor.

Güvenlik Modeli

Kural	Uygulama
Asla e-posta göndermez	Email Agent sadece taslak oluşturur (gmail_create_draft)
Budget cap	Her claude -p çağrısında --max-budget-usd flag’i
Mutex	shlock ile eş zamanlı çalışma engellenir
İdempotent	INSERT OR IGNORE + unique index ile tekrar ekleme yok
Dry run	Day Block’ta --dry-run ile önizleme
Hata izolasyonu	Bir kaynak başarısız olursa diğerleri etkilenmez
İnsan onayı	Morning Sweep, sınıflandırmayı gösterir, onay bekler
Kapsamlı yazma	Content Agent sadece belirli vault klasörlerine yazar

Bir e-postanın yanlış sınıflandırılması riski var mı? Var. Ancak sistem asla otonom hareket etmiyor. Morning Sweep’te tüm sınıflandırmalar önüme geliyor, gerekçesiyle birlikte. Onaylamadığım hiçbir şey çalışmıyor. Kritik kararlar (fiyatlandırma, strateji, sözleşme gibi) config’de force_yours olarak tanımlı, AI’ın bu konuları DISPATCH veya PREP olarak sınıflandırması engelleniyor.

Maliyet

Bileşen	Maliyet
Gece toplama + sınıflandırma (Sonnet)	~$1-3/gün
Sabah taraması (Opus)	~$1-3/gün
Gün planı (Sonnet)	~$0.25-1/gün
Google API’leri	Ücretsiz (MCP üzerinden)
Toplam	~$2-7/gün

Bu rakamlar budget cap’ler sayesinde kontrol altında. Bir adım belirlenen bütçeyi aşarsa durur, çökmez.

Şu An Ne Durumda

Çalışan katmanlar:

• SQLite schema ve veri katmanı (9 tablo, 5 view)
• Calendar, Gmail, Feed, Task, Health, Radar collector’lar
• Cloudflare (Workers + Pages) ve Coolify (uygulama, servis, veritabanı) sağlık izleme
• Renderer (SQLite’tan Obsidian Daily Note üretimi)
• Classifier prompt’u ve akışı
• 4 domain agent ile paralel sweep orchestrator
• Pipeline runner (run.sh, cos-brief.sh) ve healthchecks.io izleme
• Haftalık istatistik özeti ve zamanlama analizi
• İnteraktif kurulum sihirbazı (setup_wizard.py)

Henüz tamamlanmamış:

• Day Block (takvime zaman bloğu yazma)
• Retry mantığı (başarısız agent çalışmaları için)
• Vercel ve Neon sağlık collector’ları

Sistem her gece çalışıyor ve her sabah brifingimi hazırlıyor. Henüz tamamlanmamış katmanlar bağımsız olduğu için mevcut akışı bozmuyor.

Güncelleme: Paralel Agent’lar ve Ekosistem (20 Mart 2026)

Bu yazıyı yayınladıktan sonra üç şey değişti.

Başkaları da benzer sistemler geliştirdi

Marin County’den teknik geçmişi olmayan bir danışman olan Jim Prosser, kendi versiyonunu 36 saatte geliştirdi ve bunu Medium ve LinkedIn üzerinden anlattı. Anthropic, Chief of Staff senaryosuyla resmi bir Claude Agent SDK cookbook yayınladı. Reddit’te biri planlama ile geliştirmeyi ayıran bir skill geliştirdi.

Hepsini kendi implementasyonumla karşılaştırdım. Kalıplar birbirine yakınsıyor: herkes dispatch/prep/yours/skip benzeri bir sınıflandırmaya ulaşıyor. Farklar veri katmanında ve güvenlik modelinde. Prosser her şeyi Todoist’te tutuyor (üçüncü parti bağımlılık), Anthropic cookbook CSV dosyaları kullanıyor, Reddit skill’inde kalıcı depolama yok. Benim sistemimin SQLite ara katmanı, content hash dedup, idempotent insert’ler ve audit trail sınıflandırmaları dördünün en sağlamı. Eksik kalan paralel agent yürütmesiydi.

Subagent’lar artık paralel çalışıyor

Tek parça sweep prompt’unu async Python orchestrator (collectors/orchestrator.py) ile değiştirdim. Dört domain agent, semaphore tabanlı eşzamanlılık kontrolüyle paralel çalışıyor:

Agent	Model	Budget	Ne yapıyor
Calendar	Sonnet	$0.50	Toplantı hazırlık notu
Health	Sonnet	$0.50	Hata analizi, çözüm yönü
Task	Sonnet	$0.50	Görev tamamlama notu, araştırma taslağı
Feed	Sonnet	$0.50	Aksiyona geçirilebilir feed özetleri

Her agent kendi prompt dosyası, budget cap’i, timeout’u ve log dosyasına sahip. Bir agent başarısız olursa diğerleri çalışmaya devam ediyor. Sonuçlar toplanıp cos.db’ye tek bir transaction’da aktarılıyor. Orchestrator hata ayıklama için --sequential, test için --dry-run modlarını destekliyor.

E-posta agent’ı sadece sınıflandırma yapıyor

Test ettikten sonra otomatik Gmail taslağı oluşturmamaya karar verdim. E-postalar hala sınıflandırılıyor ve Daily Note’ta görünüyor, ancak hiçbir agent Gmail’e dokunmuyor. Brifingimi inceledikten sonra e-postalara kendim yanıt veriyorum. E-posta agent prompt’u kodda mevcut ama orchestrator’ın dispatch haritasından çıkarılmış durumda. Tekrar aktif etmek için tek satır değişiklik yeterli.

Gece pipeline’ı artık sadece toplama, sınıflandırma ve render çalıştırıyor. Sweep, Daily Note’u inceledikten sonra manuel tetikleniyor. Bu, gerçekte nasıl çalıştığıma uyuyor: bir şey ateşlenmeden önce planı görmek istiyorum.

Platform sağlık izleme

Health collector artık bireysel projelerin ötesinde altyapıyı da izliyor. İki platform seviyesinde script, Cloudflare ve Coolify kaynaklarını otomatik kontrol ediyor:

Platform	Ne izliyor	Yöntem
Cloudflare Workers	Hata oranları, invocation sayıları	GraphQL Analytics API
Cloudflare Pages	Deployment durumu	REST API
Coolify Uygulamalar	Container durumu (running/healthy)	REST API, Cloudflare Tunnel
Coolify Servisler	Servis sağlığı	REST API, Cloudflare Tunnel
Coolify Veritabanları	Veritabanı durumu	REST API, Cloudflare Tunnel

Her platform script’i JSON array olarak sonuç veriyor. Health collector bunları proje bazlı script’lerle birlikte çalıştırıp cos.db’ye yazıyor. Bir Worker’ın hata oranı %10’u aşarsa Daily Note’ta P1 olarak görünüyor. Bir Coolify container’ı durmuşsa veya unhealthy ise aynı şekilde.

Mimari genişletilebilir: yeni bir platform (Vercel, Neon, Railway) eklemek, PLATFORM_SCRIPTS’e bir script ve config’e bir section eklemek demek. Collector veya renderer’da değişiklik gerekmiyor.

Kurulum sihirbazı

Proje artık interaktif bir kurulum sihirbazı (setup_wizard.py) ile geliyor. config.example.toml’u template olarak okuyup her bölümü makul varsayılanlarla sunuyor ve config.toml dosyasını oluşturuyor. SQLite veritabanını da başlatıyor ve isteğe bağlı olarak gece çalışması için macOS launchd agent’ını kuruyor.

Her adım atlanabilir. Opsiyonel entegrasyonlar (Miniflux, Coolify, Cloudflare, healthchecks.io) ayrı ayrı soruluyor. --validate modu mevcut config’i interaktif soru sormadan kontrol ediyor. Harici bağımlılık yok, sadece stdlib.

Kapanış

Chief of Staff herkes için doğru çözüm değil. Agent framework’leri veya no-code platformları pek çok kişi için daha uygun olabilir. Benim durumumda danışmanlık ve kendi projelerim arasında genel bir rutine indirgenebilecek bir iş akışı yok. Rutin olan durumlar için farklı yaklaşımlarım zaten mevcut ve yeterli. Gereken durumlar için o duruma özel ilerlemek daha uygun.

Bu yaklaşımın bana verdiği şey kontrol. Akışı sürekli gözden geçirebiliyorum, gerektiğinde değiştirebiliyorum, kullanmadığım özelliklerin yükünü taşımıyorum. Lightweight, amaca yönelik ve taşınabilir bir sistem. Sabah oturduğumda bilgi toplamak yerine karar vermeye başlıyorum.

Bu konularda yaptığım diğer çalışmalardan, mini servisler ekosisteminden ve taşınabilir AI kurulumundan ilerleyen yazılarda bahsedeceğim.

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

Footnotes

1. dnomia-knowledge: Proje bazlı semantik bilgi yönetimi MCP sunucusu ↩
2. mcp-code-search: Yerel semantik kod arama MCP sunucusu ↩
3. Chief of Staff GitHub deposu ↩

Versiyon Bilgisi

v0.2.0Repo →

Changelog

v0.2.02026-03-20Paralel sweep orkestratör, domain-specific subagent'lar

v0.1.02026-01-03İlk sürüm: Gmail, takvim, RSS ve görev toplama pipeline'ı

Önemli Noktalar

• 01 Bilgi toplama sürecini otomatikleştirmek, karar verme sürecini hızlandırır
• 02 MCP connector'lar sayesinde OAuth kurulumu veya API key yönetimi gerektirmez
• 03 Sistem model-agnostic: prompt dosyaları ve SQLite ile herhangi bir LLM'e taşınabilir
• 04 Her katman bağımsız çalışır, tek başına değer üretir

Sık Sorulan Sorular (FAQ)

+ Chief of Staff nedir?

Solo girişimciler için geliştirilmiş local-first AI asistan. Gmail, takvim, RSS beslemeleri ve Obsidian görevlerini gece toplar, sınıflandırır ve sabah hazır bir brifing olarak sunar. Claude Code, Python ve SQLite üzerine kurulu, açık kaynak bir sistem.

+ Hangi veri kaynaklarını destekliyor?

Gmail ve Google Calendar (MCP connector'lar üzerinden), Miniflux RSS beslemeleri (REST API), Obsidian vault'taki görevler (Python grep) ve proje sağlık kontrolleri (özelleştirilebilir script'ler).

+ Neden OpenClaw veya benzeri bir framework kullanılmadı?

Güvenlik, gizlilik, maliyet ve taşınabilirlik gibi kısıtlar nedeniyle. Danışmanlık ve kendi projeleri için genel bir rutine indirgenemeyen iş akışları söz konusu. Lightweight ve amaca yönelik bir çözüm, kullanılmayan özelliklere sahip büyük bir framework'ten daha optimize ve kontrol edilebilir.

+ Claude dışında başka bir model ile çalışır mı?

Sistem model-agnostic tasarlandı. Prompt dosyaları ve SQLite katmanı herhangi bir LLM ile çalışabilir. Ollama üzerinden Llama, Mistral veya Qwen gibi local modeller de kullanılabilir.

+ Günlük maliyeti ne kadar?

Günlük yaklaşık 2-7 dolar. Toplama ve sınıflandırma Sonnet ile, sabah taraması Opus ile çalışır. Budget cap'ler ile her adımın maliyeti kontrol altında tutulur.