Resumos Semanais

Produza um resumo narrativo serial e com múltiplos capítulos do histórico completo do claude-mem de um projeto. Difere de timeline-report (um longo relatório) — isso gera um resumo por semana ISO, com cada subagente lendo o bloco de continuação da semana anterior para que a história permaneça coerente.

A contagem de capítulos é igual ao número de semanas ISO que o cronograma abrange. Um projeto com 2 semanas de dados produz 2 capítulos; um com 30 semanas produz 30. Não há um tamanho fixo — conte as semanas primeiro, depois direcione o pipeline com base nessa contagem.

Quando Usar

Acione quando o usuário pedir por:

• "Resumos semanais"
• "História semana a semana"
• "Cronograma serial"
• "Capítulos da história de [projeto]"
• "Executar um resumo para cada semana"
• "Continuar a história semana a semana"

Se o usuário quiser um único relatório abrangente, use timeline-report em vez disso. Esta habilidade é para o formato de capítulos seriais.

Pré-requisitos

• worker do claude-mem em execução
• Projeto com pelo menos uma semana ISO de observações (o pipeline degenera graciosamente — mesmo N=1 funciona)
• Um diretório de saída limpo onde o usuário se sinta confortável para escrever

Resolva a porta do worker (faça isso uma vez, reutilize $WORKER_PORT):

WORKER_PORT="${CLAUDE_MEM_WORKER_PORT:-$(node -e "const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}" 2>/dev/null)}"

Fluxo de Trabalho

Etapa 1: Determinar o Nome do Projeto

O mesmo padrão de detecção de worktree de timeline-report. Em um worktree, a fonte de dados é o projeto pai:

git_dir=$(git rev-parse --git-dir 2>/dev/null)
git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
if [ "$git_dir" != "$git_common_dir" ]; then
  parent_project=$(basename "$(dirname "$git_common_dir")")
else
  parent_project=$(basename "$PWD")
fi
echo "$parent_project"

Etapa 2: Buscar o Cronograma Completo e Salvá-lo

mkdir -p .scratch
curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true" \
  > .scratch/cm-timeline.md
wc -l .scratch/cm-timeline.md

Verificação de sanidade: confirme se o arquivo não está vazio e tem a estrutura esperada (preâmbulo, depois cabeçalhos de data como ### Mon DD, YYYY, depois linhas de observação numéricas <id> <time> <emoji> <title> e linhas de limite de sessão S<n> <prompt> (Mon DD at HH:MMpm)).

Etapa 3: Dividir o Cronograma em Arquivos por Semana ISO

Escreva um script Python para .scratch/split-timeline.py que:

1. Analisa cabeçalhos de data (### Mon DD, YYYY).
2. Agrupa dias em semanas ISO via date.isocalendar() (início na segunda-feira).
3. Emite um arquivo por semana para docs/timeline-weeks/<YYYY>-W<NN>-<MonDD>-to-<MonDD>.md, preservando cada seção do dia literalmente.
4. Executa uma verificação de sanidade de passagem dupla: o total de observações distribuídas deve ser igual à contagem no arquivo de origem.

Estrutura de saída (nomes de arquivo ilustrativos):

docs/timeline-weeks/
  README.md                       # weekly index table
  YYYY-W<NN>-MonDD-to-MonDD.md    # one per ISO week the timeline covers
  ...

Cada arquivo semanal deve preservar as seções diárias originais literalmente. Não parafraseie nesta fase — os agentes de resumo precisam de fidelidade bruta.

Conte os arquivos resultantes antes de iniciar o pipeline. Essa contagem é TOTAL e direciona todas as etapas subsequentes. Semanas vazias (zero observações entre semanas ativas) devem ser ignoradas — o pipeline opera apenas em semanas que têm conteúdo.

Etapa 4: Construir o README do Índice Semanal

Escreva docs/timeline-weeks/README.md com uma tabela markdown: Semana | Datas | Observações | Sessões | Arquivo. Isso se tornará o roteiro do operador e ajudará os agentes a entender o ritmo (semanas de pico vs. semanas de vale).

Etapa 5: Executar o Pipeline de Subagentes Consecutivos

Crítico: os subagentes são executados sequencialmente, NÃO em paralelo. Cada agente recebe o bloco de continuação do agente anterior. Este é o ponto principal da habilidade — sem ele, você tem N resumos isolados; com ele, você tem uma narrativa serial de N capítulos.

Crie o diretório de saída:

mkdir -p docs/timeline-weeks/digests