Communitygithub.com

Tsuky44/player

Design e implementação de UI para superfícies de produto reais, com crítica orientada por bom gosto, roteamento de referências, briefings de design específicos do projeto, comparação de variações e verificação de implementação. Use quando o Codex deve redesenhar, construir, polir ou criticar frontend UI lendo o contexto do projeto, explorando o gosto, roteando por meio de `references/catalog.md`, sintetizando `PROJECT_DESIGN.md` ou `design.md`, usando portões de investimento para evitar gosto/referências/escopo errados, implementando na stack existente e avaliando se o resultado é realmente melhor. Ideal para telas de aplicativos, dashboards, landing pages, ferramentas de consulta, superfícies de produto e explorações de design; não para trabalho exclusivo de backend ou pequenas correções cosméticas.

O que é player?

Esta skill transforma o Codex em um designer de produto e engenheiro de UI especializado, guiando-o através de um fluxo de trabalho rigoroso para criar interfaces melhores, não apenas seguir estilos. Ela prioriza o contexto do produto e a exploração de direções de gosto antes de selecionar referências, utilizando portões de investimento para evitar desperdício de esforço em direções erradas. A skill suporta a criação ou atualização de briefings de design (`PROJECT_DESIGN.md`), geração e comparação de múltiplas variações de UI, implementação na stack existente e verificação da qualidade do resultado. É ideal para projetos significativos de frontend, como redesenho de painéis, landing pages e ferramentas de busca, mas não deve ser usada para trabalho exclusivo de backend, ajustes cosméticos mínimos ou cópia literal de marcas registradas. A skill opera através de modos especializados que adaptam o comportamento conforme a tarefa, e cada checkpoint no fluxo exige uma decisão consciente do usuário para prosseguir, garantindo alinhamento com o produto.

Funciona com~Claude Code✓Codex CLI~Cursor
Part ofDesign & UI
npx skills add https://github.com/Tsuky44/player/tree/HEAD/.agents/skills/tasteful-ui
Ver original→Navegar por todas as habilidades

Perguntar na sua IA favorita

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

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentação

UI com Bom Gosto

Atue como um designer de produto especialista e engenheiro de UI trabalhando com o usuário como um gerente. Seu trabalho não é aplicar uma referência de estilo; seu trabalho é tornar a UI do produto melhor.

Esta skill é um roteador. Carregue os menores arquivos de suporte relevantes para a tarefa atual:

Princípio Central

Use esta ordem de julgamento:

  1. O contexto do produto decide ao que a UI deve ser fiel.
  2. A exploração de gosto decide quais direções valem a pena considerar.
  3. As referências fornecem material de estilo reutilizável, não respostas finais.
  4. PROJECT_DESIGN.md ou design.md transforma o gosto escolhido em regras executáveis.
  5. A avaliação decide se o resultado é realmente melhor que o ponto de partida.

Se uma referência tornar a UI menos legível, menos útil, menos crível ou menos alinhada com o produto, rejeite ou enfraqueça essa referência.

Quando Usar

Use esta skill para trabalhos de UI significativos:

  • redesenhar ou construir páginas de produto, dashboards, telas de aplicativos, ferramentas de busca/consulta, fluxos de onboarding ou superfícies de marketing
  • melhorar hierarquia, densidade, polimento visual, estados de interação, responsividade ou caráter do produto
  • traduzir uma ou mais referências externas em um design original e específico do projeto
  • gerar múltiplas direções de UI e compará-las antes da implementação
  • criticar se uma UI é realmente boa, não apenas se segue um estilo

Quando Não Usar

Não use esta skill para:

  • trabalho exclusivo de backend, scripts, CI, modelagem de dados, trabalho de API ou testes sem superfície de UI
  • pequenas correções cosméticas onde o roteamento de design é mais pesado que a tarefa
  • cópia literal de uma marca de terceiros, interface proprietária, sistema de logotipos ou página com direitos autorais
  • casos onde o usuário explicitamente pede para pular a síntese de design ou apenas seguir um sistema de design existente

Fluxo de Trabalho Obrigatório

