ShockRock2004/kamar-taj

Wong — guia de aprendizado de fim de dia (antigo daily-log)

Transforme um dia inteiro de trabalho com Claude Code (através de todas as sessões e repositórios) em um único arquivo Markdown datado, escrito como um guia de ensino, para que o usuário possa realmente aprender com o trabalho: reimplementar o código manualmente, entender por que cada decisão foi tomada e ser capaz de explicar como funciona porque realmente entendeu.

O resultado NÃO é um changelog. É um livro-texto para iniciantes — escrito de forma tão simples e conversacional que alguém sem experiência em software poderia lê-lo do início ao fim e entender tanto o que foi feito quanto o porquê. Cada termo técnico é definido em linguagem simples na primeira vez que aparece; o código permanece técnico, mas é envolto em explicação em inglês simples. A profundidade e o "porquê" importam mais do que a completude de detalhes triviais. Veja as regras completas de Estilo de escrita — OBRIGATÓRIO na etapa 4.

Etapa 0. Leia o nível de esforço do comando

O usuário pode passar um nível de esforço como primeiro argumento: leve, médio ou pesado. Se nenhum for fornecido, o padrão é pesado. (Eles também podem passar uma data; um token YYYY-MM-DD é a data, um token leve/médio/pesado é o esforço. Qualquer ordem, ambos opcionais. ex.: /wong medium, /wong light 2026-06-25.)

O esforço controla o uso de tokens — ele dimensiona TANTO o tamanho do resumo (através de --effort no coletor) QUANTO o quanto você faz ao escrever:

• leve — o mais barato. Documenta apenas os 2–3 principais trabalhos. Não execute git show/leituras extras de arquivos; confie no resumo + mensagens de commit e inclua no máximo um pequeno trecho de código no total. Mantenha cada seção breve. Ainda produza a seção de habilidades Git, resumo do Slack, PDF e upload.
• médio — equilibrado. Documenta os ~5 principais. Execute git show (código real) apenas para os 2–3 mais importantes. Profundidade moderada.
• pesado (padrão) — o tratamento completo descrito abaixo: cada parte distinta do trabalho, extrai código real para cada uma, profundidade total.

Carregue o nível escolhido por todas as etapas.

Etapas

1. Colete o material bruto do dia

Execute o coletor com o esforço escolhido (ele lê cada transcrição de sessão do disco, então captura todas as sessões concorrentes/fechadas, não apenas esta):

python3 ~/.claude/skills/wong/collect_day.py --effort heavy

Substitua heavy pelo nível da Etapa 0. Para registrar um dia passado, adicione a data: python3 ~/.claude/skills/wong/collect_day.py --effort medium 2026-06-25

Ele imprime o caminho para um arquivo de resumo (~/Daily Log/.digest-<date>.md). Leia esse resumo completamente. Ele contém, por repositório: o mapa de commits Git do dia, estatísticas de alterações não confirmadas e, por sessão — os prompts do usuário, os arquivos que Claude editou, a prosa explicativa de Claude e quaisquer resultados de subagentes.

Leia também o glossário em ~/Daily Log/.glossary.md (se não existir, trate como vazio). Ele lista os termos triviais/fundamentais já explicados em dias anteriores. Você NÃO irá reexplicar nada que já esteja nele — veja "Explique termos triviais apenas uma vez" na etapa 4.

Se o resumo disser que nenhuma sessão estava ativa, informe o usuário e pare.

2. Identifique recursos/tarefas distintas

Agrupe o trabalho do dia em partes distintas de trabalho, não uma seção por sessão. Mescle sessões/commits que avançaram o mesmo recurso. Uma "parte de trabalho" é algo que o usuário poderia apontar como uma parte distinta do trabalho (ex.: "a correção do bug de entrega de chamada do agente verto", "o limite de taxa de abandono do discador preditivo"). Mire nas poucas coisas que realmente importaram; não encha com trivialidades.

