Not-a-Vibe-Coder

Uma habilidade que transforma qualquer ideia de projeto — por mais vaga que seja — em 8 documentos de planejamento vivos que atuam como a memória persistente do projeto em uma janela de contexto longa. Os documentos são a fonte da verdade para "o que combinamos"; as instruções ao vivo do usuário são sempre a autoridade final e podem substituir os documentos a qualquer momento.

Quando Usar

• Use esta habilidade quando a tarefa corresponder a esta descrição: Transforma prompts vagos em 8 arquivos de planejamento estruturados para projetos totalmente novos. NÃO use em bases de código existentes.

Princípios Fundamentais (nunca viole estes)

1. Comando do usuário > arquivos > suposições da IA. Se o usuário disser algo que contradiz um arquivo, o usuário vence — e o(s) arquivo(s) relevante(s) devem ser atualizados para refletir a nova instrução.
2. Sem adições silenciosas. Nunca adicione recursos, escolhas de tecnologia, páginas, tabelas ou regras que o usuário não pediu ou aprovou. Se algo parecer faltando, pergunte — não assuma. Exceção: quando o usuário explicitamente diz "preencha", "faça um brainstorming do resto", "você decide", etc. — veja a Fase 3.
3. Design.md é especial. NUNCA preencha Design.md com seu próprio gosto. Sempre pergunte ao usuário a direção do estilo (por exemplo, minimalista, divertido, corporativo, modo escuro, neumórfico, etc.) e uma paleta de cores (ou ofereça 2-3 opções de paleta para escolher) antes de escrever qualquer coisa nele.
4. Um arquivo por vez, na ordem, durante o planejamento inicial — não despeje todos os 8 arquivos de uma vez, a menos que o usuário peça explicitamente isso.
5. Tracker.md é rastreamento de progresso apenas para adicionar — atualize-o sempre que o trabalho for concluído, nunca reescreva o histórico, apenas marque os itens e adicione novos à medida que surgem.
6. Mudanças no meio do projeto causam repercussões. Se o usuário solicitar uma mudança no meio da construção que afete decisões anteriores (por exemplo, "na verdade, vamos usar Postgres em vez de Firebase", "adicione um recurso de reserva"), atualize TODOS os arquivos afetados você mesmo, sem ser solicitado arquivo por arquivo. Em seguida, resuma o que mudou.
7. Leia antes de escrever. No início de qualquer sessão, se esses arquivos já existirem no projeto, leia todos os 8 antes de fazer qualquer outra coisa — eles são sua memória.

Os 8 Arquivos

Fluxo de Trabalho

Fase 0 — Detectar intenção

• APENAS para projetos totalmente novos. Se o projeto tiver arquivos de código existentes, ABORTE e não use esta habilidade.
• Se o usuário der uma ideia de uma linha ("crie um aplicativo de pedidos de restaurante para mim") para um novo projeto, este é o gatilho para iniciar a Fase 1.
• Se o usuário já fornecer uma especificação completa, você ainda pode criar os arquivos, mas preenchê-los diretamente com o que eles disseram — pule perguntas redundantes.

Fase 1 — PRD.md primeiro

Esta é a base. Tudo o mais depende disso.

• Pegue o que quer que o usuário tenha dado a você (mesmo que seja apenas "aplicativo de restaurante") e faça um pequeno número de perguntas esclarecedoras para detalhar o PRD — público-alvo, recursos principais, plataformas (web/mobile/ambos), itens essenciais vs. desejáveis, monetização se houver, etc. Use ask_user_input_v0 para esclarecimentos rápidos de múltipla escolha onde for natural.
• O usuário também pode optar por pular Q&A e escrever diretamente no PRD.md sozinho — se ele disser "eu vou preencher", crie um esqueleto de PRD.md com cabeçalhos de seção e placeholders, e espere por ele.
• Não invente recursos. Se a resposta do usuário for vaga, pergunte novamente ou ofereça opções — não preencha lacunas com suposições.
• Assim que o PRD parecer sólido, escreva PRD.md, mostre ao usuário e obtenha confirmação antes de passar para o próximo arquivo.

Fase 2 — Arquivos restantes, um por um (exceto Design.md)

Nesta ordem: TechSpec.md → AppFlow.md → Schema.md → ImplementationPlan.md → Rules.md → Tracker.md → Design.md (por último, veja Fase 2.5).

Para cada arquivo:

• Proponha um rascunho baseado no PRD e em quaisquer arquivos anteriores, OU faça perguntas ao usuário se houver uma decisão real a ser tomada (por exemplo, "Este deve usar PostgreSQL ou uma opção mais simples como SQLite/Firebase?").
• Mostre o rascunho, peça confirmação ou edições.

…