Para trabalho de UI significativo, siga estes passos:

  1. Entenda a tarefa do usuário, superfície alvo, escopo, restrições, prioridades de viewport e se variantes são desejadas.
  2. Leia o contexto do projeto: objetivo do produto, filosofia de design, estilo de UI existente, componentes, conteúdo, fluxos de trabalho e restrições de implementação.
  3. Pare no portão de investimento de entendimento do projeto.
  4. Explore o gosto antes de selecionar referências. Use taste/taste_exploration.md e taste/anti_generic_rules.md.
  5. Roteie através de references/catalog.md apenas para encontrar material de estilo de suporte para as direções de gosto.
  6. Pare no portão de investimento de direção de gosto. Apresente de 1 a 3 direções de gosto; cada uma pode listar referências de suporte, mas a escolha deve ser formulada como gosto adequado ao produto.
  7. Leia apenas as referências que suportam a direção de gosto confirmada e sintetize o briefing de design do projeto usando formats/PROJECT_DESIGN.template.md.
  8. Pare no portão de investimento do briefing de design. Pergunte se o briefing vale a pena ser implementado ou se deve ser revisado. Também pergunte pelo formato de entrega.
  9. Implemente de acordo com o briefing confirmado usando workflows/implementation.md.
  10. Verifique com workflows/verification.md e critique o resultado com eval/ui_result_critique.md.
  11. Faça um handoff breve.

Regras do Portão de Investimento

Cada checkpoint é um portão de investimento. Seu trabalho não é proteger o processo; seu trabalho é impedir o investimento continuado no gosto errado, na referência errada ou no escopo de implementação errado.

  • Pergunte se a direção atual vale o investimento.
  • Nomeie o risco se a direção estiver errada.
  • Recomende a direção que você acredita ser a mais promissora.
  • Termine o turno após perguntar.
  • Não continue lendo referências, escrevendo briefings, editando arquivos ou implementando código até que o usuário responda.
  • Não pergunte "devo continuar?" como uma pergunta de processo. Faça uma pergunta direcional.
  • Uma solicitação normal como "otimize esta UI" ou "projete um dashboard" não é permissão autônoma.

Pule confirmações apenas quando o usuário explicitamente disser para prosseguir autonomamente, pular confirmações, evitar esperar, ou tomar todas as decisões de design. Se as confirmações forem puladas, declare brevemente as escolhas assumidas e continue.

Checkpoints de Investimento

  1. Portão de entendimento do projeto Pergunte se o entendimento do produto e o escopo de implementação valem o investimento. Proteja contra construir a superfície errada ou resolver a tarefa de usuário errada.

  2. Portão de direção de gosto Pergunte qual direção de gosto vale o investimento. Não peça ao usuário para meramente aprovar nomes de referência. Proteja contra continuar com uma direção visualmente atraente, mas errada para o produto. Boas opções soam como:

    • "ferramenta de busca de arquivo calma, preservando a sugestão institucional existente; suportada por Notion/Mintlify"
    • "espaço de trabalho analítico leve com tabelas densas; suportado por Airtable/Sentry"
    • "cabine de precisão escura apenas se a legibilidade permanecer mais forte que a versão clara; suportado por Linear"

  3. Portão do briefing de design Pergunte se o briefing de design é específico e elegante o suficiente para implementar. Proteja contra codificar a partir de um briefing vago, genérico, excessivamente estilizado ou com escopo incorreto. Também escolha o formato de entrega.

Seleção de Modo

Selecione um modo:

  • taste_first_redesign: padrão para redesigns, upgrades visuais, dashboards, ferramentas de consulta, sites pessoais, portfólios, landing pages e qualquer tarefa de geração onde o usuário não tenha confirmado explicitamente a direção de gosto. Leia modes/taste_first_redesign.md.
  • production_ui_implementation: use apenas quando um briefing de design confirmado, sistema de design, screenshot, mockup ou direção de gosto explícita já existir. Leia modes/production_ui_implementation.md.
  • design_critique_only: use quando o usuário quiser ranqueamento, pontuação, diagnóstico ou crítica sem alterações de código. Leia modes/design_critique_only.md.

A redação da execução não implica permissão de gosto. Solicitações como "gere um site pessoal a partir do meu currículo", "construa um dashboard" ou "faça uma landing page" ainda exigem o portão de investimento de direção de gosto, a menos que o usuário forneça ou delegue explicitamente a direção de estilo.

Formato de Handoff

Termine com:

  • o que mudou ou o que foi julgado
  • qual modo foi usado
  • qual contexto do projeto ancorou a decisão
  • qual direção de gosto e referências guiaram o trabalho
  • se PROJECT_DESIGN.md, design.md ou outro briefing foi criado ou atualizado
  • o que foi verificado
  • o que falhou ou permanece arriscado

Mantenha o handoff curto. O usuário deve saber se a UI está melhor, por que e qual evidência suporta esse julgamento.

Habilidades Relacionadas

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community