context-manager · diff

git:20260310.01993a7 to git:20260310.14ae6e4

68 added, 138 removed. Audit A to A.

---

name: context-manager

description: |

- Skill de gerenciamento de contexto e tarefas usando ferramentas nativas do Claude Code (TaskCreate, TaskUpdate,

- TaskList) com persistencia em arquivos markdown. Use quando precisar organizar tarefas, acompanhar progresso,

- trocar foco de trabalho, ou manter historico entre sessoes. Trigger em: "criar tarefa", "nova task", "to-do",

- "lista de tarefas", "status", "progresso", "trocar foco", "resetar contexto", "o que falta", "proxima tarefa",

- "contexto atual", "historico", "arquivar", "pipeline", "acompanhar".

+ Skill de gerenciamento de contexto e tarefas usando o mecanismo de task, memoria ou checklist disponivel no ambiente,

+ com persistencia enxuta entre sessoes quando fizer sentido. Use quando precisar organizar tarefas, acompanhar progresso,

+ trocar foco de trabalho, ou manter historico resumido. Trigger em: "criar tarefa", "lista de tarefas", "status",

+ "progresso", "trocar foco", "resetar contexto", "o que falta", "proxima tarefa", "historico", "pipeline".

---

# Context Manager - Gerenciamento de Contexto e Tarefas

- O Context Manager mantém o foco e a rastreabilidade do trabalho. Toda sessão de desenvolvimento deve ter contexto claro e tarefas rastreáveis.

- ## Responsabilidades

- 1. Criar listas de tarefas a partir de specs, issues ou pedidos do usuário

- 2. Atualizar status das tarefas em tempo real conforme progresso

- 3. Detectar mudança de foco quando o usuário muda de assunto

- 4. Resetar contexto com histórico compacto ao trocar de feature

- 5. Persistir estado entre sessões via arquivos markdown em `docs/context/`

- ## Ciclo de Vida de uma Tarefa

- Toda tarefa segue o ciclo usando as ferramentas nativas do Claude Code:

- ```

- TaskCreate (pending) → TaskUpdate (in_progress) → Execução → TaskUpdate (completed) → TaskList (verificação)

- ```

- ### Fluxo Detalhado

- 1. **Criação**: Usar `TaskCreate` com título imperativo e descrição curta

- 2. **Início**: Antes de começar a executar, `TaskUpdate` para `in_progress`

- 3. **Execução**: Realizar o trabalho (código, análise, revisão)

- 4. **Conclusão**: `TaskUpdate` para `completed` com resumo do que foi feito

- 5. **Verificação**: `TaskList` para confirmar estado geral e decidir próxima tarefa

- ### Regras de Nomeação

- - Título sempre no imperativo: "Criar endpoint de login", "Corrigir validação de email"

- - Máximo 60 caracteres no título

- - Descrição opcional com 1 frase de contexto

- ## Detecção de Mudança de Foco

- Quando o usuário pede algo não relacionado às tarefas ativas:

- 1. **Identificar**: O novo pedido não se encaixa em nenhuma tarefa ativa

- 2. **Confirmar**: Perguntar ao usuário se deseja trocar de foco

- 3. **Arquivar**: Mover tarefas do contexto atual para `docs/context/history.md` (1-2 linhas por tarefa)

- 4. **Atualizar**: Reescrever `docs/context/current-focus.md` com o novo foco

- 5. **Criar**: Novas tarefas para o novo contexto

- ### Sinais de Mudança de Foco

- - Usuário menciona feature/módulo diferente do atual

- - Pedido não tem relação com nenhuma tarefa `in_progress` ou `pending`

- - Usuário diz explicitamente: "agora vamos para...", "muda o foco", "esquece isso"

- ## Regras de Reset

- ### Reset Explícito

+ O Context Manager mantem foco, rastreabilidade e continuidade sem inflar contexto.

- Quando o usuário pedir para resetar ("reset", "limpa tudo", "começa do zero"):

+ ## Governanca Global

- 1. Arquivar todas as tarefas ativas em `docs/context/history.md`

- 2. Limpar `docs/context/current-focus.md`

- 3. Confirmar reset com o usuário

- 4. Aguardar novo foco

+ Esta skill herda comportamento base de `GLOBAL.md` e destas policies:

- ### Reset por Mudança de Foco

+ - `policies/execution.md`

+ - `policies/persistence.md`

+ - `policies/token-efficiency.md`

+ - `policies/handoffs.md`

+ - `policies/evals.md`

- 1. Perguntar confirmação antes de arquivar

- 2. Só arquivar após confirmação explícita do usuário

- 3. Manter tarefas `completed` no histórico com status final

+ Se houver conflito entre instrucoes, a hierarquia global do kit prevalece.

- ### Limite de Tarefas Ativas

+ ## Quando Usar

- - Nunca acumular mais de 15 tarefas ativas (pending + in_progress)

- - Ao atingir 15, forçar priorização: completar ou arquivar antes de criar novas

- - Alertar o usuário quando atingir 12 tarefas ativas

+ - criar ou reorganizar lista de tarefas

+ - registrar mudanca de foco, bloqueio ou decisao relevante

+ - resumir estado atual para continuidade entre sessoes

+ - manter dependencias entre frentes visiveis

- ## Arquivos de Persistência

+ ## Quando Nao Usar

- ### docs/context/current-focus.md

+ - para substituir a logica do Orquestrador

+ - para persistir conversa operacional longa sem valor futuro

+ - para registrar detalhes triviais que nao ajudam a proxima etapa

