BIGboss248/nextjs-wordpress

Habilidade de Design de Componentes e UI (component-design)

Um fluxo de trabalho estruturado de descoberta e especificação de UX/UI para projetar componentes, seções e páginas web e de aplicativos. Gera especificações de design prontas para produção (design-spec.md) consumíveis por ferramentas de prototipagem visual como stitch-design e fluxos de implementação de código.

---

Diretrizes e Princípios Fundamentais

[!IMPORTANT] 1. Diretriz de Zero Código (Escopo Puro de Design): Esta habilidade é estritamente voltada para UX, UI, arquitetura de layout, tipografia e tokens visuais. Nunca gere componentes React, diretivas Next.js, interfaces de propriedades TypeScript ou comandos de instalação de pacotes (sem comandos CLI shadcn/Radix). A implementação de código é tratada em fluxos de trabalho de desenvolvimento posteriores.

[!CAUTION] 2. Portão de Pré-requisito de Tokens de Design (Regra dos Tokens Primeiro): Nenhum componente pode ser projetado sem tokens de design canônicos verificados em docs/project.json. Tokens faltantes devem ser questionados e persistidos antes de rascunhar designs de componentes. Veja token-verification-matrix.md.

[!TIP] 3. Regra de Conservação de Tokens (Geração de Imagem Zero Direta na Skill): Nunca invoque generate_image diretamente. Formule prompts de geração de imagem estruturados para o usuário gerar e colocar nos diretórios do projeto.

[!NOTE] 4. Consulta Seletiva de Padrões (Conservação de Tokens): Verifique a tabela de roteamento em references/component-design-patterns.md e carregue APENAS o arquivo de componente correspondente sob references/patterns/ (ex.: hero.md). Se houver correspondência, questione o usuário durante a entrevista adaptativa se ele deseja que aquele padrão seja implementado.

---

Visão Geral do Fluxo de Trabalho

flowchart TD
    Start["Invocar /component-design<br/>(Página + Nome do Componente)"] --> Step1["Passo 1: Contexto Dinâmico e Portão de Token<br/>(Examinar docs/**, CONTEXT.md, tokens e padrão alvo)"]
    Step1 --> CheckTokens{"Os Tokens de Design<br/>estão completos em docs/project.json?"}
    CheckTokens -- "Tokens Faltantes" --> GrillTokens["Questionar Tokens Faltantes<br/>(3 escolhas baseadas no contexto)"]
    GrillTokens --> SaveTokens["Persistir em docs/project.json"]
    SaveTokens --> Step2
    CheckTokens -- "Verificados" --> Step2["Passo 2: Questionamento Adaptativo em Múltiplas Rodadas<br/>(Rodadas 1–3 + Questionamento do Padrão Alvo)"]
    Step2 --> Step3["Passo 3: Formulação de Prompt de Ativo Visual<br/>(Fornecer prompts de imagem prontos para uso)"]
    Step3 --> Step4["Passo 4: Estruturar e Escrever design-spec.md<br/>(docs/design/components/[pagina]/[componente]/)"]
    Step4 --> Step5["Passo 5: Auditoria de Subagente e Auto-Reparo<br/>(invoke_subagent verifica diretrizes e tokens)"]
    Step5 --> Finish["Especificação Pronta para Entrega Posterior<br/>(Prototipagem Visual / Implementação)"]

---

Guia de Execução

Passo 1: Descoberta de Contexto Dinâmico e Portão de Verificação de Tokens de Design

1. Examinar Contexto do Projeto: Inspecione dinamicamente todos os arquivos em docs/ e CONTEXT.md raiz para extrair personas alvo, objetivos de negócio e marcadores de design existentes.
2. Examinar Locais Suportados: Leia project_context_and_metadata.supported_languages em docs/project.json.
3. Verificar Tokens de Design: Audite docs/project.json sob "design_system" conforme token-verification-matrix.md.
4. Questionar Tokens Faltantes: Se tokens estiverem ausentes, formule 3 opções adaptadas ao projeto (marcando uma como (Recomendado)), questione o usuário e persista-as sob "design_system".
5. Consulta de Padrão de Design Alvo: Examine a tabela de roteamento em references/component-design-patterns.md e veja APENAS o arquivo de padrão de componente específico sob references/patterns/ se houver correspondência com o componente sendo projetado.

