andrea-steva/personal-agents-skills

Resumo da tarefa

Toda tarefa concluída termina com um resumo: a última coisa na resposta, depois de todas as chamadas de ferramenta. Ele conta ao leitor em dez segundos o que agora é verdade, como sabemos e o que falta. É um resumo, não um registro da sessão.

Se o projeto atual tem sua própria skill task-recap, siga aquela em vez desta: ela carrega os nomes de verificação e as convenções do projeto.

Modelo

### <status> <Título: o que agora é verdade, ≤ 8 palavras>

<Uma ou duas frases: o resultado e por que é importante. Sem narração de processo.>

**Alterações**
- [`Arquivo.ext`](caminho/para/Arquivo.ext) — o que mudou, em poucas palavras
- [`Outro.ext`](caminho/para/Outro.ext:42) — …

**Verificações** · `build ✓` · `testes 14/14 ✓` · `lint ✓`

**Próximo** — <o único item em aberto, decisão ou acompanhamento>

Glifo de status

Exatamente um glifo, apenas no cabeçalho:

Glifo	Significado
✅	Feito e verificado
⚠️	Feito, mas algo não está verificado ou uma verificação falhou
⛔	Bloqueado: não foi possível terminar (diga por que no resumo)
🔎	Investigação ou pergunta respondida, nenhum código alterado

Seções

• Título — o resultado, não a atividade: "Resultados da pesquisa mantêm sua ordem", não "Corrigido bug no SearchService".
• Resumo — uma ou duas frases. Nomeie o efeito visível ao usuário primeiro, depois a causa ou abordagem se não for óbvia.
• Alterações — um marcador por arquivo ou grupo lógico, no máximo 6; agrupe o resto ("+ 4 traduções em Localizable.xcstrings"). Arquivos são links Markdown relativos ao diretório de trabalho, com :linha quando um ponto específico importa. Omita a seção quando nada mudou.
• Verificações — uma linha de badges em código inline, apenas para o que foi realmente executado nesta tarefa, nomeados de acordo com as próprias ferramentas do projeto:
  • build ✓ / build ✗, testes N/M ✓, ui ✓ (testes de UI ou ponta a ponta), lint ✓, types ✓ (verificador de tipos), changelog ✓, mais qualquer verificação que as instruções do projeto exijam (por exemplo, uma verificação de tradução).
  • Uma verificação que se aplica mas não foi executada é escrita como build – e nomeada em Próximo ou no resumo. Nunca marque ✓ o que não foi executado.
  • Omita a linha para tarefas apenas de documentação ou investigação.
• Próximo — uma linha: a decisão aguardando o usuário, o acompanhamento ou o estado do git (não commitado em main, PR aberto). Omita quando não houver pendência.

Regras

• Conciso: 4–12 linhas no total. Se precisar de mais, a lista de Alterações está muito detalhada; agrupe-a.
• Honesto: um teste que falhou ou passo pulado é declarado claramente com ⚠️, nunca escondido.
• Sem narração: sem "Primeiro eu vi…, depois…". Sem repetir a solicitação. Sem gentilezas de encerramento ou "me avise se…".
• Sem blocos de código a menos que o usuário precise executar um comando; então um bloco bash com um comando, colocado depois de Próximo.
• Apenas Markdown simples: um cabeçalho ###, rótulos em negrito, marcadores, código inline. Sem tabelas, emojis extras, linhas horizontais.
• Escreva no idioma que o usuário usou; mantenha nomes de arquivo, código e rótulos de badges em inglês.
• Refira-se a PRs e issues como links completos ([owner/repo#94](https://github.com/owner/repo/pull/94)), nunca um #94 solto.
• No aplicativo de desktop Claude, o resumo é a mensagem de encerramento escrita após a chamada wrap_up; ele não repete a pergunta mostrada na caixa de próximo passo.

Exemplos

Uma funcionalidade:

### ✅ Tela de perfil mostra a data de inscrição

Cada perfil agora mostra quando o usuário se inscreveu, abaixo do nome, formatado para a localidade do usuário.

**Alterações**
- [`ProfileHeader.swift`](Sources/Profile/ProfileHeader.swift) — rótulo de data de inscrição
- [`Localizable.xcstrings`](Sources/Profile/Resources/Localizable.xcstrings) — string `Joined %@`
- [`CHANGELOG.md`](CHANGELOG.md) — entrada em Non-released

**Verificações** · `build ✓` · `testes 32/32 ✓` · `lint ✓`

**Próximo** — não commitado em `feature/profile-join-date`; pronto para abrir o PR.

Um resultado parcial:

### ⚠️ Progresso de upload sobrevive ao background

O progresso agora é derivado dos bytes que o servidor confirmou, em vez de um contador local, portanto permanece correto após o aplicativo ser suspenso.

**Alterações**
- [`UploadViewModel.swift`](Sources/Upload/UploadViewModel.swift:58) — progresso lido de `acknowledgedBytes`

**Verificações** · `build ✓` · `testes 11/12 ✗` · `lint ✓`

**Próximo** — `testPauseResume` ainda espera o contador antigo; atualizá-lo ou manter o comportamento antigo de pausa?

Uma investigação:

### 🔎 Dashboard trava porque o cache salva tarde

O dashboard lê o cache antes que o salvamento em background termine, portanto mostra os dados anteriores até a próxima atualização.

**Próximo** — corrigir atualizando após o salvamento completar em `SyncService`; fazer aqui?