- ```markdown

- # Foco Atual

+ ## Entradas Esperadas

- - **Feature**: [nome da feature em desenvolvimento]

- - **Data início**: [YYYY-MM-DD]

- - **Status**: em andamento | pausado | aguardando revisão

- - **Pipeline**: PO → UI/UX → Backend → Frontend → QA → Security → Deploy

- - **Etapa atual**: [em qual etapa do pipeline está]

+ - pedido atual do usuario

+ - plano ou pipeline em execucao

+ - estado atual das tarefas

+ - dependencias, bloqueios e decisoes relevantes

- ## Tarefas Ativas

+ ## Saidas Esperadas

- |---|--------|--------|--------|

- ```

+ - lista de tarefas atualizada

+ - foco atual resumido

+ - historico enxuto quando houver troca de contexto

+ - handoff curto para o Orquestrador ou proxima skill

- ### docs/context/history.md

+ ## Responsabilidades

- ```markdown

- # Histórico de Contextos

+ 1. Criar listas de tarefas a partir de specs, issues ou pedidos do usuario

+ 2. Atualizar status das tarefas em tempo real conforme progresso

+ 3. Detectar mudanca de foco quando o usuario muda de assunto

+ 4. Resumir e persistir apenas o que ajuda a proxima sessao

+ 5. Tornar dependencias e blockers visiveis

- |------|---------|-----------|--------|

- ```

+ ## Ciclo de Vida de uma Tarefa

- ### Tracking Multi-Feature

+ Usar o mecanismo disponivel no ambiente:

- Quando multiplas features rodam em paralelo:

+ `Criar item (pending) -> Atualizar para in_progress -> Execucao -> Atualizar para completed -> Revisar lista geral`

- current-focus.md suporta multiplos blocos:

- ```markdown

- # Foco Atual

+ ## Regras de Operacao

- ## Feature: Login Social

- **Status:** Backend (em andamento)

- **Pipeline:** PO -> UI/UX -> Backend* -> Frontend -> QA -> Security -> Reviewer -> Deploy

+ - titulo no imperativo e curto

+ - uma tarefa `in_progress` por vez quando possivel

+ - no maximo 15 tarefas ativas antes de priorizar ou arquivar

+ - bloquear ruido e manter so o necessario para continuidade

- ## Feature: Dashboard

- **Status:** Pausado (depende de Login Social API)

- **Dependencia:** Login Social → endpoint /auth/social

+ ## Mudanca de Foco

- ## Bugfix: Calculo de Frete

- **Status:** QA (testes passando)

- **Pipeline:** Backend -> QA* -> Security -> Reviewer -> Deploy

- ```

+ Quando o pedido sair do escopo atual:

- Regras:

- - Maximo 3 features ativas simultaneamente

- - Dependencias entre features DEVEM ser registradas

- - Feature bloqueada por dependencia fica com status "Pausado"

- - Ao completar a dependencia, notificar e retomar feature bloqueada

+ - identificar se o novo pedido compete com o trabalho ativo

+ - confirmar com o usuario apenas se arquivar puder ocultar algo ainda importante

+ - persistir resumo curto do contexto anterior

+ - registrar o novo foco com tarefas iniciais

- ## Boas Práticas

+ ## Persistencia Recomendada

- 1. **Títulos imperativos**: "Criar componente X", nunca "Componente X" ou "Criando componente X"

- 2. **Máximo 10 tarefas pending**: Se passar de 10, priorizar antes de criar novas

- 3. **Arquivar a cada 5 completed**: A cada 5 tarefas concluídas, mover para histórico

- 4. **Histórico máximo 50 linhas**: Ao passar de 50, manter apenas as 30 mais recentes

- 5. **Uma tarefa in_progress por vez**: Foco em terminar antes de começar outra

- 6. **Atualizar current-focus.md a cada mudança de etapa do pipeline**

- 7. **Zero comentários no código**: Todo código gerado deve ser autoexplicativo, sem comentários

+ Preferencia de mecanismos:

- ## Integração com Orchestrator

+ 1. ferramenta nativa de task ou memoria do ambiente

+ 2. arquivo local sob `docs/context/` quando o ambiente for stateful

+ 3. resumo curto em handoff quando nao houver persistencia entre sessoes

- O Context Manager trabalha em conjunto com o Orchestrator (skill 09):

+ Se usar arquivo local, preferir `docs/context/current-focus.md` e `docs/context/history.md`.

- - O Orchestrator decide **qual skill** deve executar uma tarefa

- - O Context Manager rastreia **o progresso** dessas tarefas

- - Quando o Orchestrator delega para uma skill, o Context Manager atualiza o status

- - Quando uma skill conclui, o Context Manager registra a conclusão

- - O Context Manager informa ao Orchestrator quais tarefas estão pendentes para decidir próximos passos

+ ## Integracao com Orchestrator

- ### Fluxo Integrado

+ - o Orquestrador decide qual skill executa

+ - o Context Manager acompanha progresso, dependencias e blockers

+ - cada etapa concluida gera estado resumido e pronto para handoff

- ```

- Usuário pede feature → Context Manager cria tarefas → Orchestrator distribui para skills →

- Skills executam → Context Manager atualiza status → Orchestrator verifica próxima etapa

- ```

+ ## Evidencia de Conclusao

- ## Código Limpo

+ - lista de tasks coerente com o foco atual

+ - estado atual resumido sem ruido operacional

+ - dependencias e blockers visiveis para a proxima etapa

- Todo código produzido sob gerenciamento deste contexto segue a regra de zero comentários. O código deve ser autoexplicativo através de:

+ ## Handoff

- - Nomes de variáveis e funções descritivos

- - Funções pequenas com responsabilidade única

- - Estrutura de pastas que reflete a arquitetura

- - Types/interfaces como documentação viva

+ Seguir `policies/handoffs.md` e, quando util, `templates/handoff.md`.