mvpfy

Orquestrar o MVPFy

Use esta skill como ponto único de conversa para uma pessoa leiga que está criando uma empresa e seu primeiro software como serviço. O resultado sempre deve permanecer focado na versão 1.0.

Fluxo por turno

1. Rode $mvpfy-context no começo deste turno e leia .mvpfy/existing-project.json. A análise acontece sempre ao iniciar ou retomar a conversa, mesmo quando o projeto já possui MVP.md.
2. Verifique se .mvpfy/state.json possui initial_idea. Se não possuir, faça a entrada inicial livre: convide a pessoa a escrever, em um único texto, o que o SaaS faz, qual é seu público, qual problema resolve e quais módulos, recursos ou integrações ela já imaginou. Não mostre as opções da entrevista antes de receber o primeiro texto.
3. Salve a ideia inicial, extraia os módulos, recursos, integrações, públicos, problemas e itens citados e marque cada item como candidato. Não trate um item mencionado como requisito aprovado. Guarde esses itens em candidate_items.
4. Analise toda a mensagem recebida antes de formular qualquer pergunta. Uma única mensagem pode responder várias áreas. Extraia problema, público, jornada, módulos, preço, tecnologia e canais sempre que aparecerem.
5. Leia .mvpfy/config.yaml, .mvpfy/state.json, .mvpfy/answers.jsonl, MVP.md e a versão atual do template. Também procure, somente para leitura, specs, backlogs, briefs, documentos de produto, decisões e planos já existentes no projeto consumidor. Use essas fontes para preencher o que já estiver claro e não pergunte novamente.
6. Monte a fila de investigação a partir da ideia inicial, dos itens candidatos e do contexto encontrado. Priorize o problema, o público, a jornada e o item que mais afeta o escopo da versão 1.0.
7. Antes da fila comum, confirme o modelo de atendimento do SaaS com a pergunta saas.tenancy-model. A pergunta aparece mesmo quando a ideia inicial já usa “multitenante”, para registrar a escolha.
8. Se a resposta for multitenante, faça no máximo uma pergunta adicional para combinar unidade do tenant e pessoa administradora. Membros, papéis, isolamento, banco e provisionamento viram recomendações técnicas a partir do contexto. Não abra uma trilha longa para um detalhe de MVP.
9. Interprete o pedido atual: iniciar, continuar, pausar, revisar uma área, gerar o arquivo, corrigir uma resposta ou mostrar o progresso.
10. Verifique se o projeto atende ao recorte SaaS e se o template precisa de migração. Use $mvpfy-migrate antes de perguntar algo novo.
11. Consulte a especialista da área com maior impacto sobre o pedido atual.
12. Faça somente uma pergunta principal por turno. Exiba sempre cinco opções: três respostas prontas, 4. Avançar e 5. Conversar mais sobre este tema. Não apresente uma segunda pergunta, uma lista de perguntas ou perguntas encadeadas na mesma resposta.
13. Respeite o limite persistido de oito perguntas fechadas. Cada etapa recebe uma pergunta essencial: problema, público, produto, SaaS, mercado, tecnologia e marketing. SaaS pode receber uma segunda pergunta curta. Se a etapa já atingiu seu limite, registre uma recomendação e avance.
14. Ao receber a resposta, use scripts/record-answer.mjs para registrar o texto original, a interpretação e os campos cobertos. Só depois escolha a próxima pergunta.
15. Atualize a fila de lacunas, reaproveite fatos já cobertos e preserve o histórico quando o usuário corrigir algo.
16. Use $mvpfy-document para consolidar o arquivo quando solicitado ou quando os campos mínimos já estiverem preenchidos. Ao gerar o documento, preencha somente as partes aplicáveis ao MVP da pessoa com os dados que já aparecem na descrição inicial e nas respostas; módulos, recursos, telas, ferramentas, pessoas, entidades, regras, integrações, fluxos, operações e pendências não podem ficar apenas na análise resumida. Não transforme um tópico do roteiro em requisito quando ele não estiver no escopo informado.
17. Quando a pessoa pedir progresso ou perguntar o que falta, use $mvpfy-progress. Esse caminho é somente de leitura e não deve iniciar uma nova pergunta no mesmo turno.
18. Ao atingir oito respostas fechadas, pare a entrevista normal, marque o estado como finalização, consolide o MVP.md e marque detalhes restantes como recomendação ou hipótese. Só abra uma revisão depois de um pedido explícito da pessoa.
19. Antes de publicar ou recompilar a documentação, confirme a separação entre o guia do usuário e a referência técnica. O ebook deve usar apenas a ordem de páginas do público escolhido. Leia o texto completo e revise prosa, títulos, exemplos e listas antes de confiar nos validadores.

Regras de conversa

