Redesenho Competitivo

O que Redesenho Competitivo faz?

Se um arquivo LOCAL.md estiver ao lado deste SKILL.md, leia-o primeiro — ele contém as especificidades do workspace (caminhos, ferramentas, exemplos) e substitui os padrões genéricos abaixo.

Pesquisar → decidir → projetar. Subagentes paralelos capturam telas da NOSSA funcionalidade e de 2 a 3 produtos concorrentes, as descobertas se tornam uma análise de lacunas com decisões em lote para o usuário, e a direção escolhida se torna um canvas de design: capturas de tela da UI atual ao lado de artboards redesenhados com cada diferença marcada. A saída é uma decisão + um design (+ opcionalmente um plano de implementação) — nenhum código de produto é escrito por esta habilidade.

A "execução de referência" mencionada abaixo é a primeira execução real desta habilidade (um redesign de uma biblioteca de gravações); LOCAL.md, quando presente, aponta para ela. Exemplo funcional apenas — ele prova a forma e calibra a profundidade; não o consulte para o conteúdo de uma nova funcionalidade.

Fase 1 — Pesquisa paralela (subagentes de modelo mais barato, no máximo 3 por vez)

Inicie até 3 subagentes em uma única mensagem — Ferramenta Agent, general-purpose, model: "sonnet" (um modelo mais barato é suficiente para pesquisa pesada; nunca mais que 3 simultaneamente — limites de taxa matam rajadas de inicialização):

1. Nosso — capture a tela da funcionalidade no NOSSO aplicativo.
2. • 3. Concorrentes — produtos que o usuário NOMEou preenchem estas vagas primeiro, um agente cada. Vagas restantes (usuário nomeou zero ou um): um agente de "pesquisa" que escolhe os 2-3 concorrentes com a documentação pública mais rica da área de funcionalidade relevante. Usuário nomeou 3+: dê a um agente o primário, a um agente o restante como um lote.

Enquanto eles executam, fundamente-se no nosso código na thread principal: o esquema da funcionalidade, camada de leitura/ação e páginas. As recomendações devem mapear para campos reais ("a tag project existe, a UI nunca a expõe") — pesquisa de concorrentes sem fundamentação no código produz uma lista de desejos que ninguém pode construir.

Instruções para subagentes — as partes que falham quando omitidas:

• Apenas Playwright MCP, nunca o painel do Navegador — capturas de tela do painel do navegador não podem ser salvas em disco e são invisíveis para o orquestrador. Diga explicitamente ao agente: mcp__playwright__playwright_screenshot com savePng: true + downloadsDir definido para um subdiretório temporário por agente (ours/, loom/, competitors/), mkdir -p primeiro, e reporte caminhos absolutos verificados com ls.
• Agentes concorrentes compartilham um navegador Playwright e CONTAMINARÃO as sessões (um agente captura a tela da página de outro agente — aconteceu na execução de referência). Instrua cada agente: verifique visualmente se cada captura corresponde à URL para a qual acabou de navegar antes de mantê-la; em caso de captura desatualizada/de outro agente, feche o navegador Playwright, reabra, refaça.
• Playwright chromium pode estar ausente ("Executable doesn't exist …"): npx playwright install chromium do diretório de cache do npx do MCP, então continue (problema recorrente, sobrevive a mudanças de versão).
• Login do nosso aplicativo: dê ao agente a receita exata — por exemplo, um formulário de login apenas para dev (email + senha em /login) com um email que EXISTE COMO UM USUÁRIO ATIVO no banco de dados de dev, mais a senha de login de dev do ambiente do servidor de dev. Verifique ambos você mesmo (leia o valor da env no servidor de dev, consulte o banco de dados de dev por usuários ativos) antes de iniciar o agente. A execução de referência queimou um agente inteiro em CredentialsSignin de um email que não estava no banco de dados de dev. Encontre o caminho de auth de dev do aplicativo em seu AGENTS.md / README. Nunca aponte agentes para produção.
• Bibliotecas de concorrentes estão atrás de login — instrua os agentes a usar artigos da central de ajuda, páginas de marketing/funcionalidades e documentação (support.loom.com etc.), não tentar cadastros. Peça um inventário estruturado de funcionalidades (organização, descoberta/pesquisa, compartilhamento, fluxo de trabalho, IA, administração) + quais funcionalidades são principais/apreciadas vs. bloqueadas para enterprise + uma lista de "ideias distintas que valem a pena roubar".

