dev-methodology

Plugin dev-methodology from marketplace matheus-toolkit in matheusa1/matheus-dev-toolkit. Commands read from the repo's manifest — 10 days ago.

Skills (12)

• brainstorming

  Refina um pedido de feature vago ou high-level em uma especificação clara antes de qualquer código ser escrito. Use no início de qualquer tarefa de desenvolvimento nova, quando o pedido for ambíguo, quando faltarem critérios de aceite, ou quando o Matheus disser algo como "quero implementar X" sem d

• casos-de-teste

  Gera os casos de teste (formato Xray manual, CTxx com pré-condição, requisitos CA e passos Ação | Dados | Resultado esperado) a partir da especificação aprovada, sem viés de implementação, incluindo testes de endpoint quando a entrega tem API. Use logo depois que a spec do brainstorming for salva, a

• clean-architecture-scaffold

  Gera o esqueleto de um módulo novo seguindo Clean Architecture + DDD (domain/application/infra), convenções de nomenclatura T/I/E e injeção de dependência com Inversify. Use ao criar um módulo ou feature nova em um projeto TypeScript (NestJS, Next.js, React, React Native). Adapte os mesmos princípio

• code-review-gate

  Revisa o código de uma tarefa recém-concluída contra o plano e as convenções do projeto, classificando problemas por severidade e bloqueando avanço em caso de problema crítico. Use ao final de cada tarefa do plano, antes de marcá-la como concluída ou seguir para a próxima.

• commit-conventions

  Define o padrão de commit do Matheus — Conventional Commits com emoji e escopo = identificador da tarefa extraído da branch (sem prefixo de tipo), mensagem em português. Use sempre que for criar um commit git neste projeto, especialmente ao final de uma tarefa do plano (depois do code-review-gate pa

• convencoes-frontend

  Convenções de código para frontend (React) — implementação mobile first obrigatória (layout base para telas pequenas, breakpoints maiores só como exceção via min-width), escopo de teste unitário, preferência pelos componentes do design system em vez de elementos HTML crus, tokens de tema em vez de v

• debugging-sistematico

  Investiga um bug ou comportamento inesperado relatado pelo usuário de forma sistemática — reproduzir, coletar evidência, formular e testar hipóteses, isolar a causa raiz — antes de qualquer correção. Use sempre que o Matheus relatar "isso não está funcionando", um erro, um comportamento inesperado,

• documentacao-implementacao

  Gera a documentação final de uma implementação concluída — um arquivo markdown no formato padrão do Matheus (ticket, detalhes do back e do web, contratos, rotas, impacto), escrito a partir do diff real da branch. Etapa obrigatória no fim de toda implementação do fluxo de `using-dev-methodology`: na

• regras-de-codigo

  Regras de código que valem para todo desenvolvimento do Matheus (idioma, SOLID, vizinho legado, limite de 150 linhas por arquivo e 20 por função) com a severidade de cada uma no review, e os comandos para obter o diff de uma tarefa ou da branch. Use antes de escrever, refatorar ou revisar qualquer c

• test-driven-development

  Força o ciclo RED-GREEN-REFACTOR ao implementar qualquer lógica de negócio nova. Use sempre que for implementar uma tarefa do plano, corrigir um bug com lógica testável, ou escrever qualquer função/caso de uso novo.

• using-dev-methodology

  Explica a metodologia de desenvolvimento pessoal do Matheus e a ordem em que as outras skills deste plugin devem ser usadas. É o padrão para QUALQUER tarefa de desenvolvimento (implementar, corrigir, refatorar, revisar, commitar) neste projeto — consulte sempre no início da tarefa, mesmo que o pedid

• writing-plans

  Transforma uma especificação já aprovada em um plano de implementação dividido em tarefas pequenas, ordenadas e testáveis. Use depois da skill brainstorming e antes de escrever qualquer código de implementação.

Subagents (9)

• executor-casos-teste

  Executa os casos de teste (CTxx) salvos em docs/casos-teste/ contra a aplicação rodando — endpoints via HTTP e telas via navegador — e registra passou/falhou por CT, com os passos que falharam, marcando divergências. Use no fim da implementação, depois do code review de todas as tarefas e da conform

• gerador-modulo

  Gera o esqueleto de um módulo novo seguindo Clean Architecture + DDD (domain/application/infra), convenções T/I/E e injeção de dependência com Inversify. Use ao criar um módulo ou feature nova em um projeto TypeScript.

• implementador-frontend

  Implementa uma tarefa de tela/componente de apresentação frontend (React), sem ciclo de TDD, seguindo as convenções de frontend do projeto. Use no lugar do parceiro-tdd quando a tarefa do plano for puramente de UI (components/, pages/, JSX que só renderiza), sem lógica de negócio própria.

• investigador-bugs

  Investiga de forma sistemática um bug ou comportamento inesperado relatado pelo usuário — reproduz, coleta evidência, testa hipóteses e isola a causa raiz antes de sugerir qualquer correção. Use quando o Matheus relatar um problema e quiser a investigação isolada do contexto principal, sem já sair e

• parceiro-tdd

  Implementa uma tarefa específica do plano seguindo RED-GREEN-REFACTOR de forma disciplinada, um passo de cada vez. Use quando quiser delegar a implementação de uma tarefa isolada mantendo o ciclo de TDD estrito. Para telas/componentes de apresentação frontend, use o agent implementador-frontend em v

• revisor-acessibilidade

  Revisor read-only especializado em acessibilidade (semântica, teclado, leitor de tela, contraste, WCAG 2.2 AA) do diff de uma tarefa. Use proativamente, em paralelo com o revisor-arquiteto, SOMENTE quando o diff da tarefa altera interface de frontend (ver "Diff de UI" em using-dev-methodology) — nun

• revisor-arquiteto

  Revisor de código read-only especializado em Clean Architecture, DDD, convenções de nomenclatura (T/I/E) e injeção de dependência. Use proativamente depois que uma tarefa do plano é implementada, para revisar o diff antes de seguir para a próxima tarefa.

• revisor-conformidade

  Revisor read-only que compara o código implementado com o arquivo de especificação salvo em docs/especificacao/. Use proativamente ao final da implementação de todas as tarefas do plano, antes de considerar a feature pronta.

• revisor-responsividade

  Revisor read-only especializado em responsividade e mobile first (breakpoints, overflow, toque, telas estreitas e largas) do diff de uma tarefa. Use proativamente, em paralelo com o revisor-arquiteto, SOMENTE quando o diff da tarefa altera interface de frontend (ver "Diff de UI" em using-dev-methodo

Hooks (2)

• SessionStart

  cat

• UserPromptSubmit

  cat

Similar plugins