Gerador de Checklist Markdown

Checklist em Markdown: checkboxes versionados

Um checklist em Markdown é uma extensão introduzida pelo GitHub Flavored Markdown (GFM) e depois adotada em todo o ecossistema. A sintaxe é mínima: um bullet, um espaço, colchetes contendo um espaço (não marcado) ou um x (marcado). No GitHub, GitLab, Bitbucket, no preview do VS Code e no Obsidian, esses tokens viram checkboxes interativos — quem lê pode clicar direto em um pull request ou issue e o Markdown subjacente é atualizado.

## Checklist antes do merge
- [x] Testes unitários adicionados
- [x] Lint passa (`npm run lint`)
- [ ] Docs atualizadas
- [ ] Screenshots anexadas
  - [ ] Light mode
  - [ ] Dark mode

Onde checklists realmente pagam

• Template de PR em .github/PULL_REQUEST_TEMPLATE.md — todo PR abre com os mesmos itens (testes, docs, screenshots, breaking change sinalizado).
• Templates de issue para bug report e feature request, evitando que quem reporta pule etapas.
• RFCs e ADRs com um TODO embutido de decisões ainda em aberto.
• Onboarding ("primeiro dia", "primeira semana") versionado no repo junto do código.
• Retrospectivas e listas de prontidão de release.

Aninhamento, indentação e linhas de detalhe

Sub-itens são aninhados com indentação de dois espaços (às vezes quatro, dependendo do parser). Você também mistura texto livre entre itens indentando sob o pai sem o prefixo - [ ] — aparece como parágrafo de continuação. CommonMark sem a extensão GFM renderiza - [ ] como texto literal, então vale conferir o renderizador alvo antes de contar com o comportamento interativo.

Comportamento específico do GitHub

No GitHub, marcar uma caixa no corpo de um pull request recommita a descrição e dispara um evento que outras automações podem consumir. Incluir closes #123 no corpo fecha a issue vinculada no merge — independentemente da checkbox correspondente estar marcada. Ferramentas como GitHub CLI, vim-markdown, a extensão Markdown All in One do VS Code e o Obsidian oferecem atalhos de toggle para que você não precise editar os colchetes à mão.

Checklist vs Jira, Linear, Trello

Uma lista em Markdown vive dentro de um documento e viaja com o código — ótimo para tracking contextual ao lado do trabalho. Um task tracker (Jira, Linear, Trello) é a fonte de verdade do que está planejado, quem é dono e quando é entregue. O equilíbrio saudável é: unidades reais de trabalho no tracker e checklists contextuais efêmeros inline no repo. Tente não duplicar; escolha uma como autoritativa para cada pedaço de trabalho.

Perguntas frequentes

Renderiza igual em todo lugar? Em qualquer lugar que suporte GFM, sim: GitHub, GitLab, Bitbucket, VS Code, Obsidian, Foam, a maioria dos geradores estáticos com o plugin remark-gfm. Renderizadores CommonMark puros deixam os colchetes como texto.

Posso aninhar checklist profundamente? Sim — mantenha o mesmo passo de indentação (dois ou quatro espaços). Acima de três níveis a legibilidade cai, então considere quebrar em seções.

Marcar uma caixa persiste? Só em hosts que reescrevem o arquivo (descrições de issue/PR no GitHub, Obsidian, VS Code). Em uma renderização estática (site de docs gerado), clicar na caixa não faz nada porque não há arquivo para atualizar.

Colchetes não-ASCII quebram a sintaxe? Sim. Alguns locales substituem automaticamente [ ] por variantes full-width ou tipográficas — garanta que o editor preserve colchetes ASCII, ou o parser não detecta a tarefa.