SpecScore vs Plain Markdown
Çoğu ekip zaten "spesifikasyonlara" sahiptir — bir doküman klasöründeki amaca yönelik Markdown, Notion sayfaları veya Jira biletleri. Ücretsizdir, zaten oradadır ve işe yarar. SpecScore ise aynı Markdown'dır; yapay zeka ajanlarının lint edebileceği, sorgulayabileceği ve koda geri izleyebileceği bir yapı eklenmiş halidir.
Ortak noktaları.
Varsayılan yaklaşımın iyi yaptığı şeyler.
Düz Markdown, Notion ve Jira gerçek varsayılandır. Bunu hak etmişlerdir.
Sıfır öğrenme eğrisi
Şema yok, zorunlu alanlar yok, akışta CLI yok. Bir dosya açın, yazmaya başlayın. Tek seferlik bir not veya küçük bir proje için bu tam olarak doğrudur — ihtiyacınız olmayan yapı yalnızca sürtünme yaratır.
Zaten kurulu
Ekibiniz zaten Notion, Confluence veya bir docs/ klasöründedir. Benimseyecek veya taşıyacak bir şey yoktur. En düşük sürtünmeli seçenek, halihazırda kullandığınız seçenektir.
Evrensel olarak taşınabilir
Düz Markdown her yerde açılır ve her aracın ötesinde yaşar. SpecScore tam olarak bu özellik üzerine inşa edilmiştir — bu yüzden SpecScore bir veritabanı değil, yine Markdown'dır.
Özellik karşılaştırması.
Fark dosya türü değil — bir ajanın onunla ne yapabileceğidir.
| Yetenek | Düz Markdown / Notion | SpecScore |
|---|---|---|
| Format | Serbest biçimli Markdown / dokümanlar | Markdown + YAML frontmatter (yapılandırılmış) |
| Gereksinimler nerede yaşar | Jira, Notion, Slack, birinin zihni | Depoda, kodun hemen yanında |
| "Bu spesifikasyon tamamlandı mı?" | Bir insan okur ve karar verir | specscore lint — otomatik |
| Belirsizlik tespiti | Yok — muğlak fiiller sessizce geçer | Muğlak fiiller, eksik AC'ler, askıda referanslar işaretlenir |
| Gereksinim / AC kimlikleri | Yok | Makine tarafından adreslenebilir kimlikler (REQ: slug) |
| Yaşam döngüsü durumu | Takip ediliyorsa bile örtük | Uygulanan — Draft → Approved → Implementing → Stable |
| Koddan spesifikasyona izlenebilirlik | Yok | specscore: açıklamaları + Verifies: fragmanları |
| Ajan navigasyonu | Bir şey bulmak için her dosyayı okuma | CLI'dan spesifikasyon grafiğini sorgulama |
| CI'da kalite kapısı | Yok | specscore lint tıpkı bir linter gibi sıfır olmayan kodla çıkar |
| Öğrenme eğrisi | Yok | Öğrenilecek bir format (kademeli) |
| Maliyet / lisans | Ücretsiz | Ücretsiz, açık kaynak |
SpecScore'un daha ileri gittiği alanlar.
Belirsizlik yorumlanmaz, yakalanır
Serbest biçimli spesifikasyonlarda, bir ajanla her etkileşim yorumlamayla başlar — "giriş çalışmalı" ifadesi, doğru ile akla yatkın ama yanlış arasında bir yazı-turadır. SpecScore'un lintkomutu, bir ajan harekete geçmeden önce muğlak fiili ve eksik kabul kriterini işaretler.
$ specscore lint auth/login.md ✗ R1 "should work" — ölçülebilir değil ✗ R1 no acceptance criteria
Yanlış yorumlamalar birikmeyi durdurur
Bir ajan bir gereksinimi yanlış yorumlar, ikincisi bunun üzerine inşa eder, üçüncüsü her ikisine de bağımlı olur — ve bunu üç ajan sonra fark edersiniz. Yapılandırılmış kabul kriterleri her ajana aynı başarılı/başarısız koşullarını verir; böylece yorumlama aralarında sapmaz.
Kod, spesifikasyona geri izlenir
Düz dokümanların uyguladıkları kodla hiçbir bağlantısı yoktur. SpecScore kaynaktaspecscore: açıklamaları ve commit'te Verifies: fragmanları ekler — specscore code refs "bu gereksinimi hangi kod uyguluyor?" sorusunu deterministik olarak yanıtlar.
Kırk bilet yerine tek bir spesifikasyon
Yeni bir ekip arkadaşı (veya taze bir ajan), niyeti kırk Jira biletinden ve bir Slack dizisinden yeniden oluşturmak yerine, tüm bağlamıyla birlikte bir özellik spesifikasyonunu okur.
Ajanlar yeniden okumak yerine sorgular
Bir doküman klasöründe "ne devam ediyor?" sorusunu bulmak dosyaları açmak anlamına gelir. SpecScore'da ise bu specscore feature list komutudur — spesifikasyon grafiği CLI'dan yanıt verir; böylece ajanlar depoyu yeniden okuyarak bağlamı tüketmez.
Kalite CI'da uygulanır
Serbest biçimli spesifikasyonların bir kapısı yoktur — yarım yazılmış olanı da tam olanı kadar kolay birleştirilir. specscore lint, tıpkı ESLint veyago vet'in kodu koruması gibi, sorunlarda sıfır olmayan bir kodla çıkar.
Hangisi ne zaman kullanılmalı?
Şu durumlarda düz Markdown uygundur…
- Tek seferlik bir not, bir deneme veya yapıya ihtiyaç duymayacak kadar küçük bir proje ise.
- Dokümandan hiçbir yapay zeka ajanı kod üretmeyecekse — bir insan okuyup doğrudan anlayabiliyorsa.
- Birinin uygulayacağı bir gereksinimi değil, kaba bir fikri yakalıyorsanız.
Şu durumlarda SpecScore'a başvurun…
- Bir yapay zeka ajanı spesifikasyondan kod üretiyorsa — belirsizlik hatalı koda dönüşür.
- Birden fazla ajan veya insan aynı gereksinimlere bağımlıysa.
- Hangi kodun hangi gereksinimi uyguladığını bilmeniz gerekiyorsa.
- "Bu spesifikasyon bitti mi?" sorusunu bir toplantı değil, bir araç yanıtlamalıysa.
- Proje her şeyi yeniden okumanın ölçeklenemeyeceği kadar büyükse.
Halihazırda sahip olduğunuz spesifikasyonları geliştirin.
Birikiminizi dönüştürmez veya araçlarınızı değiştirmezsiniz. Bir sonraki özelliğinizi seçin, onun için bir SpecScore spesifikasyonu yazın ve specscore lint çalıştırın — biletinizin gözden kaçırdığı bir şeyi yakalayıp yakalamadığına bakın. Uyguladığınızda specscore:açıklamaları ekleyin. Yalnızca faydalı olduysa bir sonraki sprinte genişletin.
Düz Markdown giriş rampasıdır. SpecScore ise onun evrildiği haldir.
Diğer karşılaştırmalar.
Aynı biçim, spesifikasyon güdümlü diğer araçların yanında:
Hepsi tek sayfada: 2026’nın en iyi spesifikasyon güdümlü geliştirme araçları.
Geri bildirim
Bu karşılaştırma herkese açık belgelere ve kaynak koda dayanır. Bir şey yanlış veya eski mi? düzeltme issue’su açın. SpecScore’u başka bir araçla karşılaştırmamızı ister misiniz? bir tane isteyin.