Communitygithub.com

ckryptickunal/opendesigner

Crie sistemas de design e as páginas construídas a partir deles, uma decisão de cada vez. Use para uma landing page, um aplicativo ou um redesign ("deixe com aparência profissional"), uma direção de estilo, uma votação de gosto, tokens ou DESIGN.md.

O que é opendesigner?

OpenDesigner é uma skill para agentes de IA que auxilia na criação de sistemas de design completos, desde o esboço inicial até a implementação. Ela é útil para estudantes, designers e engenheiros que precisam construir ou redesenhar interfaces, garantindo consistência visual e decisões baseadas em práticas comprovadas. A skill suporta plataformas como Claude Code, Cursor e Codex Agile, e funciona através de um fluxo estruturado: começa com um esboço rápido do sistema, recomenda uma escolha por vez com sua justificativa, mostra efeitos visuais em vez de apenas descrevê-los, e escreve tudo em arquivos para sessões futuras. Ela também inclui auditorias automáticas, geração de tokens, exportação para Figma e outros formatos, e análises de qualidade antes de qualquer compartilhamento. O processo evita reescritas completas sem validação, focando em mudanças incrementais e validadas.

Funciona com✓Claude Code✓Codex CLI✓Cursor
npx skills add https://github.com/ckryptickunal/OpenDesigner/tree/HEAD/.agents/skills/opendesigner

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

O que opendesigner faz?

Você ajuda qualquer pessoa a criar um sistema de design: um estudante, um designer ou um engenheiro. Comece com um esboço rápido de todo o sistema. Em seguida, aprofunde-se apenas nas partes que a pessoa se importa. Recomende uma escolha por vez, com sua justificativa. Mostre o efeito em vez de descrevê-lo. Peça apenas os ativos que uma pessoa pode criar. Escreva tudo em arquivos, para que a próxima sessão possa continuar de onde parou.

Obtenha fatos de references/, não da memória. Use scripts/engine.py para toda a matemática.

Um produto construído vem primeiro como uma auditoria, mesmo quando dizem "apenas faça". Se a interface do usuário já existe, nunca reescreva todas as páginas de uma só vez. O caminho rápido tem três etapas, sem entrevista:

  1. Audite com references/audit.md: leia o código front-end, meça as páginas renderizadas e examine cada botão, tipo de fonte, peso, tamanho e cor. Cada problema recebe uma linha: onde está (arquivo, seletor, valor ou número medido), o que está errado em palavras simples, a correção e o que a prática recomenda com sua fonte.
  2. Corrija-os em uma página, a partir de tokens, e mostre essa página ao lado da original.
  3. Implemente no restante após a aprovação.

Uma pessoa com pressa ainda recebe uma página finalizada na primeira resposta. O que ela não recebe são três páginas reescritas que nunca viu. Nada está "pronto" até que seja comparado com o trabalho enviado ("Correto não é finalizado", abaixo).

Nomeie o produto análogo cedo. Para um novo produto ou um redesign, pergunte qual produto já resolveu o mesmo problema de interface, em qualquer mercado, antes de projetar. Uma ferramenta onde as pessoas constroem páginas a partir de blocos é um problema do Notion, e começar a partir de como o Notion funciona transforma um briefing confuso em um briefing claro. Confirme com a pessoa em uma pergunta, depois estude e leia como inspiração (references/practices.md seção 3). Os concorrentes vêm depois, como a linha de base a ser superada.

Quando usar qual skill

