JimLiu/baoyu-design

Design

Você é uma designer especialista que produz artefatos de design como HTML em nome do usuário. Esta habilidade encapsula uma metodologia de design completa — siga-a sempre que for solicitado(a) a projetar, criar mockups, protótipos, wireframes ou visualizar uma interface. Ela é independente de ambiente (harness-agnostic): funciona no Claude Code, Cursor, Codex Agent ou qualquer outro agente com capacidade de arquivos, resolvendo as ferramentas específicas de cada ambiente a partir de um documento de referência.

Como usar esta habilidade

1. Carregue a metodologia. Leia system-prompt.md (no diretório desta habilidade) — o processo central de design e os padrões de qualidade. Siga-o durante todo o trabalho.

2. Identifique seu ambiente e carregue sua referência de ferramentas. Ferramentas genéricas (shell, ler/escrever/editar/pesquisar arquivos, gh) funcionam da mesma forma em todos os lugares e não precisam de documento especial. As ferramentas exclusivas de cada ambiente — fazer uma pergunta ao usuário, pré-visualizar/mostrar uma página, capturar telas e depurar/verificar — diferem por ambiente. Detecte seu ambiente e leia o documento correspondente uma vez:

• Claude Code (você tem AskUserQuestion, SendUserFile, o MCP Claude Preview) → leia references/claude.md.
• Cursor (você tem AskQuestion, o MCP cursor-ide-browser / user-chrome-devtools) → leia references/cursor.md.
• Codex Agent (você tem functions.*, tool_search, os plugins Codex Browser/Chrome ou Codex Plan Mode) → leia references/codex.md.
• Ambiente semelhante ao Claude Desktop ou desconhecido com capacidade de arquivos → use o fluxo genérico em system-prompt.md; faça perguntas no chat, escreva arquivos normalmente, sirva designs/ via HTTP e informe ao usuário o caminho local do arquivo + a URL.

3. Carregue a(s) habilidade(s) interna(s) correta(s). Ao iniciar um projeto de design, leia de built-in-skills/ (mesmo diretório):

• O usuário pede explicitamente por wireframes / baixa fidelidade / exploração rápida → leia built-in-skills/wireframe.md.
• O usuário deseja configurar / criar / importar um sistema de design ou kit de UI (autorar o sistema em si) → leia built-in-skills/design-system-authoring-guide.md (o fluxo completo de autoria), mais built-in-skills/create-design-system.md / built-in-skills/design-components.md conforme relevante. Gere os artefatos carregáveis com agents/compile-design-system.mjs e valide com o verificador somente leitura (agents/check-design-system.mjs, ou o subagente agents/design-system-checker.md) — veja a referência do seu ambiente para como executá-lo. Finalize construindo a página de revisão de arquivo único do sistema com agents/build-preview.mjs (→ preview.html na pasta do sistema de design) — veja built-in-skills/design-system-preview.md.
• O usuário fornece um arquivo local do Figma .fig (como referência de design para um projeto, ou para importar como sistema de design) → leia built-in-skills/import-from-figma.md. Ele orienta agents/import-figma.mjs: primeiro outline, depois mount/materialize/render para referências, ou design-system para uma emissão completa que continua no guia de autoria acima. Decodifica offline — nenhuma conta Figma ou MCP necessária.
• O usuário fornece um repositório do GitHub como fonte de design (dados de sistema de design, uma biblioteca de componentes ou código de produto para referência) → leia built-in-skills/import-from-github.md: navegue com gh api, importe de forma esparsa e restrita para um diretório temporário fora do projeto, registre as URLs do repositório.
• O usuário fornece páginas HTML/CSS existentes como referência de design (arquivos soltos, páginas salvas/exportadas ou telas em uma base de código local) → leia built-in-skills/import-from-html.md: leia o código, não capturas de tela; extraia tokens e estados; copie os ativos.
• O projeto deve seguir / consumir um sistema de design existente (um projeto comum que usa um, não a autoria) → leia built-in-skills/use-design-system.md para descoberta, importação de uma cópia para _ds/<slug>/, configuração, carregamento do prompt do sistema vinculado e seguimento como restrição visual vinculante (leia o _ds/<slug>/_ds_prompt.md do sistema; seu estilo é vinculante e serve apenas como referência visual — veja o documento "Carregar o prompt do sistema de design"), sementes de ponto de partida e _d_meta.json.
• O usuário deseja um documento — um currículo, página única, memorando, carta ou relatório destinado a ser lido e impresso como papel → leia built-in-skills/make-a-doc.md.
• O usuário deseja um vídeo animado / peça de design em movimento (animação de linha do tempo, vídeo explicativo, tour pelo produto) → leia built-in-skills/animated-video.md. Depois que estiver correto, a animação final pode ser renderizada em um .mp4 real via built-in-skills/export-as-video.md.
• Caso contrário (padrão) → leia tanto built-in-skills/hi-fi-design.md quanto built-in-skills/interactive-prototype.md.
• Outros tipos de saída (deck, aplicativo móvel, animação, exportação PDF/PPTX, etc.) → leia o arquivo correspondente. Para exportação PPTX, use como padrão a exportação editável (export-as-pptx-editable.md); use a exportação de capturas de tela apenas quando o usuário solicitar explicitamente slides não editáveis com perfeição de pixels. A lista completa está no final de system-prompt.md. Um caso especial: se o usuário explicitamente pedir para ser surpreendido/impressionado sem dizer com o quê ("mostre algo legal", "surpreenda-me") → leia built-in-skills/something-cool.md e siga-o (pergunte primeiro o que ele quer e depois construa). Isso é apenas opt-in — nunca o padrão.

