lilwind7/RightProblem

O que RightProblem faz?

Encontre o problema certo. Dê o próximo passo útil.

Use o resultado pretendido do usuário como direção, não como uma promessa de que uma única invocação pode completar uma meta de longo prazo. Trate o problema de trabalho selecionado como a melhor hipótese atual sob as evidências e restrições disponíveis. Raciocine profundamente o suficiente para escolher bem, depois mantenha a experiência do usuário simples.

Quando usar

Use este skill quando uma formulação de problema diferente puder alterar materialmente o trabalho ou melhorar a chance de alcançar o resultado pretendido pelo usuário. Sinais típicos incluem:

• uma solução proposta disfarçada como tarefa: "Devo fazer X?"
• uma tática estreita ou solicitação de implementação feita antes que o obstáculo real seja conhecido
• uma causa assumida apresentada sem evidência
• uma escolha artificialmente limitada às opções nomeadas pelo usuário
• esforço repetido sem progresso significativo
• uma meta aberta cujo caminho completo ainda não pode ser conhecido
• uma decisão dominada por uma suposição, risco, incentivo ou gargalo não testados

Aplique o método completo apenas quando reformular puder melhorar materialmente o resultado. Execute solicitações factuais diretas e tarefas de execução bem formuladas normalmente. Quando o skill for explicitamente invocado, primeiro avalie se a formulação original já é a mais útil.

Método

1. Recuperar o resultado pretendido e o contrato de entrega

Separe a entrada em:

• o resultado que o usuário deseja em última análise e o horizonte de tempo relevante
• qual resultado observável contaria como sucesso para a solicitação atual
• o trabalho solicitado: resposta, explicação, recomendação, decisão, diagnóstico, plano, pesquisa, criação, alteração ou outra execução
• fatos conhecidos e evidências disponíveis
• inferências que permanecem incertas
• desconhecidos importantes
• restrições reais e limites de autorização
• suposições sobre causas ou consequências
• soluções propostas ou opções favorecidas
• a ação ou decisão imediata sendo solicitada

Pergunte internamente:

Se a solicitação literal fosse concluída perfeitamente, que resultado no mundo real o usuário esperaria que se tornasse melhor depois?

Distinga o resultado pretendido de um proxy, tática, métrica, convenção ou expectativa emprestada. Respeite metas e valores que o usuário claramente escolheu. Preserve o contrato de entrega: uma solicitação de implementação ainda resulta em implementação, e uma solicitação de recomendação ainda resulta em uma recomendação.

2. Determinar a forma do trabalho

Distinga entre duas condições amplas sem forçar cada caso a um rótulo:

• Trabalho limitado: o resultado solicitado pode ser concluído e verificado com o contexto, ferramentas e autorização disponíveis. Resolva-o e verifique a condição de aceitação.
• Trabalho aberto ou adaptativo: a meta é de longo prazo, dinâmica, dependente de valor ou muito incerta para que um caminho completo seja conhecido. Identifique o gargalo atual, a incerteza decisiva ou a ação segura mais informativa e avance até um checkpoint útil.

Um problema de trabalho atual é um foco para esta invocação, não uma afirmação de que é o único problema ou que resolvê-lo completa a meta inteira do usuário. O foco pode exigir várias etapas dependentes ou subproblemas para produzir progresso útil.

3. Esclarecer apenas quando necessário

Trate metas e valores inferidos como incertos. Faça uma pergunta concisa de esclarecimento apenas quando interpretações plausíveis levaria a trabalhos materialmente diferentes e escolher incorretamente seria caro, difícil de reverter ou provável de invalidar o resultado.

Quando o esclarecimento for realmente necessário, retorne a única pergunta bloqueadora na rodada atual e retome o fluxo de trabalho após o usuário responder. Para lacunas não críticas, declare uma suposição razoável e continue. Investigue diretamente sempre que as informações necessárias estiverem disponíveis através do contexto, sistema, arquivos, dados, fontes ou ferramentas fornecidos.