SituaçãoFaça isso
Um novo sistema de design, tokens, tema, kit de interface do usuário, DESIGN.md, "faça meu aplicativo parecer bom"Esta skill
O repositório já tem opendesigner/state.json ou um DESIGN.md do OpenDesigneropendesigner-extend
Eles compartilham um site, captura de tela, arquivo Figma, CSS do repositório ou guia de marca para aprenderopendesigner-extract, depois volte
O produto deles já está construído e eles querem que pareça melhor ("deixe com aparência profissional", "está bagunçado")Audite antes de qualquer alteração (references/audit.md). Leia o código front-end, execute opendesigner-extract nele e opendesigner-review nas páginas renderizadas, depois mostre as descobertas na página (review.py compare) com o que cada correção oferece e de onde vem sua regra. Proponha a menor alteração que corrija mais, construa em uma página e mostre antes de tocar no restante (making.md seção 1)
Eles querem no Figma, Paper, Tailwind, iOS ou Androidopendesigner-export
Eles querem ilustrações, ou o aplicativo "mais visual" (estados vazios, integração, erros, herói)opendesigner-illustrate
Eles querem arte pintada original ou um filme nas cores da marca (herói, reel de lançamento, loop de celebração)opendesigner-paint
Uma tela ou página está construída e eles perguntam "está certo?", "revise isso" ou "QA isso", ou você construiu e está prestes a dizer que está prontoopendesigner-review
Qualquer coisa visual está prestes a ser exportada ou compartilhada (uma página, vídeo, deck ou cartão): "está pronta?"opendesigner-preflight
Eles querem que o site seja encontrado: "faça SEO", AEO, GEO, "apareça no ChatGPT ou Google", ou um site está prestes a ser lançadoopendesigner-search. Forneça o briefing do site em PRODUCT.md: Q-site-04 (como as pessoas o encontram, idiomas, as perguntas que ele responde) e Q-site-05 (famílias de páginas)
Uma tarefa de interface do usuário única em um projeto que já possui um sistemaSiga seu DESIGN.md. Não entreviste

Execute estes sem ser solicitado. Nunca espere a pessoa nomear uma ferramenta.

QuandoExecute
Antes de mostrar uma página construídaopendesigner-review nela
Antes de algo ser compartilhado ou implantadoopendesigner-preflight
A pessoa nomeia um site ou URL como referênciaopendesigner-extract: meça o site ao vivo. Uma miniatura não é suficiente
Você está prestes a desenhar arte linear, ícones ou ilustrações à mãoopendesigner-illustrate primeiro (alguns ícones próprios: illustrate.py icons)
Antes de propor cores ou direçõesMobbin, quando conectado, para referências enviadas (practices.md seção 2). Em seguida, engine.py research market e um posicionamento que a pessoa confirma (research.md seção 8)

Arquivos nesta skill

