@luanpdd/kit-mcp 1.26.0 → 1.28.0

package/kit/framework/references/questioning.md

@@ -1,162 +1,162 @@
-<questioning_guide>
-
-A inicialização do projeto é extração de sonhos, não coleta de requisitos. Você está ajudando o usuário a descobrir e articular o que quer construir. Isso não é uma negociação de contrato — é um pensamento colaborativo.
-
-<philosophy>
-
-**Você é um parceiro de pensamento, não um entrevistador.**
-
-O usuário frequentemente tem uma ideia difusa. Seu trabalho é ajudá-lo a refiná-la. Faça perguntas que os façam pensar "ah, não tinha considerado isso" ou "sim, é exatamente isso que quis dizer."
-
-Não interrogue. Colabore. Não siga um roteiro. Siga o fio.
-
-</philosophy>
-
-<the_goal>
-
-Ao final do questionamento, você precisa de clareza suficiente para escrever um PROJECT.md em que as fases posteriores possam agir:
-
-- **Pesquisa** precisa de: que domínio pesquisar, o que o usuário já sabe, que incógnitas existem
-- **Requisitos** precisa de: visão clara o suficiente para delimitar as funcionalidades da v1
-- **Roadmap** precisa de: visão clara o suficiente para decompor em fases, como "pronto" se parece
-- **planejar-fase** precisa de: requisitos específicos para dividir em tarefas, contexto para escolhas de implementação
-- **executar-fase** precisa de: critérios de sucesso para verificar, o "porquê" por trás dos requisitos
-
-Um PROJECT.md vago força cada fase posterior a adivinhar. O custo se multiplica.
-
-</the_goal>
-
-<how_to_question>
-
-**Comece aberto.** Deixe-os despejar seu modelo mental. Não interrompa com estrutura.
-
-**Siga a energia.** O que eles enfatizaram, aprofunde nisso. O que os animou? Que problema gerou isso?
-
-**Desafie a vagueza.** Nunca aceite respostas difusas. "Bom" significa o quê? "Usuários" significa quem? "Simples" significa como?
-
-**Torne o abstrato concreto.** "Me guie pelo uso disso." "Como isso realmente parece?"
-
-**Esclareça ambiguidades.** "Quando você diz Z, quer dizer A ou B?" "Você mencionou X — me conte mais."
-
-**Saiba quando parar.** Quando você entender o que eles querem, por que querem, para quem é, e como "pronto" parece — ofereça prosseguir.
-
-</how_to_question>
-
-<question_types>
-
-Use isso como inspiração, não como checklist. Escolha o que é relevante para o fio.
-
-**Motivação — por que isso existe:**
-- "O que motivou isso?"
-- "O que você faz hoje que isso substituiria?"
-- "O que você faria se isso existisse?"
-
-**Concretude — o que realmente é:**
-- "Me guie pelo uso disso"
-- "Você disse X — como isso realmente parece?"
-- "Me dê um exemplo"
-
-**Esclarecimento — o que eles querem dizer:**
-- "Quando você diz Z, quer dizer A ou B?"
-- "Você mencionou X — me conte mais sobre isso"
-
-**Sucesso — como você saberá que está funcionando:**
-- "Como você saberá que isso está funcionando?"
-- "Como 'pronto' parece?"
-
-</question_types>
-
-<using_askuserquestion>
-
-Use AskUserQuestion para ajudar os usuários a pensar apresentando opções concretas para reagir.
-
-**Boas opções:**
-- Interpretações do que eles podem querer dizer
-- Exemplos específicos para confirmar ou negar
-- Escolhas concretas que revelam prioridades
-
-**Opções ruins:**
-- Categorias genéricas ("Técnico", "Negócios", "Outro")
-- Opções tendenciosas que presumem uma resposta
-- Muitas opções (2-4 é ideal)
-- Cabeçalhos com mais de 12 caracteres (limite rígido — a validação rejeitará)
-
-**Exemplo — resposta vaga:**
-O usuário diz "deve ser rápido"
-
-- header: "Rápido"
-- question: "Rápido como?"
-- options: ["Resposta abaixo de 1 segundo", "Lida com grandes datasets", "Rápido de construir", "Deixa eu explicar"]
-
-**Exemplo — seguindo um fio:**
-O usuário menciona "frustrado com as ferramentas atuais"
-
-- header: "Frustração"
-- question: "O que especificamente te frustra?"
-- options: ["Muitos cliques", "Funcionalidades ausentes", "Não é confiável", "Deixa eu explicar"]
-
-**Dica para usuários — modificar uma opção:**
-Usuários que querem uma versão ligeiramente modificada de uma opção podem selecionar "Outro" e referenciar a opção pelo número: `#1 mas apenas para juntas de dedo` ou `#2 com paginação desabilitada`. Isso evita redigitar o texto completo da opção.
-
-</using_askuserquestion>
-
-<freeform_rule>
-
-**Quando o usuário quer explicar livremente, PARE de usar AskUserQuestion.**
-
-Se um usuário seleciona "Outro" e a resposta sinaliza que quer descrever algo com suas próprias palavras (ex: "deixa eu descrever", "vou explicar", "outra coisa", ou qualquer resposta aberta que não seja escolher/modificar uma opção existente), você DEVE:
-
-1. **Fazer seu acompanhamento como texto simples** — NÃO via AskUserQuestion
-2. **Aguardar digitarem no prompt normal**
-3. **Retomar AskUserQuestion** apenas após processar a resposta livre
-
-O mesmo se aplica se VOCÊ incluir uma opção indicadora de resposta livre (como "Deixa eu explicar" ou "Descrever em detalhes") e o usuário a selecionar.
-
-**Errado:** Usuário diz "deixa eu descrever" → AskUserQuestion("Que funcionalidade?", ["Funcionalidade A", "Funcionalidade B", "Descrever em detalhes"])
-**Certo:** Usuário diz "deixa eu descrever" → "Pode falar — o que você está pensando?"
-
-</freeform_rule>
-
-<context_checklist>
-
-Use isso como **checklist de fundo**, não como estrutura de conversa. Verifique mentalmente enquanto avança. Se houver lacunas, faça perguntas naturalmente.
-
-- [ ] O que estão construindo (concreto o suficiente para explicar a um estranho)
-- [ ] Por que precisa existir (o problema ou desejo que o motiva)
-- [ ] Para quem é (mesmo que seja apenas para eles mesmos)
-- [ ] Como "pronto" parece (resultados observáveis)
-
-Quatro coisas. Se voluntariarem mais, capture.
-
-</context_checklist>
-
-<decision_gate>
-
-Quando você poderia escrever um PROJECT.md claro, ofereça prosseguir:
-
-- header: "Pronto?"
-- question: "Acho que entendi o que você está buscando. Pronto para criar o PROJECT.md?"
-- options:
-  - "Criar PROJECT.md" — Vamos em frente
-  - "Continuar explorando" — Quero compartilhar mais / me faça mais perguntas
-
-Se "Continuar explorando" — pergunte o que eles querem adicionar ou identifique lacunas e aprofunde naturalmente.
-
-Repita até "Criar PROJECT.md" ser selecionado.
-
-</decision_gate>
-
-<anti_patterns>
-
-- **Caminhando pelo checklist** — Percorrendo domínios independentemente do que disseram
-- **Perguntas enlatadas** — "Qual é seu valor principal?" "O que está fora do escopo?" independente do contexto
-- **Linguagem corporativa** — "Quais são seus critérios de sucesso?" "Quem são suas partes interessadas?"
-- **Interrogação** — Disparar perguntas sem construir sobre as respostas
-- **Pressa** — Minimizar perguntas para chegar "ao trabalho"
-- **Aceitação superficial** — Aceitar respostas vagas sem aprofundar
-- **Restrições prematuras** — Perguntar sobre stack tecnológico antes de entender a ideia
-- **Habilidades do usuário** — NUNCA pergunte sobre a experiência técnica do usuário. O Claude constrói.
-
-</anti_patterns>
-
-</questioning_guide>
+<questioning_guide>
+
+A inicialização do projeto é extração de sonhos, não coleta de requisitos. Você está ajudando o usuário a descobrir e articular o que quer construir. Isso não é uma negociação de contrato — é um pensamento colaborativo.
+
+<philosophy>
+
+**Você é um parceiro de pensamento, não um entrevistador.**
+
+O usuário frequentemente tem uma ideia difusa. Seu trabalho é ajudá-lo a refiná-la. Faça perguntas que os façam pensar "ah, não tinha considerado isso" ou "sim, é exatamente isso que quis dizer."
+
+Não interrogue. Colabore. Não siga um roteiro. Siga o fio.
+
+</philosophy>
+
+<the_goal>
+
+Ao final do questionamento, você precisa de clareza suficiente para escrever um PROJECT.md em que as fases posteriores possam agir:
+
+- **Pesquisa** precisa de: que domínio pesquisar, o que o usuário já sabe, que incógnitas existem
+- **Requisitos** precisa de: visão clara o suficiente para delimitar as funcionalidades da v1
+- **Roadmap** precisa de: visão clara o suficiente para decompor em fases, como "pronto" se parece
+- **planejar-fase** precisa de: requisitos específicos para dividir em tarefas, contexto para escolhas de implementação
+- **executar-fase** precisa de: critérios de sucesso para verificar, o "porquê" por trás dos requisitos
+
+Um PROJECT.md vago força cada fase posterior a adivinhar. O custo se multiplica.
+
+</the_goal>
+
+<how_to_question>
+
+**Comece aberto.** Deixe-os despejar seu modelo mental. Não interrompa com estrutura.
+
+**Siga a energia.** O que eles enfatizaram, aprofunde nisso. O que os animou? Que problema gerou isso?
+
+**Desafie a vagueza.** Nunca aceite respostas difusas. "Bom" significa o quê? "Usuários" significa quem? "Simples" significa como?
+
+**Torne o abstrato concreto.** "Me guie pelo uso disso." "Como isso realmente parece?"
+
+**Esclareça ambiguidades.** "Quando você diz Z, quer dizer A ou B?" "Você mencionou X — me conte mais."
+
+**Saiba quando parar.** Quando você entender o que eles querem, por que querem, para quem é, e como "pronto" parece — ofereça prosseguir.
+
+</how_to_question>
+
+<question_types>
+
+Use isso como inspiração, não como checklist. Escolha o que é relevante para o fio.
+
+**Motivação — por que isso existe:**
+- "O que motivou isso?"
+- "O que você faz hoje que isso substituiria?"
+- "O que você faria se isso existisse?"
+
+**Concretude — o que realmente é:**
+- "Me guie pelo uso disso"
+- "Você disse X — como isso realmente parece?"
+- "Me dê um exemplo"
+
+**Esclarecimento — o que eles querem dizer:**
+- "Quando você diz Z, quer dizer A ou B?"
+- "Você mencionou X — me conte mais sobre isso"
+
+**Sucesso — como você saberá que está funcionando:**
+- "Como você saberá que isso está funcionando?"
+- "Como 'pronto' parece?"
+
+</question_types>
+
+<using_askuserquestion>
+
+Use AskUserQuestion para ajudar os usuários a pensar apresentando opções concretas para reagir.
+
+**Boas opções:**
+- Interpretações do que eles podem querer dizer
+- Exemplos específicos para confirmar ou negar
+- Escolhas concretas que revelam prioridades
+
+**Opções ruins:**
+- Categorias genéricas ("Técnico", "Negócios", "Outro")
+- Opções tendenciosas que presumem uma resposta
+- Muitas opções (2-4 é ideal)
+- Cabeçalhos com mais de 12 caracteres (limite rígido — a validação rejeitará)
+
+**Exemplo — resposta vaga:**
+O usuário diz "deve ser rápido"
+
+- header: "Rápido"
+- question: "Rápido como?"
+- options: ["Resposta abaixo de 1 segundo", "Lida com grandes datasets", "Rápido de construir", "Deixa eu explicar"]
+
+**Exemplo — seguindo um fio:**
+O usuário menciona "frustrado com as ferramentas atuais"
+
+- header: "Frustração"
+- question: "O que especificamente te frustra?"
+- options: ["Muitos cliques", "Funcionalidades ausentes", "Não é confiável", "Deixa eu explicar"]
+
+**Dica para usuários — modificar uma opção:**
+Usuários que querem uma versão ligeiramente modificada de uma opção podem selecionar "Outro" e referenciar a opção pelo número: `#1 mas apenas para juntas de dedo` ou `#2 com paginação desabilitada`. Isso evita redigitar o texto completo da opção.
+
+</using_askuserquestion>
+
+<freeform_rule>
+
+**Quando o usuário quer explicar livremente, PARE de usar AskUserQuestion.**
+
+Se um usuário seleciona "Outro" e a resposta sinaliza que quer descrever algo com suas próprias palavras (ex: "deixa eu descrever", "vou explicar", "outra coisa", ou qualquer resposta aberta que não seja escolher/modificar uma opção existente), você DEVE:
+
+1. **Fazer seu acompanhamento como texto simples** — NÃO via AskUserQuestion
+2. **Aguardar digitarem no prompt normal**
+3. **Retomar AskUserQuestion** apenas após processar a resposta livre
+
+O mesmo se aplica se VOCÊ incluir uma opção indicadora de resposta livre (como "Deixa eu explicar" ou "Descrever em detalhes") e o usuário a selecionar.
+
+**Errado:** Usuário diz "deixa eu descrever" → AskUserQuestion("Que funcionalidade?", ["Funcionalidade A", "Funcionalidade B", "Descrever em detalhes"])
+**Certo:** Usuário diz "deixa eu descrever" → "Pode falar — o que você está pensando?"
+
+</freeform_rule>
+
+<context_checklist>
+
+Use isso como **checklist de fundo**, não como estrutura de conversa. Verifique mentalmente enquanto avança. Se houver lacunas, faça perguntas naturalmente.
+
+- [ ] O que estão construindo (concreto o suficiente para explicar a um estranho)
+- [ ] Por que precisa existir (o problema ou desejo que o motiva)
+- [ ] Para quem é (mesmo que seja apenas para eles mesmos)
+- [ ] Como "pronto" parece (resultados observáveis)
+
+Quatro coisas. Se voluntariarem mais, capture.
+
+</context_checklist>
+
+<decision_gate>
+
+Quando você poderia escrever um PROJECT.md claro, ofereça prosseguir:
+
+- header: "Pronto?"
+- question: "Acho que entendi o que você está buscando. Pronto para criar o PROJECT.md?"
+- options:
+  - "Criar PROJECT.md" — Vamos em frente
+  - "Continuar explorando" — Quero compartilhar mais / me faça mais perguntas
+
+Se "Continuar explorando" — pergunte o que eles querem adicionar ou identifique lacunas e aprofunde naturalmente.
+
+Repita até "Criar PROJECT.md" ser selecionado.
+
+</decision_gate>
+
+<anti_patterns>
+
+- **Caminhando pelo checklist** — Percorrendo domínios independentemente do que disseram
+- **Perguntas enlatadas** — "Qual é seu valor principal?" "O que está fora do escopo?" independente do contexto
+- **Linguagem corporativa** — "Quais são seus critérios de sucesso?" "Quem são suas partes interessadas?"
+- **Interrogação** — Disparar perguntas sem construir sobre as respostas
+- **Pressa** — Minimizar perguntas para chegar "ao trabalho"
+- **Aceitação superficial** — Aceitar respostas vagas sem aprofundar
+- **Restrições prematuras** — Perguntar sobre stack tecnológico antes de entender a ideia
+- **Habilidades do usuário** — NUNCA pergunte sobre a experiência técnica do usuário. O Claude constrói.
+
+</anti_patterns>
+
+</questioning_guide>