Codex Goal Writer

O que Codex Goal Writer faz?

Crie um comando /goal do Codex, pronto para copiar, que uma thread futura do Codex possa executar sem depender de memória de conversa frágil. Não inicie a meta nem implemente o trabalho a menos que o usuário peça explicitamente.

Contrato de Saída

Saída padrão:

1. Suposições com no máximo 5 tópicos, apenas se as suposições forem relevantes.
2. Pronto para copiar com um bloco de código cercado por fences contendo exatamente um comando /goal ....
3. Notas com no máximo 3 tópicos explicando as principais escolhas de design ou riscos remanescentes.

Se o usuário pedir apenas o comando, produza apenas o bloco de código cercado por fences.

O prefixo do comando deve ser /goal. O corpo pode usar o idioma do usuário.

Restrições Oficiais

• Trate o texto de /goal como prompt inicial e critério de conclusão.
• Mantenha o objetivo não vazio e com menos de 4.000 caracteres.
• Para instruções longas, escreva ou referencie um arquivo markdown e mantenha o /goal curto.
• Se /goal não estiver disponível, mencione ativar [features].goals = true ou codex features enable goals.
• Não invente flags de barra não suportadas, como /goal --tokens. Se um orçamento for útil, expresse-o como uma condição textual de parada ou pausa.

Fluxo de Decisão

1. Plano Existente ou Plano Markdown

Use este caminho quando um plano, PRD, issue, alteração OpenSpec/OSpec, PLAN.md, GOAL.md, tasks.md ou documento de implementação for mencionado ou evidente.

Regras:

• Inclua o caminho exato no comando, de preferência relativo ao repositório.
• Diga ao Codex para ler o plano primeiro e tratá-lo como fonte da verdade.
• Adicione uma cláusula anti-esquecimento: releia o caminho antes de continuar após compactação de contexto, retomada ou incerteza.
• Inclua a parte solicitada se o usuário quiser apenas uma parte do plano.
• Mantenha listas de tarefas detalhadas no arquivo, não no texto do /goal.

Forma:

/goal Execute o plano de implementação em <caminho> como fonte da verdade. Leia-o antes de alterar arquivos e releia-o após qualquer compactação de contexto, retomada ou incerteza. Complete <plano completo ou parte>, preserve <restrições>, verifique com <verificações/evidências> e pare com um relatório de bloqueio se <condições de bloqueio>.

2. Contexto de Conversa Útil

Use este caminho quando turnos anteriores definirem a tarefa.

Regras:

• A instrução mais recente do usuário prevalece sobre contexto mais antigo.
• Preserve restrições explícitas: somente leitura, sem edições, sem commits, arquivos específicos, sem novas dependências, testes exigidos, apenas revisão, idioma ou formato de saída.
• Inclua caminhos de arquivo exatos, comandos, IDs de issues, links de PRs e caminhos de artefatos quando conhecidos.
• Ignore intenções anteriores obsoletas que conflitam com a solicitação mais recente.

Forma:

/goal <resultado pretendido mais recente>, usando a conversa atual apenas como contexto. Escopo: <arquivos/subsistemas>. Restrições: <deve preservar>. Concluído quando: <critérios verificáveis>. Verifique por <comandos/evidências>. Pare se <condições de bloqueio>.

3. Nenhum Contexto Útil

Use este caminho quando o usuário pedir uma meta mas não tiver fornecido uma tarefa concreta.

Regras:

• Faça apenas descoberta leve: diretório atual, nome do repositório, README*, AGENTS.md, CONTEXT.md, documentos de plano óbvios, manifestos de pacote e scripts de teste.
• Não invente direção de produto.
• Gere um objetivo de descoberta primeiro, de escopo fechado e pequeno.
• Prefira "descubra -> escolha um issue estreito de maior valor -> corrija ou documente -> verifique" em vez de "otimize o projeto inteiro".
• Se não houver repositório ou alvo seguro, faça uma pergunta concisa ou produza um objetivo de descoberta agnóstico ao repositório.

Forma:

/goal Em <caminho>, inspecione o estado atual do projeto, identifique o issue ou oportunidade de otimização pequena e acionável de maior valor que possa ser verificada localmente, conclua uma melhoria conservadora de escopo fechado, preserve o trabalho não relacionado, verifique com as verificações relevantes descobertas e relate evidências mais os acompanhamentos restantes. Pare se nenhum alvo seguro e verificável for encontrado ou se o contexto necessário estiver faltando.

Anatomia da Meta

Toda meta forte deve conter estas ideias, usando rótulos compactos:

• Objetivo: estado final concreto, não uma atividade.
• Escopo: arquivos, pastas, subsistema, issue, caminho de plano ou área de descoberta.
• Restrições: o que não deve mudar.
• Limites: escritas permitidas, caminhos proibidos, serviços externos, dados de produção, credenciais ou operações destrutivas.
• Concluído quando: critérios de aceitação mensuráveis.
• Verificação: comandos, logs, artefatos, screenshots, limites de benchmark, verificações de CI ou citações baseadas em fonte.
• Política de iteração: como reagir a falhas, quantas rodadas de melhoria focada e quando re-verificar.
• Pare/Pause se: bloqueadores concretos, requisitos conflitantes, credenciais ausentes, expansão insegura de escopo, ambiente indisponível, verificação repetidamente falha, decisões humanas.
• Evidência de saída: o resumo final deve incluir o que mudou, evidências, comandos executados, falhas, risco residual e próximos passos.

Para metas apenas de pesquisa, exija mapeamento de afirmação para evidência, citações de arquivo/URL, rótulos de incerteza e nenhuma edição de código a menos que explicitamente permitido.

Portões de Qualidade

Antes de mostrar o comando:

• Garanta que uma sessão nova do Codex poderia agir sem contexto oculto.
• Garanta que a intenção mais recente do usuário está representada.
• Garanta que caminhos de plano/documento estão incluídos quando disponíveis.
• Garanta que a meta é finita e auditável.
• Substitua termos vagos como "melhorar", "otimizar", "limpar", "tudo", "completamente", "everything" ou "make it good" por critérios mensuráveis, ou declare a suposição.
• Use comandos exatos quando conhecidos; caso contrário, diga "descubra e execute as verificações documentadas relevantes do repositório".
• Não deixe placeholders como <caminho>, [TODO], TBD ou 待定 na saída copiável final.
• Não permita permissões amplas como "edite qualquer coisa" a menos que o usuário tenha solicitado explicitamente e o risco seja baixo.
• Não declare sucesso com base em exaustão de orçamento, tempo gasto ou ausência de erros óbvios.

Se a meta for fraca, faça no máximo 3 perguntas direcionadas. Se detalhes ausentes forem de baixo risco, faça suposições e prossiga.

Referências e Ferramentas

• Leia references/examples.md quando o caso for ambíguo ou o usuário quiser variantes.
• Leia references/source-patterns.md ao explicar a lógica de design ou comparar práticas.
• Use scripts/lint_goal_command.py ao auditar um arquivo de meta salvo ou quando puder validar um comando rascunhado de forma barata.