Communitygithub.com

danielmiessler/LifeOS

Projete e integre interfaces web por três caminhos: DirectDesign (escreve o design inline com a filosofia frontend-design da Anthropic — o padrão), comandos nativos /design + /design-sync do Claude Code (preferido para integração de código e sincronia de design system) ou ClaudeDesign (usa o claude.ai/design via Interceptor — fallback visual experimental). USE PARA design web, design de UI, criar protótipo, design system, sincronia de design, redesenho de site, mockup, landing page, design de dashboard, design-to-code, frontend design, polir UI, auditoria de design, UI brutalista/editorial/retrô. NÃO USE PARA ilustrações/logos (use Art) ou vídeo (use Remotion).

O que é LifeOS?

A habilidade Webdesign do LifeOS oferece um sistema unificado para projetar interfaces web, combinando três abordagens distintas para cobrir diferentes necessidades de fluxo de trabalho. O caminho padrão, DirectDesign, permite que o assistente de IA escreva o design diretamente no código, carregando a filosofia estética frontend-design de código aberto da Anthropic — sem dependência de navegador ou autenticação, ideal para iterações rápidas e ad-hoc dentro da base de código. Para trabalho mais integrado, o caminho nativo do Claude Code (Path 2), via comandos /design e /design-sync, sincroniza o design system real da base de código com o Claude Design e aplica alterações, sendo a opção preferida para qualquer trabalho que envolva integração com código existente. Por fim, o caminho experimental ClaudeDesign (Path 3) usa o Interceptor para controlar a tela visual do claude.ai/design, permitindo revisão visual e criação de protótipos compartilháveis, mas requer autenticação e nunca foi executado de ponta a ponta. A habilidade roteia automaticamente entre esses caminhos com base na solicitação do usuário, priorizando speed e integração para tarefas curtas, e o canvas visual para revisão. A habilidade é projetada para operar de forma integrada com contextos de projeto maiores, aceitando configurações existentes e produzindo diffs em vez de arquivos isolados, respeitando tokens de design e padrões de componentes, e lê preferências personalizadas de design de arquivos em ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Webdesign/.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/danielmiessler/LifeOS/tree/HEAD/LifeOS/install/skills/Webdesign

Perguntar na sua IA favorita

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

Documentação

Notificação por Voz (PRIMEIRA AÇÃO OBRIGATÓRIA)

curl -s -X POST http://localhost:31337/notify \
  -H "Content-Type: application/json" \
  -d '{"message": "Executando a habilidade Webdesign", "voice_enabled": true}' > /dev/null

O que Faz

Projeta e integra interfaces web por meio de dois caminhos. ClaudeDesign controla o produto claude.ai/design da Anthropic através da habilidade Interceptor, depois incorpora o resultado à sua base de código. DirectDesign escreve o design inline usando a filosofia frontend-design de código aberto da Anthropic, carregada de uma referência local. Roteamento padrão: trabalho curto, ad-hoc e dentro da base de código vai para DirectDesign; protótipos de várias páginas ou compartilháveis vão para ClaudeDesign.

O Problema

Produzir uma boa UI web geralmente significa ou lutar com uma ferramenta visual que não toca sua base de código real, ou codificar manualmente do zero e cair nos mesmos padrões genéricos sempre. Os dois modos de falha puxam em direções opostas: ferramentas visuais dão polimento, mas uma lacuna de entrega; enquanto escrever código diretamente dá integração, mas estética plana. Esta habilidade oferece ambas as rotas sob o mesmo teto — um ciclo visual através de claude.ai/design quando a revisão importa, ou design inline com uma doutrina estética real carregada quando velocidade e iteração dentro da base de código importam — e roteia para a rota certa com base na solicitação.

Como Funciona

Webdesign cobre três caminhos para produzir UI web. Escolha o caminho que se encaixa; apresente opções pelo nome quando a intenção for ambígua. Sempre dirigimos qualquer versão do Claude Design que esteja ativa — não há versão para fixar.

Caminho 1 — DirectDesign (padrão; {{DA_NAME}} escreve o design inline)

{{DA_NAME}} escreve o design diretamente com a doutrina estética frontend-design de código aberto da Anthropic carregada inline. O conteúdo de prompt principal é espelhado de github.com/anthropics/skills/tree/main/skills/frontend-design (licenciado MIT) em References/FrontendDesignPhilosophy.md — lista de registro, regras anti-padrão, receitas de pares tipográficos, vocabulário de movimento, disciplina de cor. Autocontido: sem dependência de tempo de execução, sem navegador, sem autenticação. Este é o caminho que realmente entregou todos os designs reais que esta habilidade produziu. Fluxo de trabalho: DirectDesign.