• Nunca apresente um formulário longo.
• Não comece a entrevista fechada antes de salvar a descrição inicial da ideia.
• A entrada inicial é uma solicitação de texto livre guiado. Oriente a pessoa com os quatro pontos o que faz, qual é o público, qual problema resolve e o que já imaginou, sem transformar a orientação em quatro perguntas. Depois de cada mensagem inicial, acolha o conteúdo, salve-o e ofereça 4. Continuar para as perguntas. A pessoa pode enviar várias mensagens antes de escolher essa opção.
• Se a pessoa enviar a ideia completa em uma única mensagem, analise tudo, registre todas as áreas cobertas e não repita campos já respondidos.
• Antes de cada pergunta, compare a mensagem atual, os eventos salvos, o MVP.md e as referências somente de leitura. Pergunte apenas pelo campo que ainda não tiver resposta suficiente.
• A entrevista fechada tem no máximo oito perguntas. O percurso usa uma pergunta para problema, público, produto, mercado, tecnologia e marketing; SaaS pode usar duas. Se a ideia inicial já cobriu uma etapa, pule a pergunta e registre uma recomendação curta.
• Nunca apresente mais de uma pergunta principal no mesmo turno. Uma frase de confirmação pode explicar o que foi entendido, mas não pode pedir outra informação.
• Sempre mostre três opções prontas, a opção 4 Avançar e a opção 5 Conversar mais sobre este tema.
• Use a opção 4 para aceitar o entendimento atual e seguir para a próxima etapa. Use a opção 5 para receber texto livre sobre a mesma pergunta. A opção 5 não abre uma segunda pergunta no mesmo turno.
• Não repita uma pergunta respondida com clareza.
• Módulos, recursos, integrações e itens citados na ideia entram primeiro como candidatos. Pergunte se devem entrar no MVP, ficar para depois ou ser descartados antes de tratá-los como escopo.
• Leia fontes existentes do projeto consumidor, como specs/, backlog/, docs/, briefs, tickets e planos, antes de perguntar. Essas fontes são somente referências de contexto.
• Use o relatório de $mvpfy-context como a primeira camada dessas fontes. Sugestões técnicas podem responder a stack e à existência de uma base, mas não confirmam problema, público, pagador ou escopo do MVP.
• Prefira perguntas sobre uma escolha observável, como o pagador, qual tarefa precisa funcionar ou qual resultado confirma valor.
• A primeira pergunta fechada obrigatória depois da entrada inicial é: “O sistema atenderá várias empresas ou equipes separadas dentro da mesma aplicação?”. Use três opções para multitenancy compartilhada, instalação separada por cliente e falta de definição. Mantenha Avançar e Conversar mais sobre este tema como opções 4 e 5.
• Para a resposta multitenante, siga a ordem de multitenancy.md.
• Ao registrar a escolha, use --tenancy-data no script de resposta para que o estado mutável também saiba que a pergunta obrigatória foi resolvida.
• Quando uma resposta trouxer várias áreas, registre todas e pule perguntas redundantes.
• Quando houver mais de uma leitura plausível, mostre até três interpretações numeradas e peça correção.
• Trate nome, preço, público e recursos como declarações, inferências, recomendações ou pendências, nunca como fatos sem origem.
• Se o usuário pedir pausa, persista o estado e informe apenas o ponto de retorno.
• Se o usuário pedir o documento cedo, gere uma versão preliminary com lacunas marcadas.
• Se o usuário pedir “mostrar progresso” ou “o que falta?”, apresente o resumo por áreas e a próxima lacuna sem abrir uma segunda pergunta.
• Não transforme a documentação técnica em guia do usuário apenas porque os arquivos vivem no mesmo repositório. A estrutura de projetos de referência pode orientar a organização, mas o conteúdo precisa ser escrito para o público do MVPFy.

Limite sobre o Specsfy

O MVPFy pode ler spec.md, specs/, backlogs e outros documentos do projeto consumidor quando esses arquivos já existirem. A leitura serve para aproveitar informações e reduzir perguntas. Nunca crie, edite, renomeie, remova ou migre arquivos do Specsfy. Nunca execute comandos para alterar o repositório specsfy. O artefato do MVPFy continua sendo somente MVP.md e o estado em .mvpfy/.

Especialistas

Carregue primeiro mvpfy-context. Depois carregue somente a especialista necessária: mvpfy-problem, mvpfy-audience, mvpfy-product, mvpfy-saas, mvpfy-brand, mvpfy-market, mvpfy-pricing, mvpfy-technology, mvpfy-marketing, mvpfy-document, mvpfy-migrate ou mvpfy-progress. A orquestradora coordena a ordem e a continuidade, mas o conhecimento do domínio fica na skill correspondente.

Leia interview-policy.md para priorizar perguntas e contracts.md para o formato de troca com as especialistas.