bishoe01/blueprint-extractor

Extract

Crie um DESIGN.md fundamentado a partir de um site público. Extraia padrões de design observáveis; não clone o site como código executável nem reivindique diretrizes oficiais da marca.

Comportamento do Comando

Quando o usuário digitar /extract <url>, trate como uma solicitação para executar este fluxo de trabalho imediatamente.

Se o usuário digitar apenas /extract, peça a URL pública HTTPS e não inicie a extração até que ele a forneça.

Saída padrão:

• pacote de evidências: .blueprint-extractor/<slug>/
• documento final: DESIGN.md no projeto atual do usuário, a menos que ele solicite outro caminho

Fluxo de Trabalho

1. Valide a URL de destino.
2. Crie uma pasta de evidências em .blueprint-extractor/<slug>/ no projeto do usuário.
3. Colete evidências dos dados da página pública:
   • título HTML e metadados
   • CSS vinculado e inline
   • estilos computados de elementos representativos
   • screenshot de desktop em 1440x900 quando a ferramenta de navegador estiver disponível
   • screenshot mobile em 390x844 quando a ferramenta de navegador estiver disponível
4. Extraia tokens concretos apenas do CSS obtido, estilos computados ou screenshots registrados.
5. Escreva blueprint.json e sources.json antes de escrever a prosa final.
6. Sintetize DESIGN.md usando o contrato exato de 9 seções em references/DESIGN_TEMPLATE.md.
7. Execute uma etapa de auto-revisão antes de finalizar:
   • melhore a utilidade de implementação com receitas de componentes observados;
   • melhore a linguagem qualitativa do tema quando suportada por screenshots;
   • separe as evidências extraídas do comportamento inferido por screenshots e das orientações de implementação;
   • remova alegações amplas de produto que não sejam visíveis ou presentes no CSS extraído;
   • preserve o domínio, a arquitetura da informação e os fluxos de trabalho principais do projeto de destino; transfira apenas a linguagem visual;
   • abstraia componentes do domínio de origem antes da reutilização, como "playlist" para "lista de coleção" ou "arte do álbum" para "miniatura visual";
   • mantenha exemplos não suportados fora do DESIGN.md, a menos que marcados como qualitativos ou inferidos.
8. Valide o Markdown final em relação ao template e às evidências.
9. Relate o caminho de saída e quaisquer avisos de confiança na resposta final.

Segurança da URL

Rejeite a solicitação com uma breve explicação quando a URL for insegura ou estiver fora do escopo:

• não https://
• localhost, loopback, IP privado, link-local ou hostname privado
• conteúdo com autenticação ou paywall
• resposta não HTML
• inalcançável, vazia ou com muitos redirecionamentos
• solicitação para ignorar login, raspar dashboards privados, extrair Figma ou clonar código executável

Não siga formulários, fluxos de login, fluxos de checkout, ações destrutivas ou páginas específicas de usuário.

Extração

Se scripts/extract-blueprint.mjs existir e as dependências estiverem disponíveis, execute-o primeiro e use seus artefatos como fonte da verdade. Se estiver indisponível, use as ferramentas de navegador, HTTP e sistema de arquivos disponíveis para reunir evidências equivalentes manualmente.

Prefira evidências determinísticas em vez de suposições visuais:

• As cores devem vir de CSS, estilos computados, atributos SVG ou screenshots amostrados.
• As famílias de fontes devem vir de CSS, estilos computados ou @font-face.
• Os breakpoints devem vir de media queries ou ser explicitamente marcados como inferidos de screenshots.
• Espaçamento, raio, sombras, bordas e movimento devem citar CSS ou estilos computados.
• Se apenas screenshots estiverem disponíveis, mantenha as observações qualitativas e evite tokens numéricos inventados.

Leia references/EXTRACTION_SCHEMA.md antes de criar ou editar blueprint.json e sources.json. Leia references/FAILURE_MODES.md quando a extração for parcial ou bloqueada. Leia references/QUALITY_CHECKLIST.md antes de tratar um DESIGN.md gerado como um bom exemplo ou saída com qualidade de lançamento.