Caminho 2 — CLI Nativo do Claude Design (preferido para integração de código + sincronia de design system)

A Anthropic lançou comandos de primeira parte /design e /design-sync dentro do Claude Code (Junho de 2026, GA em Pro/Max/Team/Enterprise — oficial: support.claude.com/en/articles/14604416). /design-sync puxa o design system real de uma base de código para o Claude Design e envia as alterações criadas de volta; /design cria e edita designs a partir do terminal. Estes são a substituição determinística e de primeira parte para o aparato de pacote de entrega do Interceptor — prefira-os para qualquer coisa vinculada a código. Fluxo de trabalho: NativeDesignSync.

Caminho 3 — ClaudeDesign via Interceptor (FALLBACK VISUAL EXPERIMENTAL)

⚠️ Não verificado e atualmente não funcional. Este caminho controla a tela web claude.ai/design através da habilidade Interceptor para revisão visual. Requer uma sessão autenticada do claude.ai no perfil Chrome interceptor-test, que não está atualmente logada, e nunca foi executado de ponta a ponta (todas as execuções reais desta habilidade usaram DirectDesign). Use apenas quando você especificamente quiser a tela web visual E tiver configurado o login primeiro. Fluxos de trabalho: CreatePrototype, ExtractDesignSystem, RefinePrototype, WebsiteToRedesign, ExportToCode, IntegrateIntoApp, DeployDesign. Ferramenta: DriveClaudeDesign.ts.

Regra de Roteamento

Quando o usuário pedir "um design bacana" / "projetar algo" sem nomear um caminho:

  • Padrão para DirectDesign para trabalho curto, ad-hoc, dentro da base de código — velocidade e iteração em contexto.
  • Use a CLI nativa (/design-sync) quando o trabalho for sincronizar um design system de base de código real ou fazer trabalho de design vinculado a código e os comandos estiverem disponíveis.
  • Recorra ao ClaudeDesign (Caminho 3) apenas quando a revisão visual da tela web for explicitamente desejada, e lembre-se de que precisa do login único e não é comprovado.

Operação Consciente de Integração (CRÍTICO)

Esta habilidade é frequentemente chamada como sub-etapa de trabalho de site maior — escrevendo um post de blog, construindo um painel de administração, enviando uma página de marketing. Quando invocada a partir de um contexto pai, a habilidade:

  • Aceita contexto de projeto existente como entrada: framework, arquivo de tokens, diretório de componentes, alvo de implantação.
  • Produz saída como diffs / patches contra o aplicativo existente, não arquivos HTML isolados.
  • Respeita tokens de design e padrões de componentes existentes — NÃO os sobrescreve a menos que o usuário solicite um redesenho completo.
  • Roteia trabalho de integração através de Workflows/IntegrateIntoApp.md.

Quando invocada de forma independente para um design greenfield, a habilidade produz um protótipo autocontido e opcionalmente scaffolding de um novo aplicativo.

Personalização

Preferências de design específicas do usuário (paleta de cores, tipografia, grade de espaçamento, temporização de animação, padrões de framework) residem em:

~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Webdesign/
├── PREFERENCES.md     # Tokens de design, frameworks preferidos
├── README.md
└── EXTEND.yaml

A habilidade lê PREFERENCES.md se presente e passa esses tokens para o briefing do Claude Design e qualquer pacote de entrega downstream. Sem uma camada de personalização, a habilidade usa a saída padrão de extração de design system do Claude Design.

Roteamento de Fluxo de Trabalho

Ao executar um fluxo de trabalho, produza esta notificação:

