ARQAWA/cursor-pi

Definir Goal

Visão Geral

Molde a intenção do usuário em um resultado concreto com escopo delimitado e fundamentos para conclusão extraídos da solicitação. A verificação comum usa leitura e avaliação lógica sob a regra do prompt principal; use números apenas quando eles expressam um requisito real.

Esta skill cobre apenas a definição de goal e criação da ferramenta-goal. Não crie artefatos de planejamento intermediários, snapshots duráveis, registros, logs de decisão ou arquivos de retomada a partir desta skill.

Apenas o Main raiz gerencia o Goal nativo. Sua seleção não adiciona testes, revisão, delegação, permissões ou outros fluxos de trabalho. O Gold Standard avalia independentemente o estado de trabalho útil, com ou sem Goal. O Notebook pode automaticamente se juntar a um Goal selecionado sob suas próprias condições, sem outra solicitação manual; Goal sozinho não exige isso. Mantenha notas operacionais úteis sob essa política, fora deste procedimento de definição; o objetivo e status nativos permanecem autoritativos.

A definição sozinha não autoriza a execução da tarefa proposta. Goal nunca substitui aprovação ou confirmação de execução exigida: a preparação ToSpec não inicia o Goal de execução futuro, enquanto um Goal de preparação explicitamente selecionado diz respeito apenas ao resultado de preparação solicitado. A seleção automática não substitui uma pausa do usuário nem transforma um bloqueador, aguardo de aprovação, fim de turno ou cancelamento sem descarte em conclusão. Siga as regras reais de status nativo; a conclusão exige o resultado real e todas as ações já obrigatórias.

Fluxo de Trabalho

1. Avalie se Goal é útil para a ordem atual real.

   • Selecione automaticamente quando um resultado solicitado de forma independente precisa de continuidade através de etapas dependentes, pesquisa substantiva ou incerteza, ou execução prolongada, sujeito à verificação de autoridade no passo 6.
   • Perguntas curtas, edições diretas breves e discussão de possíveis trabalhos futuros não exigem Goal. A descoberta solicitada pode em si ter um resultado concreto; discuti-la não autoriza executá-la.
   • Um /goal direto, solicitação para criar um goal ou pedido de definição de goal seleciona esta skill independentemente da complexidade. Uma instrução para trabalhar sem Goal tem precedência sobre a seleção automática para a tarefa afetada.
   • Reavalie após uma mudança material na tarefa, não a cada chamada de ferramenta; não use limiares para comandos, minutos ou arquivos.

2. Reafirme o provável goal em termos concretos. Um goal utilizável nomeia:

   • o resultado específico que será verdadeiro
   • o artefato principal, sistema, repositório, ambiente ou comportamento voltado ao usuário envolvido
   • como o resultado real será estabelecido por leitura e avaliação lógica, além de qualquer evidência explicitamente exigida
   • o que está no escopo
   • o que está fora do escopo quando a ambiguidade importaria
   • a condição de parada para perguntar ao usuário em vez de prosseguir cegamente

3. Use critérios que representam o resultado solicitado.

   • Derive resultado, caminhos de artefato, escopo, formato, valores e condições binárias de conclusão da solicitação.
   • Não invente métricas, limiares, validadores ou contagens de execução para mensurabilidade formal.
   • Testes, comandos, CI, medições e contagens de evidência são opções apenas para evidência empírica explicitamente solicitada ou um procedimento especificamente adotado ou obrigação de prioridade superior.
   • Para correções comuns, análise ou trabalho de desempenho baseado em arquitetura, defina a conclusão através do resultado real e da avaliação lógica.

4. Repare goals fracos antes de defini-los.

   • Reescreva goals vagos em critérios de resultado concretos quando a solicitação e o contexto local tornarem essa interpretação segura.
   • Faça uma pergunta de esclarecimento concisa quando o detalhe ausente alterar o resultado pretendido ou a validação.
   • Rejeite goals de atividade pura como "fazer progresso", "continuar investigando", "melhorar coisas" ou "trabalhar em X" a menos que sejam refinados em um resultado verificável.

5. Verifique o estado ativo do goal antes de criar um goal.

   • Leia o snapshot nativo do Goal raiz atual de scope_focus_native_context. Valide conversationId, goalId, objetivo e status nativo (0 não especificado, 1 ativo, 2 pausado, 3 completo, 4 limpo). Um estado raiz válido ausente significa nenhum goal; identidade/estado desconhecido é desconhecido, não ausência. Filhos não gerenciam o Goal raiz. Use apenas campos de orçamento nativos reais quando fornecidos; não os invente.
   • Use as ferramentas nativas disponíveis create_goal/update_goal e seus esquemas atuais. Cursor create_goal recebe objective; não passe um campo de orçamento apenas do Codex. Uma capacidade nativa exigida ausente interrompe sua transição dependente; não simule Goal nem reivindique prontidão total.
   • Se não houver goal inacabado, o objetivo atende à barra de qualidade e o passo 6 permite a criação, chame create_goal.
   • Reutilize um goal inacabado correspondente de acordo com as instruções atuais do usuário e o estado nativo; a seleção repetida não cria uma duplicata nem repete operações concluídas.
   • Preserve um goal inacabado conflitante. Não redefina, substitua ou marque como completo apenas para abrir espaço. Resolva apenas o conflito material através de um caminho nativo permitido ou uma pergunta focada ao usuário; não exija uma nova thread.

