Aaalexy/craft-codex-prompts

Criar Briefs do Codex

Objetivo

Transformar contexto incompleto em um pacote de tarefas que outra conversa do Codex possa executar sem tratar interpretações derivadas como fato. Otimizar para fidelidade à fonte, autoridade limitada, conclusão testável e baixa sobrecarga de prompt.

Selecionar a operação

• Rascunho: Construir um prompt a partir de arquivos, contexto do projeto ou uma solicitação vaga.
• Revisão: Diagnosticar fraquezas em um prompt existente e, em seguida, produzir uma versão revisada.
• Transferência: Converter trabalho anterior, resultados e questões em aberto no próximo prompt executável.
• Loop de conhecimento: Produzir atualizações de estado atual, decisões, questões em aberto e transferência prontas para a base de conhecimento.

Se o usuário pedir apenas um prompt, retorne apenas o prompt mais as suposições essenciais. Se pedir um fluxo de trabalho reutilizável, retorne o pacote de tarefas completo.

Fluxo de trabalho

1. Estabelecer fontes e autoridade

Inspecione os arquivos fornecidos pelo usuário e o material do projeto acessível apenas para leitura antes de redigir, quando for autorizado e útil. Não modifique o projeto de origem enquanto apenas prepara um prompt.

Classifique as entradas:

• Fatos primários: arquivos atuais, estado do repositório, declarações explícitas do usuário, documentos de projeto oficiais.
• Contexto derivado: resumos, conclusões anteriores do assistente, relatórios e chats copiados.
• Incógnitas: arquivos faltantes, estado de runtime não verificado, escolhas não resolvidas e dependências externas.

Trate o contexto derivado como uma pista, não como prova. Declare explicitamente que a conversa em execução deve verificá-lo em relação às fontes primárias.

Não presuma que arquivos anexados a uma conversa estão disponíveis em outra. Nomeie cada arquivo ou workspace exato que a conversa em execução deve receber.

2. Identificar o tipo de tarefa

Escolha o tipo de tarefa mais próximo:

• responder ou explicar;
• inspecionar ou revisar;
• diagnosticar;
• alterar ou construir;
• pesquisar ou comparar;
• criar um artefato;
• realizar uma ação externa.

Preserve o limite de autoridade correspondente. Uma solicitação para analisar ou diagnosticar não autoriza edições. Uma solicitação para alterar ou construir normalmente autoriza implementação e verificação no escopo, mas não refatorações não relacionadas, publicação, envio de mensagens, commits, pushes ou ações destrutivas.

Leia task-blueprints.md para o padrão de tarefa correspondente.

3. Separar regras estáveis do delta da tarefa

Coloque regras de projeto duráveis em um contrato de projeto, como AGENTS.md, PROJECT_BRIEF.md ou CODEX_TASK_CONTRACT.md. Mantenha o prompt atual focado no que mudou desta vez.

Repita uma regra estável no prompt da tarefa apenas quando for crítica para a segurança ou provável de ser esquecida.

4. Resolver ambiguidade proporcionalmente

Faça uma pergunta esclarecedora apenas quando a resposta alterar materialmente o escopo, a seleção de fontes, o comportamento irreversível, os efeitos externos ou o padrão de aceitação. Caso contrário, escolha a suposição razoável mais segura e rotule-a.

Nunca esconda uma fonte ausente, capacidade não suportada ou bloqueador externo dentro de uma redação confiante.

5. Compor o pacote de tarefas

Crie estas seções quando relevante:

1. Resultado: um estado final concreto.
2. Fonte da verdade: arquivos, caminhos, dados ou decisões do usuário exatos.
3. Estado atual: apenas fatos verificados ou claramente atribuídos.
4. Escopo: leituras, edições, sistemas e artefatos permitidos.
5. Não-objetivos: expansões prováveis, mas não autorizadas.
6. Verificações adjacentes: superfícies downstream que podem expor o mesmo defeito.
7. Diretrizes de execução: restrições que afetam a correção, não detalhes especulativos de implementação.
8. Aceitação: verificações observáveis e evidências esperadas.
9. Bloqueadores e condições de parada: condições que exigem relato em vez de suposição.
10. Entrega: arquivos alterados, artefatos, evidências, limitações e próxima transferência.

Use a escada de verificação L1-L4 quando a implementação estiver envolvida:

• L1: validação de sintaxe, importação, esquema ou estática;
• L2: testes unitários, de serviço ou de regressão focados;
• L3: validação de caminho de dados com arquivos reais ou ponta a ponta;
• L4: IU real, runtime empacotado, dispositivo, produção simulada ou aceitação humana.

Não apresente um nível inferior como prova de um nível superior.

Inclua esta cláusula de fidelidade à fonte, adaptada à tarefa:

Trate este prompt como um breve de execução, não como prova do estado do repositório. Verifique suas afirmações em relação ao workspace atual e aos arquivos primários. Se houver conflito, preserve o material de origem, relate o conflito e siga a fonte primária, a menos que o usuário decida o contrário.

6. Manter o prompt executável

• Comece com o resultado.
• Use instruções diretas e substantivos concretos.
• Prefira nomes de arquivos, caminhos, contagens e artefatos esperados a adjetivos.
• Evite copiar chat bruto, a menos que a redação exata seja em si uma evidência.
• Evite prescrever arquitetura antes da inspeção, a menos que o usuário tenha fixado essa escolha.
• Mantenha as proibições limitadas a modos de falha realistas.
• Indique se o Codex deve apenas relatar, diagnosticar, implementar ou implementar e verificar.
• Termine com um formato de conclusão compacto.

7. Auditar antes da entrega

Pontue o prompt internamente em seis verificações:

• Fidelidade: Cada afirmação factual pode ser rastreada até uma fonte?
• Autoridade: As leituras, edições, ações externas e ações proibidas são inequívocas?
• Completude: Os consumidores adjacentes prováveis e caminhos de falha estão cobertos?
• Testabilidade: A conclusão pode ser demonstrada com evidências observáveis?
• Viabilidade: Ferramentas indisponíveis, limites de runtime e dependências humanas estão expostos?
• Brevidade: Cada instrução altera a execução ou verificação?

Retorne um status:

• PRONTO: executável com o contexto disponível;
• PRONTO_COM_SUPOSICOES: executável após listar suposições limitadas;
• PRECISA_DE_ENTRADA: uma ou mais escolhas materiais estão faltando;
• BLOQUEADO_FONTE_AUSENTE: material primário necessário não está disponível.

Não infle o prompt apenas para melhorar seu rigor aparente.

8. Fechar o loop de conhecimento

Quando o usuário arquivar trabalho no Obsidian ou outra base de conhecimento, leia obsidian-loop.md. Mantenha chats brutos imutáveis separados da verdade atual do projeto. Após a execução, atualize o estado atual, decisões, questões em aberto e a transferência em vez de confiar apenas na transcrição.

Saída padrão

A menos que o usuário solicite outro formato, retorne:

## BRIEF_DA_TAREFA
[fatos verificados, suposições, incógnitas, fontes]

## PROMPT_PRINCIPAL
[prompt pronto para copiar]

## STATUS_DO_PROMPT
[PRONTO, PRONTO_COM_SUPOSICOES, PRECISA_DE_ENTRADA, ou BLOQUEADO_FONTE_AUSENTE]
[explicação curta e quaisquer anexos necessários]

Para revisão de prompt, adicione uma seção LACUNAS_PRINCIPAIS curta antes de PROMPT_PRINCIPAL. Não exponha cadeia de pensamento privada; forneça razões concisas e relevantes para a decisão.