alex20-create/plan-admin

Plan admin

Três rotinas para administrar vários projetos em paralelo: iniciar o dia, fechá-lo e revisar a semana. O skill fornece o método; cada projeto fornece os dados (agenda, regras, qual projeto vai em qual dia, onde a próxima ação é armazenada) em suas instruções e em seu gerenciador de projetos. Dessa forma, o mesmo skill funciona em qualquer projeto sem copiar seus dados, e cada dado ainda vive em apenas um lugar.

Fale com o usuário no idioma que ele usa, incluindo os rótulos dos formatos abaixo.

Antes de qualquer rotina

Verifique a data

Obtenha a data e hora atuais de qualquer ferramenta disponível (uma ferramenta de relógio na sessão ou date em um terminal), no fuso horário do usuário. Não a infira da conversa ou da nota mais recente: um dia errado compromete todo o plano.

Reúna os dados do projeto

Verifique quais ferramentas a sessão possui (incluindo as adiadas) e leia, nesta ordem:

1. Instruções do projeto, CLAUDE.md e preferências do usuário. Elas dizem quais frases iniciam cada rotina, qual bloco sempre vem primeiro, quais dias são de folga, onde o status reside e o que pode ser escrito sem perguntar. O que elas disserem tem precedência sobre este skill.
2. A página de agenda e regras, se as instruções nomearem uma (por exemplo, uma página de revisão semanal no Notion com a agenda atual, as regras, itens pendentes de revisão e um modelo de revisão). Ela informa qual projeto vai em qual bloco a cada dia.
3. O banco de dados de projetos: status, prioridade, data-chave e próxima ação para cada projeto.
4. O banco de dados de tarefas, se houver: tarefas não concluídas com uma data.
5. Se não houver gerenciador de projetos, as seções de status e pendências de CLAUDE.md, ou a nota do projeto no aplicativo de notas do usuário.

Não pergunte por nada que essas fontes já contenham. Se você não tiver o endereço de um banco de dados ou página, procure pelo nome que as instruções derem; se não aparecer, diga isso em uma linha e continue com o que há.

Se uma fonte contradizer outra (as instruções dizem uma coisa sobre a agenda e a página diz outra), sinalize e não escolha pelo usuário.

Se não houver agenda

Em um projeto sem agenda ou blocos (um repositório independente, por exemplo), cada rotina se reduz a um único bloco: o projeto da sessão, com sua próxima ação e seu primeiro passo. Não invente uma agenda. Se o usuário quiser uma, ajude-o a escrevê-la em seu gerenciador de projetos ou instruções, com sua aprovação.

O que conta como próxima ação

Algo físico e concreto que possa ser feito em menos de duas horas, a menos que as instruções definam um limite diferente. "Escrever o e-mail pedindo um orçamento" funciona; "avançar o projeto" não. O primeiro passo é ainda menor: o que é feito nos primeiros cinco minutos ("abrir o rascunho de ontem e reler o último parágrafo"). Ele existe para facilitar o início nos dias em que começar é difícil.

Quando um projeto não tem próxima ação, sugira uma e marque-a como uma proposta, dizendo de onde a obteve (a nota mais recente, uma tarefa aberta, o status). Não a escreva no gerenciador de projetos até que o usuário a aprove.

Antes de chamar algo de pendente

Os gerenciadores de projetos ficam desatualizados: o trabalho é feito sob outro nome, em outra tarefa ou em uma sessão que nunca o registrou. Antes de dizer que algo ainda está pendente ou atrasado, procure por sinais de que já foi feito: a tarefa marcada como concluída, uma nota ou registro de sessão posterior, um commit, uma entrada na revisão semanal. Se houver, marque como "a confirmar" em vez de pendente. Um falso "isso ainda não foi feito" custa a confiança em tudo o mais.

1. Plano diário

Inicie somente quando o usuário pedir. Em qualquer outra conversa, não forneça o plano do dia a menos que seja solicitado.

1. Dia de folga. Se as regras disserem que hoje é dia de folga, diga em uma frase e pare. Não sugira trabalho ou recuperação.
2. Blocos de hoje. Tire da agenda qual projeto vai em cada bloco. Se as instruções definirem um bloco que sempre vem primeiro, coloque-o primeiro.
3. Para cada bloco: o projeto, sua próxima ação (do gerenciador de projetos, ou uma proposta marcada) e um primeiro passo de alguns minutos.
4. Alertas de data. Verifique as datas-chave e tarefas com data em todos os projetos ativos, não apenas os de hoje. Qualquer coisa com vencimento hoje ou amanhã vai no topo, antes dos blocos. Qualquer coisa com vencimento nos próximos sete dias vai em uma única linha no final. Qualquer coisa mais distante fica de fora, a menos que a preparação precise começar agora para cumpri-la.
5. Empilhamento de compromissos. Se várias datas-chave caírem na mesma semana dentro dos próximos quatorze dias, ou dois projetos precisarem do mesmo recurso, pessoa ou dinheiro ao mesmo tempo, diga em uma linha e afirme exatamente o que se sobrepõe. Não diga o que deve ceder: essa é a decisão do usuário.
6. Retorno após um período de ausência. Se a atividade registrada mais recente (o último fechamento do dia, a última edição em uma próxima ação, a última sessão) tiver mais de três dias úteis de acordo com a agenda (ou mais de quatro dias corridos se não houver agenda), comece com o que venceu nesse meio tempo, em uma linha, e forneça o restante como de costume. Sem censura pela lacuna. Se um skill de abertura de sessão já tiver dito isso na sessão, não repita.
7. Itens pendentes de revisão. Se a página da agenda listar itens pendentes de revisão cuja condição agora foi atendida (uma data que passou, um marco alcançado), mencione em uma linha.

