Blog — Jekyll + GitHub Pages

O que Blog — Jekyll + GitHub Pages faz?

Repositório: ~/repos/github.com/<seu>/<seu>.github.io Motor: Jekyll + GitHub Pages, tema: minima Branch: master → deploy automático ao fazer push Índice: mantenha um arquivo de notas do índice do blog (ex.: ~/notes/blog.md) — atualize após cada post

Nota — Nenhuma build local do Jekyll necessária. O GitHub faz a build no lado do servidor.

---

⚠️ Regra rígida: nenhuma informação do empregador

NUNCA inclua em nenhum post:

• Ferramentas internas, sistemas, codinomes ou infraestrutura do seu empregador
• Nomes de projetos internos, nomes de equipes, estrutura organizacional ou detalhes de roadmap
• Nomes de clientes, nomes de parceiros ou detalhes de contratos
• Tickets internos, páginas wiki ou conteúdo de reuniões
• Salário, headcount, orçamento ou métricas de negócio

Escreva sobre técnicas, ferramentas e padrões — não sobre onde você trabalha ou o que seu empregador lança. Em caso de dúvida, pergunte ao usuário antes de publicar.

---

Fluxo de trabalho

1. Escreva o post

_posts/YYYY-MM-DD-slug-aqui.md

Frontmatter:

---
layout: post
title: "Seu Título Aqui"
date: YYYY-MM-DD
categories: ai agentes produtividade   # separados por espaço
series: "Produtividade com agente de IA"   # omita se não fizer parte de uma série
---

2. Estilo

• Comece com o problema, não com a solução
• Uma frase de abertura concreta — sem "Neste post vou..."
• Blocos de código para qualquer coisa executável
• Tabelas para comparações
• Termine com uma seção ## Fonte linkando repositórios/referências
• Sem floreios de LLM — escreva como um README
• Escape @palavra como \@palavra para evitar erros de citação do typst se um PDF for necessário

Escolha um post bem avaliado publicado no blog e use-o como referência para tom e densidade.

3. Verifique cada link ANTES de publicar (não pule)

Citar URLs de memória resulta em 404s. Verifique o status HTTP de cada link primeiro:

for u in "https://example.com/a" "https://example.com/b"; do
  echo "$(curl -sS -L -o /dev/null -w '%{http_code}' "$u")  $u"
done

Todo link DEVE retornar 200 (ou 301/302 para um destino válido) antes do commit. Isso é mais barato do que enviar um link quebrado e corrigi-lo depois que o usuário perceber.

4. Commit e push

cd ~/repos/github.com/<seu>/<seu>.github.io
git add _posts/YYYY-MM-DD-slug.md
git commit -m "post: <título>"
git push   # GitHub Pages faz deploy automaticamente em ~60s

5. Atualize o índice

Adicione uma linha à tabela ## Posts no arquivo de notas do índice do blog (mais recente primeiro) e acrescente o post à linha ## Série ativa se ele pertencer a uma série:

| YYYY-MM-DD | Título | `categoria/caminho/YYYY/MM/DD/slug.html` |

A URL segue o padrão permalink do Jekyll derivado de categories + date + slug.

6. Verifique se realmente foi ao ar (não pule)

Uma build bem-sucedida do Pages NÃO significa que o post está no ar — o Jekyll descarta silenciosamente posts com data futura. Faça curl da URL real após a build ser concluída:

base="https://<seu>.github.io"; slug="/CATEGORIA/CAMINHO/YYYY/MM/DD/slug.html"
curl -sS -L -o /dev/null -w "%{http_code}\n" "$base$slug"   # deve ser 200
curl -sS -L "$base/" | grep -o 'slug[^"]*html' | head -1     # deve aparecer na homepage

Se der 404 mas a build foi bem-sucedida, é quase certo que é a armadilha de data futura abaixo.

---

Salvaguardas para atualizações de posts publicados

• Preserve a narrativa original e anexe uma atualização claramente identificada, a menos que o usuário solicite explicitamente uma reescrita.
• Verifique HTTP apenas de URLs recém-adicionadas ou modificadas; não verifique repetidamente links publicados inalterados, a menos que uma auditoria de links seja solicitada.
• Após o push, verifique se a URL publicada real retorna HTTP 200.

---

Dicas

• Mantenha uma seção ## TODO no arquivo de notas do índice do blog para ideias de rascunho; verifique-a antes de começar do zero
• Se o post continuar ou contradizer um post anterior, linke-o com {% post_url YYYY-MM-DD-slug %}
• Publicação antes do amanhecer + armadilha de data futura: O Jekyll interpreta um date: YYYY-MM-DD sem hora como meia-noite no fuso horário do site e descarta silenciosamente posts com data no futuro. Antes de _config.yml ter uma linha timezone: explícita, um post escrito às 04:00 hora local era lido como meia-noite UTC = ~1h no futuro → descartado até o UTC alcançar. Defina timezone: em _config.yml e NÃO o remova. Se um post antes do amanhecer ainda der 404 após uma build bem-sucedida, adicione uma hora explícita ao frontmatter (date: YYYY-MM-DD 04:00:00 +0530).