Communitygithub.com

victor-lis-bronzo/rws-skill

Sessão socrática de UI/UX: uma pergunta por vez, com recomendações fundamentadas em patterns e exemplos reais. Após aprovação, grava a especificação e as regras visuais de forma persistente.

rws-skill 是什麼?

Este skill conduz um processo colaborativo de design de UI/UX, fazendo uma pergunta por vez ao usuário, sempre acompanhada de recomendações concretas e referências a aplicativos reais (como Stripe, Linear, Airbnb). Ele cobre todas as dimensões de design – desde público e contexto até acessibilidade e onboarding – e sugere patterns de UI consolidados, exibindo wireframes ASCII quando relevante. Após aprovação explícita do usuário, o skill grava a especificação completa em `wiki/ui-specs/`, atualiza o sistema de design em `schema/design-system.md`, cria tickets de implementação no GitHub e registra tudo no log. É ideal para equipes que desejam definir de forma estruturada e rastreável a aparência e o comportamento de uma aplicação, apoiando-se em boas práticas e exemplos do mundo real.

相容平台✓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.

相關技能