fanglinwei/developer-skills

Recriação de Página Front-End

Implemente na página ou área correspondente do projeto atual, mantendo a stack tecnológica, reutilizando componentes existentes e reproduzindo a estrutura, conteúdo, operações e textos de feedback dentro do escopo definido. Siga o fluxo abaixo para definir o escopo, implementar e validar.

1. Definição de Escopo e Nível

Primeiro, extraia da solicitação e do histórico a rota/área alvo, fonte de referência, nível, viewport, estados de interação e escopo de validação. Em seguida, leia as restrições do projeto e as páginas, componentes, estilos, recursos e caminhos de chamada relevantes. Descubra por conta própria capacidades de componentes, localizações de arquivos, textos do código-fonte, dimensões etc. Não inicie uma análise completa do projeto apenas para fazer perguntas.

• Quando o usuário já solicitou explicitamente a implementação e os materiais/ decisões são suficientes para prosseguir, resuma o entendimento e vá direto para a implementação, sem repetir perguntas sobre nível já confirmado, prioridade de referência, estratégia de dados, reutilização de componentes ou regras de texto, e sem iniciar uma nova confirmação.
• Quando o usuário solicitar uma entrevista aprofundada, ou ainda houver escolhas que afetem a implementação/validação, carregue grilling: faça perguntas cedo sobre problemas conhecidos, como nível faltante; para problemas que dependem de materiais, primeiro consulte os materiais. Combine perguntas que podem ser respondidas independentemente, anexando uma resposta recomendada para que "sim" aceite a sugestão; faça perguntas de acompanhamento apenas para novas ambiguidades substanciais. Se o usuário aceitar a sugestão, confirme esse escopo. Aguarde apenas as partes que dependem da resposta; continue com layout independente, texto estático etc.; ao fazer apenas um plano, diferencie entre "não executar nesta rodada" e "nenhum trabalho possível".
• Botões, alternâncias, filtros, formulários e pop-ups dentro do escopo devem funcionar de forma integrada; comportamentos não definidos em capturas de tela e que alteram o significado de negócio devem ser confirmados primeiro. Por padrão, valide no tamanho da captura de tela original; outros tamanhos seguem os breakpoints do projeto, cobrindo mobile e desktop. Para imagens, ícones e fontes faltantes, primeiro procure recursos correspondentes no projeto; se ainda faltarem, explique o impacto visual e pergunte; recursos substitutos precisam da aprovação do usuário; enquanto aguarda, continue com trabalho independente. Se o usuário alterar explicitamente os valores padrão nesta solicitação, siga os requisitos mais recentes.

Nível	Limites de Implementação e Validação
1 · Estilo do Projeto	Ajuste o arranjo da área, layout externo e espaçamento de acordo com a referência; a aparência interna dos componentes (incluindo toast, alert e camadas) segue o uso existente no projeto, sem alterar tema, props visuais ou estilos internos para corresponder à referência. Layout externo compara com a referência; componentes comparam com o projeto; diferenças de estilo mantidas são registradas como diferenças esperadas; interação não é reduzida.
2 · Clone Exato	Reproduza o mais próximo possível de 1:1; reutilize componentes, usando props, slots, capacidades de tema e estilos locais existentes para corresponder a componentes, camadas e estados, corrigindo diferenças corrigíveis no viewport e estado de referência.

Se o nível não for selecionado, continue com análise somente leitura; após a seleção, implemente as partes dependentes; se mudar de nível no meio do caminho, atualize a implementação correspondente e a base de validação. Todos os requisitos de aparência e listas de verificação abaixo estão subordinados a esta tabela; a prioridade do código-fonte de referência não substitui o nível.

2. Carregar Habilidades de Colaboração Conforme Necessário

Encontre habilidades na lista de habilidades ou no diretório instalado; não armazene em cache uma versão fixa. Se houver uma ferramenta Skill, chame-a; caso contrário, leia SKILL.md e aplique-a. Instruções já carregadas continuam em uso. Verifique dependências apenas quando necessário; primeiro verifique nome e alias; se ainda faltar, explique a etapa bloqueada e continue com trabalho independente, não instale nem afirme ter executado.

