---
name: criador-exercicios
description: Use esta skill ao criar ou revisar exercícios práticos deste repositório, especialmente em seções didáticas de HTML, CSS, JavaScript, DOM, arrays, objetos e PHP. Ela ajuda a produzir enunciados concretos em PT-BR, com objetivos claros, requisitos operacionais, reaproveitamento de conteúdos anteriores e estrutura compatível com a organização pedagógica do projeto.
---

# Criador de Exercícios

Use esta skill quando o pedido envolver criar, expandir, revisar ou reorganizar exercícios práticos em qualquer seção do curso.

## Objetivo

Produzir exercícios que sejam:

- claros para estudantes iniciantes;
- práticos e verificáveis;
- coerentes com o conteúdo já estudado;
- locais à pasta da seção ou do exercício;
- criativos entre si, com fluxos de interação realmente diferentes quando o pedido envolver mais de um exercício;
- escritos em PT-BR correto, com acentuação adequada no texto didático e nos rótulos visíveis.

## Regras do repositório

- Prefira soluções simples, explícitas e fáceis de explicar em aula.
- Mantenha as mudanças locais à pasta do exercício.
- Não introduza frameworks ou dependências novas sem pedido explícito.
- Preserve nomes em português quando o contexto já estiver em português.
- Em textos didáticos, use ortografia correta em PT-BR.
- Quando criar uma sequência de exercícios, não produza variações superficiais do mesmo fluxo com outro tema. Cada exercício deve mudar de forma observável o tipo de estado, a interação central ou a regra de negócio.
- Em exercícios de frontend, evite atributos `data-*` e `dataset`.
- Para ações em elementos criados dinamicamente, use criação explícita de nós (`createElement`), montagem com `append` / `appendChild` e eventos ligados diretamente com `addEventListener`.

## Fluxo recomendado

1. Identifique a seção e o que já foi estudado antes dela.
2. Leia o README da seção para manter continuidade pedagógica.
3. Verifique exemplos vizinhos para copiar o nível de dificuldade e o formato esperado.
4. Defina um problema concreto do mundo real ou escolar.
5. Quando houver múltiplos exercícios, planeje primeiro como eles serão diferentes entre si. Varie a interação principal antes de trocar tema:
	- grade ou mapa visual;
	- votação, ranking ou agregação;
	- fluxo por etapas, wizard ou navegação por índice;
	- estado temporal com pausa, retomada ou expiração;
	- simulação, jogo, tentativa ou desafio;
	- rascunho, preferências, progresso ou histórico.
6. Escolha o estado da aplicação de forma didática:
	- arrays simples para listas lineares;
	- objetos para representar uma entidade;
	- arrays de objetos para coleções estruturadas;
	- objetos indexados por chave para mapas, grades e estados de lookup;
	- objetos de sessão para fluxos em andamento;
	- DOM como camada de exibição e interação.
7. Crie ou revise o README do exercício com requisitos observáveis.
8. Implemente HTML, CSS e JavaScript de forma consistente com o enunciado.
9. Valide se o exercício realmente exige os conceitos da seção e, quando fizer sentido, reutiliza conteúdos anteriores.
10. Revise o conjunto completo e remova exercícios que pareçam cópia com tema trocado.

## Como escrever o README do exercício

Use uma estrutura parecida com esta:

1. Título do exercício.
2. Objetivo da atividade.
3. Conceitos trabalhados.
4. Especificações técnicas do sistema.
5. Estrutura mínima esperada.
6. Regras de funcionamento.
7. O que observar durante a prática.

## Critérios de qualidade do enunciado

O README não deve ficar só em descrições genéricas como "crie um sistema" ou "manipule dados".

O enunciado deve deixar claro:

- quais dados existem;
- onde esses dados ficam armazenados;
- quais ações o usuário pode fazer;
- o que deve mudar na interface após cada ação;
- quais validações mínimas precisam existir;
- quais conceitos da seção estão sendo exercitados.

## Continuidade pedagógica

Sempre que for conveniente, reaproveite conteúdos anteriores.

Exemplos:

- em DOM, use arrays ou objetos como estado da interface;
- em objetos, use formulários simples para atualizar propriedades;
- em arrays, transforme listas em resumos, filas, rankings ou coleções visuais;
- em exercícios posteriores, trate o DOM como exibição dos dados e não como única fonte de verdade.

## Variedade entre exercícios

Quando o usuário pedir vários exercícios novos, trate variedade como requisito, não como acabamento.

Evite entregar uma sequência em que todos seguem o mesmo esqueleto "formulário -> array -> lista", mudando apenas o assunto. Esse padrão pode aparecer em um exercício, mas os demais devem explorar fluxos distintos.

Bons sinais de variedade:

- o formato do estado muda entre exercícios, por exemplo array, objeto único, objeto indexado, sessão em andamento ou ranking consolidado;
- a ação principal muda, por exemplo ocupar posição, distribuir pontos, avançar etapa, pausar tempo, responder tentativa ou recuperar progresso;
- a validação muda de natureza, por exemplo conflito, soma exata, limite temporal, bloqueio de duplicidade, índice válido ou cálculo final;
- a renderização muda de estrutura, por exemplo grade, painel, ranking, tela por etapa, barra de progresso ou controle de timer.

## Padrões por tipo de exercício

### Arrays

- Use problemas com ordem, coleção, busca, filtro, soma, média, contagem ou fila.
- Faça a interface refletir exatamente o conteúdo do array.
- Evite depender de variáveis soltas quando o array pode ser a fonte principal.

### Objetos

- Use objetos para representar entidades como aluno, produto, contato, postagem ou tarefa.
- Garanta que propriedades tenham propósito visível na tela.
- Se houver vários registros, prefira array de objetos.

### DOM

- Deixe claro quais elementos serão atualizados ou criados dinamicamente.
- Se o exercício ficar melhor com estado explícito, use array ou objeto para controlar a renderização.
- Eventos devem ter efeito observável e imediato na interface.
- Não dependa de `data-*` para identificar ação ou item; prefira closures ou funções que recebam o objeto/ID no momento da criação do elemento.

## Implementação

- HTML: estrutura enxuta, nomes claros, rótulos em português.
- CSS: suficiente para distinguir áreas, estados e ações.
- JavaScript: funções pequenas, nomes autoexplicativos, fluxo direto.
- Comentários: apenas quando ajudarem a explicar algo menos óbvio.

## Checklist final

Antes de concluir, confirme:

- o exercício está compatível com a seção e com os conhecimentos anteriores;
- o README diz com precisão o que o aluno deve construir;
- a interface implementada corresponde ao enunciado;
- o texto está em PT-BR correto;
- a solução está simples o bastante para uso em aula.

Se precisar de um modelo enxuto de estrutura para README, leia [./references/readme-modelo.md](./references/readme-modelo.md).