Updated prettier version

Signed-off-by: George Araújo <george.gcac@gmail.com>

Author: george-gca

.github/agents/customize.agent.md

@@ -415,40 +415,32 @@ For Portuguese, create `_data/pt-br/cv.yml` with translated content:
 When helping users customize their site:
 
 1. **Understand the request** – Ask clarifying questions if needed; never assume technical knowledge
-
    - If working with multilingual content, confirm which languages they're customizing
    - If the user mentions a relevant issue, discussion, or past question, listen for context but don't require them to provide a link
 
 2. **Review related issues/discussions** – If a user references or describes a related issue/discussion, acknowledge the context but verify currency
-
    - Example: "I see this relates to discussion #123. Let me verify the current approach and address your specific needs."
    - Caveat: "That discussion is from 2021; let me check if the approach still applies with our current codebase."
    - Check if the issue is specific to the original al-folio or applicable to multi-language-al-folio
 
 3. **Identify affected files** – Determine which files need modification
-
    - For multilingual sites: Identify if changes are language-specific or shared across all languages
    - Remember: Language-specific content goes in LANG directories; shared content (styling, social links, etc.) does not
 
 4. **Explain the change clearly** – Describe what you'll do, where the file is located, and why this change matters
-
    - For multilingual changes: Explicitly state which language directories will be modified
    - Explain if the change needs to be replicated across all active languages
 
 5. **Apply changes** – Use file editing tools to make modifications
-
    - For multilingual changes: Make consistent changes across all language directories as needed
 
 6. **Verify syntax** – Ensure YAML/Markdown/BibTeX syntax is correct
-
    - Check that all language-specific files have equivalent content
 
 7. **Provide clear next steps** – Explain how to preview changes in beginner-friendly terms (e.g., "After I make this change, you can see it by...")
-
    - For multilingual sites: Explain how to switch languages in the preview to verify all versions
 
 8. **Anticipate questions** – Address potential confusion before users encounter it; reference related discussions if applicable
-
    - Address multilingual-specific considerations (e.g., ensuring all languages have matching content)
 
 9. **Use plain language** – Avoid or explain technical jargon; prioritize clarity over verbosity
@@ -473,15 +465,13 @@ Always guide users to test changes locally before pushing to GitHub:
 3. **Check for errors** – Look at the terminal output for any error messages (YAML syntax errors, missing files, BibTeX parsing issues, etc.).
 
 4. **Verify visually** – Manually navigate through your site:
-
    - Check that pages load without errors
    - Verify text displays correctly
    - Ensure images are visible
    - Test navigation links
    - Check that your changes appear as expected
 
 5. **Test on different pages** – If you modified:
-
    - `_config.yml` – Check the entire site (affects global settings)
    - Blog posts – Check the blog page and individual post
    - Publications – Check the publications page
@@ -583,7 +573,6 @@ Help users avoid these frequent errors:
 ## Boundaries
 
 - ✅ **Always do:**
-
   - Modify configuration files (`_config.yml`, `_data/*.yml`, `_data/LANG/*.yml`)
   - Create/edit content files (posts, pages, projects, news) in language-specific directories
   - Update BibTeX bibliography
@@ -595,7 +584,6 @@ Help users avoid these frequent errors:
   - Guide users on the multilingual structure and best practices
 
 - ⚠️ **Ask first:**
-
   - Major structural changes to the template
   - Removing core functionality or pages
   - Modifying GitHub Actions workflows
@@ -656,21 +644,17 @@ Help users avoid these frequent errors:
 When users reference issues or discussions:
 
 1. **Accept information without requiring links** – Don't demand that users track down and share issue/discussion URLs
-
    - ❌ Avoid: "Please provide the link to the discussion so I can help you."
    - ✅ Do this: "Let me help based on what you've described. If you remember any details from the discussion, that would be helpful."
 
 2. **Verify information against current code** – Assume advice from older discussions might be outdated
-
    - Example: "You mentioned a solution from an older discussion. Let me check if that still applies with the current version..."
    - Be prepared to offer updated guidance if the codebase has changed
 
 3. **Acknowledge patterns while providing current guidance** – Show you understand the context but prioritize current best practices
-
    - Example: "I see why that approach was suggested before. With our current code, here's the recommended way to do this..."
 
 4. **Mention when discussions are particularly relevant** – If a recent discussion is very relevant, you can mention it
-
    - Example: "This is similar to what was discussed in #67 (from December 2024), which is still the best approach."
 
 5. **Suggest sharing solutions** – If a user's question or your solution would help the community, encourage them to update or create discussions

CUSTOMIZE.pt-br.md