6. Crie o goal somente depois que ele passar pela barra de qualidade.

   • Escolher esta skill não autoriza por si só create_goal. Siga as instruções reais da ferramenta e regras de prioridade superior. A adoção expressa pelo usuário do Goal automático condicional, ou uma instrução aplicável do sistema/desenvolvedor, fornece uma solicitação permanente apenas onde essas regras a aceitam. A disponibilidade da skill ou uma tarefa comum sozinha não é essa autoridade; se o host exigir uma solicitação explícita separada, não infira permissão contra esse requisito.
   • Se Goal nativo não estiver disponível ou não for permitido, não o simule com arquivos ou outro controlador. Continue o trabalho autorizado compatível; divulgue a limitação concreta apenas quando material para o resultado ou um Goal explicitamente solicitado.
   • Use uma única string de objetivo concisa.
   • Inclua fundamentos suficientes para conclusão: o resultado solicitado avaliado através de leitura e lógica, além de qualquer evidência explicitamente obrigatória. Cada limiar ou método adicionado deve seguir a solicitação; escrevê-lo no objetivo não cria autoridade.
   • Inclua limites de escopo quando eles restringem o trabalho.
   • Um orçamento é fornecido apenas quando explicitamente solicitado e suportado pelo esquema nativo real. Se um orçamento solicitado não puder ser representado pelo Goal nativo do Cursor, interrompa essa transição dependente e divulgue a capacidade ausente; não descarte silenciosamente nem simule o orçamento.
   • Formule um goal permitido claro sem perguntar novamente apenas para habilitar o modo ou aprovar sua redação técnica. Pergunte apenas quando uma escolha ausente alterar materialmente o resultado solicitado, a autoridade ou a evidência obrigatória. Uma solicitação apenas de definição permanece apenas de definição.

Barra de Qualidade do Goal

Antes de create_goal, o objetivo deve responder:

• Que coisa concreta será verdadeira quando isso estiver concluído?
• Que fundamentos materiais e lógicos reais a estabelecem, e que evidência empírica o usuário explicitamente exigiu?
• Que resultado solicitado ou condição binária/quantitativa significativa define o sucesso?
• Que limites de escopo importam?
• O que deve fazer o agente parar e perguntar?

Bom:

Substitua A por B na configuração especificada. Termine quando a edição estiver presente e a leitura do código afetado estabelecer consistência com a solicitação.

Bom:

Resolva a questão de design especificada a partir de fontes relevantes e lógica. Termine quando a conclusão for suportada e as contradições materiais forem abordadas.

Fraco:

Tornar o checkout mais rápido.

Fraco:

Continuar investigando os comentários do PR.

Heurísticas de Quantificação

• Para bugs, defina a correção necessária e explique-a através do código e lógica afetados. Reprodução e um validador que falha e depois passa exigem uma solicitação explícita para essa evidência.
• Para testes explicitamente solicitados, nomeie o cenário ordenado e sua condição de aprovação; honre um comando especificado.
• Para desempenho, raciocine a partir de mecanismos, trabalho e contexto. Rotule a complexidade calculada como cálculo; reivindique uma melhoria medida apenas a partir de medições reais. Não invente uma métrica, alvo, método ou contagem de execução.
• Para trabalho de qualidade, use o resultado solicitado, normalmente avaliado através de leitura e lógica; não adicione lint, verificações de tipo ou testes automaticamente.
• Para pesquisa, defina a decisão que a pesquisa deve permitir, as fontes ou sistemas no escopo e o padrão de evidência.
• Para operações, defina o estado resultante solicitado. Não invente janelas de monitoramento, limiares ou trabalho de reversão.

Perguntas de Esclarecimento

Pergunte apenas quando uma reformulação razoável arriscar perseguir o resultado errado. Mantenha a pergunta curta e orientada em torno do validador ausente ou limite de escopo.

Formatos de perguntas úteis:

• "Qual métrica deve definir o sucesso aqui: latência, custo, precisão ou comportamento visível ao usuário?"
• "Contra qual ambiente devo verificar: local, staging ou produção?"
• "Qual é a evidência mínima que você deseja antes de eu marcar este goal como concluído?"

Quando um critério significativo segue diretamente da solicitação, formule-o sem outra confirmação. Pergunte apenas quando uma escolha não resolvida alterar materialmente o resultado ou a evidência obrigatória.