CAFEERON21br18/Daily_Master_Prompt

Criar um Prompt Mestre Diário

Visão Geral

Um prompt mestre diário é um arquivo auto-contido, DAILY_PROMPT.md, que qualquer sessão nova pode executar para retomar um projeto, realizar um dia de trabalho e deixá-lo pronto para o dia seguinte. A memória do projeto reside em cinco arquivos de estado ao lado dele, nunca na conversa. Após a primeira execução, o usuário apenas digita:

Read <pasta>/DAILY_PROMPT.md and execute it.

Entrada do usuário: $ARGUMENTS (uma pasta e/ou uma explicação do projeto; qualquer um pode estar faltando).

O que existe quando você termina

Tudo na pasta do projeto (<pasta>), construído a partir dos templates em ${CLAUDE_SKILL_DIR}/templates/:

Arquivo	Contém	Mudanças
DAILY_PROMPT.md	Missão, marco, regras, mapa de contexto, procedimento da sessão	Apenas quando o usuário pedir
BACKLOG.md	Itens de trabalho ordenados com IDs e status	Toda execução
DEVLOG.md	Log datado e anexado de cada execução	Toda execução
HANDOFF.md	Estado atual, próximas 3 ações, avisos	Reescrito toda execução
QUESTIONS.md	Perguntas para o usuário, com uma recomendação cada	Execuções perguntam, usuário responde
APPROVALS.md	Ações arriscadas ou irreversíveis aguardando sim/não	Execuções solicitam, usuário decide

O progresso vai para os arquivos de estado. DAILY_PROMPT.md contém apenas o que permanece verdadeiro por semanas.

Passos

1. Encontre a pasta. Use a pasta nos argumentos. Caso contrário, use a pasta que contém a especificação ou o código do projeto; se várias se encaixarem, pergunte.
2. Reúna contexto lendo, não perguntando. A explicação do usuário; README*, CLAUDE.md, AGENTS.md; especificações (GDD, PRD, roadmap, docs/); git log --oneline -30 e git status; uma árvore de arquivos de 2 a 3 níveis; manifestos e scripts que revelam comandos de build, teste, lint e execução; servidores MCP conectados que o trabalho precisa; notas TODO/FIXME; quaisquer arquivos de estado existentes. Separe o que está feito do que não está.
3. Pergunte apenas pelo que os arquivos não dizem, em uma única chamada AskUserQuestion (máximo 4 perguntas), a partir desta lista: marco atual e sua definição de pronto; como um item finalizado é verificado; regras rígidas (nunca publicar/implantar, perguntar antes de novas dependências, política de branch e push); se as execuções são supervisionadas, não supervisionadas ou ambas. Se ninguém responder, adote a leitura mais segura (não supervisionada, sem push, sem publicar) e registre cada suposição em QUESTIONS.md com sua linha "Assumido até ser respondido".
4. Escreva DAILY_PROMPT.md a partir de DAILY_PROMPT.template.md. Cada seção nomeia os caminhos reais, comandos, ferramentas e marco deste projeto. Na linha diária, escreva a pasta relativa à raiz do repositório (onde o usuário abre o Claude), não um caminho absoluto; quando a pasta for a própria raiz, a linha é Read DAILY_PROMPT.md and execute it. Se executar ou testar o projeto puder tocar dados reais (arquivos do usuário, contas ativas, produção, um local publicado), adicione uma regra fundamental e um método de verificação que usem uma cópia temporária ou de teste.
5. Crie os arquivos de estado a partir de seus templates. Se um já existir, mescle a ele; nunca sobrescreva ou reordene o histórico do usuário. Popule BACKLOG.md a partir do marco, lacunas na especificação, TODOs e objetivos do usuário, ordenado de modo que o item 1 possa começar hoje e cada item caiba em uma sessão, cada um com um "Pronto quando" concreto. Popule HANDOFF.md com o estado inicial. Um template cujo exemplo de entrada ainda não se aplica mantém seu cabeçalho e linhas de formato, com Nenhum ainda. no lugar da entrada. Verifique: grep -n "{{" <pasta>/*.md não retorna nada.
6. Faça commit dos novos arquivos se a pasta estiver em um repositório git (chore: adicionar prompt mestre diário), seguindo as regras de commit do repositório.
7. Primeira execução. A menos que o usuário tenha dito para não, execute DAILY_PROMPT.md agora, exatamente como uma sessão nova faria. Este é o teste do prompt: quando um passo foi ambíguo, falhou ou precisou de conhecimento que não está nos arquivos, corrija o prompt e anote a correção em DEVLOG.md.
8. Passe o bastão. Informe ao usuário o que foi criado, o que a primeira execução fez e forneça a linha diária em um bloco de código:

   Read <pasta>/DAILY_PROMPT.md and execute it.
   

   Mencione /daily-master-prompt:run <pasta> como a mesma coisa, e que a linha também funciona como o prompt de uma tarefa agendada.

Atualizando um prompt existente

Quando DAILY_PROMPT.md já existir, leia-o e todos os arquivos de estado primeiro. Aplique a alteração no lugar, ou sob ## Adendos como uma entrada datada quando o usuário pedir um adendo. Mantenha todo o estado. Registre a alteração em DEVLOG.md.

Erros comuns

Erro	Resultado	Faça em vez disso
Prompt genérico ("trabalhe no projeto")	Cada execução redescobre o projeto	Caminhos reais, comandos, marco, definição de pronto
Progresso escrito em DAILY_PROMPT.md	Prompt fica obsoleto e contradiz arquivos de estado	Progresso vive em BACKLOG/HANDOFF/DEVLOG
Nenhuma etapa de verificação	Itens "prontos" que não funcionam	Uma verificação concreta por item (testes, build, playtest, lint)
Execuções param no primeiro bloqueio	Dias não supervisionados não produzem nada	Registre em QUESTIONS/APPROVALS, continue com o próximo item
Itens do backlog muito grandes	Trabalho meio feito todos os dias	Divida até que um item caiba em uma sessão
Sobrescrever arquivos de estado existentes	Usuário perde histórico	Mescle