Communitygithub.com

victor-lis-bronzo/rws-skill

/grill-design — Sessão socrática dedicada a UI e UX. O agente pergunta, uma questão por vez, sobre jornadas, layout, componentes, estados e acessibilidade, sempre sugerindo patterns de UI nomeados e aplicações de referência correlatas. Após aprovação explícita, grava a spec em wiki/ui-specs/ e as regras visuais em schema/design-system.md.

rws-skill 是什么?

O /grill-design é uma habilidade socrática focada em UI/UX, que guia o agente através de uma série de perguntas (uma de cada vez) para projetar a interface do usuário e sua experiência. A habilidade é especialmente útil para desenvolvedores e designers que trabalham em projetos de software, pois garante que as decisões de design sejam baseadas em padrões consolidados e referências reais, resultando em especificações de UI/UX persistentes. Suportada por plataformas como Claude Code e Cursor, a habilidade define regras de condução que exigem que cada pergunta seja acompanhada de sugestões concretas, incluindo opções de design, padrões de UI, referências (como aplicações reais) e um wireframe ASCII da opção recomendada. O fluxo de trabalho inclui preparação silenciosa (leitura de documentação existente, inspeção de código e catálogo de padrões), iteração sobre 12 dimensões de design (público, jornada, layout, estados, etc.), síntese em uma spec usando um template, aprovação explícita por parte do usuário e, finalmente, a gravação da spec em arquivos markdown no wiki e em regras de design system. A habilidade também gera automaticamente tarefas de implementação relacionadas e as registra em um log.

兼容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/victor-lis-bronzo/rws-skill/tree/HEAD/skills/grill-design

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

/grill-design

Objetivo: definir como a aplicação deve parecer e se comportar para o usuário final, apoiado em patterns consolidados e em produtos reais, e registrar isso de forma persistente.

Preparação (silenciosa)

  1. Ler wiki/index.md, wiki/overview.md, specs relacionadas em wiki/ui-specs/ e schema/design-system.md (se existir).
  2. Inspecionar a UI existente no código (biblioteca de componentes, tokens, Tailwind config, telas parecidas).
  3. Ler o catálogo de patterns.
  4. Se a feature não tem /grill prévio e as regras de negócio são incertas, sugerir rodar /grill antes.

Regras de condução

  1. Uma pergunta por vez, com recomendação justificada.

  2. Toda pergunta de design vem com sugestões concretas, no formato:

    **Pergunta:** Como o usuário deve navegar pelos 2.000 pedidos?
    
    | Opção | Pattern | Referências (o que copiar) | Prós | Contras |
    |---|---|---|---|---|
    | A ⭐ | Data table + filtros facetados + saved views | **Stripe Dashboard** (chips de filtro acima da tabela), **Linear** (views salvas na sidebar) | Escala, power users | Pior no mobile |
    | B | Master-Detail | **Gmail** (lista + leitura lado a lado) | Contexto preservado | Exige tela larga |
    | C | Cards grid | **Airbnb** (cards com foto) | Visual | Difícil comparar |
    
    **Recomendo A** porque o público é operacional, desktop, e compara status/valores.
    
  3. Referências devem ser apps reais e correlatos ao domínio do projeto (fintech → Nubank, Stripe, Mercury; produtividade → Linear, Notion; marketplace → Airbnb, Mercado Livre; etc.). Diga o que exatamente copiar (um detalhe específico), não só o nome.

  4. Se o agente tiver busca web, pode pesquisar exemplos (Mobbin, Page Flows, Dribbble) para enriquecer.

  5. Sempre que possível, mostre um wireframe ASCII da opção recomendada.

  6. Respeite o design system existente; só proponha mudanças nele explicitamente.

Dimensões (percorrer o que for relevante, nesta ordem)

#DimensãoPerguntas típicasPatterns comuns a sugerir
1Público e contextoQuem é? Frequência de uso? Desktop/mobile? Nível técnico?— (define o resto)
2Jornada / user flowDe onde vem, qual objetivo, para onde vai? Passos?Wizard, hub-and-spoke, linear flow
3Arquitetura de informaçãoQuais telas? Hierarquia? Navegação?Sidebar, tabs, bottom bar, ⌘K, breadcrumbs
4Layout e hierarquia visualPonto focal? Densidade? Grid? Responsividade?Master-detail, dashboard de KPI, split view
5Exibição de dadosLista, tabela, cards, gráfico? Busca/filtro/ordenação?Data table, kanban, facetas, saved views
6Criação e ediçãoComo cria/edita? Validação? Salvamento?Modal, drawer, inline edit, autosave, stepper
7EstadosLoading, vazio, erro, sucesso, parcial, sem permissão, offlineSkeleton, empty state educativo, undo toast, optimistic UI
8Feedback e micro-interaçõesConfirmações, transições, hover, atalhosToast, inline validation, keyboard shortcuts
9Design system e tokensBiblioteca (shadcn, Radix, MUI…)? Cores semânticas, tipografia, espaçamento, dark modeTokens semânticos, escala 4/8px
10AcessibilidadeTeclado, foco, contraste AA, leitor de tela, prefers-reduced-motionSkip links, focus ring, ARIA patterns
11Conteúdo e tomMicrocopy, idioma, tom de voz, mensagens de erro—
12Onboarding e ativaçãoPrimeiro uso? Dados de exemplo?Checklist, template gallery, sample data

Síntese

Apresente a spec preenchendo o template ui-ux-spec.md, incluindo:

  • tabela Patterns adotados (pattern → onde → referência → motivo);
  • tabela Referências (app → o que copiar → o que evitar);
  • wireframes ASCII das telas principais;
  • matriz de estados por componente;
  • tokens/regras novas propostas para o design system.

E a tabela de gravações:

DestinoArquivoAção
wikiwiki/ui-specs/<tela-ou-fluxo>.md/wiki:add
wikiwiki/concepts/<feature>.md (link para a spec)/wiki:increment
schemaschema/design-system.md/schema:add (1ª vez) ou /schema:increment

Plano de Implementação de UI (Tasks / Tickets)

TaskVerticalDepende dePrioridadeAção
wiki/tasks/<slug-da-tela>.mdui-medium/ticket:new (wiki + issue)

Aprovação explícita (gate)

"Aprova a spec de UI/UX, as gravações no design system e a criação das tasks (+ issues no GitHub)? (sim / ajustar)" — sem aprovação inequívoca, não grave nada.

Formalização (após aprovação)

  1. /wiki:add → wiki/ui-specs/<slug>.md (type: ui-spec).
  2. /wiki:increment nas páginas de feature/entidade relacionadas.
  3. /schema:add ou /schema:increment → schema/design-system.md (template design-system-rules.md).
  4. Execute /ticket:new para cada task de UI planejada (componentes, telas, interações), com as labels vertical:ui (ou vertical da feature) e status:planned.
  5. Append em wiki/log.md: ## [AAAA-MM-DD] grill-design | <tela/fluxo> com as páginas e tasks criadas.
  6. Sugerir próximos passos: /implement <task-de-ui>, protótipo, telas vizinhas sem spec.

相关技能