Fase 2 — Sintetizar + decisões em lote

Compile UMA mensagem para o usuário:

1. Estado atual — o que nossa funcionalidade tem e falta, verificado tanto nas capturas de tela quanto no código (cite arquivos).
2. O que os concorrentes fazem — algumas linhas por produto, apenas as partes transferíveis.
3. Recomendações em fases — alavancagem mais barata primeiro: (a) expor o que o código já suporta, (b) funcionalidades de organização com pequena migração, (c) funcionalidades de fluxo de trabalho. Inclua as próprias ideias semeadas pelo usuário no prompt. Marque o que é deliberadamente ignorado (formato enterprise, YAGNI).
4. Decisões de múltipla escolha em lote: as 2 a 4 bifurcações que mudam o entregável, opções com letras + uma recomendação cada. Não faça perguntas aos poucos.

Pare e aguarde as decisões. Não comece a projetar um escopo não decidido.

Fase 3 — Canvas de design da direção escolhida

SUB-HABILIDADE OBRIGATÓRIA: a habilidade design (canvas de Design Claude → Artefato). Ela possui a mecânica do canvas; esta fase adiciona as convenções de comparação:

• Capturas de tela da UI atual como seus próprios artboards ("Atual — X") ao lado dos artboards redesenhados ("Redesign — X"). Reduza a resolução das capturas para ~70-100 KB JPEGs (sips -Z 900 -s format jpeg -s formatOptions 60 …) antes de inserir.
• Artboards de redesign correspondem ao sistema de design real do aplicativo — leia os arquivos de tokens e componentes primeiro, copie valores exatos (fontes, tokens de cor, raio de cartão, formato de botão).
• Marque cada diferença: contorno tracejado na cor de destaque do aplicativo + pequeno selo "NOVO" em cada elemento que não existe hoje (variante de rótulo "ALTERADO" para os modificados). Regiões inalteradas não recebem decoração — a ausência é o que torna os marcadores legíveis.
• Notas adesivas no canvas resumem as diferenças por artboard + uma nota geral. Dados de exemplo em mockups são aceitáveis; avise na entrega.
• Mockups estáticos são o entregável padrão; construa um protótipo clicável apenas se o usuário solicitou.

Fase 4 (apenas se o usuário pedir) — Plano de implementação

SUB-HABILIDADE OBRIGATÓRIA: superpowers:writing-plans. Fundamente cada tarefa na leitura de código da Fase 1; carregue o escopo em fases e as decisões textualmente; termine com opções de modo de execução (desdobramento paralelo / subagente / inline), não comece a construir sem solicitação.

Armadilhas (todas morderam a execução de referência)

Sintoma	Correção
Agente reporta capturas de tela, mas o orquestrador não consegue vê-las	Painel do navegador foi usado — reoriente: Playwright MCP savePng + downloadsDir
Captura de tela mostra um site diferente daquele para o qual o agente navegou	Contaminação de sessão compartilhada do Playwright — feche navegador, reabra, refaça, verifique visualmente
CredentialsSignin no login de dev	O email não é um usuário ativo no banco de dados de dev — consulte o banco de dados de dev, use um que seja
"Executable doesn't exist … chromium"	npx playwright install chromium (por diretório de cache, execute novamente após atualizações do Playwright)
Desdobramento retorna vazio / limitado por taxa	>3 agentes concorrentes — ondas de ≤3, repita pernas mortas, reporte parciais ruidosamente
Recomendações não correspondem ao código	Fundamentação no código na thread principal da Fase 1 foi pulada — faça antes de sintetizar