3. Obtenha o código real para cada parte

Portão de esforço: no leve, pule esta etapa completamente (sem git show/leituras de arquivos — use o resumo + mensagens de commit, máximo de um trecho no total). No médio, faça isso apenas para as 2–3 partes mais importantes. No pesado, faça para cada parte.

O resumo lista SHAs de commit e arquivos editados, mas NÃO diffs completos. Para cada parte que você está documentando, extraia o código real para que os trechos sejam reais, não parafraseados:

git -C <repo> show <sha>            # diff completo para um commit
git -C <repo> show <sha> -- <path>  # diff de um arquivo
git -C <repo> diff -- <path>        # trabalho não confirmado

Ou leia o arquivo atual nas linhas relevantes. Prefira mostrar as linhas principais (as que carregam a ideia) em vez de despejar arquivos inteiros.

Consulte o CLAUDE.md do repositório e docs/GOTCHAS.md (se presente) para armadilhas relevantes ao trabalho — eles são ouro para a seção "Armadilhas e lições".

4. Escreva o guia de ensino — INCREMENTAL, nunca sobrescreva

Formato do nome do arquivo. O arquivo é salvo em ~/Daily Log/ e nomeado:

<YYYY-MM> - <DD> - <uma linha do que fizemos naquele dia>.md

ex.: 2026-06 - 26 - Fixed agent call delivery and started Yotel 3D landing page.md. A parte de uma linha é um título curto, em linguagem simples, do trabalho do dia (sem hífens, pois os separadores de data já usam " - "; mantenha abaixo de ~12 palavras). O cabeçalho # no topo do arquivo deve ser a mesma string que o nome do arquivo sem o .md.

Encontrando o arquivo de hoje (importante para a lógica de anexação). Como o sufixo de uma linha varia, nunca procure por um <date>.md exato. Em vez disso, encontre o arquivo de hoje pelo seu prefixo de data — liste ~/Daily Log/ e corresponda ao arquivo que começa com <YYYY-MM> - <DD> - (ex.: ls "~/Daily Log/" e escolha aquele que começa com 2026-06 - 26 - ). Há no máximo um por dia.

Esta habilidade pode ser executada várias vezes em um único dia. Em cada execução após a primeira, você deve adicionar apenas o trabalho ainda não documentado — nunca sobrescreva ou duplique o que está lá.

Procedimento:

1. Se nenhum arquivo para hoje existir (nenhum arquivo corresponde ao prefixo de data): crie-o com a estrutura completa abaixo (Visão geral do dia + uma seção por parte do trabalho, numeradas ## 1., ## 2., …), nomeado no formato acima.
2. Se o arquivo de hoje JÁ EXISTIR (encontrado pelo prefixo de data): Leia-o primeiro. Construa um conjunto do que já está coberto, varrendo seus cabeçalhos ## N. <título> existentes e os SHAs de commit / ids de sessão em cada linha de Referências. Em seguida, a partir do resumo de hoje, identifique partes do trabalho cujos commits/sessões ainda não estão nesse conjunto.
   • Mantenha o título de uma linha preciso para o dia inteiro: se o trabalho recém-adicionado mudar qual deve ser o título do dia, renomeie o arquivo (e atualize seu cabeçalho # para corresponder) para que o título ainda reflita tudo o que foi feito naquele dia. Se o título ainda se encaixar, deixe o nome como está.
   • Se não houver nada novo, informe ao usuário que o arquivo já está atualizado e pare (não o reescreva).
   • Caso contrário, anexe novas seções ## N. (continue a numeração existente) apenas para o novo trabalho, usando o mesmo modelo por recurso.
   • Atualize o bloco Visão geral do dia no local: aumente as contagens de Commits/Sessões e estenda o Título para mencionar o trabalho recém-adicionado. Não toque nas seções de recurso existentes.
   • Use Edição (inserções direcionadas), não uma sobrescrita completa, para que seções anteriores — incluindo quaisquer que você tenha editado manualmente — sejam preservadas literalmente.

Trate uma "parte de trabalho" como já coberta se seu SHA(s) de commit ou o id da sessão já aparecerem no arquivo. Corresponda a esses identificadores, não à redação, para que a reexecução nunca produza uma seção quase duplicada.

Estilo de escrita — OBRIGATÓRIO (este é o ponto principal)

Escreva como um capítulo de livro-texto para um iniciante completo — alguém inteligente que não sabe nada sobre software. O leitor deve ser capaz de seguir cada seção do início ao fim sem contexto prévio.

• Conversacional e simples. Frases curtas. Palavras simples. Explique como se estivesse falando com um amigo, não escrevendo um relatório. Evite jargões na narrativa.
• Defina cada termo técnico uma vez em toda a série — não uma vez por dia. Na primeira vez que um termo aparecer sempre, defina-o em linguagem cotidiana em um bloco de citação: > **O que "X" significa.** … (use analogias do mundo real). Mas primeiro verifique o glossário (~/Daily Log/.glossary.md) e nunca redefina um termo já listado lá. Isso é mais importante para fundamentos triviais e recorrentes — o que é um repo/commit/branch, o que é Yotel, git básico — explique-os uma vez, depois apenas use-os. Um termo totalmente novo que é genuinamente central para o trabalho de hoje ainda recebe seu bloco; um termo básico que já foi coberto antes não. Veja "Explique termos triviais apenas uma vez" abaixo para os detalhes.
• Mantenha-se técnico apenas onde a precisão técnica é o ponto — ex.: a mudança de código real, o arquivo exato, a troca real. Mostre o código real, mas envolva-o em explicação em inglês simples antes e depois, e comente o trecho em linguagem simples. Nunca apenas despeje código.
• Inicie cada seção com a "versão cotidiana" — a história em linguagem simples do que estava quebrado/necessário e por que isso importa — antes de qualquer detalhe técnico.
• Use uma nota curta "Como ler este documento" no topo, e uma visão geral "O panorama geral (leia isto primeiro)" que explica os projetos em termos simples (o que é este produto, quem o usa, por quê).
• Mantenha os pontos de "como explicar" em forma de frase única, simples e confiante, seguida pelo único insight inteligente para explicar de forma simples.
• Seja honesto: separe claramente o código real enviado da configuração/exploração, e diga isso em palavras simples.

Corresponda ao tom do arquivo existente mais recente em ~/Daily Log/ (leia-o como o exemplo de referência se existir um).

Explique termos triviais apenas uma vez (o glossário)

Um leitor de toda a série não deve ver "o que é um repo" ou "o que é Yotel" reexplicados todos os dias. Então:

1. Antes de escrever, leia ~/Daily Log/.glossary.md (a lista de termos já explicados). Trate tudo nele como conhecido — não escreva um bloco > **O que "X" significa.** para qualquer termo na lista. Apenas use o termo normalmente.
2. Enquanto escreve, adicione um bloco de definição apenas para um termo que seja genuinamente novo na série (não no glossário). Tenda fortemente a não redefinir fundamentos triviais; se estiver em dúvida sobre um termo básico, assuma que já foi coberto e pule.
3. Depois de escrever/anexar, atualize ~/Daily Log/.glossary.md: anexe (um por linha) qualquer termo que você definiu pela primeira vez hoje. Nunca remova entradas existentes. Se o arquivo não existir, crie-o.

Isso se aplica a termos triviais e recorrentes acima de tudo (repo, commit, branch, worktree, o que é o produto, git básico). Um termo complexo que é o cerne do trabalho de um dia ainda pode ser explicado naquele dia, mas uma vez que está no glossário, não é reexplicado mais tarde.

Estrutura por recurso e visão geral do dia (adapte os cabeçalhos à voz amigável para iniciantes acima — estes são os conteúdos a cobrir, não rótulos rígidos para copiar literalmente):

# <YYYY-MM> - <DD> - <uma linha do que fizemos naquele dia>

> **Como ler este documento.** (1-2 frases dizendo a um iniciante como usá-lo.)

## O panorama geral (leia isto primeiro)
Visão geral em linguagem simples do que foi feito hoje. Defina "projeto/repositório", "commit" e o que é o produto (ex.: Yotel) aqui **apenas se eles ainda não estiverem no glossário** — ou seja, no primeiro registro. Em todos os dias posteriores, pule esses conceitos básicos e o explicador "o que é este produto"; apenas nomeie-os e siga em frente.

---

## 1. <Título em linguagem simples da parte do trabalho>   (<repo>)

### A versão cotidiana
A história sem jargões — o que estava quebrado ou necessário, e por que isso importa para uma pessoa real. Use uma analogia.

### O que realmente estava acontecendo / a correção (a parte técnica)
Agora o detalhe preciso: a causa real, a mudança de código real (mostrada e explicada em inglês simples com trechos comentados), o caminho do arquivo exato `path`. Coloque um bloco `> **O que "termo" significa.**` antes de cada nova palavra técnica.

### Como você poderia fazer isso sozinho, passo a passo
Passos concretos e numerados que um iniciante poderia seguir.

### Como explicar (depois que você entender)
- Um resumo em frase simples do que o trabalho faz.
- O único insight inteligente, explicado de forma simples.
- A troca a ser defendida, em termos cotidianos.

### Lições que valem a pena lembrar
Conclusões em linguagem simples + qualquer armadilha relevante de CLAUDE.md / docs/GOTCHAS.md.

**Onde encontrar:** arquivos, SHA(s) de commit, id(s) de sessão.

---

## 2. <próxima parte…>

---

## Habilidades Git usadas hoje
(Sempre a ÚLTIMA seção do documento. Construída a partir dos blocos "Comandos Git que Claude executou" do resumo — veja as instruções dedicadas abaixo.)

### <operação git, ex.: Confirmando alterações>   `git commit`
**O que fez** — em palavras simples, o que este comando realizou no trabalho de hoje.
**Por que** — por que este passo era necessário naquele ponto do fluxo de trabalho.
**Como fazer você mesmo** — o comando real com uma breve nota sobre o que cada parte e sinalizador significa, para que o leitor possa executá-lo manualmente.

### <próxima operação git…>

A seção "Habilidades Git usadas hoje" — OBRIGATÓRIO (sempre a última seção)

Termine o documento de todos os dias com uma seção ## Habilidades Git usadas hoje, construída a partir dos blocos "Comandos Git que Claude executou" no resumo (um bloco por sessão).

Como construí-la:

1. Reúna todos os comandos git de cada sessão no resumo. Uma entrada capturada pode ser um comando composto (ex.: cd repo && git add ... && git commit ...); extraia a(s) parte(s) git.
2. Agrupe-os por operação git (ex.: confirmar, criar um branch, criar um worktree, enviar, staging, stash, restaurar, rebase, inspecionar com log/diff/show/status). Uma subseção por operação distinta — não liste a mesma operação muitas vezes. Se muitos comandos são apenas inspeção somente leitura (git status, git log, git diff, git show), cubra-os juntos em uma subseção curta "Explorando o repositório" em vez de um para cada.
3. Para cada operação, escreva três coisas na voz amigável para iniciantes usada em todo o resto do documento:
   • O que fez — o que isso realizou no trabalho real de hoje.
   • Por que — por que aquele passo foi necessário naquele ponto.
   • Como fazer você mesmo — o comando real, com uma nota simples sobre o que cada parte e sinalizador importante significa, para que o leitor possa executá-lo manualmente. Coloque um bloco > **O que "X" significa.** antes do primeiro uso de qualquer termo técnico.