Passo 2: Questionamento Progressivo de Componente em Múltiplas Rodadas

Execute uma entrevista adaptativa de 3 rodadas usando ask_question (ou chat interativo), pausando entre as rodadas para absorver as respostas do usuário. Consulte adaptive-grilling-rounds.md para formulações completas das perguntas:

• Se um padrão correspondente foi localizado em references/patterns/, incorpore seu questionário na Rodada 1 ou Rodada 2 para questionar explicitamente o usuário se ele deseja que ele seja implementado.
• Rodada 1 (Intenção e História): Esclareça o propósito do componente, as tarefas do usuário e o tom emocional.
• Rodada 2 (Hierarquia Espacial e Grade): Adapte layout de múltiplas colunas, escalas de densidade e fluxo visual focal com base nas respostas da Rodada 1.
• Rodada 3 (Interações e Destaques): Estabeleça dinâmicas de estados hover/foco, ativos de mídia e nuances BiDi / RTL com base nas Rodadas 1 e 2.

Passo 3: Formulação Proativa de Prompt de Ativo Visual

Se o componente exigir gráficos personalizados, fundos ou ícones, formule prompts de geração estruturados para o usuário em vez de chamar generate_image. Veja o formato do bloco de prompt em adaptive-grilling-rounds.md.

Passo 4: Estruturar Pasta do Componente e design-spec.md

1. Crie o diretório: docs/design/components/[nome da página]/[nome do componente]/
2. Estruture design-spec.md usando o layout canônico de 9 seções de design-spec.template.md:
   • §1 Resumo Executivo e História
   • §2 Hierarquia Visual e Fluxo Espacial
   • §3 Grade de Layout e Pontos de Quebra Responsivos (Mobile, Tablet, Desktop)
   • §4 Tokens de Design e Mapeamento de Cores (Claro e Escuro)
   • §5 Escala Tipográfica (Por Locale Suportado)
   • §6 Matriz de Estados de Interação (Padrão, Hover, Ativo, Foco, Desabilitado, Skeleton)
   • §7 Adaptações Bidirecionais (RTL)
   • §8 Acessibilidade e Ergonomia (WCAG AA/AAA, $\ge 44\text{px}$ alvos de toque)
   • §9 Ativos Visuais Recomendados e Prompts

Passo 5: Auditoria de Qualidade Independente por Subagente (invoke_subagent)

Para garantir qualidade imparcial, invoque um subagente revisor independente antes de apresentar os resultados ao usuário:

1. Crie um subagente auditor (TypeName: "self", Role: "Auditor Independente de Design e UX", Model: "inherit").
2. Use o prompt de auditoria estruturado em subagent-audit-protocol.md.
3. Se ISSUES_FOUND, resolva imediatamente todos os problemas sinalizados em design-spec.md antes de concluir.

---

Entrega Posterior

Assim que design-spec.md for aprovado e verificado:

1. Prototipagem Visual: Acione stitch-design para gerar telas de UI e variantes de layout no Google Stitch.
2. Implementação de Código: Forneça design-spec.md para habilidades de implementação de componentes (ex.: nextjs-component-dev / nextjs-create-component).

---

Lista de Verificação de Execução

Antes de concluir a execução, confirme:

• Nenhum comando de código ou instalação de biblioteca (sem React, Next.js, shadcn CLI) existe nos entregáveis.
• Tokens de design canônicos em docs/project.json estão verificados e completos.
• O diretório de saída está estruturado em docs/design/components/[pagina]/[componente]/.
• As opções de questionamento foram sintetizadas dinamicamente, sem suposições fixas de repositório.
• O questionamento do componente seguiu rodadas adaptativas progressivas.
• generate_image NÃO foi chamado diretamente; prompts de ativos foram fornecidos ao usuário.
• design-spec.md inclui todas as 9 seções necessárias.
• A auditoria independente do subagente foi invocada via invoke_subagent e todos os problemas foram resolvidos.