frontend-skill

name	frontend-skill
description	Implementa frontends Next.js (App Router) com UI alinhada ao design system, Atomic Design, TypeScript, SCSS, ShadCN sem Tailwind, DTOs Zod, React Hook Form, middleware/auth, RBAC na UI, estados de carregamento/erro e SSE quando o produto exigir. Use ao criar ou alterar páginas, componentes, hooks, integração com API ou qualquer UI neste repositório.

Skill — Frontend (Next.js, monorepo EmpregaNet)

Documento único: regras para humanos e para o agente de IA. Mantém o mesmo conteúdo de referência.

Quando esta skill se aplica

Qualquer trabalho no frontend: novas telas, componentes, hooks, camada de API, fluxos de autenticação, tempo real (SSE) ou refatorações que toquem na UI.

Alinhamento com o agente

Para implementação, siga as mesmas regras do agente frontend-engineer. Leia e respeite docs/agents/frontend-engineer.md antes de escrever código (stack, o que evitar, organização de pastas).

Resumo

• Usar o perfil frontend-engineer para implementação (link acima).
• Respeitar a estrutura do monorepo em frontend/.
• Não introduzir Tailwind nem expandir o seu uso.
• SCSS e componentes no estilo ShadCN/Radix já adaptados ao projeto.
• Acessibilidade e estados de UI (carregamento, erro, vazio, retry) sempre explícitos.

Regras obrigatórias

• Arquitetura: estrutura por feature; separação clara entre UI, lógica de aplicação e serviços (cliente HTTP em frontend/src/services/, barril conforme convenção do repositório).
• Estilo: SCSS + padrões ShadCN já usados. Não introduzir Tailwind.
• Tipos nas fronteiras: DTOs tipados com Zod (validar entradas da API e variáveis de ambiente quando fizer sentido).
• Acessibilidade: HTML semântico, rótulos, teclado, foco em overlays; ARIA só quando a semântica nativa não bastar.
• UX: estados explícitos de carregamento, vazio, erro e retry — nunca falha silenciosa nem tela em branco.

Checklist de entrega de feature

Use como guia ao construir uma feature:

1. Pasta da feature — features/<feature>/ (ou convenção do projeto): UI, hooks, tipos e serviços específicos colocados juntos.
2. Componentes de UI — peças enxutas e apresentacionais; reutilizar primitivos do design system.
3. Lógica — hooks e/ou serviços pequenos para dados, validação e efeitos colaterais (não dentro de árvores JSX grandes).
4. Camada de API — cliente centralizado; requisições/respostas tipadas (Zod); evitar fetch espalhado sem padrão.
5. Carregamento / erro — UI de pendência e falha; política de reconexão se usar streams.
6. Acessibilidade — teclado e leitor de ecrã nas partes interativas.
7. SSE — só se o produto exigir push no servidor: reutilizar ou criar hook/serviço com backoff, reconexão e erro visível.

Sempre incluir (quando relevante)

• Pastas claras — limites entre components/, hooks/serviços por feature; API + Zod por domínio em services/<domínio>/ (*-api.ts, *-schema.ts); tipos locais na feature quando fizer sentido.
• Middleware / auth — middleware do Next.js em rotas protegidas; sessão ou JWT conforme padrão do projeto.
• UI por papéis — menus, ações e rotas condicionadas a papéis/permissões; centralizar verificações de capacidade; evitar strings mágicas duplicadas.

Stack técnica (estrita)

Usar	Não usar
Next.js App Router, TypeScript	Tailwind (novo ou expansão)
SCSS para estilo	Lógica de negócio inchada em componentes de UI
ShadCN adaptado a SCSS	Acoplamento forte a detalhes internos do backend
Zod para DTOs / validação	—
React Hook Form + resolvers Zod	—

Expectativas de saída

• Seguir naming, layout de ficheiros e estilo de imports já existentes no repositório.
• Texto voltado ao utilizador em português (Brasil) quando o produto for em português.
• Explicar só estrutura ou limites de estado não óbvios; priorizar código que funciona.