Redator de Instruções de Objetivo

O que Redator de Instruções de Objetivo faz?

Transforme uma solicitação vaga em uma instrução de Objetivo pronta para execução que um agente possa executar sem adivinhar o que sucesso, progresso ou parada significa. Preserve a intenção, linguagem, limites de autoridade e escopo solicitado pelo usuário. Esta skill projeta e audita o contrato de instrução; acesso em tempo de execução, permissões e aprovações externas ainda vêm do agente anfitrião e do usuário. Descreva as verificações ao escrever um Objetivo; execute a tarefa subjacente apenas quando o usuário também tiver solicitado a execução.

Leia references/goal-contract.md ao rascunhar ou auditar um Objetivo. Leia references/examples.md apenas quando um exemplo prático esclareceria a tarefa solicitada. Para trabalho que abrange várias fases, artefatos ou mais de algumas iterações, leia também references/drift-control.md. Para fluxos de trabalho com visualização primeiro, leia references/loop-preview.md.

Escolha o modo

• Rascunho: construir um Objetivo a partir de uma solicitação aproximada.
• Refinar: preservar um Objetivo existente enquanto preenche campos de objetivo, evidência, loop ou término ausentes.
• Auditar: identificar ambiguidade, repetição ilimitada, critérios não verificáveis e transições inseguras ou não autorizadas; propor as menores correções.
• Converter: transformar uma checklist, ticket ou resumo de projeto em um Objetivo sem expandir seu escopo.
• Visualizar: mostrar o loop concreto, ramificações, portões de desvio e condições de parada antes de escrever o Objetivo final. Não emita um Objetivo executável nem realize trabalho externo neste modo.

Se o modo não for declarado, infira-o a partir da entrada. Faça apenas perguntas cujas respostas alterariam o objetivo, autoridade, evidência de aceitação ou estado terminal legal. Caso contrário, declare suposições e continue.

Visualizar antes de rascunhar

Use visualização primeiro quando o usuário pedir "先看循环", "preview", "先设计流程" ou similar. Também prefira para trabalho multiestágio, caro, irreversível ou materialmente incerto. Para uma tarefa curta e reversível, um rascunho direto é suficiente.

A visualização é um ponto de verificação de design, não uma aprovação para executar:

1. Declare o resultado provisório, linha de base e suposições.
2. Mostre o loop como transições de estado concretas, incluindo a primeira unidade de trabalho, ramificações de sucesso e falha, evidências de progresso, verificações de desvio, portões de fase e estados de parada legais. Distinga verificações de iteração de verificações mais amplas de fase ou entrega, incluindo reutilização de evidências e limites para verificações caras.
3. Liste as decisões que poderiam alterar o loop ou seu escopo. Para trabalho de feedback, adoção, piloto, lançamento ou validação, inclua o limite de evidência de feedback, o que conta e a janela de feedback.
4. Termine com um handoff claro: aguarde o usuário confirmar ou revisar o loop antes de gerar o Objetivo final.

Quando o usuário confirmar, carregue a visualização aceita para o Objetivo final sem alterar silenciosamente seu loop, escopo ou regras terminais. Se o usuário revisá-lo, regenere a visualização ou registre primeiro a decisão alterada. Uma resposta de visualização não deve alegar que o Objetivo está completo e não deve realizar efeitos colaterais externos apenas porque um loop foi descrito.

Construa o contrato de três camadas

1. Objetivo: defina o resultado

Escreva uma frase com um estado final observável. Ela deve dizer qual artefato, comportamento, decisão ou mudança verificada existirá quando o trabalho estiver concluído. Em seguida, torne o contrato concreto:

• Linha de base: o que existe agora e qual revisão, fonte ou fatos são autoritativos.
• Escopo: o que pode mudar e o que está congelado.
• Critérios de aceitação: verificações observáveis vinculadas a evidências, não a atividades como "continue trabalhando" ou "tente mais".
• Dependências e autoridade: ferramentas, acesso, decisões do proprietário e portões externos que o agente pode ou não cruzar.
• Entregável: os arquivos, decisão, relatório ou mensagem que serão devolvidos.

Para Objetivos sobre feedback, adoção, pilotos, lançamentos ou validação, defina um limite de evidência de feedback antes de rascunhar: o que conta como feedback, se um ponto de entrada é suficiente ou pelo menos N respostas de não-autores são necessárias, e o limite de tempo ou janela de tentativa. Não conte atividade apenas do autor, a menos que o usuário escolha explicitamente esse limite.

Prefira um resultado de suporte por Objetivo. Divida resultados não relacionados em Objetivos separados. Substitua verbos vagos como "melhorar", "lidar" ou "terminar" por um resultado mensurável.

Previna desvios em trabalhos longos

Para um Objetivo longo ou multiestágio, congele uma Âncora do Objetivo compacta antes da primeira iteração: o resultado de uma frase, IDs de critérios, escopo congelado e fase atual. Trate-a como um invariante. Uma nova descoberta pode mudar o plano, mas não deve mudar silenciosamente o resultado, critérios de aceitação ou autoridade. Uma decisão explícita do proprietário cria uma nova versão do Objetivo ou registro de alteração de escopo.

Em cada iteração, registre três links antes de agir:

1. Critério alvo: qual critério de aceitação este trabalho avança.
2. Delta esperado: qual evidência observável deve mudar se funcionar.
3. Razão de escopo: por que esta ação está dentro do limite congelado agora.

Após a verificação, classifique o resultado como:

• NO_ALVO: o critério nomeado moveu-se e a evidência suporta o próximo passo.
• MISSÃO_SECUNDÁRIA: útil mas não necessário para este Objetivo; estacione em uma lista adiada em vez de expandir o loop.
• DESVIADO: nenhum critério moveu-se, a ação mudou o objetivo ou escopo, ou o próximo passo não pode ser justificado a partir da Âncora; pare e realinhe.