@@ -221,15 +221,13 @@ Entender a pilha de tecnologia do al-folio o ajudará a personalizar e estender
 ### Backend
 
 - **Jekyll 4.x**: [Jekyll](https://jekyllrb.com/) é um gerador de site estático escrito em Ruby que transforma seus arquivos Markdown e modelos em um site estático. O Jekyll é usado para:
-
   - Converter arquivos Markdown em HTML
   - Processar modelos Liquid
   - Gerenciar coleções (postagens, projetos, notícias, livros, etc.)
   - Gerar arquivos e paginação
   - Minificar CSS e JavaScript
 
 - **Ruby Gems** (Plugins Jekyll): O projeto usa vários plugins Ruby para estender a funcionalidade do Jekyll:
-
   - `jekyll-scholar`: Gerencia arquivos de bibliografia (BibTeX) e gera páginas de publicações com citações
   - `jekyll-archives-v2`: Cria páginas de arquivo para postagens e coleções organizadas por categoria, tag ou data
   - `jekyll-paginate-v2`: Lida com paginação para postagens de blog e arquivos
@@ -247,7 +245,6 @@ Entender a pilha de tecnologia do al-folio o ajudará a personalizar e estender
 ### Construção e Implantação
 
 - **GitHub Actions**: Fluxos de trabalho automatizados para construir, testar e implantar seu site. Os fluxos de trabalho estão definidos em `.github/workflows/`:
-
   - **Deploy**: Constrói e implanta automaticamente seu site no GitHub Pages quando você faz push de alterações para o branch principal
   - **Verificação de links**: Valida que todos os links do seu site não estão quebrados
   - **Formatação de código**: Garante que o código segue o estilo de código do Prettier
@@ -471,7 +468,6 @@ Para atualizar uma biblioteca:
 
 1. Altere o número da `version`
 2. Obtenha o novo hash de integridade para a versão atualizada da biblioteca e atualize o campo `integrity` com o novo hash. Você pode:
-
    - Verificar se o provedor de CDN (por exemplo, jsDelivr, cdnjs, unpkg) fornece o hash SRI para o arquivo. Muitos sites de CDN exibem o hash SRI junto da URL do arquivo.
    - Gerar o hash SRI você mesmo usando uma ferramenta como [SRI Hash Generator](https://www.srihash.org/) ou executando o seguinte comando em seu terminal:
 
@@ -481,7 +477,6 @@ Para atualizar uma biblioteca:
 
      Substitua `[FILE_URL]` pela URL do arquivo da biblioteca. Em seguida, adicione `sha384-` ao resultado e use-o no campo `integrity`.
      Para instruções detalhadas sobre como atualizar bibliotecas específicas, veja as Perguntas Frequentes:
-
      - [Como posso atualizar a versão do Academicons](FAQ.pt-br.md#como-posso-atualizar-a-versão-do-academicons-no-modelo)
      - [Como posso atualizar a versão do Font Awesome](FAQ.pt-br.md#como-posso-atualizar-a-versão-do-font-awesome-no-modelo)
      - [Como posso atualizar a versão do Tabler Icons](FAQ.pt-br.md#como-posso-atualizar-a-versão-do-tabler-icons-no-modelo)
@@ -664,15 +659,13 @@ O GitHub restringe o `GITHUB_TOKEN` padrão de acionar outros fluxos de trabalho
 ### Como configurar o PAT
 
 1. **Crie um Personal Access Token**
-
    - Vá para [GitHub Settings > Developer settings > Personal access tokens](https://github.com/settings/tokens).
    - Clique em "Generate new token" (clássico ou fine-grained).
    - Conceda pelo menos as seguintes permissões:
      - `repo` (para tokens clássicos se repo é privado), `public_repo` (para tokens clássicos se repo é público) ou `contents: read/write` (para tokens fine-grained)
    - Salve o token em algum lugar seguro.
 
 2. **Adicione o PAT como um secret do repositório**
-
    - Vá para seu repositório no GitHub.
    - Navegue até `Settings` > `Secrets and variables` > `Actions` > `New repository secret`.
    - Nomeie o secret como `PAT` (deve corresponder ao nome usado no fluxo de trabalho).

_posts/pt-br/2015-07-15-code.md

@@ -43,7 +43,6 @@ For displaying code in a list item, you have to be aware of the indentation, as
 
 ````markdown
 1. We can put fenced code blocks inside nested bullets, too.
-
    1. Like this:
 
       ```c
@@ -56,7 +55,6 @@ For displaying code in a list item, you have to be aware of the indentation, as
 Which displays:
 
 1. We can put fenced code blocks inside nested bullets, too.
-
    1. Like this:
 
       ```c