31 skills, 72 sistemas: como funciona a biblioteca do Open Design

O Open Design é, mecanicamente, quatro primitivas empilhadas umas sobre as outras:

1. Skills — o que o agente deve fazer
2. Sistemas — como a saída deve parecer
3. Adaptadores — qual agente faz o trabalho
4. O daemon — o loop que conecta tudo

Cada primitiva é uma pasta de arquivos. Nenhuma delas exige um banco de dados, um runtime de plugin ou um serviço hospedado. Essa é a biblioteca inteira — não há um quinto conceito escondido atrás de um muro de login. Este post percorre cada uma por vez e mostra o que acontece quando você aponta seu agente para um briefing real. Se você quer o argumento de por que a moldamos assim antes do como, comece com por que construímos o Open Design como uma camada de skills, não um produto.

Skills: a unidade de capacidade

Uma skill é uma pasta contendo um SKILL.md e zero ou mais arquivos de apoio. O arquivo Markdown é o contrato do agente — todo o resto na pasta está ali para ajudar o agente a cumpri-lo.

Anatomia de uma pasta de skill

Uma skill típica é assim:

skills/
  guizang-ppt/
    SKILL.md
    templates/
      magazine.html
    examples/
      product-launch.html
      pitch-deck.html

O SKILL.md declara o nome da skill, as condições de gatilho, o formato de entrada, o formato de saída e qualquer orientação inline para o agente. As pastas templates/ e examples/ são opcionais, mas carregam muito peso: os exemplos são artefatos comprovadamente bons contra os quais o agente pode fazer correspondência de padrões, o que é a diferença entre “me faça um deck” produzir algo coerente versus algo improvisado.

O front matter é a parte que o daemon lê para registrar a skill; o corpo é a parte que o agente lê para executá-la:

---
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.

Por que o arquivo é o registro

Quando o daemon inicia, ele varre skills/ e registra toda pasta que contenha um SKILL.md. Não há manifesto de plugin. Não há campo de versão. Não há etapa de upload, fila de revisão ou build. Há o arquivo, e o arquivo é a fonte da verdade. Coloque uma nova pasta, reinicie o daemon, e a skill aparece no seletor. Apague-a, e ela some — sem entrada de registro órfã apontando para código que não existe mais.

Atualmente entregamos 31 skills. Algumas são geradoras de deck, algumas produzem mockups mobile, algumas constroem páginas editoriais, algumas escrevem documentos de escritório (Word, Excel, PowerPoint). Cada uma é uma pasta que você pode forkar, editar ou substituir. Como o contrato é texto puro, “escrever uma skill” e “ler uma skill para entender o que ela faz” são a mesma atividade — você a audita abrindo-a.

Sistemas: a unidade de bom gosto

Se uma skill descreve o que fazer, um sistema descreve como deve parecer. Um sistema é um arquivo DESIGN.md mais ativos de referência opcionais. Ele descreve uma identidade visual em forma legível por máquina:

• Cor — valores OKLch para primeiro plano, fundo, destaque, erro e assim por diante
• Tipografia — pilha de fontes, pesos, a escala tipográfica, convenções de entrelinha
• Espaço — unidade base, escala de espaçamento, larguras de container, regras de gutter
• Postura de layout — escolhas de grid, regras de assimetria, preferências de densidade
• Voz — a tipografia das palavras: tom, vocabulário, ritmo das frases

Um DESIGN.md é um contrato, não uma biblioteca de componentes

Na prática, um DESIGN.md se lê como um briefing de marca curto e opinativo que um agente não consegue interpretar errado:

## 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.

As cores são OKLch para que permaneçam perceptualmente uniformes entre superfícies claras e escuras; a escala tipográfica é uma escada da qual o agente não vai se desviar; as regras de postura são a diferença entre dez telas geradas que parecem um único produto e dez que parecem dez estagiários diferentes. O agente lê isso uma vez e respeita pelo trabalho inteiro.

Um sistema não é uma biblioteca do Figma. Não há componentes, nem variantes, nem instâncias aninhadas, nem formato binário se interpondo entre você e as regras. É um contrato que qualquer agente pode ler e qualquer humano pode auditar. Entregamos 72 sistemas prontos de fábrica, incluindo versões portáteis de Linear, Vercel, Stripe, Apple, Cursor, Figma e uma longa cauda de sistemas editoriais e de marca.

Misture, forke, seja dono

Como um sistema é apenas texto, você pode forkar um e editá-lo no lugar, entregar uma variante ou escrever o seu do zero em cerca de 30 minutos de trabalho focado. Você pode até misturar sistemas no meio do projeto — tipografia do Linear, lógica de cor do Vercel, layout de uma especificação interna — porque nada está preso a um binário proprietário. A separação entre as pastas skills/ e design-systems/ é deliberada: capacidade e bom gosto são ortogonais, então qualquer skill pode rodar sob qualquer sistema, e qualquer sistema pode dirigir qualquer skill.

Adaptadores: a unidade de agente

