diff --git a/README.md b/README.md
index 73ef6de..493ca38 100644
--- a/README.md
+++ b/README.md
@@ -1,12 +1,10 @@
-Sugestões
-*********
+# Sugestões
 
 Repositório com sugestões para o MP sobre alguns aspectos da TI.
 
 Caso alguém tenha sugestão pode abrir uma isssue ou um PR.
 
-CI/CD
-=====
+## CI/CD
 Para fazer deploy em desenvolvimento/homologação/produção é necessário intervenção manual de alguma pessoa.
 
 **Sugestão** Realizar deploy em ambiente de desenvolvimento a cada commit e no de homologação quando houver **TAGs** e para produção quando houver uma aprovação dos membros responsáveis.
@@ -16,8 +14,7 @@ https://stackoverflow.com/questions/7805603/is-it-possible-for-jenkins-to-automa
 https://jenkins.io/doc/pipeline/steps/pipeline-input-step/
 
 
-Realizar testes automatizados
-=============================
+## Realizar testes automatizados
 Durante o CI/CD realizar os testes automáticos que existirem. No Portal de Serviços os testes foram explicitamentes removidos durante o deploy e só eram realizados no final da Sprint.
 
 **Sugestão** Só aceitar deploy para homologação com o nível de cobertura definido no contrato. Caso contrário é rejeitado automaticamente. É preciso garantir o mínimo de cobertura no código.
@@ -25,22 +22,19 @@ Durante o CI/CD realizar os testes automáticos que existirem. No Portal de Serv
 https://stackoverflow.com/questions/35540823/minimum-code-coverage-threshold-in-jacoco-gradle#43018683
 
 
-Para comentario dos commits:
-============================
+## Para comentario dos commits:
 Aguns dos commits tem só a referência do JIRA da empresa terceirizada. Isso deixa o comentário muito difícil de compreender pricipalmente pela falta de acesso ao JIRA e no futuro para outros desenvolvedores.
 
 **Sugestão** Poderia definir e seguir algumas práticas como: https://sethrobertson.github.io/GitBestPractices/
 
 
-Dar visibulidade da cobertura dos testes
-========================================
+## Dar visibulidade da cobertura dos testes
 Atualmente usamos o Sonar para dar visibilidade dos testes e seus resultados.
 
 **Sugestão** Colocar na documentação do projeto (README) o badge para o projeto no Sonar com as checagens dos parâmetros do contrato.
 
 
-Backlog do projeto
-==================
+## Backlog do projeto
 Atualmente usamos vários softwares para a gestão do backlog.
 
 **Sugestão** Usar o próprio board issue do gitlab. Assim o backlog fica visível e disponível para discussão com todos os envolvidos. E possivelmente até com o cidadão.
@@ -48,8 +42,7 @@ Atualmente usamos vários softwares para a gestão do backlog.
 https://about.gitlab.com/features/issueboard/
 
 
-Usar pipelines
-==============
+## Usar pipelines
 Atualmente os projetos utilizam o Jenkins como ferramenta de CI/CD.
 
 **Sugestão** Usar o próprio pipeline do Gitlab para CI/CD. Assim é possível fazer o pipeline as code e é facilmente visto o que deu errado em um build.
@@ -57,33 +50,28 @@ Atualmente os projetos utilizam o Jenkins como ferramenta de CI/CD.
 https://docs.gitlab.com/ee/ci/pipelines.html
 
 
-Usar Chats
-==========
+## Usar Chats
 Atualmente é difícil a conversa com os desenvolvedores.
 
 **Sugestão** Usar alguma ferramenta de Chat inclusive com integrações para um **chatops**
 
-
 https://docs.gitlab.com/ee/ci/chatops/
 https://github.com/RocketChat/Chat.Code.Ship
 
 
-Ter mais janelas de RDM (ou não precisar ter)
-=============================================
+## Ter mais janelas de RDM (ou não precisar ter)
 Atualmente a RDM só pode ser executado em terça e quinta.
 
 **Sugestão** Poder realizar CI/CD de maneira automatizada sem a necessidade de RDM ou ter mais janelas.
 
 
-Acesso aos Logs de produção
-===========================
+## Acesso aos Logs de produção
 Atualmente o acesso aos logs tem que ser liberados.
 
 **Sugestão** Disponibilizar automaticamente em alguma ferramenta como Kibana ou similar.
 
 
-Sprints com features e bugs
-===========================
+## Sprints com features e bugs
 Atualmente as sprints concorrem com os bugs e features. Isso torna a geração de valor com novas features mais difícil e moroso.
 
 **Sugestão** As sprints serem somente para novas features e os bugs não ocupam slot de tempo na sprint.
--
libgit2 0.21.2