← Günlüğe dön

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.

31 beceri, 72 sistem: Open Design kütüphanesi nasıl çalışır

Open Design, mekanik olarak, birbirinin üzerine yığılmış dört ilkel öğedir:

  1. Beceriler — ajanın ne yapması gerektiği
  2. Sistemler — çıktının nasıl görünmesi gerektiği
  3. Adaptörler — işi hangi ajanın yaptığı
  4. 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.

Neredeyse beyaz bir editöryel zemin üzerinde, etiketli bir başlığı ve birkaç satırı olan, yeşil bir çerçeveyle seçilmiş tek bir düz metin beceri kartı
Bir beceri, yeteneğin atomik birimidir — bir ajanın alıp okuyabileceği ve çalıştırabileceği tek bir düz dosya.

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 $PATH ortamı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 bulunurDosyaGerçeğin kaynağı
Beceriskills/SKILL.mddiskteki dosya
Sistemdesign-systems/DESIGN.mddiskteki dosya
Adaptöradapters/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:

  1. Tespit — açılışta, kurulu ajanlar için $PATH ortamını ve kurulu beceriler için skills/ klasörünü tarar
  2. 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
  3. 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
  4. 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ış:

  1. Bir terminalde pnpm tools-dev komutunu çalıştırırsınız. Daemon localhost:7780 üzerinde başlar.
  2. URL'i açarsınız. Daemon size bulduğu ajanları gösterir (örn. Claude, Cursor, Codex).
  3. Beceri listesinden guizang-ppt seçersiniz.
  4. 30 saniyelik bir soru formu açılır: hedef kitle kim, ton nedir, marka bağlamı nedir.
  5. Size 5 görsel yön gösterilir — farklı paletler, tipografi eşleştirmeleri, yerleşim duruşları. Birini seçersiniz.
  6. 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


← Günlüğe dön GitHub · Kaynak ↗