Files

134 lines
4.4 KiB
Markdown

---
name: start
description: Orquestrador do pipeline de trabalho novo — brainstorm → discover → spec → plan → execute. Use quando iniciar sistema novo, feature grande, ou projecto com múltiplos componentes. Impede saltar para execução sem planeamento.
---
# /start — Pipeline de trabalho novo
Orquestra as 5 fases obrigatórias para qualquer trabalho novo não-trivial.
Anti-pattern que combate: saltar directamente para código sem brainstorm/spec/plan.
---
## Quando usar
**USAR quando:**
- Utilizador pede sistema/pipeline/feature nova com >2 componentes
- Trabalho estimado >1h ou >3 ficheiros
- Projecto novo em `05-Projectos/` ou `Dev/`
- Qualquer tarefa em que a abordagem não está obviamente definida
**NÃO usar quando:**
- Bugfix / correcção pontual
- Operação unitária conhecida
- Continuação de plano já existente
- Admin / manutenção / diagnóstico
---
## Protocolo (5 fases sequenciais)
### Fase 1 — Brainstorming (obrigatório)
Invocar `superpowers:brainstorming` skill OU `project-manager:brainstorm` skill.
Objectivos:
- Explorar 3+ abordagens alternativas
- Identificar requisitos explícitos e implícitos
- Listar trade-offs conhecidos
- Detectar ambiguidades que precisam de clarificação do utilizador
Output: secção "Brainstorming" com alternativas consideradas.
### Fase 2 — Discover / Research (obrigatório)
Invocar `project-manager:discover` skill.
Verificar em paralelo:
- **Codebase actual** — existem componentes reutilizáveis? Glob + Grep
- **NotebookLM** — há notebook relevante? `mcp__notebooklm-mcp__notebook_list` + query
- **Hub** — procedimentos, QRs, decisões anteriores? Grep em `Hub/06-Operacoes/`
- **Memórias** — contexto de sessões anteriores? `mcp__mem0__search_memories`
- **Web** (se externo) — context7, WebSearch para libs/frameworks
- **Desk CRM** — tarefa associada? Projecto relacionado?
Output: secção "Discovery" com fontes consultadas e descobertas relevantes.
### Fase 3 — SPEC (obrigatório)
Invocar `gestao:spec-coauthor` OU `project-manager:spec` (skill `spec create`).
Gerar `SPEC.md` no directório do projecto (Hub/05-Projectos/NOME/ ou Dev/NOME/) com:
- **Porquê** — problema que resolve
- **Escopo** — o que entra
- **Não-escopo** — o que NÃO entra (crítico contra scope creep)
- **Critérios de sucesso** — como saber que está pronto
- **Arquitectura** — diagrama ou descrição dos componentes
- **Riscos** — o que pode correr mal
- **Plano faseado** — divisão em MVPs
Aguardar aprovação do utilizador. Marcar como aprovado com `<!-- APPROVED: YYYY-MM-DD -->` no topo.
### Fase 4 — Plan detalhado (obrigatório)
Invocar `superpowers:writing-plans` skill.
Traduzir SPEC em plano executável:
- Lista numerada de passos concretos
- Cada passo tem: acção, comando/código esperado, critério de validação
- Ordem de execução e dependências
- Checkpoints de revisão humana
Guardar em `Hub/05-Projectos/NOME/PLAN.md` ou `.claude/plans/NOME.md`.
### Fase 5 — Execução (finalmente)
Invocar `superpowers:executing-plans` ou `superpowers:subagent-driven-development`.
Durante execução:
- Seguir PLAN.md passo a passo
- Marcar progresso em TodoWrite
- Validar cada passo antes do seguinte
- Comentar no Desk CRM task associada
- Se desviar do spec → parar e actualizar SPEC.md primeiro (scope creep alert)
---
## Output esperado da skill
Ao invocar `/start "descrição do trabalho"`:
```
/start detectou novo trabalho: "descrição"
Fase actual: 1 — Brainstorming
Próxima: Discovery
[invoca brainstorming skill automaticamente]
```
Skill não salta fases. Se utilizador insistir em saltar, avisa mas aceita override explícito (`/start --skip-to=execute`).
---
## Anti-patterns
- **NUNCA** começar Fase 5 (execução) sem Fases 1-4 completas
- **NUNCA** criar código antes de SPEC.md aprovado
- **NUNCA** inventar decisões arquitecturais sem brainstorming documentado
- **NUNCA** tratar "pareceu boa ideia" como substituto de discovery
- **SEMPRE** criar SPEC.md no repositório do projecto (não em `/tmp` ou inline)
- **SEMPRE** aguardar aprovação explícita entre fases críticas
---
## Integração com spec-gate.sh
O hook `spec-gate.sh` (PreToolUse Write|Edit) valida que existe SPEC.md aprovado antes de permitir edições em `/Dev`. Esta skill garante que esse SPEC é criado via pipeline correcto antes de chegar à execução.
Para bypass temporário (quick fixes, 30min): `/spec bypass`.
---
*Skill v1.0.0 | 2026-04-08 | Descomplicar®*