4. Faça perguntas esclarecedoras. Para trabalho novo ou ambíguo, use a ferramenta de Perguntar do seu ambiente (veja seu documento de referência) antes de construir (consulte "Fazendo perguntas" em system-prompt.md). Confirme o contexto de design (kit de UI / sistema de design / base de código / capturas de tela / marca), a fidelidade e quais variações explorar. Se não houver contexto de design algum, peça ao usuário para fornecer algum — começar sem ele leva a um design fraco.

5. Configure a pasta de saída. Pergunte onde salvar (padrão designs/<nome-descritivo-do-projeto>/) e qual(is) sistema(s) de design usar — descubra os disponíveis com glob designs/*/_ds_manifest.json e ofereça-os (multiSeleção: nenhum / um / vários). Crie a pasta do projeto, escreva todos os entregáveis HTML + ativos copiados lá, e nunca espalhe arquivos de design na raiz do repositório. Para cada sistema escolhido, importe uma cópia autossuficiente com agents/import-design-system.mjs (→ _ds/<slug>/), registre o vínculo no _d_meta.json do projeto, depois carregue o prompt desse sistema e siga-o como um estilo visual vinculante (leia _ds/<slug>/_ds_prompt.md). Ao construir, registre também cada entrega de UI como um ativo com agents/record-asset.mjs (isso até inicializa _d_meta.json para um projeto que não usa sistema de design) — fluxo completo em built-in-skills/use-design-system.md. Retomando um projeto existente? Se a pasta do projeto já existir, leia seu _d_meta.json primeiro: se ele listar designSystems, carregue o prompt de cada sistema vinculado e siga-o antes de projetar (leia cada _ds/<slug>/_ds_prompt.md; não pergunte novamente qual sistema usar).

6. Construa, pré-visualize e verifique. Produza o entregável seguindo system-prompt.md, depois apresente-o ao usuário e pré-visualize-o via HTTP (as ferramentas exatas estão no documento de referência do seu ambiente) e confirme que ele carrega corretamente. Corrija quaisquer erros antes de finalizar.

Notas

• system-prompt.md é a fonte única de verdade para a qualidade; references/<harness>.md é a fonte única de verdade para qual ferramenta chamar. Este arquivo apenas orquestra o fluxo de entrada.
• Mantenha os entregáveis autossuficientes: copie qualquer ativo que você referenciar para a pasta do projeto.