/mochi-redesign
Um fluxo de trabalho de redesign guiado. Ele não aplica um visual fixo. Ele aplica um processo fixo: entender a pessoa, encontrar um conceito, construir um pequeno sistema de design, colocar tudo que é importante na primeira tela como cartões, mover detalhes para popups ricos e páginas dedicadas, escrever copy honesta e verificar cada mudança em tamanhos de tela reais antes de mostrá-la.
Foi destilado de um portfólio real que passou de um template de coluna única para um site estilo bento ao longo de várias rodadas de feedback do proprietário. As lições dessas rodadas (o que funcionou, o que foi rejeitado, o que quebrou) estão codificadas abaixo e em references/.
O resultado nunca deve se parecer com o site de onde este skill veio. Mesma disciplina, identidade diferente: novo conceito, novas fontes, novas cores, novo detalhe de assinatura. Se você se pegar recorrendo a um traço de pincel calêndula, um mascote ou uma grade bento só porque "é o que o skill faz", pare e volte para a Fase 1.
Como executar
Os argumentos são texto livre opcional, ex.: /mochi-redesign cliente/ ou /mochi-redesign apenas a página inicial, mantenha o blog como está.
Trabalhe através das fases em ordem. Cada fase termina em um gate: mostre ao proprietário o resultado (capturas de tela, não descrições) e aguarde a reação antes de prosseguir. Redesigns falham quando várias decisões não revisadas se acumulam.
| Fase | Leia primeiro | Gate |
|---|---|---|
| 0. Coleta e auditoria | references/01-intake-audit.md | Proprietário confirma metas, público, escopo, o que não pode mudar |
| 1. Conceito e sistema | references/02-concept-system.md | Proprietário escolhe uma direção; tokens registrados |
| 2. Verdade do conteúdo | references/03-content.md | Proprietário aprova alegações (sem exageros) |
| 3. Primeira tela | references/04-layout.md | Cabe em uma tela de laptop em cada tamanho alvo |
| 4. Camada de detalhes | references/05-interaction.md | Popups rolam internamente, travam a página, sem alteração de layout |
| 5. Páginas secundárias | references/06-content-pages.md | Listas e páginas de leitura correspondem ao sistema |
| 6. Mídia (opcional) | references/07-media.md | Walkthroughs reais, compactados, reproduzem apenas quando visíveis |
| 7. Polimento e QA | references/08-qa.md | Clip check passa, ambos os temas, mobile, lint, build |
| 8. Entrega | references/09-feedback-and-handoff.md | Diff limpo, documento de design atualizado, proprietário decide sobre o commit |
references/10-anti-patterns.md é a lista de erros cometidos na primeira vez. Leia uma vez antes da Fase 1 e novamente antes da Fase 7.
Inegociáveis
- Olhe antes de mudar. Leia o código existente, execute o site, tire capturas de tela nos tamanhos alvo. Nunca redesenhe apenas a partir do código.
- Uma identidade por site. O conceito vem do assunto (o que a pessoa ou produto realmente é), não de uma tendência ou da origem deste skill.
- Tudo importante na primeira tela. Os visitantes devem ver quem, o quê e prova (melhor trabalho) sem rolar. Os detalhes ficam a um clique de distância, não a cinco telas abaixo.
- Copy honesta. Nenhuma alegação que o proprietário não possa defender em uma entrevista. Prefira "praticou", "já fez", "onde se encaixa" em vez de "todo", "sempre", "tudo". Mostre provas (números, coisas entregues) em vez de adjetivos.
- Verifique em tamanhos, não na sua cabeça. Toda mudança visual é seguida pela verificação de recorte (
scripts/clip-check.mjs) e por pelo menos uma captura de tela. Nunca relate "pronto" de uma alteração que você não olhou. - Passos pequenos e reversíveis. Mude uma coisa, mostre, escute. Se o proprietário rejeitar algo duas vezes, pare de adivinhar: ofereça 2–3 opções concretas com pré-visualizações e deixe-o escolher. Se ele pedir para reverter, restaure a versão anterior exatamente, não uma reconstrução "mais ou menos".
- Não quebre o que está ativo. Mantenha rotas antigas funcionando, não toque em páginas não relacionadas, não reformate arquivos que não precisavam ser alterados (a reformatação esconde o diff real), não faça commit ou push sem ser solicitado.
- Piso de acessibilidade. Acessível por teclado, foco visível, botões e links reais,
prefers-reduced-motionrespeitado, contraste verificado em ambos os temas, nada importante transmitido apenas por hover.
Como é "pronto"
- Uma primeira tela que cabe em um laptop (1280×720 até 1920×1080) sem conteúdo cortado, sem rolagem horizontal e com um ponto focal claro.
- Um sistema de design pequeno e escrito (tokens, tipografia, raio, regras de movimento) que cada novo componente utiliza.
- Cartões que abrem detalhes ricos (diálogos ou páginas) em vez de rolagem longa.
- Copy aprovada pelo proprietário linha por linha.
- Páginas secundárias (listas, leitores, estudos de caso) que parecem parte do mesmo site.
- Um documento de design no repositório (
DESIGN.mdou similar) descrevendo o sistema e as decisões, para que a próxima pessoa (ou agente) mantenha a consistência.
Arquivos neste skill
SKILL.md este arquivo: fluxo de trabalho, gates, regras
references/01-intake-audit.md perguntas a fazer, como auditar o site atual
references/02-concept-system.md encontrando um conceito; tokens, tipografia, detalhe de assinatura
references/03-content.md escrevendo copy verdadeira, escaneável e destacada
references/04-layout.md layout bento da primeira tela e receitas de cartões
references/05-interaction.md diálogos, hover, movimento, pequenos prazeres
references/06-content-pages.md páginas de blog/lista/leitura que mantêm as pessoas lendo
references/07-media.md gravando walkthroughs e trailers de trabalho real
references/08-qa.md matriz de viewport, clip check, temas, a11y
references/09-feedback-and-handoff.md iterando com o proprietário; finalizando de forma limpa
references/10-anti-patterns.md o que deu errado na primeira vez e a correção
scripts/clip-check.mjs script CDP: cartões cortados, overflow, ajuste à dobra
scripts/shots.mjs script CDP: capturas de tela por viewport e tema
templates/ snippets independentes de framework (React + Tailwind)