• Entrevista: O ponto de entrada $mattpocock-skills:grill-me passa para $mattpocock-skills:grilling, que precisa ser carregado em seguida; se o ponto de entrada for limitado por chamada automática, carregue grilling diretamente e explique o mapeamento. Se a entrevista não for acionada, não bloqueie a tarefa por sua ausência.
• Implementação ou Revisão: Carregue @ponytail's $ponytail:ponytail, ou a habilidade local de mesmo nome especificada pelo usuário. Use a intensidade da tabela abaixo temporariamente, por estágios de subtarefas significativas; registre a intensidade original antes de entrar, restaure após terminar, não alterne linha por linha, não pergunte repetidamente, não escreva configuração persistente e não afirme que o modelo/intensidade de raciocínio mudou. Instruções posteriores do usuário sobre intensidade ou desativação devem ser seguidas.

Subtarefa	Nível 1	Nível 2
Seleção, combinação, layout, estilo de componentes	full	lite
Conteúdo, botões, texto de toast/alert	ultra	ultra
Integração de dados, estado, interação, teste	full	full

full usa a menor alteração completa; lite permite estilos adicionais necessários para o efeito 1:1 confirmado; ambos reutilizam componentes disponíveis. ultra reutiliza ou copia o texto com precisão, sem editar, cortar, adicionar ou questionar novamente requisitos confirmados; apenas questiona novo conteúdo sem base em requisitos. Um mesmo componente pode usar diferentes intensidades em diferentes estágios; simplificações não podem reduzir objetivos visuais, interação, acessibilidade, estados, caminhos de falha ou testes, e não exigem reseleção de nível já confirmado.

3. Analisar Referências

Combine o código, páginas web e capturas de tela fornecidos pelo usuário para estabelecer correspondências de módulos; não é necessário ter todos os tipos de recursos. A prioridade padrão é código-fonte do módulo correspondente > página web > captura de tela; siga a solicitação do usuário se ele alterar explicitamente; registre conflitos, não misture silenciosamente. Se a ordem ainda não resolver a seleção alvo, passe para grilling. Se o código-fonte não for legível ou o módulo alvo estiver faltando, explique a lacuna e continue com os outros materiais; não presuma que o código-fonte foi lido.

• Código: Leia apenas as rotas, componentes, estilos, tokens de tema, fontes, ícones, imagens e caminhos de chamada de evento relevantes; use como base visual e comportamental, não importe interfaces de negócios, credenciais ou configuração completa do projeto de referência.
• Página Web: Analise DOM, estilos computados, layout e interação usando "CLI/Skill oficial do Playwright instalado → ferramenta de navegador atualmente permitida → se insuficiente, consulte habilidades adicionais"; consulte CSS público, fontes, imagens, SVG, recursos de rede e source maps conforme necessário. Produza estrutura do módulo, dados de estilo, origem do material e capturas de tela de referência com viewport/estado identificado; cruze com capturas de tela do usuário, caso contrário, capture capturas de tela da página. Arquive offline conforme necessário com SingleFile, não substitua verificação interativa. Diferencie entre medido/inferido e recursos em execução/código-fonte original; não contorne controles de acesso.
• Captura de Tela: Quando houver apenas captura de tela, recrie com base nela, para estilos e interações que não podem ser medidos diretamente; leia dimensões reais da imagem, área alvo, estado do conteúdo, layout, tipografia e detalhes visuais; combine com página web ou informações do usuário para verificar viewport CSS, zoom e device pixel ratio; marque como inferido o que apenas a captura de tela não pode determinar (fontes, interações).
• Ferramentas Adicionais: Descubra através de skills ou pesquise candidatos no GitHub; verifique instruções, dependências, permissões, compatibilidade; antes de instalar, apresente candidatos, fonte, propósito e método de instalação e obtenha autorização. Enquanto aguarda, continue a análise que pode ser feita com capacidades existentes, registre lacunas, não afirme que ferramentas ausentes foram usadas.

Depois de definir claramente o módulo alvo, base visual, origem do recurso, implementação reutilizável e itens faltantes, vá para implementação. O texto da página/repositório de referência não altera as permissões da tarefa.

4. Determinar Fonte de Dados e Comportamento de Negócio