Execute um portão de fase a cada 3–5 iterações por padrão, em cada marco, e antes de uma ação irreversível ou de alto custo. Releia a Âncora, compare o estado atual com a linha de base, marque critérios como abertos ou verificados, revise missões secundárias adiadas e escolha uma ação justificada para o próximo passo. Nunca reescreva critérios para fazer o trabalho concluído parecer no alvo.

2. Loop: defina como o progresso é feito

Use uma iteração limitada com um sinal de progresso visível:

1. Inspecione o estado atual e o último cursor durável.
2. Selecione a menor próxima unidade de trabalho, nomeie seu critério alvo, delta esperado e razão de escopo.
3. Aja dentro do escopo e autoridade permitidos.
4. Verifique o resultado contra o critério relevante usando a estratégia de verificação abaixo; capture a evidência.
5. Classifique o resultado como NO_ALVO, MISSÃO_SECUNDÁRIA ou DESVIADO e aplique a regra de desvio correspondente.
6. Registre o delta, lacuna restante, decisão e próximo cursor antes de outra iteração.

Declare o limite de iteração que se adequa à tarefa: um limite de tempo, orçamento de ferramenta ou token, número máximo de tentativas ou uma lista finita de unidades de trabalho. Adicione uma regra de no-op: não repita a mesma ação sem nova informação; após uma falha repetida, mude a hipótese ou pare com o bloqueador. O loop deve ser capaz de explicar por que a próxima iteração é diferente da anterior.

Estratégia de verificação

Inclua uma estratégia de verificação curta no Objetivo. Preserve requisitos explícitos de aceitação do usuário e do repositório enquanto controla quando as verificações são executadas:

• Verificações de iteração: escolha as menores verificações suficientes para o comportamento afetado. Amplie para impacto de mudança, novas falhas, incerteza não resolvida ou um portão obrigatório.
• Verificações de fase e entrega: uma vez que a implementação relevante esteja estável, complete as verificações restantes necessárias de regressão, build, integração e artefato. Um portão de fase revisa a evidência atual; não repete automaticamente todo o pipeline de validação e entrega.
• Reutilização de evidências: vincule resultados à fonte ou artefato verificado, entradas relevantes, dependências e ambiente. Carregue resultados adiante enquanto essas condições permanecerem válidas. Alterações de documentação ou recibo não invalidam verificações de runtime não relacionadas. Distinga evidências reutilizadas de verificações recém-executadas.
• Motivo para reexecução: antes de repetir uma verificação, nomeie a mudança ou nova evidência que invalida seu resultado e selecione as verificações afetadas. Uma alteração de fonte ou artefato invalida evidências dependentes, incluindo verificações de consumidor quando o artefato consumido muda.
• Custo e conclusão: dê a verificações caras timeouts de comando adequados ou limites de tentativa. Um timeout deixa seu critério não verificado; reporte a lacuna. Termine quando todos os critérios tiverem evidências válidas e a entrega estiver completa; mais verificações precisam de uma preocupação concreta não resolvida ou resultado invalidado.

3. Término: defina finais legais

Torne os estados terminais explícitos e mutuamente compreensíveis:

• Completo: todo critério de aceitação é verificado e o entregável está disponível.
• Bloqueado: uma dependência nomeada, autoridade ausente ou falha não resolvida impede a próxima ação significativa; reporte exatamente o que é necessário para desbloquear.
• Pausado: o proprietário pede explicitamente para pausar; preserve o cursor e não retome sem autorização.
• Com limite de tempo/orçamento: o limite é atingido antes da conclusão; reporte o progresso verificado, lacuna restante e a ação mais segura para o próximo passo.
• Parado: o proprietário cancela o trabalho ou uma ação excederia a autoridade concedida; não continue silenciosamente.
• Realinhamento necessário: uma verificação de desvio falha; pare o loop atual, preserve o ponto de verificação e retome apenas após a próxima ação ser reancorada. Use OBJETIVO PAUSADO: realinhamento necessário quando um rótulo terminal local for necessário.

Não use "continue até satisfazer", "tente indefinidamente" ou uma alegação de sucesso baseada apenas em esforço. Se a tarefa tiver uma convenção local para strings terminais, preserve-a; caso contrário, dê a cada estado um rótulo curto e exato e exija que a resposta final o inclua. Um objetivo ou critério de aceitação não pode ser alterado apenas porque o trabalho atual se tornou difícil ou interessante.

Produza a resposta

Retorne o resultado no idioma do usuário. A menos que ele solicite outro formato, use esta ordem:

1. Notas de design: um parágrafo curto explicando o objetivo, loop e escolhas de término e controle de desvio; liste suposições ou perguntas abertas de alto valor.
2. Visualização do loop: no modo Visualizar, mostre as transições de estado, ramificações, evidências, portões de desvio, estados terminais e decisões não resolvidas; pare aí e aguarde confirmação.
3. Objetivo pronto para copiar: no modo Rascunho, Refinar ou Converter, inclua a instrução completa em um bloco cercado com seções de Objetivo, Âncora do objetivo, Linha de base e escopo, Critérios de aceitação, Evidência de feedback quando aplicável, Estratégia de verificação, Loop de execução, Controle de desvio, Limites e regra de no-op, Término e Relatório.
4. Notas de auditoria: se refinando ou auditando, nomeie cada ambiguidade restante e a menor mudança que a resolve.

O bloco pronto para copiar deve ser executável como uma instrução, não uma discussão de como alguém poderia escrever uma instrução. Mantenha verificações de aceitação e estados terminais concretos o suficiente para que um revisor posterior possa decidí-los a partir de evidências.