Skills e sistemas são texto inerte. Adaptadores são a pequena quantidade de código que os conecta ao agente que de fato faz o trabalho. Um adaptador é um arquivo TypeScript curto em adapters/ que sabe como:

• detectar se o agente está instalado no $PATH do usuário
• iniciar uma sessão com aquele agente
• encaminhar uma invocação de skill para dentro
• coletar a saída de volta

Hoje entregamos adaptadores para 12 agentes: Claude, Codex, Gemini, Cursor, Copilot, OpenCode, Devin, Hermes, Pi, Kimi, Kiro, Qwen. O daemon detecta automaticamente quais estão presentes e os oferece como um dropdown na primeira inicialização — você não configura nada, apenas vê os agentes que já tem.

Primitiva	Mora em	Arquivo	Fonte da verdade
Skill	skills/	SKILL.md	o arquivo em disco
Sistema	design-systems/	DESIGN.md	o arquivo em disco
Adaptador	adapters/	um arquivo .ts	uma chamada register()

Se você quiser adicionar um novo adaptador, o arquivo tem cerca de 80 linhas de TypeScript e uma única chamada register(). Nenhum SDK para aprender, nenhuma permissão para solicitar, nenhum registro central para publicar. O mesmo agente em que você já confia no seu laptop vira o motor — o Open Design nunca o substitui. (O texto complementar fluxo de design BYOK percorre como apontar um adaptador para a sua própria chave.)

O daemon: o loop que amarra tudo

O daemon é o único processo em execução no sistema. É um pequeno processo Node que você inicia com pnpm tools-dev, e ele faz quatro coisas em sequência:

1. Detectar — varre o $PATH em busca de agentes instalados e skills/ em busca de skills instaladas, na inicialização
2. Descobrir — abre um formulário interativo de perguntas para fixar superfície, público, tom, escala e contexto de marca do briefing atual
3. Direcionar — apresenta 5 direções visuais determinísticas (paleta em OKLch, pilha de fontes, dicas de postura de layout) e pede que o usuário escolha uma
4. Entregar — invoca a skill selecionada com o sistema travado, deixa o agente gravar em disco e pré-visualiza a saída em um iframe em sandbox

O loop inteiro cabe em cerca de 1500 linhas de código. Ele é intencionalmente pequeno. A esperteza está nas skills, não no runtime — o trabalho do daemon é varrer pastas, rotear um briefing pelos quatro passos e sair do caminho. Essa pequenez é o ponto: há muito pouco aqui que pode apodrecer, e quase nada que pode manter seu trabalho refém.

Como é na prática

Suponha que você queira um deck de lançamento para um novo recurso de produto. Veja o fluxo:

1. Você roda pnpm tools-dev em um terminal. O daemon inicia em localhost:7780.
2. Você abre a URL. O daemon mostra quais agentes encontrou (ex.: Claude, Cursor, Codex).
3. Você escolhe guizang-ppt na lista de skills.
4. Um formulário de perguntas de 30 segundos aparece: quem é o público, qual é o tom, qual é o contexto de marca.
5. São mostradas 5 direções visuais — paletas diferentes, pares tipográficos, posturas de layout. Você escolhe uma.
6. O agente grava em disco. Um iframe em sandbox mostra o resultado. Você pode exportar para HTML, PDF, PPTX, ZIP ou Markdown.

Trace de volta pelas primitivas e a coisa toda fica legível: o passo 3 escolheu uma skill, o passo 5 travou um sistema, o agente por trás veio através de um adaptador, e o daemon rodou o loop de quatro passos. A saída é real. Os arquivos são seus. Você pode editá-los em qualquer editor, entregá-los a um designer ou realimentá-los em outra skill.

Por que arquivos, não um banco de dados

Toda primitiva — skills, sistemas, adaptadores — é uma pasta de arquivos de texto. Não há banco de dados central. Não há “conta do Open Design.” Não há serviço hospedado que precise continuar funcionando para que o seu trabalho continue funcionando.

Esse é um trade-off deliberado. Abrimos mão da capacidade de fazer análises espertas entre usuários, memória entre projetos ou colaboração hospedada. Em troca, ganhamos: portabilidade, longevidade, auditabilidade e a capacidade de qualquer um forkar a biblioteca inteira e entregar a própria variante. Um SKILL.md escrito hoje se lê de forma idêntica para um agente daqui a dois anos e para um humano sem ferramenta nenhuma — o mesmo não se pode dizer de um plugin preso à API do ano passado.

Se você viu uma geração de ferramentas de design morrer levando seus arquivos junto, vai entender por que esse trade-off vale a pena.

Leitura relacionada

• Por que construímos o Open Design como uma camada de skills, não um produto — a aposta por trás das quatro primitivas
• Fluxo de design BYOK: rode Claude, Codex ou Qwen com sua própria chave — como os adaptadores se conectam ao agente que você já paga
• A camada de layout que o canvas costumava esconder — por que regras de postura num DESIGN.md ganham de arrastar caixas num canvas