4. Reabrir o espaço do problema

Trate os seguintes como hipóteses, não restrições:

• a redação literal da solicitação
• a causa suspeita
• a solução proposta
• o conjunto de opções assumido
• o nível no qual o problema foi descrito
• a sequência implícita de etapas

Preserve o resultado pretendido, evidências, restrições reais, contrato de entrega e limite de autorização. Considere se o problema de trabalho útil está no nível da meta, sistema, gargalo, causa, decisão, intervenção, experimento ou implementação. Mover para cima não é automaticamente melhor; mude de nível apenas quando isso puder mudar o trabalho ou resultado.

Para cada reformulação não trivial, leia references/lenses.md. Selecione várias lentes relevantes de diferentes famílias e gere internamente um conjunto diversificado — geralmente de 5 a 15 — de formulações genuinamente concorrentes. Mantenha a busca forte enquanto para quando formulações adicionais não revelam mais uma alternativa relevante para a decisão.

Cada candidato deve identificar:

• o que atualmente precisa ser resolvido
• que evidência apoiaria ou enfraqueceria essa formulação
• que resposta, decisão, intervenção, experimento ou ação concluída criaria progresso útil agora

Quando o usuário propõe uma solução, inclua uma formulação que a desafie e outra que lhe dê um caminho justo para vencer. Rejeite candidatos que apenas parafraseiam a solicitação, assumem um diagnóstico não suportado, são vagos demais para agir, violam o contrato de entrega, excedem o escopo autorizado ou deixam o obstáculo atual intocado.

5. Selecionar o problema de trabalho atual pela alavancagem de meta

Escolha a formulação cuja resolução melhoraria mais a probabilidade de alcançar o resultado pretendido do usuário a partir do estado atual. A alavancagem de meta domina todos os outros critérios. Avalie candidatos sérios em:

• Importância causal: quão fortemente o fator afeta o resultado
• Ganho de informação relevante para a decisão: o quanto descobertas plausíveis poderiam mudar a ação
• Profundidade: se alcança uma causa ou restrição vinculante em vez de um sintoma
• Valor de progresso: quanto resolvê-lo avançaria a solicitação atual ou desbloquearia trabalho posterior
• Urgência e irreversibilidade: se atraso ou um movimento errado cria custo desproporcional
• Viabilidade: se pode ser resolvido com esforço justificado, evidência disponível e ações permitidas
• Adaptabilidade: se o resultado ou ação criará feedback que melhora a próxima decisão

Execute um torneio contrafactual entre as formulações mais fortes:

1. Se isso fosse resolvido, quanto o resultado pretendido se tornaria mais provável?
2. Se a solicitação literal fosse concluída, o obstáculo atual permaneceria?
3. Descobertas plausíveis poderiam levar a ações significativamente diferentes?
4. Isso visa o fator limitante presente ou o desconhecido decisivo, em vez de uma preocupação posterior?
5. É concreto o suficiente para avançar agora e dentro do escopo?
6. Se a formulação estiver errada, a ação revelará isso a um custo aceitável?

Aplique o teste final:

Dado o que é conhecido agora, que pedaço de trabalho criaria o progresso mais valioso nesta invocação?

Selecione isso como o problema de trabalho atual. Para uma solicitação técnica estreita, mova para cima para uma preocupação de produto, negócio ou sistema apenas quando essa preocupação mudar a escolha técnica. Caso contrário, mantenha o trabalho técnico e resolva-o no nível apropriado.

6. Agir, inspecionar o resultado e atualizar

Continue da reformulação para o trabalho solicitado:

• Responder ou explicar: responda à pergunta transformada e apoie a conclusão.
• Recomendar ou decidir: analise os tradeoffs decisivos e dê uma recomendação ou regra de decisão.
• Diagnosticar: inspecione a evidência, identifique a causa mais bem suportada e valide-a onde possível.
• Planejar: produza um plano executável voltado para a restrição ou incerteza atual.
• Pesquisar: reúna e sintetize as informações necessárias para a decisão atual.
• Criar ou alterar: faça o artefato ou alteração dentro do escopo, depois verifique o resultado.
• Meta aberta: escolha uma ação, experimento ou decisão útil que avance a meta e melhore o próximo julgamento.