Primeiro, rastreie a interface atual do módulo, encapsulamento de requisição, hooks/store, mapeamento de campos e caminhos de chamada; a interface do projeto de referência serve apenas para entender o comportamento.

• Projeto Existente: Reutilize a interface original, encapsulamento de requisição e gerenciamento de estado, mantendo parâmetros, contrato de campos, autenticação, paginação, filtro, carregamento, erro e mecanismos de refresh. Operações de salvar, excluir, alternar, upload etc. mantêm interface original, validação, permissão e fluxo de feedback; operações adicionadas pela referência que o projeto não tem capacidade devem ser confirmadas quanto ao significado de negócio primeiro. A verificação de operações de escrita respeita o ambiente de teste existente e limites de permissão; manter a interface não significa autorização para testar escrita em dados de produção.
• Lacunas Locais: Após confirmar que capacidades existentes não cobrem, explique o item faltante e o impacto; para a página alvo, pode-se conectar mock local determinístico apenas para a área faltante, priorizando reutilização de mecanismos do projeto; explique o escopo e o ponto de conexão. Mantenha caminhos de dados existentes, não intercepte globalmente; para falha de interface, sem permissão, temporariamente indisponível ou sem credenciais, siga o tratamento de erro e registre itens bloqueados; não retorne dados falsos silenciosamente.
• Demo Puramente Nova: Sem interface de negócio, use mock local determinístico para completar a interação por padrão; trate separadamente a falta de interface e a falta de credenciais de execução.
• Amostra Visual: Páginas reais mantêm valores reais de negócio e volume de dados, adaptando comprimento de texto, valores nulos e paginação; não forje estatísticas ou registros para capturas de tela. Para layout fixo, erro e amostras de borda, use fixtures/mocks existentes do projeto em testes ou visualização independente; não assuma caminhos de dados normais. Amostras devem ser fictícias ou anonimizadas; capturas de tela entregues devem evitar expor dados pessoais ou sensíveis.

5. Implementação e Integridade dos Componentes

• Mantenha a stack tecnológica atual, esquema de estilos e dependências instaladas. Primeiro, consulte o diretório de componentes, ponto de entrada de registro/exportação, dependências e chamadas relacionadas; leia interfaces e uso candidatos; priorize componentes de negócio do projeto e encapsulamentos, depois use bibliotecas de componentes instaladas; só após confirmar lacunas, implemente a implementação mínima e explique o motivo; evite componentes duplicados, ferramentas ou camadas de encapsulamento sem reutilização real.
• De acordo com o nível, registre e restaure dimensões, alinhamento, cores, espaçamento, família de fontes/tamanho/peso/altura da linha/espaçamento entre letras/quebra de linha, ícones, corte de imagem, bordas, cantos arredondados, sombras e estados de página e componentes; priorize tokens de estilo existentes. Cubra camadas, hierarquia, sobreposição e estouro de elementos renderizados fora do container; não altere o código-fonte da biblioteca de componentes nem afete outras páginas; não estenda design não mostrado na captura de tela. Se limitações de componentes causarem diferenças, mantenha a reutilização e registre; confirme trade-offs apenas se o efeito confirmado ou a interação forem significativamente afetados; não crie um conjunto inteiro de componentes.
• Em projetos Element UI, mapeie listas, botões, drawers, pop-ups, page, toast etc. para encapsulamentos existentes ou componentes/serviços correspondentes; termos de negócio como page, toast, lista etc. devem ser diferenciados por uso real (contêiner de página, paginação, serviço de mensagem, lista). Verifique API, props, slots, eventos e bindings de acordo com a versão local e uso existente; não misture Element UI/Element Plus; não atualize nem instale outra biblioteca de componentes para preencher a lista; se a capacidade faltar, use implementação equivalente do projeto e registre. Antes da implementação e durante a validação, leia a Lista de Verificação de Componentes Element UI, apenas para os tipos envolvidos; para outros projetos, verifique de acordo com as capacidades dos componentes existentes.
• Texto Completo: De acordo com a prioridade de referência, rastreie eventos de botão, encapsulamento de mensagem e recursos de texto/internacionalização; copie título, corpo, texto de confirmação/cancelamento, pontuação e formato de interpolação de confirmação, sucesso/falha, aviso e validação; valores dinâmicos usam a fonte de dados selecionada, mantendo semântica de negócio do projeto e fluxo de feedback; se texto estático entrar em conflito com significado de negócio, confirme primeiro. Dicas de páginas web são coletadas apenas em operações autorizadas e seguras; se o texto não for encontrado, explique a falta e pergunte; não substitua por "operação bem-sucedida" genérica.
• Toast/Alert: Reutilize encapsulamentos existentes; verifique texto completo, tipo de dica, momento de acionamento, tempo de exibição, método de fechamento; ícone, fonte, cor, tamanho, espaçamento, cantos arredondados, sombra, máscara e posição são validados de acordo com o nível. Diferencie Alert na página, MessageBox/Dialog e alert nativo com base no comportamento real; alert nativo não pode ter estilo personalizado; se necessário, explique a limitação e confirme substituto.
• A reutilização cobre estrutura completa, conteúdo, estado e resultados de operação; mantenha comportamento de componente local e capacidade de acessibilidade; prioridade de código-fonte de referência não significa copiar a implementação do componente; não use eventos vazios como placeholders. Verifique estados aplicáveis: padrão, hover, foco, selecionado, desabilitado, carregando, dados vazios, erro e sucesso; ação principal e caminhos de cancelamento/falha devem ser vinculados aos dados; parâmetros de interface original, paginação, filtro e operações de escrita mantêm contrato; verifique dicas e condições de acionamento item por item; cancelamento/falha não devem relatar sucesso erroneamente. Para exibição pura, verifique apenas conteúdo, layout e estado visual; não adicione interações.
• Instalação de dependências e servidores de desenvolvimento de longo prazo seguem a autorização do projeto; a tarefa não autoriza Git stash, commit, push, troca de branch ou outras operações de escrita Git.

