mingdui/AI-Product-Skills

Skill de Protótipo de Alta Fidelidade Front-end para Product Manager

一、Objetivo

Com base no código-fonte de um projeto front-end existente, criar um protótipo de alta fidelidade, clicável e isolado da entrada de negócios oficial, permitindo que o gerente de produto visualize, demonstre e discuta a solução do produto rapidamente.

Priorizar:

• Consistência de estilo com o projeto existente.
• Aparência de produto real, não de uma demo temporária.
• Uso de dados simulados alinhados ao negócio.
• Fluxo principal clicável.
• Interação adequada para revisão de requisitos.
• Fácil modificação futura.
• Possibilidade de executar e visualizar localmente imediatamente.
• Não afetar páginas de negócios e rotas em uso por padrão.

A menos que o usuário solicite explicitamente, não trate a tarefa como reconstruir todo o sistema do zero.

Quando o objetivo é um protótipo de alta fidelidade, não priorize o desenvolvimento de interfaces de backend, pipelines de dados de produção ou arquitetura complexa.

Convenção de Isolamento Padrão: Primeiro, reutilize o código-fonte, layout, componentes e regras visuais do projeto existente. Em seguida, implemente o protótipo em páginas, rotas ou diretórios de funcionalidades independentes. Não modifique páginas de negócios em uso, entradas de produção ou chamadas de API existentes por padrão; só o faça se o usuário solicitar explicitamente "demonstrar na página original" ou "sobrepor o protótipo à página existente".

---

二、Cenários de Aplicação

Use esta Skill quando o usuário solicitar:

• Criar páginas de protótipo independentes ou rotas com base em código-fonte de projetos React, Vue, HTML ou outros front-ends existentes.
• Demonstrar interações de protótipo em páginas de produto existentes, quando solicitado explicitamente.
• Adicionar páginas de administração, CRM, SaaS, back-office operacional ou estação de trabalho.
• Transformar páginas estáticas em protótipos clicáveis.
• Adicionar dados simulados e estados de interação com alta verossimilhança.
• Adicionar ou otimizar tabelas, formulários, filtros, abas, drawers, modais, gráficos, páginas de detalhes ou fluxos de negócios.
• Estender novas funcionalidades seguindo o estilo do projeto existente.
• Completar uma demo de alta fidelidade para revisão sem desenvolver backend.
• Otimizar hierarquia visual, densidade de informação, responsividade ou feedback de interação.

Expressões comuns:

• Adicionar uma página de lista de clientes no back-office existente.
• Adicionar um dashboard de dados operacionais seguindo o estilo atual do projeto.
• Adicionar um módulo de registro de acompanhamento na página de detalhes existente.
• Completar esta página para se tornar um protótipo clicável.
• Adicionar interações de busca, filtro, alternância de status, drawer e modal.
• Otimizar esta página existente, mas sem alterar o estilo geral do sistema.

---

三、Cenários Não Aplicáveis

Não use esta Skill por padrão nos seguintes casos:

• O usuário deseja começar um novo produto a partir de um diretório vazio.
• O usuário precisa apenas de um site de marketing ou landing page.
• O usuário solicita desenvolvimento de interfaces backend, banco de dados ou serviços de produção.
• O usuário precisa de documentação de arquitetura técnica, não de protótipo.
• O usuário deseja apenas gerar imagens visuais ou capturas de tela estáticas.
• A tarefa atual é principalmente análise de requisitos ou redação de PRD.

Se o diretório atual estiver vazio, explique que esta Skill é voltada para projetos existentes e priorize o uso da "Skill de Protótipo de Alta Fidelidade HTML a partir do Zero".

---

四、Princípios Principais

1. Verifique o Projeto Antes de Começar o Design

Não comece a codificar imediatamente após receber o requisito.

Primeiro, procure em docs/product/ a base de experiência do produto correspondente ao projeto atual e ao front-end atual (c-end/ ou admin/). Se a base existir, leia seus termos de produto, navegação, padrões de página, regras visuais e de interação; ela complementa as convenções técnicas do código-fonte do projeto, mas não substitui a biblioteca de componentes, roteamento e arquitetura de dados.

Se o usuário está iniciando a primeira versão dos requisitos, ou se a funcionalidade atual expõe regras de produto que ainda não foram definidas, mas que se repetem entre páginas, recomende o uso de product-experience-foundation. Protótipos de funcionalidade única não devem criar ou reescrever a base global do produto por conta própria.

Verifique no projeto existente:

• Páginas adjacentes.
• Estrutura de layout da página.
• Estrutura de rotas.
• Diretório de componentes.
• Hooks e funções utilitárias públicas.
• Variáveis CSS.
• Arquivo de tema.
• Design Tokens.
• Uso de ícones.
• Estilo de tabelas.
• Estilo de formulários.
• Estilo de modais e drawers.
• Estilo de mensagens e notificações.
• Gerenciamento de estado atual.

É necessário entender do projeto existente:

• Densidade de informação.
• Espaçamentos entre páginas.
• Hierarquia de fontes.
• Tamanho de cantos arredondados.
• Uso de cores.
• Estrutura de navegação.
• Modo de chamada de componentes.
• Estratégia responsiva.

Novos conteúdos devem parecer uma extensão natural do sistema existente, não um sistema reinventado.

2. Priorize a Reutilização, Não Reinvente a Roda

Priorize a reutilização do que já existe no projeto:

• Botões.
• Tabelas.
• Formulários.
• Seletores suspensos.
• Seletores de data.
• Abas.
• Modais.
• Drawers.
• Paginação.
• Tags de status.
• Mensagens de dica.
• Componentes de layout de página.
• Ícones.
• Funções utilitárias.
• Hooks.
• Design Tokens.

Se o projeto existente já possui capacidade correspondente, não crie um segundo sistema de componentes.

3. Isole a Entrada do Protótipo por Padrão

O protótipo deve ser implementado com base no código-fonte existente, não copiando um site estático separado do projeto; ao mesmo tempo, deve ser isolado da entrada de negócios oficial por padrão.

Priorize uma das seguintes formas suportadas pelas convenções do projeto existente:

• Rota de protótipo independente, por exemplo /__prototype/<feature> ou convenção de rota demo existente no projeto.
• Página de protótipo independente ou diretório de funcionalidades, expondo a entrada apenas no ambiente de desenvolvimento/preview.
• Entrada de protótipo explícita que não altera o comportamento padrão da página original, como parâmetros de consulta, menu de desenvolvimento ou item de navegação temporário.

A entrada do protótipo deve ser capaz de reutilizar o shell da página real e os componentes, mas não deve substituir a entrada online, modificar dados de negócios existentes ou afetar outras funcionalidades por padrão. Se o projeto já possui uma convenção de protótipo, ela deve ser seguida; se não houver, escolha a forma que cause o menor impacto no código de produção e seja fácil de remover, e indique a localização da entrada na resposta final.

4. Trate a Tarefa como um Protótipo de Produto, Não uma Reestruturação Oficial

Priorize servir:

• Revisão do produto.
• Demonstração de negócios.
• Discussão de requisitos.
• Alinhamento entre design e desenvolvimento.
• Iteração rápida.

Use implementações diretas e fáceis de modificar.

A menos que o projeto existente já utilize o padrão correspondente, não introduza:

• Reestruturações globais em grande escala.
• Novas camadas de arquitetura.
• Dependências pesadas.
• Abstração excessiva.
• Máquinas de estado complexas.

5. Use Dados Simulados, Não Corra para Desenvolver o Backend

A menos que o usuário solicite explicitamente, não:

• Conecte-se a APIs reais.
• Projete APIs de backend.
• Crie uma camada de serviço.
• Lide com pipelines de dados de produção.

Coloque os dados simulados o mais próximo possível da página ou funcionalidade atual, para facilitar ajustes pelo gerente de produto.

Use estado local para simular:

• Criação.
• Edição.
• Exclusão.
• Busca.
• Filtro.
• Ordenação.
• Alternância de abas.
• Seleção.
• Mudança de estado.
• Abertura de drawer.
• Abertura de modal.
• Envio de formulário.
• Confirmação secundária.
• Indicação de sucesso.
• Indicação de erro.

6. O Protótipo Deve Ser Clicável

Além do fluxo principal, complemente, conforme necessário, os estados que o gerente de produto precisa revisar:

• Busca.
• Filtro.
• Abas.
• Seleção.
• Visualização de detalhes.
• Estado vazio.
• Estado de carregamento.
• Validação de formulário.
• Estado desabilitado.
• Confirmação secundária.
• Feedback de sucesso.
• Feedback de erro.
• Caminho de retorno.
• Navegação de várias etapas.

Se o requisito incluir várias etapas, o fluxo deve poder ser totalmente percorrido, em vez de deixar várias páginas estáticas não conectadas.

7. Não Transforme um Sistema de Negócios em um Site de Marketing

Quando o usuário precisa de um aplicativo, ferramenta, back-office, CRM, sistema operacional ou estação de trabalho:

• Não crie títulos enormes na primeira tela.
• Não priorize composições visuais de marketing.
• Não use grandes quantidades de gradientes decorativos e fundos como visuais principais.
• Não reduza drasticamente a densidade de informação para efeitos visuais.
• Não substitua controles de negócios reais por cartões de marketing.

---

五、Análise a Ser Concluída Antes de Codificar

Antes de começar a codificar, extraia dos requisitos e do projeto:

• Objetivo do produto.
• Usuário-alvo ou papel.
• Tarefas principais que o usuário precisa realizar.
• Páginas a serem adicionadas ou modificadas.
• Páginas semelhantes existentes.
• Entrada da página.
• Fluxo principal do usuário.
• Campos necessários.
• Estados necessários.
• Diferenças de permissão para diferentes papéis.
• Interações que devem ser implementadas.
• Necessidades de dados simulados.
• Suposições do produto.
• Regras de negócio ainda não definidas.

Não pergunte novamente sobre informações já fornecidas pelo usuário.

Se apenas detalhes da camada de apresentação estiverem faltando, suposições razoáveis podem ser usadas.

Não é permitido complementar, por conta própria, regras de negócio principais que mudariam o escopo do produto.

---

六、Processo de Verificação do Projeto

Primeiro Passo: Identificar a Stack Tecnológica

Confirme:

• Framework front-end.
• Ferramenta de build.
• Método de roteamento.
• Biblioteca de componentes UI.
• Biblioteca de ícones.
• Esquema de estilos.
• Método de gerenciamento de estado.
• Convenções de requisição de dados.
• Método de teste ou preview.

Segundo Passo: Procurar Páginas Semelhantes

Priorize a busca por:

• Páginas de lista do mesmo tipo.
• Páginas de detalhes do mesmo tipo.
• Formulários do mesmo tipo.
• Dashboards de dados do mesmo tipo.
• Modais ou drawers do mesmo tipo.
• Fluxos de negócios do mesmo tipo.
• Estados vazios, de carregamento e de erro do mesmo tipo.

Use estas páginas como referência para implementar as novas páginas.

Terceiro Passo: Identificar Conteúdos Reutilizáveis

Liste o que deve ser reutilizado nesta tarefa:

• Componentes.
• Hooks.
• Design Tokens.
• Funções utilitárias.
• Layout de página.
• Métodos de interação.

Evite reimplementar capacidades já existentes.

Quarto Passo: Entender o Sistema Visual Existente

Verifique:

• Largura da página.
• Padding interno da área de conteúdo.
• Espaçamento entre módulos.
• Hierarquia de fontes.
• Estilo de botões.
• Densidade de formulários.
• Densidade de tabelas.
• Cores de estado.
• Estilo de bordas.
• Uso de sombras.
• Breakpoints responsivos.

Quinto Passo: Determinar o Escopo do Protótipo

Esclareça:

• Onde a entrada do protótipo será colocada e como será isolada da entrada oficial.
• Páginas ou módulos de protótipo a serem adicionados.
• Se o usuário solicita explicitamente a modificação de páginas de negócios existentes.
• Quais interações devem ser clicáveis.
• Quais dados usarão dados simulados.
• Quais estados devem ser representados.
• Quais suposições de produto são necessárias.
• Quais padrões de página de nível de produto a funcionalidade atual reutiliza.
• Quais novos padrões são apenas para esta funcionalidade e quais podem ser candidatos a upgrade futuro.

---

七、Padrões para Dados Simulados

Dados simulados devem usar linguagem de negócios real.

Evite usar:

• Test User.
• Lorem ipsum.
• Company A.
• Sample Data.
• User 001.

Dados simulados devem, idealmente, cobrir:

• Diferentes estados.
• Textos longos.
• Valores ausentes.
• Informações de aviso.
• Dados de limite.
• Decisões de diferentes usuários.
• Diferentes estágios de negócios.
• Resultados vazios.
• Operações desabilitadas.

O papel dos dados simulados não é preencher a página, mas ajudar o gerente de produto a encontrar problemas de página e interação.

---

八、Regras para Suposições de Produto

A IA pode razoavelmente complementar detalhes da camada de apresentação, como:

• Nomes de exemplo.
• Datas de exemplo.
• Dados de lista de exemplo.
• Texto de estado vazio.
• Mensagens de sucesso e erro.
• Condições de filtro comuns.
• Métodos de interação alinhados aos hábitos do projeto existente.

A IA não deve complementar, silenciosamente, a seguinte lógica de negócios principal:

• Novos estados de negócios.
• Novas permissões de papéis.
• Novas regras de aprovação.
• Novas formas de cálculo de negócios.
• Novos módulos de gestão.
• Novo escopo de produto.
• Novas dependências de sistemas externos.