Executando **WorkflowName** em **Webdesign**...
Fluxo de TrabalhoGatilhoArquivo
DirectDesign (Caminho 1 — padrão, {{DA_NAME}} escreve inline)"faça um design bacana", "projete isso diretamente", "faça o design você mesmo", "projete algo legal", "estética frontend", "UI brutalista/editorial/retrô/maximalista", qualquer solicitação curta ad-hoc de design sem "protótipo" / "mockup" / "claude design"Workflows/DirectDesign.md
NativeDesignSync (Caminho 2 — preferido para trabalho de código)"/design", "/design-sync", "sincronia de design", "sincronizar design system", "puxar design system para o Claude Design", "enviar código de volta para o Claude Design", "comando de design nativo"Workflows/NativeDesignSync.md
CreatePrototype (Caminho 3 — experimental, controla claude.ai/design)"projetar um protótipo", "criar protótipo", "mockup", "construir um design", "claude design", "usar claude.ai/design"Workflows/CreatePrototype.md
ExtractDesignSystem (Caminho 3)"extrair design system", "puxar tokens de", "extrair marca"Workflows/ExtractDesignSystem.md
RefinePrototype (Caminho 3)"iterar em", "refinar", "ajustar espaçamento", "mudar cor"Workflows/RefinePrototype.md
WebsiteToRedesign (Caminho 3)"redesenhar este site", "reconstruir esta URL", "modernizar"Workflows/WebsiteToRedesign.md
ExportToCode (Caminho 3 fallback — prefira /design-sync)"exportar para código", "enviar para código", "enviar para Claude Code", "processar entrega"Workflows/ExportToCode.md
IntegrateIntoApp (Caminho 3 fallback — prefira /design-sync)"integrar isso em", "aplicar no aplicativo", "inserir na base de código existente"Workflows/IntegrateIntoApp.md
DeployDesign (Caminho 3)"implantar o design", "enviar para produção"Workflows/DeployDesign.md

Para trabalho vinculado a código (exportação, integração, extração/sincronia de design system), prefira Caminho 2 (NativeDesignSync → /design-sync). Os fluxos de trabalho do Caminho 3 acima permanecem como fallback documentado para quando você estiver trabalhando a partir da tela web, mas não são comprovados e precisam do login do perfil de teste.

Pré-requisitos (PREFLIGHT)

Caminho 1 (DirectDesign) não precisa de nada — sem navegador, sem autenticação. Caminho 2 (CLI nativo) precisa apenas de uma assinatura Claude que inclua Claude Design e um Claude Code atual (/update se os comandos não aparecerem). As verificações abaixo se aplicam APENAS ao Caminho 3 (ClaudeDesign via Interceptor):

  1. Habilidade Interceptor disponível — which interceptor retorna um caminho. Se não, instrua o usuário a invocar Skill("Interceptor") setup first.
  2. Sessão autenticada do claude.ai — o perfil Chrome interceptor-test deve estar logado no claude.ai. Verifique em tempo de execução (um perfil não autenticado encontra a página de marketing, não o aplicativo); se não estiver, um login com interface gráfica único é necessário antes que qualquer fluxo de trabalho do Caminho 3 possa ser executado.
  3. Acesso ao Claude Design — a assinatura Claude deve incluir Claude Design (Pro, Max, Team ou Enterprise com opt-in do administrador).
  4. Para IntegrateIntoApp: caminho do projeto pai + identificador de framework (next, astro, vitepress, vite-react, vue, vanilla) passado no contexto.

Pré-requisitos ausentes → pare com uma etapa de remediação clara. Nunca faça fallback silencioso.

Pegadinhas