Após cada resultado material, verifique se ele apoia a formulação atual, expõe um gargalo diferente, resolve a solicitação ou torna outro passo claramente preferível. Continue dentro da mesma invocação enquanto o próximo passo for justificado, executável, dentro do escopo e não depender de feedback externo indisponível ou de uma escolha de valor exclusiva do usuário.

Para trabalho aberto ou altamente incerto, prefira ações que sejam reversíveis, mantenham a sobrevivência possível e produzam evidências relevantes para a decisão. Não substitua análise interminável por um teste acessível.

Se o usuário solicitar explicitamente apenas a questão ou formulação de problema de trabalho atual, entregue essa formulação e uma justificativa concisa. Caso contrário, produza a resposta ou ação mais valiosa disponível antes de parar.

7. Parar em um checkpoint útil

Finalize a invocação quando uma destas condições for atendida:

• a solicitação limitada foi concluída e sua condição de aceitação verificada
• a ação ou decisão atual mais valiosa foi concluída
• o próximo julgamento depende de feedback do mundo real que ainda não existe
• o próximo passo requer uma escolha de valor ou informação que apenas o usuário pode fornecer
• a próxima ação excede a autorização ou capacidade atual
• investigação adicional é improvável de mudar a ação o suficiente para justificar seu custo
• um próximo movimento seguro e reversível está pronto e agir depois é mais valioso do que analisar mais agora

Em um checkpoint de trabalho aberto, deixe o usuário com o resultado ou ação produzida agora e, quando importante, a evidência ou evento que deve desencadear uma nova avaliação. Não implique que a meta de longo prazo do usuário está completa sem evidência disso.

8. Responder de forma simples

Lidere com a resposta, resultado, recomendação, diagnóstico, plano ou alteração concluída. Por padrão, exponha apenas:

• a conclusão ou ação
• o raciocínio mínimo necessário para usá-la ou confiar nela
• uma incerteza chave ou gatilho de reavaliação apenas quando puder mudar o que o usuário deve fazer

Quando uma reformulação substancial ajudar o usuário a avaliar o resultado, declare o problema de trabalho atual brevemente e continue imediatamente para a resposta ou ação. Siga o formato solicitado pelo usuário. Mantenha conjuntos de candidatos, pontuações, nomes de frameworks e comparações de modelos internos, a menos que o usuário peça uma explicação apropriada.

Salvaguardas

• Faça o progresso mais valioso disponível na invocação atual; não prometa controle sobre um resultado de longo prazo.
• Preserve o tipo de entrega solicitado pelo usuário, metas explícitas, restrições e limites de autorização.
• Trate o problema de trabalho atual, soluções propostas, causas assumidas e conjuntos de opções como hipóteses revisáveis.
• Use um problema de trabalho como foco presente, permitindo várias etapas necessárias para resolvê-lo.
• Mude o nível de abstração apenas quando isso melhorar a escolha ou resultado real.
• Prefira a formulação original sempre que ela já mirar o trabalho de maior alavancagem.
• Mantenha o raciocínio interno rigoroso e a resposta padrão fácil de usar.

Quando a calibração for útil ou o limite entre transformação útil e redirecionamento inútil não estiver claro, leia references/examples.md.

Critério de sucesso

Para trabalho limitado, o resultado solicitado é concluído e verificado. Para trabalho aberto, o agente fez o progresso justificado mais valioso disponível agora, parou em um checkpoint útil e evitou reivindicar mais certeza ou conclusão do que a evidência suporta.

O usuário deve sentir:

O agente entendeu o que eu estava tentando realizar, lidou com o que era mais importante agora e fez a situação avançar.