Se uma suposição for necessária para a demonstração, ela deve ser explicada de forma concentrada na resposta final.

Se uma nova interação entrar em conflito com a base de experiência do produto, não a sobreponha silenciosamente. Siga a base confirmada, ou liste o motivo do desvio e "se é necessário retornar à base" como itens a serem confirmados.

---

九、Padrões de UI e Interação

1. Arquitetura da Informação

Priorize garantir:

• Hierarquia clara.
• Agrupamento razoável.
• Seleção de campos eficaz.
• Ação principal evidente.
• Densidade de informação estável.
• Página fácil de escanear.

2. Escolha de Controles

Priorize o uso de controles familiares ao usuário:

• Ações de ferramentas usam botões de ícone.
• Alternância de modo usa controle segmentado.
• Configurações binárias usam interruptor ou caixa de seleção.
• Configurações numéricas usam campo de entrada, controle deslizante ou stepper.
• Opções múltiplas usam menu ou suspenso.
• Visualizações de mesmo nível usam abas.
• Tarefas secundárias usam drawer ou modal.

3. Uso de Cartões

Evite cartões aninhados dentro de cartões.

Cartões são adequados para:

• Itens de lista repetidos.
• Modais.
• Drawers.
• Ferramentas independentes.
• Grupos de dados que precisam de destaque claro.

Não transforme cada bloco da página em um cartão.

4. Controle de Decoração

Evite:

• Gradientes decorativos com brilho.
• Esferas flutuantes.
• Efeitos bokeh.
• Decorações SVG sem sentido.
• Fundos puramente atmosféricos.
• Tela inicial estilo marketing.
• Página preenchida com um único tom.

Após implementar, verifique o CSS; se a página quase só tiver uma paleta de cores, ajuste adequadamente.

Preste atenção especial para evitar:

• Grandes áreas de gradiente roxo ou azul-roxo.
• Grandes áreas de bege ou areia.
• Grandes áreas de azul escuro ou cinza-azulado.
• Grandes áreas de marrom ou laranja.

5. Estabilidade de Texto e Layout

Garanta que o texto se adapte a:

• Botões.
• Células de tabela.
• Cartões.
• Barra lateral.
• Drawers.
• Modais.
• Contêineres mobile.

Use conforme necessário:

• Quebra automática de linha.
• Truncamento de texto.
• Largura mínima e máxima.
• Grade estável.
• aspect-ratio.
• Dimensões relativas ao contêiner.

Não escale fontes dinamicamente com base na largura da viewport.

A menos que o sistema de design existente exija, mantenha o espaçamento entre letras como 0.

6. Não Explique o Protótipo Dentro da Interface do Produto

Não exiba na página explicações como:

• Como o protótipo foi feito.
• Quais soluções temporárias foram usadas.
• Como o revisor deve entender a página.
• Quais interações são simuladas.

Adicione instruções na interface apenas se o próprio produto realmente precisar de conteúdo de ajuda.

---

十、Escopo Responsivo

Sistemas Back-Office para Desktop

Se o projeto for claramente um back-office para desktop:

• Primeiro, faça bem a versão desktop.
• Mantenha uma densidade de informação estável.
• Garanta que não quebre completamente em telas pequenas.
• Evite que operações críticas fiquem inacessíveis.
• Evite, tanto quanto possível, rolagem horizontal desnecessária.

Produtos Mobile ou para Consumidor

Se o produto for voltado para consumidores, mobile-first, ou o usuário solicitar explicitamente uma versão mobile:

• Projete o layout e a interação mobile com o mesmo cuidado.
• Verifique o tamanho das áreas de toque.
• Verifique o corte de controles.
• Verifique elementos com posicionamento fixo.
• Verifique espaçamentos de segurança.
• Verifique o comportamento do teclado e formulários, conforme necessário.

Todas as Páginas Precisam Ser Verificadas

• Sobreposição de texto.
• Corte de controles.
• Entrada de ação oculta.
• Breakpoints de navegação da página.
• Estouro horizontal.
• Tabela ilegível.
• Drawer ou modal inutilizável.

---

十一、Fluxo de Implementação

Primeiro Passo: Ler o Projeto Existente

Verifique a estrutura do projeto relevante e páginas semelhantes.

Segundo Passo: Esclarecer a Entrada e o Escopo do Protótipo

Organize:

• Localização da página, rota ou diretório de funcionalidades do protótipo.
• Método de isolamento da entrada de negócios oficial.
• Páginas ou módulos existentes a serem modificados apenas quando o usuário solicitar explicitamente.
• Fluxo principal do usuário.
• Interações que devem ser implementadas.
• Estados de dados simulados.
• Componentes reutilizáveis.