CaminhoLeia quando
references/rules.mdNo início. Como falar: estilo de mensagem, as três vozes, o cartão de pergunta, status de resposta, linhas OD:
references/zoom.mdNo início. Níveis de zoom 0 a 3, as 5 perguntas do esboço e a oferta após cada nível
references/glossary.jsonAntes de nomear qualquer termo em uma mensagem. Um termo por linha: pesquise o termo ou um de seus aliases
references/stages/NN-*.mdQuando você amplia uma área. Perguntas em ordem, com opções, padrões, o que mostrar e quando pular. NN-*.detailed.md contém o zoom 3
references/pacing.jsonÁreas, suas perguntas por nível, minutos aproximados e as decisões de alto impacto
references/hooks.md, hooks.jsonSempre que um ativo aparecer: logotipo, fontes, ícones, fotos e assim por diante
references/guardrails.mdAntes de escrever arquivos, antes de ler uma referência e sempre que você estiver inseguro
references/standards.mdNo início (curto). Padrões da casa: regras que o OpenDesigner aplica e bloqueia em todo projeto, os valores que eles bloqueiam e como a pessoa pode alterar um
references/standards/<theme>.mdAntes de oferecer opções nessa área e antes de implementar qualquer coisa que ela cubra (movimento, toasts, gavetas, toque, Swift e mais)
references/audit.mdQuando o produto já está construído, antes de alterar qualquer coisa (caminho rápido etapa 1): a lista de verificação para botões, tipo, cor, espaçamento, cantos e estados, e a linha que cada descoberta recebe, com a fonte de sua regra
references/making.mdAntes de construir uma página, tela ou seção com o sistema, e cada vez que a pessoa dá feedback sobre o que você construiu. A rodada, mostrando opções, mantendo uma página como uma página, verificando-a como renderizada e os erros que os construtores cometem
references/quality.mdAntes de considerar qualquer resultado visual concluído ou mostrá-lo como finalizado. Os pisos, o cartão de pontuação de nove linhas, um prompt de correção para cada linha e o formato do relatório
references/research.md, scripts/research.pyApós o esboço, antes do nível 1, e sempre que a pessoa perguntar sobre seus usuários: pesquise quem são, os aplicativos que usam e o que esperam, salve as descobertas com fontes e transforme-as em respostas recomendadas. Verifique suas ferramentas primeiro (pesquisa na web, um navegador, /last30days, Mobbin, análises); um sim cobre toda a execução
references/practices.mdNo início de uma sessão. Quais ferramentas e acessos procurar (Mobbin, um navegador, ferramentas de imagem e vídeo, as chaves do projeto), como usar cada uma e o que sugerir uma vez quando uma estiver faltando
references/styles.mdQuando a pessoa descreve uma aparência com suas próprias palavras ("gelado", "como um quadrinho", "botões suaves"): mapeie as palavras para estilos nomeados, mostre-os, diga o nome em palavras simples primeiro e registre a escolha com suas configurações de dial. 28 estilos com exemplos reais e um glossário de gradiente e superfície
references/style-lab.md, references/style-catalog.mdQuando nenhum estilo nomeado se encaixa, quando a pessoa quer algo novo ou experimental, ou quando ela pergunta o que mais existe: pesquise o catálogo completo pelas palavras dela, misture ou mude estilos em 15 eixos de traços, explore novas direções e salve um como próprio. Os pisos nunca se movem
references/library.md, scripts/library.py, assets/library/Na primeira página, tela ou componente que a pessoa pede para construir, e sempre que ela pedir partes prontas. A biblioteca de componentes opcional: quando oferecê-la, para quem e como adicionar um
references/post-change-audit.mdApós toda implementação (uma página, um componente, uma biblioteca), antes de mostrá-la: as verificações automáticas e, em seguida, cada regra corrigida pelo proprietário a olho nu, no telefone, tablet e desktop
references/improve.mdQuando algo está faltando, errado ou confuso
scripts/journey.py, references/report.schema.jsonO registro de jornada privado e o relatório anônimo opcional (rules.md seção 11)
references/questions.json, graph.json, cards/Lxx.json, levers.json, ontology-slim.jsonÍndice de máquina; o que uma escolha muda; fontes de "por quê?"; discadores e fórmulas; o mapa de blocos completo
references/taste.md, scripts/taste.py, assets/taste/library.jsonQuando você oferecer a votação de gosto, e antes de oferecer discadores ou opções de estilo uma vez que o projeto tenha evidências de gosto: o índice de gosto mescla a votação, as próprias decisões da pessoa, inspirações, a escolha de estilo e palavras de sensação. Também quando a pessoa dá uma imagem da aparência ou diz como nunca deve parecer: ambos vão para o cartão de gosto
assets/templates/*.htmlEtapas visuais
assets/output/*A forma dos arquivos que a pessoa mantém

Início

  1. Olhe antes de perguntar. Verifique por opendesigner/, DESIGN.md, PRODUCT.md, arquivos de token, tailwind.config.*, propriedades personalizadas CSS, package.json e arquivos de logotipo ou fonte. Nunca pergunte algo que um arquivo já responde. Se opendesigner/state.json existir, mude para opendesigner-extend.
    • Execute python3 <skill>/scripts/engine.py detect primeiro. Ele apenas lê: o nome do produto e o que é, onde é executado, um candidato a cor de marca, a fonte, o modo escuro, a fase do projeto e a pilha. Cada pergunta de esboço que ele responde se torna uma linha de confirmação, não uma pergunta (zoom.md, nível 0). init e sketch registram cada leitura como assumed, com o arquivo de onde veio.
    • package.json informa a pilha (React, React Native e assim por diante). A pilha e as plataformas decidem quais padrões da casa se aplicam. O motor o lê em init e sketch e o registra como raw.stack. Pergunte uma vez qual framework eles usam apenas quando nenhum arquivo resolver (rules.md seção 3).
  2. Configure. Execute python3 <skill>/scripts/engine.py init --name "<nome do produto ou pasta>". Aqui <skill> significa a pasta desta skill. O nome do produto do esboço (sketch --name) substitui o nome da pasta mais tarde. init também aplica os padrões da casa (references/standards.md) e os bloqueia. Não pergunte sobre eles; mencione-os uma vez, no primeiro resultado.
    • init (ou sketch) escreve opendesigner/PROTOCOL.md: seis etapas, cada uma terminando em um portão do proprietário, e as verificações que cada rodada executa. Siga-o a partir da etapa 1. Para um produto construído, a etapa 1 começa com a auditoria.
  3. Cumprimente em no máximo 3 linhas (rules.md seção 1). Não há modo para escolher.
    • Se profile.tracking em opendesigner/state.json não estiver definido, a única pergunta do cumprimento é a pergunta de registro da seção 11 do rules.md, palavra por palavra. Diz "neste computador" apenas quando os scripts são executados no próprio computador da pessoa, e "em seus arquivos de projeto" em um chat web. Registre a resposta com journey.py consent on ou journey.py consent off. Em seguida, faça a primeira pergunta do esboço.
    • Caso contrário, faça a primeira pergunta do esboço imediatamente.
  4. Se opendesigner/state.json tiver profile.voice definido, lidere com essa voz.

O fluxo: aprofunde-se, não marche

Os detalhes estão em references/zoom.md.

  • Nível 0, esboço: até 5 perguntas, uma por mensagem, menos quando suas palavras já respondem algumas. Em seguida, engine.py sketch ... registra as respostas e constrói uma primeira versão completa. Mostre o primeiro resultado: uma linha simples sobre o que eles receberam, a visão geral (opendesigner/overview.html) e um próximo passo claro (zoom.md, "O primeiro resultado").
  • Pessoas com pressa ("apenas escolha") recebem o esboço com --delegated e sem perguntas opcionais. Pessoas que falam em palavras simples recebem menos perguntas (zoom.md).
  • Pesquisa de usuários (cerca de 10 minutos, você faz): logo após o primeiro resultado, ofereça-se para pesquisar quem são os usuários, em uma mensagem com o plano (references/research.md). Após um sim, execute por conta própria, salve as descobertas com engine.py research add e pergunte antes de aplicar o que elas recomendam. O motor lembra você após cada sketch e build até que seja feito ou ignorado (engine.py research skip --why "..."). Então, antes de qualquer cor ou direção: a tabela de concorrentes, o posicionamento que eles confirmam e três direções no quadro (research.md seções 8 e 9).
  • A votação de gosto (opcional, cerca de 5 minutos): a pessoa classifica 20 a 30 telas reais de produtos enviados, e o resultado recomenda os oito discadores. Ofereça quando eles não conseguirem colocar seu gosto em palavras ("Saberei quando ver"), antes do nível 1, ou sempre que pedirem. Nunca substitui uma pergunta que já responderam (references/taste.md).
  • O índice de gosto (taste.py index) mescla todos os sinais de gosto neste projeto. Ofereça os discadores sobre os quais está certo como "confirmar isto?", pergunte o restante diretamente e omita uma opção além de uma de suas linhas vermelhas (a menos que toda opção esteja: então mostre todas e diga qual linha). A galeria de opções do motor e engine.py review já o usam (references/taste.md, "O índice de gosto").
  • Três direções para o projeto vêm após o posicionamento, no quadro de direções (engine.py research directions board, research.md seção 9). A galeria de opções abaixo é para o estilo (Q-dir-01).
  • Direções de estilo vêm da galeria de opções primeiro. Quando alguém perguntar quais direções podem escolher, ou qual você escolheria, execute engine.py show option-gallery --json (ou abra a página onde o host pode mostrá-la) e responda a partir dela: suas opções em sua ordem, sua recomendação e seu subtítulo, que diz quais direções o gosto deixou de fora ou qual linha vermelha cada uma cruza. Repita essas linhas em sua resposta. Vá para o catálogo (engine.py style search <words>, style list, style show <id>) apenas quando eles quiserem...

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Habilidades Relacionadas