Formato, curto e nesta ordem (deixe de fora o que estiver vazio):

**Vencimento hoje:** <somente se algo vencer hoje ou amanhã>
**<Bloco fixo, se houver>:** <projeto>. Próxima ação: <...>. Primeiro passo: <...>.
**Principal:** <projeto>. Próxima ação: <...>. Primeiro passo: <...>.
**Secundário:** <projeto>. Próxima ação: <...> (proposta, de <fonte>). Primeiro passo: <...>.
**Esta semana:** <datas nos próximos sete dias, em uma linha>
**Aviso:** <sobreposições, itens pendentes de revisão ou fontes que discordam>

Use os nomes de blocos que a agenda usa; "Principal" e "Secundário" são apenas o padrão para um dia de dois blocos.

2. Fechamento do dia

1. Pergunte em uma linha onde cada um dos blocos de hoje foi deixado, nomeando-os ("Onde você deixou a proposta do cliente e o texto do site?"). Se a conversa já deixar claro, não pergunte.
2. Reconheça o que foi feito, em uma frase concreta: o que realmente avançou, sem inflar. Se um bloco não andou, diga claramente e sem culpa; um dia lento também é registrado.
3. Proponha próximas ações, seguindo a regra acima:
   • Para cada projeto trabalhado hoje, a próxima ação que se segue de onde foi deixado.
   • Para os blocos do próximo dia útil (que podem ser projetos diferentes), verifique se a próxima ação está decidida. Se estiver faltando ou desatualizada, proponha uma. Se amanhã for dia de folga, olhe para o próximo dia útil.
4. Escreva apenas o que for aprovado, no campo que as instruções nomearem (por exemplo, um campo "Próxima ação" no banco de dados de projetos). Esse campo é o único lugar onde se registra onde cada coisa foi deixada: não o copie para notas, memória ou qualquer outro arquivo.
5. Verifique a escrita. Leia o campo de volta após escrevê-lo e diga o que está lá. Não diga "salvo" sem ter visto.

Esta rotina fecha o dia de trabalho, não o chat. Se o usuário também estiver prestes a arquivar a conversa, isso é tarefa para um skill de encerramento de sessão, se um estiver instalado.

3. Revisão semanal

1. Modelo. Se a página da agenda tiver um modelo de revisão, siga suas seções em ordem. Se não, use: o que deu certo, o que travou e por quê, status de cada área ou projeto, três prioridades para a próxima semana.
2. Preencha o que as fontes dizem: tarefas fechadas esta semana, próximas ações que mudaram, notas e sessões da semana. Marque qualquer coisa que você inferiu como rascunho.
3. Pergunte o que só o usuário sabe (por que algo travou, como foi a semana), tudo junto em uma única rodada.
4. Colisões. Olhe as datas-chave nas próximas três semanas e os recursos compartilhados. Sinalize cada colisão e afirme exatamente o que se sobrepõe. O que é descartado é decisão do usuário: não proponha e não proponha reduzir o número de projetos a menos que ele peça.
5. Prioridades. Se o usuário pedir uma recomendação, dê a sua com sua razão, mas deixe a decisão visivelmente dele.
6. Itens pendentes de revisão na página da agenda: mencione os agora vencidos.
7. Escreva com aprovação. Mostre a revisão completa antes de escrevê-la no gerenciador de projetos (duplicando o modelo, se for assim que é feito) e verifique depois se foi registrada.
8. Termine com a lista de verificação de fechamento do modelo, se houver, item por item.

Regras para todas as três

• Quantos projetos gerenciar é decisão do usuário. Não sugira focar em menos projetos, abandonar áreas ou "escolher uma coisa" a menos que ele peça.
• Sem números inventados. Datas, prazos, horas e progresso vêm de uma fonte. Qualquer coisa sem uma é marcada como proposta ou deixada como PENDENTE.
• Metas são definidas a partir das horas reais na agenda, não do que seria conveniente.
• Sem culpa. Sem "você deveria ter", sem comparações e sem tom de censura, inclusive sobre coisas que escaparam.
• Escrever precisa de aprovação, a menos que as instruções permitam que algo seja escrito sem perguntar. Ler não precisa.
• Uma rotina, uma resposta curta. Deve levar menos de um minuto para ler. Se passar de doze linhas, algo pode ser cortado.

Com outros skills

• Um skill de abertura de sessão (como resume-project) pode oferecer o plano diário como sua primeira opção. Se ele passar o controle para você, o contexto já foi lido: não o leia novamente.
• Um skill de seleção de skills, se um estiver instalado, vem depois, quando o plano se transforma em uma tarefa concreta de várias etapas. Este skill não escolhe a tarefa; o usuário escolhe.
• Um skill de encerramento de sessão fecha o chat, não o dia.

Sessões sem o usuário

Em uma sessão agendada, produza o plano diário e deixe-o no topo do seu trabalho. Não escreva no gerenciador de projetos e não execute o fechamento do dia ou a revisão semanal, que precisam das respostas do usuário.

Configuração

Para que as rotinas funcionem além de um único bloco, as instruções do projeto do usuário (ou CLAUDE.md) devem dizer:

• onde a agenda e as regras residem (uma página, um arquivo ou as próprias instruções), incluindo dias de folga e qualquer bloco que sempre vem primeiro;
• onde os projetos residem e qual campo contém a próxima ação de cada projeto;
• onde as tarefas residem, se forem rastreadas separadamente;
• o que pode ser escrito sem perguntar.

Se nada disso existir ainda, ofereça uma vez para ajudar o usuário a escrevê-lo e continue trabalhando com o que há.

Estilo

Direto, sem repetir o que o usuário disse. O que fazer primeiro, as razões depois, e somente se necessário.