Acumule lições aqui. A densidade de informação é mais alta nas pegadinhas.

  • Dois caminhos, uma habilidade. ClaudeDesign (CreatePrototype e outros) controla claude.ai/design; DirectDesign faz {{DA_NAME}} escrever o design inline usando References/FrontendDesignPhilosophy.md. Não os confunda. Quando a intenção do usuário for ambígua, apresente ambos como opções nomeadas e deixe-o escolher — nunca roteie silenciosamente.
  • Nativo primeiro — código e tokens são a fonte da verdade, Figma não é uma dependência. Importe um design system vinculando o repositório (Claude Design lê componentes e tokens reais do código) ou fazendo upload de arquivos de token/componente, nunca uma exportação .fig. NÃO adicione um ciclo Figma em nenhuma direção (design → .fig, ou código → quadros Figma editáveis). A aposta é que o design vive na base de código, não em um arquivo de intercâmbio externo. Se uma necessidade de revisão visual sem repositório surgir, resolva-a com um compartilhamento de URL/captura de tela, não acoplando a habilidade ao Figma.
  • DirectDesign é autocontido. A doutrina estética está em References/FrontendDesignPhilosophy.md (espelhado da fonte MIT anthropics/skills). Nenhuma dependência de tempo de execução no plugin frontend-design upstream do Claude Code estar instalado — DirectDesign funciona em qualquer ambiente LifeOS.
  • /design + /design-sync nativos são o caminho vinculado a código agora (CONFIRMADO). A documentação oficial da Anthropic (support.claude.com/en/articles/14604416) documenta ambos os comandos, GA em Pro/Max/Team/Enterprise desde Junho de 2026. /design-sync faz sincronia bidirecional base de código↔design system — use-o em vez do aparato de pacote de entrega do Interceptor para qualquer coisa vinculada a código. Ainda não há API REST pública ou servidor MCP; os comandos CLI são a superfície programática. Se eles não aparecerem, execute /update.
  • O caminho ClaudeDesign/Interceptor (Caminho 3) não é comprovado e atualmente está bloqueado. Nunca foi executado de ponta a ponta — toda execução real desta habilidade usou DirectDesign. O perfil interceptor-test não está logado no claude.ai, então DriveClaudeDesign.ts encontra a página de marketing, não o aplicativo. A ferramenta tem como alvo controles por heurísticas de árvore de acessibilidade (composer por role=textbox/contenteditable, send por /send|submit/, export por /export/), então um botão movido NÃO é o bloqueador — a autenticação ausente e a superação da CLI nativa são. Antes de confiar no Caminho 3: faça login do perfil de teste no claude.ai uma vez, depois execute uma única execução supervisionada.
  • Chrome real necessário. Use a habilidade Interceptor — é a única automação de navegador sancionada no LifeOS. A UI do Claude Design depende do estado de sessão completo do claude.ai; automação baseada em CDP dispara detecção de bot e descarta cookies de sessão.
  • Pacotes de entrega são diretórios, não arquivos únicos. Um pacote contém PROMPT.md, opcional tokens.json, components/, assets/ e scaffolding específico do framework. Trate o diretório inteiro como a unidade.
  • Plugin frontend-design ativa automaticamente. Quando o pacote de entrega é alimentado ao Claude Code, o plugin (já instalado no marketplace oficial) pega o trabalho frontend automaticamente — não o invoque manualmente.
  • A extração de design system do Claude Design é executada durante a integração. Para uma nova base de código que você deseja que o Claude Design entenda, execute ExtractDesignSystem PRIMEIRO antes de CreatePrototype — caso contrário, o Claude Design usa padrões genéricos e substitui seus tokens.
  • Integração ≠ sobrescrita. IntegrateIntoApp produz diffs sobre o código existente. Se o usuário quiser um redesenho completo que substitua a UI existente, sinalize explicitamente e obtenha confirmação.
  • Exportações Canva são editáveis. Se o usuário quiser que um não-desenvolvedor (marketeiro, fundador) refine o design, roteie através de Workflows/ExportToCode.md com --format canva.
  • Sem colaboração em tempo real. Claude Design não suporta edição multijogador como Figma. Compartilhe via exportação de URL para revisão assíncrona.
  • Gate Enterprise. Contas Enterprise precisam que um administrador habilite Claude Design nas configurações da Organização antes que o ícone da paleta apareça no claude.ai.
  • Cotas de sessão. A geração do Claude Design consome muitos tokens. A partir da atualização de Junho de 2026, seu uso compartilha um pool com o chat do claude.ai, Claude Code e Cowork — não é mais uma cota separada. Pro é fino para trabalho de design sustentado; Max recomendado.
  • Design-system primeiro é a correção de tokens. O maior consumidor de tokens é reinferir sua marca a cada passagem e depois corrigi-la. Execute ExtractDesignSystem uma vez para que o sistema seja uma referência fixa reutilizável; toda geração posterior o reutiliza em vez de adivinhar. Menos ciclos de correção = muito menos tokens ao longo da vida de um projeto. Esta é a única ação de maior alavancagem contra queima de cota.
  • Fidelidade de saída ≠ pronto para produção. Claude Design produz visuais polidos, mas o código de entrega geralmente precisa de uma verificação + passagem de acessibilidade. Execute Tools/VerifyDesign.ts pós-integração.
  • Visão não adivinha. Se o prompt não especificar breakpoints responsivos, requisitos de contraste ou comportamento de modo escuro, Claude Design escolhe padrões que podem não corresponder ao aplicativo alvo. Seja explícito no briefing.

Exemplos

Exemplo 1: Criar um protótipo a partir de um briefing

Usuário: "Projete uma página de preços para uma startup de segurança de IA — estética editorial, apenas escuro"
→ Invoca fluxo de trabalho CreatePrototype
→ Preflight: Interceptor + sessão autenticada do claude.ai
→ Compõe briefing com estética explícita, restrições, diferenciação
→ Controla claude.ai/design via Ferramentas

…

[truncado para tradução]

Habilidades Relacionadas