Communitygithub.com

byteratio/ux-agents

Cria agentes de teste de UX baseados em personas para uma aplicação web — arquivos .claude/agents/<persona>-ux.md com escopo de projeto que acionam um navegador real via Playwright, percorrem jornadas do usuário como uma persona específica e reportam descobertas de fricção com tags. Use ao configurar automação de revisão de UX, quando o usuário perguntar o que um segmento específico pensaria do aplicativo, ou após o usuário aceitar uma oferta para adicionar testes de persona.

O que é ux-agents?

Este skill (byteratio/ux-agents) fornece um padrão para capturar problemas de UX que escapam de testes unitários e auto-revisão humana. Ele permite definir agentes de persona que conduzem um navegador real via Playwright, percorrem jornadas do ponto de vista de um usuário específico e relatam pontos de fricção. É particularmente útil para aplicações web com múltiplos tipos de usuários distintos (como novo graduado vs. profissional experiente, usuário gratuito vs. administrador corporativo, paciente vs. provedor) onde a superfície do aplicativo é grande demais para ser testada manualmente para cada persona em cada alteração. O skill organiza cada persona como um arquivo `.md` individual dentro do diretório `.claude/agents/`, com frontmatter contendo nome, descrição, ferramentas e instruções detalhadas de fluxo de trabalho. Também inclui um arquivo `_shared-ux-protocol.md` para configurações e expectativas compartilhadas. O agente cria automaticamente um workspace de teste via API, popula dados simulados para a persona, executa testes no navegador, captura screenshots, avalia os resultados e gera um relatório estruturado em `plans/ux-reports/` com tags como `[blocker]`, `[friction]` e `[polish]`, além de uma seção "Top 3 correções para enviar a seguir". O skill é compatível com Claude Code e exige que o Playwright esteja funcional e um servidor de desenvolvimento local esteja rodando. A abordagem é eficiente e focada: cada execução leva minutos, evitando uso excessivo de recursos.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/byteratio/skills/tree/main/plugins/hechtch-skills/skills/ux-agents

Perguntar na sua IA favorita

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

Documentação

Agentes de teste de UX — revisão baseada em persona conduzida por navegador

Um padrão para capturar problemas de UX que escapam de testes unitários e auto-revisão humana: defina agentes de persona que conduzem um navegador real via Playwright, percorrem jornadas da perspectiva de um usuário específico e relatam fricção. Resultado real que provou ser útil: um agente sinalizou um bug de dessincronização de dropdown de workspace na mesma sessão em que foi executado pela primeira vez, antes de alguém ter registrado o problema.

Quando configurar isso

  • O projeto tem um frontend web com múltiplos tipos de usuários distintos — novo graduado vs. profissional de meio de carreira vs. aposentado, nível gratuito vs. administrador corporativo, paciente vs. provedor, etc. As personas precisam ser diferentes o suficiente para que padrões / vocabulário / recursos disponíveis realmente pareçam diferentes para cada uma.
  • O aplicativo tem área de superfície grande o suficiente para que percorrê-lo manualmente para cada persona a cada alteração não seja realista.
  • O servidor de desenvolvimento pode ser executado localmente sem complicações de autenticação (ou a autenticação tem um bypass programável para testes).

Pule isso para: APIs sem interface de usuário, CLIs, ferramentas internas de persona única.

Onde os agentes vivem

Com escopo de projeto em .claude/agents/, não na configuração global do usuário. As personas incorporam conhecimento específico do projeto (faixas numéricas, nomes de recursos, jornadas) que não seriam generalizáveis. Cada persona é seu próprio arquivo .md com frontmatter:

---
name: <slug-da-persona>-ux
description: Testa UX de <app> da perspectiva de uma <persona em uma linha>. Conduz um navegador real via Playwright, captura screenshots de cada aba e relata pontos de fricção. Use proativamente após alterações de UI que afetem <área>.
tools: Bash, Read, Write, Edit
---

Você é um agente de teste de UX interpretando uma <persona>.

## Sua persona
<5–10 linhas: idade, função, nível de conhecimento, objetivo nesta sessão, o que eles NÃO saberiam>

## Fluxo de trabalho
1. Crie um novo workspace via API (não polua dados reais).
2. Popule entradas via API para corresponder à persona.
3. Conduza o navegador em /tmp/ux-<slug>.mjs com Playwright.
4. Capture screenshots das abas relevantes para esta persona.
5. Leia cada screenshot e avalie.
6. Escreva as descobertas em plans/ux-reports/<slug>-<data>.md.
7. Limpe o workspace de teste.

Também coloque um _shared-ux-protocol.md no mesmo diretório (o sublinhado inicial impede que seja confundido com um agente). Esse arquivo contém expectativas de ambiente, formato de saída, a rubrica "o que avaliar", etc. — os arquivos por persona o citam quando útil.

