dev-workflow

dev-workflow — Orquestrador de Desenvolvimento (fusao Power-DevSuperPlan)

Esta skill coordena o ciclo de ponta a ponta. Ela NAO implementa diretamente: cada fase delega a uma skill especializada ou a um subagent. Anuncie a fase atual ao Murilo conforme avanca.

Fase 0 — Bootstrap Obrigatorio (NUNCA pular)

1. Chamar brain-get-context (MCP Second Brain) → carrega CLAUDE.md + MEMORY.md do vault.
2. Ler memorias relevantes: memory/user.md, memory/preferences.md, memory/decisions.md, memory/people.md, memory/AGENTS.md.
3. Se houver projeto existente → ler projects/[NOME]/ (incluindo CLAUDE.md e structure.md).
4. Verificar daily note de hoje (daily/YYYY-MM-DD.md) — carregar se existir.

Se o Second Brain estiver inacessivel, avisar o Murilo e prosseguir com o contexto disponivel.

Fase 1 — Interpretacao + Artefatos de Projeto

Classifique a sessao:

Situacao	Acao
Feature nova em projeto existente	Ler projects/[NOME]/ → Fase 2
Projeto novo do zero	Criar projects/[NOME]/ + artefatos (abaixo) → Fase 2
Continuacao de sprint	Ler projects/[NOME]/sprints/ → retomar ultima task
Hotfix Minecraft emergencial	Ver "Hotfix Emergencial" no final

Artefatos de projeto (obrigatorios ao criar/analisar projeto): garantir a existencia de CLAUDE.md e structure.md, espelhados em DOIS locais:

• No vault: projects/[NOME]/CLAUDE.md e projects/[NOME]/structure.md
• No repo de codigo: CLAUDE.md e structure.md na raiz do repositorio

Use os templates em references/project-claude-template.md e references/structure-template.md.

• Projeto ja existe → ler os artefatos; atualizar se desatualizados.
• Projeto novo → criar os dois em ambos os locais.
• CLAUDE.md = contexto/visao (fonte de verdade). structure.md = arvore do codigo-fonte (regeneravel).

No maximo 2 perguntas de esclarecimento se o prompt for ambiguo; caso contrario, inferir do vault.

Fase 2 — Spec (composicao brainstorming + tlc-spec-driven)

Nenhum codigo sem spec aprovado pelo Murilo.

A Fase 2 compoe duas skills: brainstorming (exploracao de intencao/design) e tlc-spec-driven (montagem do spec e tasks atomicas rastreaveis).

Passo a passo:

1. Invocar brainstorming para alinhar intencao, requisitos, restricoes e criterios de sucesso.
2. Invocar tlc-spec-driven com o trigger correto (tabela abaixo) para gerar o spec em .specs/.
3. Apresentar o spec ao Murilo e aguardar aprovacao explicita antes da Fase 3.

Triggers da tlc-spec-driven (escolha conforme a situacao):

Situacao	Trigger a usar	Saida
Projeto novo do zero	"Initialize project"	.specs/project/PROJECT.md + ROADMAP.md
Codebase existente (plugin baixado)	"Map codebase"	.specs/codebase/ (STACK, ARCHITECTURE, CONVENTIONS...)
Feature nova	"Specify feature: [descricao]"	.specs/features/[feature]/spec.md
Ambiguidade / dominio novo	"Discuss feature: [descricao]"	spec.md + context.md (gray areas)
Continuacao de sprint	"Resume work"	carrega HANDOFF.md + STATE.md
Fix pontual (<=3 arquivos)	"Quick fix: [descricao]"	quick mode direto, sem pipeline

Auto-dimensionamento (a tlc-spec-driven se ajusta sozinha — nao forcar o pipeline completo):

Escopo	O que a skill gera
Bug simples / mudanca <=3 arquivos	Quick mode — implementa direto
Feature clara, <10 tasks	spec.md resumido → Execute (design e tasks inline)
Feature multi-componente	spec.md → design.md → tasks.md → Execute

Apos a tlc-spec-driven gerar o spec, apresentar ao Murilo e so avancar com aprovacao.

Fase 3 — Scrum: separacao de sprints

Invocar o subagent scrum-master (ou a skill scrum-master) para:

• Quebrar em epicos → historias → sprints (reaproveitando tasks.md se ja existir).
• Estimar esforco, definir Definition of Done, priorizar backlog.
• Duracao padrao: 1 semana (AusTV/plugins) | 2 semanas (TCC/academico).

Regra critica: 1 PR = 1 responsabilidade logica, funcional e deployavel por si so. Salvar em projects/[NOME]/sprints/.

