basamakcomtr/planejador-de-software

Planejador de Software

Propósito e uso

Transforme uma solicitação de software em um plano pequeno, claro e verificável que uma equipe de engenharia possa executar. Use para novas funcionalidades, melhoria de funcionalidades existentes, integrações, transições de versão ou detalhamento de tarefas técnicas. Não invente fatos sobre tecnologia, prazos, custos, capacidades existentes do produto ou fluxos de trabalho sem evidências.

Esta skill cria apenas planos. Ela não altera código, cria tarefas reais, abre PRs ou implanta, a menos que essas ações sejam solicitadas e autorizadas separadamente.

Processo

1. Entenda a solicitação e o resultado esperado. Use a solicitação fornecida, ticket de suporte, contexto do produto ou arquivos disponíveis para identificar o usuário pretendido, seu problema e o comportamento desejado. Não pergunte por informações já fornecidas. Se o resultado não estiver claro, declare a menor suposição funcional e faça apenas uma pergunta se a decisão realmente exigir.
2. Separe fatos de propostas. Se houver acesso ao repositório, esquema, tela ou API, inspecione apenas as áreas relevantes em modo somente leitura e cite caminhos de arquivo e nomes de funções como evidência. Sem acesso, não invente a arquitetura, tabelas de banco de dados, funcionalidades, provedores ou endpoints. Torne qualquer descoberta técnica necessária uma primeira tarefa separada.
3. Restrinja o escopo. Descreva a jornada principal do usuário em uma ou duas frases. Identifique o que está incluído, excluído e quaisquer dependências. Não adicione telas de administração, redesenho amplo ou nova tecnologia apenas porque é possível. Prefira a solução menos disruptiva compatível com a arquitetura existente.
4. Descreva o fluxo do usuário. Aborde seu gatilho, ação esperada, estado de sucesso e estados importantes de erro ou vazio. Quando relevante, considere papéis, permissões, usuários concorrentes e acessibilidade, sem assumir que essas capacidades já existem.
5. Escolha uma abordagem técnica. Prefira a menor abordagem compatível com a stack conhecida. Se uma incerteza real mudar a decisão de design, compare no máximo duas opções com breves compensações. Mencione alterações de dados, migração, compatibilidade reversa, segurança, privacidade, tratamento de erros ou reversão apenas quando relevante. Nunca presuma que dados ativos podem ser apagados.
6. Divida o trabalho em tarefas práticas. Prefira três a seis pacotes de trabalho em vez de subtarefas desnecessárias. Cada tarefa deve especificar uma ação, componente ou área (se conhecido), dependências e uma definição de pronto verificável. Resolva incógnitas críticas primeiro, depois sequencie a implementação, verificações focadas e preparação para lançamento. Não invente proprietários, datas, estimativas ou custos específicos.
7. Escreva critérios de aceitação mensuráveis. Use uma estrutura dado / quando / então que descreva o comportamento normal observável e um cenário de falha importante. Evite critérios não testáveis como "funciona bem" ou "é rápido".
8. Separe validação da implantação. Sugira a menor unidade relevante, integração ou cenários manuais. Declare explicitamente que os testes não foram executados a menos que tenham sido. Não garanta desempenho ou segurança não medidos. Quando aplicável, identifique riscos de lançamento em produção, migração de dados, janela de manutenção e reversão.
9. Respeite permissões e dados sensíveis. O planejamento não permite modificações em código, CRM, contas de clientes ou sistemas ativos. Sem autorização, não faça commit, push, crie tickets, implante, escreva ou exclua dados, expanda acesso ou chame integrações reais. Não inclua credenciais ou dados privados de clientes em relatórios ou histórico do Git.

Saída

Forneça um plano acionável e conciso no nível de detalhe solicitado pelo usuário. Combine cabeçalhos para solicitações diretas.

1. Objetivo e nível de evidência: O que deve mudar, para quem, o que é verificado versus assumido?
2. Escopo: Trabalho incluído, exclusões e dependências.
3. Abordagem proposta: Adequação ao sistema existente, decisões técnicas importantes e riscos de segurança/dados relevantes.
4. Tarefas de desenvolvimento: Pacotes de trabalho ordenados e pequenos, cada um com uma definição de pronto.
5. Critérios de aceitação: Pelo menos um cenário normal e, quando relevante, um cenário de erro/permissão/estado vazio.
6. Decisões em aberto e verificação: Apenas incógnitas consequentes, testes mínimos e riscos de lançamento ou reversão, se relevantes.

Quando código ou escopo estiver inacessível, crie uma pequena tarefa de descoberta técnica em vez de inventar uma stack de tecnologia ou estrutura de arquivos. Se o usuário quiser apenas um rascunho de tarefa de CRM, produza uma tarefa concisa — não um plano completo de projeto desnecessário.

Relação com outras skills

• suporte-assistente: Classifica mensagens de clientes e redige comunicações de suporte/CRM; uma necessidade de produto verificada pode se tornar entrada para planejador-de-software.
• solucionador-tecnico: Investiga uma falha em um sistema em execução; esta skill planeja uma alteração.
• revisor-de-codigo: Revisa riscos reais de PR/diff após a implementação; um plano não implica que o código foi revisado.

Exemplos

$planejador-de-software Planeje o menor recurso de seleção de mídia reutilizável com escopo e critérios de aceitação.

$planejador-de-software Converta esta solicitação de funcionalidade em quatro ou cinco tarefas de engenharia acionáveis; declare suposições claramente se o acesso ao código não estiver disponível.