Estrutura necessária

  • plans/ux-reports/ existe (crie-o durante a configuração para que os relatórios tenham onde cair). Isso assume a convenção de que plans/ no repositório contém documentos de trabalho sobre trabalho em andamento, commitados no git para que o raciocínio sobreviva à sessão de chat; relatórios de UX são um desses documentos. Se um projeto não tiver um diretório plans/, crie-o — ou combine outra localização com o usuário e escreva-a em cada arquivo de persona, já que os agentes codificam o caminho.
  • Playwright funciona via npx playwright (agentes podem precisar de npx playwright install chromium uma vez em uma máquina nova — inclua isso nas instruções do agente).
  • Uma API para popular dados deve existir OU um fluxo de UI determinístico deve ser documentado. Sem um desses, o agente acaba muito frágil.

Regras de design de persona

  • A lacuna de conhecimento é o valor — o agente novo graduado encontra jargão que o experiente nem notaria; o aposentado encontra simplificações excessivas. Se duas personas dessem relatórios idênticos, mescle-as.
  • Defina um objetivo concreto por sessão, não um vago "explorar o aplicativo". "Posso me aposentar um dia com este salário?" é testável. "Usar o aplicativo" não é.
  • Especifique o que eles NÃO sabem — "não sabe o que significa SWR / Coast FI / 72(t)" força o agente a sinalizar esses termos em vez de ignorá-los.
  • Faixas numéricas importam — se a pessoa tem $5K economizados, padrões projetados para poupadores de $500K revelarão bugs na escala de eixos de gráficos, tratamento de zero, etc., que personas medianas perderiam.

Disciplina de saída (codifique em cada agente)

  • Marque cada descoberta como [blocker] / [friction] / [polish].
  • Uma sugestão de correção por linha para cada problema.
  • Termine com uma seção "Top 3 correções para enviar a seguir" para que o usuário receba uma lista de ações priorizadas.
  • Relate apenas o que foi realmente observado em screenshots / respostas da API — sem reclamações especulativas.

Executando um agente

Após colocar os arquivos .md, reinicie o Claude Code — as definições de agente são verificadas no início da sessão. Na nova sessão: use o agente <persona>-ux para revisar a calculadora após minhas últimas alterações. Cada execução leva minutos (navegador real), então não dispare todos a cada alteração — execute após trabalho significativo de UI.

O que registrar para o usuário

Ao configurar este padrão, anote no CHANGELOG.md do projeto ou em um documento de plano em plans/:

  • Que os agentes existem e para onde vão os relatórios.
  • O pré-requisito do servidor de desenvolvimento (para que um novo colaborador não tente executar um agente contra um projeto frio).
  • Quaisquer peculiaridades específicas do projeto na criação de dados que as personas dependem.

Armadilhas comuns

  • Não deixe agentes iniciarem o servidor de desenvolvimento. Eles tendem a deixar processos zumbis. Faça com que verifiquem curl -fsS http://localhost:<porta> e recusem prosseguir se estiver caído — o usuário o inicia.
  • Não reutilize um workspace / conjunto de dados real. Sempre crie e delete um workspace UX: <persona>. Descobertas poluídas por estado residual desperdiçam o tempo de revisão do usuário.
  • Não torne a persona um "usuário casual" genérico. É daí que vem o ruído. Quanto mais específica a persona, mais útil o relatório.
  • Não execute muitas em paralelo — Playwright + servidor de desenvolvimento + Chromium por agente vai rapidamente estourar a memória de um laptop. Execuções em série são suficientes.

Individual skills in this repo

This repo contains 5 individual skills — each has its own dedicated page.

byteratio/example-skill

Template skill for this marketplace. Use as a starting point when adding a new skill — copy this plugin directory, rename it, and replace this description with the specific trigger conditions for your skill (what the user says or does that should invoke it).

byteratio/iphone-dev

Conventions for native iPhone app development — SwiftUI + SwiftData local-first apps, XcodeGen project generation, CLI-only build/test/deploy loops (simulator by default, signed device deploys via devicectl), XCTest with visible coverage, and the free-personal-team signing gotchas. Use when creating an iOS/iPhone app, adding iOS targets or Makefile loops to a project, debugging Xcode signing/provisioning/deploy problems, or porting an existing app's logic into a native Swift client.

byteratio/kanban-plans

Track multi-session plans on a locally-running kanban board (github.com/hechtch/kanban) via its agent REST API. Claim a plan, move it through todo/doing/blocked/awaiting_merge/done, leave notes, and set the git branch. Use at the start of any non-trivial multi-session plan, when resuming such a plan, or when the user asks what's on the board or where a plan stands.

byteratio/password-generator

Generates secure, memorable passwords using 3 random dictionary words with leet-speak substitutions. Use when the user asks to generate a password, create a new password, or needs a secure passphrase.

byteratio/security-sweep

Investigate whether a project (or every repo on the machine) is exposed to known and actively-exploited dependency vulnerabilities. Combines a deterministic per-ecosystem audit (npm audit, govulncheck, pip-audit, osv-scanner) with live web research into recent/active supply-chain incidents, then checks each project's lockfiles directly — the leading-indicator check that `npm audit` misses. Use when the user asks to "investigate security", "check for vulnerable dependencies", "are we affected by <a named CVE / package compromise>", "scan the projects for supply-chain issues", or wants a recurring security sweep.

Habilidades Relacionadas