Regras de Síntese

Use o idioma solicitado pelo usuário. Se nenhum idioma for solicitado, escreva DESIGN.md em inglês.

O DESIGN.md final deve conter exatamente estas seções H2, nesta ordem:

1. 1. Visual Theme & Atmosphere
2. 2. Color Palette & Roles
3. 3. Typography Rules
4. 4. Component Stylings
5. 5. Layout Principles
6. 6. Depth & Elevation
7. 7. Do's and Don'ts
8. 8. Responsive Behavior
9. 9. Agent Prompt Guide

Não adicione uma seção de Fontes, Confiança ou Apêndice ao DESIGN.md. Coloque avisos de confiança na resposta final do assistente ou no pacote de evidências.

Cada token concreto em DESIGN.md deve ser rastreável até blueprint.json. Marque descobertas incertas como observações qualitativas em vez de valores exatos.

Não transforme o documento final em um despejo seco de tokens. Converta evidências em orientações de design reutilizáveis:

• Nomeie o arquétipo do site apenas quando for visível a partir da página capturada, como "shell de dashboard", "página editorial de aterrissagem", "catálogo de comércio", "player de mídia" ou "site de documentação".
• Trate marcas famosas com moderação: não importe padrões de produto conhecidos, lore da marca ou alegações de sistema oficial, a menos que a página capturada, CSS ou amostras computadas os suportem.
• Preserve o modelo de domínio, a estrutura de informações e os fluxos de trabalho do usuário do aplicativo de destino. O site de origem fornece linguagem visual, não permissão para converter o projeto de destino na categoria de produto do site de origem.
• Separe traços de design transferíveis de objetos de domínio de origem não transferíveis. Transfira cor, tipografia, espaçamento, densidade, forma, camadas de superfície e sensação de interação; não transfira objetos de domínio como faixas, playlists, carrinhos, páginas de documentação, dashboards ou fluxos de checkout, a menos que o usuário solicite explicitamente essa estrutura de produto.
• Quando um componente de origem for útil, expresse-o como um padrão neutro de domínio: "barra lateral de coleção/navegação" em vez de "barra lateral de playlist", "item de conteúdo repetido" em vez de "linha de faixa", "miniatura visual ou bloco de destaque" em vez de "arte do álbum".
• Preserve a distinção entre tokens observados, comportamento de layout inferido por screenshots e orientação de implementação na prosa.
• Transforme componentes recorrentes observados em receitas compactas: propósito, superfície, tipografia, espaçamento, raio, borda/sombra, interação.
• Prefira padrões que generalizem em toda a página em vez de valores decorativos pontuais.
• Diferencie breakpoints extraídos de breakpoints de conveniência de implementação.
• Use 7. Do's and Don'ts para restrições concisas que evitem leituras incorretas prováveis, incluindo uso excessivo de cores de destaque, adição de componentes não suportados, importação do modelo de domínio do site de origem ou alteração da categoria de produto do projeto de destino.
• Torne 9. Agent Prompt Guide prático: referência rápida de cores, exemplos de prompts de componentes e orientação de iteração quando as evidências os suportarem.
• Mantenha a orientação inspirada por e pronta para implementação, sem instruir um agente a clonar o site de destino.

Validação

Antes de finalizar:

• Confirme que DESIGN.md existe no caminho de saída pretendido.
• Confirme que os nomes e a ordem das seções H2 correspondem a references/DESIGN_TEMPLATE.md.
• Confirme que cada cor hex, família de fonte, breakpoint, raio, sombra e valor de espaçamento aparece em blueprint.json ou é explicitamente marcado como inferido/qualitativo.
• Confirme que a saída satisfaz references/QUALITY_CHECKLIST.md ao criar um exemplo ou candidato a lançamento.
• Se a validação falhar, corrija as evidências ou rebaixe os valores não suportados antes de apresentar o resultado.