Bir depoda yararlı olan ayar diğerinde gereksiz olabilir. Örneğin Türkçe kısa yanıt tercihi birçok projede geçerliyken, belirli test komutu yalnızca tek uygulamada anlamlıdır. Codex yapılandırmasını katmanlara ayırmak, bu farkları yönetmeyi kolaylaştırır. Resmî belgeler kullanıcı düzeyindeki config.toml ile proje düzeyindeki yapılandırmayı ayırır; proje katmanlarının yüklenmesi için güven bağlamının da önemli olduğunu belirtir.
Önce bilgileri türüne göre ayırın
Elinizdeki notları üç gruba bölün. Kişisel tercihler çalışma dilini ve rapor uzunluğunu anlatabilir. Proje bilgileri uygulamanın kurulumunu, ilgili dizinleri ve doğrulama yöntemini açıklar. Geçici görev talimatı ise bugün değiştirilecek davranışı tanımlar. Bu üçü aynı dosyaya yığıldığında eski bir isteğin yeni görevleri yanlış yönlendirmesi kolaylaşır.
Bir blog projesinde “yazı tipi Poppins” tasarım kararı olabilir; “şu başlığı bugün büyüt” ise görev kapsamıdır. İlkinin tasarım rehberinde bulunması faydalıdır. İkincisini bütün projelere geçerli kalıcı kurala çevirmek, sonraki düzenlemelerde gereksiz çelişki yaratır. Bilgiyi yerleştirirken geçerlilik süresini de düşünün.
Çalışma yönergesi ile teknik ayarı karıştırmayın
Bir yapılandırma dosyası desteklenen teknik seçenekleri taşır. AGENTS.md ise geliştiriciye ve Codex'e proje hakkında çalışma rehberi sunabilir. Şema dışı bir anahtar ekleyerek doğal dilde talimat vermeye çalışmak yerine doğru aracı seçin. Benzer biçimde ağ erişimini etkileyen teknik bir sınırlamayı yalnızca “erişimin var” cümlesiyle değiştirmiş saymayın.
Örnek görev: “Depodaki mevcut Codex ayarlarını ve AGENTS.md dosyasını incele. Kişisel tercih, proje kuralı ve geçici iş notlarını sınıflandır. Tekrarları göster; desteklenmeyen ayar anahtarı üretme. Düzenleme gerekiyorsa her değişikliğin hangi kapsamda etkili olacağını açıkla.” Bu inceleme, doğrudan bütün ayarları değiştirmekten önce küçük ve değerlendirilebilir bir sonuç üretir.
Dar kapsamı gerçekten dar tutun
Bir monorepoda ödeme servisiyle belge sitesi farklı doğrulama komutları kullanabilir. Kök yönerge ortak kuralları anlatırken alt dizin yönergesi yalnızca ilgili servisin bilgilerini taşıyabilir. Dosyanın hangi çalışma dizininden keşfedildiğini doğrulayın. Sırf klasörde bulunduğu için her oturumda okunacağını varsaymak, yanlış beklenti oluşturur.
Takım arkadaşının kişisel makinesine ait mutlak dizini ortak kurala eklemeyin. Mümkün olduğunca depo içindeki ilişkileri tarif edin. Yalnızca bir bilgisayarda bulunan araç için alternatif veya açık bir gereksinim belirtin. Bu ayrıntılar, aynı görevin farklı ortamda tekrar yürütülmesini kolaylaştırır.
Değişikliği küçük bir görevle sınayın
Yeni katman düzenini kurduktan sonra risksiz bir okuma görevi verin: “Bu projede testleri nasıl çalıştıracağını ve hangi yönergeleri kullandığını özetle.” Beklenen bilgi eksikse kapsamı veya dosya konumunu kontrol edin. Ardından küçük bir kaynak değişikliğiyle gerçekten doğru doğrulamanın seçildiğini görün. Dosyanın varlığı, çalışma biçiminin doğrulandığı anlamına gelmez.
Zamanla ayar envanteri tutmak da faydalıdır. Her kalıcı kural için amaç ve geçerli alanı bir cümleyle kaydedin. Yeni bir araç veya depo geldiğinde tüm katmanları kopyalamak yerine yalnızca ortak olanları devralın. Bu düzen, yapılandırmayı büyütmekten çok gereksiz etkileri azaltmaya hizmet eder.
Örneğin tek serviste farklı bir test komutu gerekiyorsa ortak kök dosyaya birden çok koşullu paragraf eklemek yerine ilgili alt dizini değerlendirin. Ardından başka bir serviste başlayan görevin bu istisnayı yanlışlıkla benimsemediğini kontrol edin. Kapsam düzeninin başarısı, doğru bilginin doğru görevde görünmesiyle ölçülür.
Resmî kaynaklar: OpenAI Docs — Config basics, AGENTS.md.