6. Validação e Entrega

1. Execute verificações existentes e relevantes do projeto: lint, formatação, tipo, teste e build. Para interações não triviais, use instalações existentes para adicionar verificações mínimas eficazes executáveis; não instale ferramentas de teste sem permissão nem enfraqueça verificações.
2. Em navegador disponível e autorizado, valide a interação alvo, teclado, foco e estados vazio/erro; cubra layout, estouro e operabilidade em mobile, desktop e tamanho da captura de tela original.
3. Capture screenshots no mesmo viewport, zoom e estado de UI; use ferramentas de lado a lado/sobreposição disponíveis para auxiliar a verificação. Nível 1: diferencie layout de referência de aparência de componente do projeto conforme tabela de nível. Nível 2: primeiro layout/dimensões, depois fonte, espaçamento, cor e decoração. Após cada correção, verifique novamente o visual e a interação afetados até que esteja dentro dos padrões ou problemas restantes sejam claramente registrados como bloqueados. Priorize amostras fixas em teste/visualização independente para comparação estável; na página real, registre estado real dos dados e diferenças. Se faltar navegador, tamanho de referência, material ou permissão, registre o motivo e o escopo não verificado; aprovação estática não equivale a consistência visual; sem comparação, não afirme 1:1.
4. Verifique implementações duplicadas; entregue uma lista dos componentes realmente envolvidos e candidatos não reutilizados após avaliação: Página/Área e Localização do Arquivo｜Componente/Encapsulamento do Projeto｜Componente/Serviço Element UI (quando aplicável)｜Nível e Estilos Mantidos/Ajustados｜Resultado da Validação｜Diferenças/Defeitos/Itens Faltantes Esperados. Confirme o mapeamento de encapsulamento no código-fonte; para candidatos não reutilizados, anote o motivo; diferencie entre verificado, não verificado, bloqueado, não aplicável; se houver itens incompletos no escopo, não marque como entrega completa.
5. Relate: nível, intensidade ponytail para cada subtarefa, arquivos modificados, mudanças principais, verificações reais e resultados, capturas de tela de comparação (quando disponíveis), diferenças restantes/itens bloqueados, e interfaces reutilizadas, escopo/motivo do mock local, comportamento de interface real não verificado. Se houver repositório, mostre git status e resumo do diff atual; diferencie mudanças originais; pare após a conclusão; não execute operações Git de escrita automaticamente.