Fase 4 — Desenvolvimento com subagents + skills

1. Isolar o trabalho com a skill using-git-worktrees (um worktree por feature/fix). O worktree e SEMPRE criado em .claude/.worktrees/<branch> na raiz do projeto (garantir que esteja no .gitignore).
2. Executar as tasks com a skill executing-plans (ou subagent-driven-development).
3. Acionar o subagent de stack adequado:

Stack	Subagent nativo
Plugin Minecraft (Java/Spigot)	gamedev-plugin-specialist + backend-specialist
API NestJS / TypeScript	backend-specialist
Spring Boot	backend-specialist
Angular / React / Next.js	frontend-specialist
PostgreSQL / schema	database-specialist
CI/CD / Docker / Nginx	devops-specialist
Documentacao	documentation-specialist

Commits em Conventional Commits. Jamais alterar main, dev ou prod diretamente.

Fase 5 — Qualidade e Seguranca (bloqueiam o merge)

Fornecer sempre contexto completo (spec + regras de negocio + codigo integral), nunca snippets.

Verificacao	Como
Testes (unit/integ/edge/regressao)	skill test-driven-development
Code review (qualidade, Google Style)	skill requesting-code-review + subagent code-reviewer
Seguranca (OWASP, IDOR, secrets, JWT)	subagent cybersecurity-validator
Verificacao final antes de "pronto"	skill verification-before-completion

Escalonamento: media/baixa → merge com ressalva documentada (Murilo aprova) | critica → bloqueio total. Ao receber feedback de review, usar a skill receiving-code-review.

Fase 6 — Entrega e Registro

1. Finalizar a branch com a skill finishing-a-development-branch (merge/PR/cleanup do worktree).
2. Atualizar o vault via MCP: decisoes → memory/decisions.md; pessoas → memory/people.md; resumo → daily/YYYY-MM-DD.md. Atualizar projects/[NOME]/structure.md se a arquitetura mudou.
3. Mover para archive/ se o projeto foi concluido.

Hotfix Emergencial — Minecraft (unica excecao)

Exclusivo para bug critico derrubando o servidor AusTV com jogadores ativos: fix direto no servidor → documentar em daily/YYYY-MM-DD.md → abrir issue (org austv-minecraft) → na proxima sprint formalizar via branch fix/ e fluxo completo. Permitido apenas no servidor Minecraft de producao; proibido em NestJS/Spring/frontend/banco.

Mapa de Skills — qual skill em qual momento

Tabela de decisao. Quando o gatilho ocorrer, invocar a skill correspondente (todas vendorizadas no proprio plugin). Skills de processo tem prioridade sobre as de execucao.

Gatilho / momento	Skill a invocar	Fase tipica
Inicio de qualquer trabalho criativo (feature, componente, comportamento novo)	brainstorming	2
Montar/aprimorar spec de projeto ou feature; mapear codebase existente	tlc-spec-driven	2
Transformar um spec aprovado num plano de implementacao passo a passo	writing-plans	3-4
Bug, teste falhando ou comportamento inesperado (antes de propor fix)	systematic-debugging	qualquer
Implementar qualquer feature ou bugfix (escrever codigo)	test-driven-development	4
Precisa isolar o workspace para uma feature/fix	using-git-worktrees	4
Executar um plano escrito, em sessao separada, com checkpoints	executing-plans	4
Executar um plano com tasks independentes, na mesma sessao	subagent-driven-development	4
2+ tarefas independentes que podem rodar em paralelo	dispatching-parallel-agents	4
Concluiu uma feature/task; antes de mergear — pedir review	requesting-code-review	5
Recebeu feedback de review (antes de aplicar sugestoes)	receiving-code-review	5
Prestes a afirmar "pronto / funciona / passa" (antes de commit/PR)	verification-before-completion	5-6
Implementacao completa; decidir merge / PR / cleanup da branch	finishing-a-development-branch	6
Criar, editar ou validar uma skill	writing-skills	meta

Regra de ouro: na duvida entre duas skills, rode primeiro a de processo (brainstorming, systematic-debugging) — ela determina COMO abordar a tarefa.

Convencoes sempre aplicadas

Codigo em ingles; comunicacao em portugues; Google Style Guide; timezone America/Sao_Paulo; datas YYYY-MM-DD; vault AusTV em projects/AUSTV/; Finance MCP sempre com data explicita; git worktrees sempre em .claude/.worktrees/<branch> (na raiz do projeto, gitignored).

Referencias

• Detalhes e exemplos: references/workflow-details.md
• Templates de projeto: references/project-claude-template.md, references/structure-template.md