31 beceri, 72 sistem: Open Design kütüphanesi nasıl çalışır
Open Design'ı birleştirilebilir kılan dört ilkel öğenin incelemesi: beceriler, sistemler, adaptörler ve daemon. Bir Markdown dosyasının nasıl piksel mükemmelliğinde bir teslimata dönüştüğüne dair somut örneklerle.
Open Design, mekanik olarak, birbirinin üzerine yığılmış dört ilkel öğedir:
- Beceriler — ajanın ne yapması gerektiği
- Sistemler — çıktının nasıl görünmesi gerektiği
- Adaptörler — işi hangi ajanın yaptığı
- Daemon — bunları birbirine bağlayan döngü
Her ilkel öğe, bir dosya klasörüdür. Hiçbiri bir veritabanı, bir eklenti çalışma zamanı veya barındırılan bir hizmet gerektirmez. Tüm kütüphane budur — bir giriş duvarının ardında saklanan beşinci bir kavram yoktur. Bu yazı, her birini sırayla inceliyor ve ajanınızı gerçek bir brief'e yönelttiğinizde neler olduğunu gösteriyor. Nasıl'dan önce bunu neden bu şekilde biçimlendirdiğimizin argümanını isterseniz, Open Design'ı neden bir ürün değil, bir beceri katmanı olarak inşa ettik yazısıyla başlayın.
Beceriler: yetenek birimi
Bir beceri, bir adet SKILL.md ve sıfır veya daha fazla destekleyici dosya içeren bir klasördür. Markdown dosyası ajanın sözleşmesidir — klasördeki diğer her şey, ajanın bu sözleşmeye ulaşmasına yardımcı olmak içindir.
Bir beceri klasörünün anatomisi
Tipik bir beceri şöyle görünür:
skills/
guizang-ppt/
SKILL.md
templates/
magazine.html
examples/
product-launch.html
pitch-deck.html
SKILL.md, becerinin adını, tetikleme koşullarını, girdi biçimini, çıktı biçimini ve ajan için satır içi yönergeleri bildirir. templates/ ve examples/ klasörleri isteğe bağlıdır ama büyük bir ağırlık taşır: örnekler, ajanın örüntü eşleştirmesi yapabileceği bilinen-iyi eserlerdir ve bu da "bana bir sunum yap" dediğinizde tutarlı bir şey üretilmesiyle doğaçlama bir şey üretilmesi arasındaki farktır.
Ön bilgi (front matter), daemon'un beceriyi kaydetmek için okuduğu kısımdır; gövde ise ajanın onu yürütmek için okuduğu kısımdır:
---
name: guizang-ppt
trigger: a deck, slide presentation, or pitch
output: HTML (exportable to PDF, PPTX)
---
Build a horizontal slide deck. One idea per slide.
Lead with a cover, close with a call to action.
Respect the locked-in design system for color, type, and spacing.
Pattern-match against examples/ for layout density and rhythm.
Dosyanın neden kayıt defteri olduğu
Daemon başladığında, skills/ klasörünü tarar ve SKILL.md içeren her klasörü kaydeder. Eklenti bildirimi yoktur. Sürüm alanı yoktur. Yükleme adımı, inceleme kuyruğu, derleme yoktur. Sadece dosya vardır ve dosya, gerçeğin kaynağıdır. Yeni bir klasör bırakın, daemon'u yeniden başlatın ve beceri seçicide görünür. Onu silin ve gider — artık var olmayan bir koda işaret eden öksüz bir kayıt defteri girişi kalmaz.
Şu anda 31 beceri sunuyoruz. Bazıları sunum üreteci, bazıları mobil maket üretir, bazıları editöryel sayfalar oluşturur, bazıları ofis belgeleri (Word, Excel, PowerPoint) yazar. Her biri, çatallayabileceğiniz, düzenleyebileceğiniz veya değiştirebileceğiniz bir klasördür. Sözleşme düz metin olduğu için, "bir beceri yazmak" ve "ne yaptığını anlamak için bir beceriyi okumak" aynı etkinliktir — onu açarak denetlersiniz.
Sistemler: zevk birimi
Bir beceri ne yapılacağını tanımlıyorsa, bir sistem nasıl görünmesi gerektiğini tanımlar. Bir sistem, bir DESIGN.md dosyası artı isteğe bağlı referans varlıklarıdır. Görsel bir kimliği makine tarafından okunabilir biçimde tanımlar:
- Renk — ön plan, arka plan, vurgu, hata vb. için OKLch değerleri
- Tipografi — font yığını, ağırlıklar, tipografi rampası, satır yüksekliği gelenekleri
- Boşluk — temel birim, boşluk ölçeği, kapsayıcı genişlikleri, oluk kuralları
- Yerleşim duruşu — ızgara seçimleri, asimetri kuralları, yoğunluk tercihleri
- Ses — kelimelerin tipografisi: ton, kelime dağarcığı, cümle ritmi
Bir DESIGN.md bir sözleşmedir, bir bileşen kütüphanesi değil
Pratikte bir DESIGN.md, bir ajanın yanlış yorumlayamayacağı kısa, görüş sahibi bir marka brief'i gibi okunur:
## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);
## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height
## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.
Renkler OKLch'tir, böylece açık ve koyu yüzeyler arasında algısal olarak dengeli kalırlar; tipografi rampası, ajanın dışına sapmayacağı bir merdivendir; duruş kuralları ise tek bir ürün gibi hissettiren on üretilmiş ekran ile on farklı stajyer gibi hissettiren on ekran arasındaki farktır. Ajan bunu bir kez okur ve tüm iş boyunca buna saygı gösterir.
Bir sistem, bir Figma kütüphanesi değildir. Sizinle kurallar arasında duran hiçbir bileşen, varyant, iç içe örnek veya ikili format yoktur. Herhangi bir ajanın okuyabileceği ve herhangi bir insanın denetleyebileceği bir sözleşmedir. Kutudan çıktığı haliyle 72 sistem sunuyoruz; bunlara Linear, Vercel, Stripe, Apple, Cursor, Figma'nın taşınabilir sürümleri ve uzun bir editöryel ve marka sistemi listesi dahil.
Karıştırın, çatallayın, sahiplenin
Bir sistem sadece metin olduğu için, birini çatallayıp yerinde düzenleyebilir, bir varyant gönderebilir veya yaklaşık 30 dakikalık odaklanmış bir çalışmayla sıfırdan kendinizinkini yazabilirsiniz. Hatta proje ortasında sistemleri karıştırabilirsiniz — Linear'dan tipografi, Vercel'den renk mantığı, kurum içi bir spesifikasyondan yerleşim — çünkü hiçbir şey tescilli bir ikili formata kilitli değildir. skills/ ve design-systems/ klasörleri arasındaki ayrım kasıtlıdır: yetenek ve zevk birbirinden bağımsızdır, böylece herhangi bir beceri herhangi bir sistem altında çalışabilir ve herhangi bir sistem herhangi bir beceriyi yönlendirebilir.
Adaptörler: ajan birimi
Beceriler ve sistemler hareketsiz metinlerdir. Adaptörler ise onları işi gerçekte yapan ajana bağlayan az miktarda koddur. Bir adaptör, adapters/ içinde şunları yapmayı bilen kısa bir TypeScript dosyasıdır:
- ajanın kullanıcının
$PATHortamına kurulu olup olmadığını tespit etmek - o ajanla bir oturum başlatmak
- bir beceri çağrısını içeri aktarmak
- çıktıyı geri toplamak
Bugün 12 ajan için adaptör sunuyoruz: Claude, Codex, Gemini, Cursor, Copilot, OpenCode, Devin, Hermes, Pi, Kimi, Kiro, Qwen. Daemon, hangilerinin mevcut olduğunu otomatik olarak tespit eder ve ilk açılışta bunları bir açılır menü olarak sunar — hiçbir şey yapılandırmazsınız, sadece zaten sahip olduğunuz ajanları görürsünüz.
| İlkel öğe | Şurada bulunur | Dosya | Gerçeğin kaynağı |
|---|---|---|---|
| Beceri | skills/ | SKILL.md | diskteki dosya |
| Sistem | design-systems/ | DESIGN.md | diskteki dosya |
| Adaptör | adapters/ | bir .ts dosyası | bir register() çağrısı |
Yeni bir adaptör eklemek isterseniz, dosya kabaca 80 satır TypeScript ve tek bir register() çağrısından ibarettir. Öğrenilecek bir SDK, istenecek bir izin, yayımlanacak merkezi bir kayıt defteri yoktur. Dizüstü bilgisayarınızda zaten güvendiğiniz aynı ajan motor olur — Open Design onu asla değiştirmez. (Tamamlayıcı yazı BYOK tasarım iş akışı, bir adaptörü kendi anahtarınıza yöneltme konusunu inceler.)
Daemon: hepsini birbirine bağlayan döngü
Daemon, sistemdeki çalışan tek süreçtir. pnpm tools-dev ile başlattığınız küçük bir Node sürecidir ve sırayla dört şey yapar:
- Tespit — açılışta, kurulu ajanlar için
$PATHortamını ve kurulu beceriler içinskills/klasörünü tarar - Keşif — mevcut brief için yüzeyi, hedef kitleyi, tonu, ölçeği ve marka bağlamını belirlemek üzere etkileşimli bir soru formu açar
- Yönlendirme — 5 deterministik görsel yön (OKLch'te palet, font yığını, yerleşim duruşu ipuçları) sunar ve kullanıcıdan birini seçmesini ister
- Teslimat — seçilen beceriyi kilitlenmiş sistemle çağırır, ajanın diske yazmasına izin verir ve çıktıyı korumalı bir iframe'de önizler
Tüm döngü kabaca 1500 satır koda sığar. Kasıtlı olarak küçüktür. Zekâ çalışma zamanında değil, becerilerdedir — daemon'un görevi klasörleri taramak, bir brief'i dört adımdan geçirmek ve yoldan çekilmektir. Bu küçüklük asıl meseledir: burada çürüyebilecek çok az şey, çalışmanızı rehin alabilecek neredeyse hiçbir şey yoktur.
Pratikte nasıl hissettirdiği
Diyelim ki yeni bir ürün özelliği için bir lansman sunumu istiyorsunuz. İşte akış:
- Bir terminalde
pnpm tools-devkomutunu çalıştırırsınız. Daemonlocalhost:7780üzerinde başlar. - URL'i açarsınız. Daemon size bulduğu ajanları gösterir (örn. Claude, Cursor, Codex).
- Beceri listesinden
guizang-pptseçersiniz. - 30 saniyelik bir soru formu açılır: hedef kitle kim, ton nedir, marka bağlamı nedir.
- Size 5 görsel yön gösterilir — farklı paletler, tipografi eşleştirmeleri, yerleşim duruşları. Birini seçersiniz.
- Ajan diske yazar. Korumalı bir iframe sonucu gösterir. HTML, PDF, PPTX, ZIP veya Markdown olarak dışa aktarabilirsiniz.
İlkel öğeler üzerinden geriye doğru izlediğinizde her şey okunaklı hale gelir: 3. adım bir beceri seçti, 5. adım bir sistem kilitledi, arkasındaki ajan bir adaptör aracılığıyla geldi ve daemon dört adımlı döngüyü çalıştırdı. Çıktı gerçektir. Dosyalar sizindir. Onları herhangi bir düzenleyicide düzenleyebilir, bir tasarımcıya verebilir veya başka bir beceriye geri besleyebilirsiniz.
Neden veritabanı değil de dosyalar
Her ilkel öğe — beceriler, sistemler, adaptörler — bir metin dosyası klasörüdür. Merkezi bir veritabanı yoktur. Bir "Open Design hesabı" yoktur. Çalışmanızın çalışmaya devam etmesi için çalışmaya devam etmesi gereken barındırılan bir hizmet yoktur.
Bu kasıtlı bir ödünleşimdir. Kullanıcılar arası zekice analizler, projeler arası bellek veya barındırılan iş birliği yapma yeteneğinden vazgeçiyoruz. Karşılığında şunları kazanıyoruz: taşınabilirlik, kalıcılık, denetlenebilirlik ve herkesin tüm kütüphaneyi çatallayıp kendi varyantını gönderebilmesi. Bugün yazılan bir SKILL.md, iki yıl sonraki bir ajana ve hiçbir araca sahip olmayan bir insana da aynı şekilde okunur — geçen yılın API'sine sabitlenmiş bir eklenti için aynı şey söylenemez.
Bir nesil tasarım aracının dosyalarınızı da yanlarında götürerek öldüğünü izlediyseniz, bu ödünleşimin neden buna değer olduğunu anlarsınız.
İlgili okumalar
- Open Design'ı neden bir ürün değil, bir beceri katmanı olarak inşa ettik — dört ilkel öğenin arkasındaki bahis
- BYOK tasarım iş akışı: Claude, Codex veya Qwen'i kendi anahtarınızla çalıştırın — adaptörlerin zaten ödeme yaptığınız ajana nasıl bağlandığı
- Tuvalin gizlemeye alışık olduğu yerleşim katmanı — bir DESIGN.md'deki duruş kurallarının bir tuvalde kutuları sürüklemeyi neden geride bıraktığı