Terceiro Passo: Implementar o Protótipo Independente Seguindo a Maneira do Projeto Existente

Mantenha o existente:

• Framework técnico.
• Sistema de componentes.
• Método de estilos.
• Método de roteamento.
• Ícones.
• Funções utilitárias.
• Hábitos de gerenciamento de estado.

Quarto Passo: Adicionar Dados Simulados e Interação

Use estado local para implementar o fluxo completo necessário para esta revisão.

Quinto Passo: Complementar Estados Necessários

Adicione apenas estados relevantes para a funcionalidade atual:

• Estado vazio.
• Estado de carregamento.
• Estado de validação.
• Estado desabilitado.
• Estado de sucesso.
• Estado de erro.
• Confirmação secundária.
• Estado sem permissão.
• Estado de dados indisponíveis.

Sexto Passo: Executar o Projeto Realmente

Inicie o serviço de desenvolvimento local existente, se necessário.

Não declare que a tarefa está concluída antes que o projeto possa ser visualizado.

Sétimo Passo: Realizar Verificação Visual e de Interação

Verifique:

• A página não está em branco.
• Os estilos carregaram corretamente.
• Ícones e recursos estão sendo exibidos normalmente.
• Não há estouro de texto evidente.
• O layout não está pulando de forma anormal.
• As interações principais podem ser usadas.
• A navegação não tem becos sem saída.
• O desempenho responsivo é aceitável.

Se possível, use a inspeção do navegador ou capturas de tela para verificar.

---

十二、Entregas Finais

De acordo com a situação real da tarefa, a entrega final deve incluir:

• Código-fonte front-end adicionado ou modificado.
• Página de protótipo independente, diretório de funcionalidades ou rota, e explicação da entrada.
• Páginas de negócios existentes modificadas apenas quando solicitado explicitamente pelo usuário.
• Componentes públicos reutilizados.
• Dados simulados locais.
• Interações principais clicáveis.
• Estados vazios, de carregamento, validação, desabilitados, de sucesso e de erro relevantes.
• Navegação de página funcionando corretamente.
• Instruções para executar ou visualizar o projeto.
• Explicação das suposições de produto.
• Lista de regras de negócio ainda não definidas.
• Se um demo.md for criado, registre as conclusões da revisão e os itens a serem confirmados; ele serve apenas como marcador de transição, não substitui os artefatos de engenharia do projeto.

A menos que ajude na execução ou revisão, não crie documentos ou arquivos de arquitetura adicionais em grande quantidade.

---

十三、Critérios de Conclusão

O protótipo só é considerado concluído quando as seguintes condições forem atendidas:

• A página ou módulo de protótipo já existe no projeto atual e está isolado da entrada de negócios oficial (a menos que o usuário solicite explicitamente a substituição da entrada original).
• O estilo visual é consistente com o projeto existente.
• Os componentes existentes e Design Tokens foram reutilizados adequadamente.
• O fluxo principal do usuário pode ser percorrido do início ao fim.
• Cada ação principal tem feedback claro.
• A navegação da página não tem becos sem saída.
• Os dados simulados podem ser atualizados após ações críticas.
• Os estados de página relevantes foram representados.
• Não há estouro de texto evidente.
• O projeto pode ser executado localmente sem erros de bloqueio.
• O escopo do produto já confirmado não foi expandido sem autorização.
• A resposta final explica claramente as suposições de produto e as regras a serem confirmadas.

---

十四、Requisitos da Resposta Final

Após a conclusão, explique de forma fácil de entender para o gerente de produto:

• Quais páginas, módulos e fluxos foram adicionados ou modificados.
• A localização da entrada do protótipo e como ela está isolada da entrada de negócios oficial.
• Quais interações já estão clicáveis.
• Quais dados simulados e estados de página foram adicionados.
• Quais componentes e padrões de projeto existentes foram reutilizados.
• Quais suposições de produto foram feitas.
• Quais regras de negócio ainda precisam ser confirmadas.
• Como executar ou visualizar o protótipo.
• Quais verificações visuais e de interação foram concluídas.
• Quais bases de experiência do produto foram reutilizadas; se novos padrões repetidos surgirem, explique se são apenas candidatos, não os extraindo como regras globais antes da confirmação.
• Após a confirmação da revisão, o desenvolvimento implementará conforme o protótipo; não crie artefatos de engenharia falsos na fase de protótipo, nem implemente código de produção sem autorização.

A resposta final deve ser concisa, focando no conteúdo que o gerente de produto precisa revisar.