---
name: construtor-imperatriz
description: >
  Meta-skill de build autônomo com guardrails. Escaneia o projeto atual,
  propõe escopo explícito (o que VAI e o que NÃO VAI ser tocado), define
  critério de sucesso verificável, seleciona as skills do ecossistema mais
  relevantes, ativa /goal com critério de escopo embutido, e executa com
  /loop até concluir. Verifica o diff antes de encerrar para garantir que
  nada fora do escopo foi alterado. Use quando o usuário pedir "modo
  autônomo", "constrói X sem me chamar", "piloto automático", "ativa o
  construtor", "executa a fase X sem interrupção", "usa /goal e /loop pra
  construir", ou qualquer build longo onde quer autonomia com segurança.
  NÃO use para tarefas simples de uma etapa — o overhead não compensa.
---

# Construtor Imperatriz

Meta-skill que monta o cockpit antes de executar: escopo declarado, critério de sucesso definido, skills certas na ordem certa, loop travado no objetivo.

## Filosofia

Três contratos não-negociáveis:
1. **Plano antes de código** — zero execução sem escopo aprovado
2. **Escopo é lei** — o diff final precisa bater com o que foi declarado
3. **Promessas honestas** — o construtor não garante 100% de autonomia; garante máxima autonomia dentro dos guardrails

## Workflow (6 fases)

### FASE 1 — ESCANEAR (executa antes de qualquer resposta)

```bash
# Rodar em paralelo:
cat package.json 2>/dev/null || cat pyproject.toml 2>/dev/null || echo "sem manifest"
git log --oneline -5 2>/dev/null || echo "sem git"
ls -la
cat CLAUDE.md 2>/dev/null || echo "sem CLAUDE.md"
```

Identificar: linguagem, framework, fase/fatia atual do projeto, último commit.

### FASE 2 — PROPOR ESCOPO + CRITÉRIO

Criar `.build-scope.md` na raiz do projeto com:

```markdown
# Escopo desta execução
**Tarefa:** [o que foi pedido]
**Data:** [hoje]

## ✅ Será tocado
- [lista de arquivos/pastas específicos]

## ❌ NÃO será tocado
- [tudo o que está fora — explícito]

## 🏁 Critério de sucesso
1. [item verificável 1]
2. [item verificável 2 — máx 3 itens]

## ⚠️ Riscos identificados
- [qualquer gotcha conhecido do projeto]
```

**Apresentar o escopo e aguardar aprovação.** O usuário pode editar antes de confirmar. Só avança com "pode ir", "aprovado", "vai", ou equivalente.

### FASE 3 — SELECIONAR SKILLS

Consultar `references/skill-map.md` e listar as 2-4 skills mais relevantes para a tarefa e em que ordem serão usadas. Apresentar junto com o escopo na Fase 2.

### FASE 4 — ATIVAR /goal

Após aprovação, ativar com critério que inclui verificação de escopo:

```
/goal [critério de sucesso da tarefa] E zero diff fora dos arquivos declarados em .build-scope.md
```

### FASE 5 — EXECUTAR COM /loop

Ativar `/loop` com intervalo adequado:
- Build/código: sem intervalo (iteração contínua)
- Deploy/VPS: `2m` (aguarda propagação)
- Testes pesados: `1m`

Consultar `references/guardrails.md` antes de cada operação destrutiva.

### FASE 6 — VERIFICAR ESCOPO (antes de encerrar)

```bash
git diff --name-only HEAD 2>/dev/null || git status --short
```

Comparar arquivos alterados contra `.build-scope.md`.

- **Todos dentro do escopo** → encerra, remove `.build-scope.md`, reporta sucesso
- **Algum fora do escopo** → parar, listar os arquivos divergentes, pedir instrução antes de continuar

## Regras duras

1. **Nunca executa sem escopo aprovado** — mesmo que o usuário insista em pular a Fase 2
2. **Nunca toca arquivo fora do escopo** — se precisar de um arquivo não listado, pausa e pergunta
3. **Operações da lista de guardrails sempre pedem confirmação** — ver `references/guardrails.md`
4. **Não refatora código adjacente** — se viu algo "melhorável" fora do escopo, registra no `.build-scope.md` como "observação" mas não toca
5. **Drift de escopo requer re-aprovação** — se a tarefa cresceu, volta à Fase 2 com escopo atualizado

## Quando a obra é grande demais pra uma execução

Esta skill executa **uma tarefa** com escopo aprovado. Quando a tarefa é na verdade uma reforma arquitetural inteira (3+ fatias, decisões de design ainda em aberto), o escopo não deveria nascer aqui — deveria nascer de um diagnóstico.

Nesse caso use `/obra-imperatriz`: ela chama o `arquiteto-imperatriz` pra projetar as fatias (com critério de aceite e arquivos permitidos já definidos por padrão arquitetural), leva pra aprovação da Tata, e dispara **um subagente `construtor-imperatriz` por fatia** — rodando em paralelo quando não há dependência. No fim, o arquiteto vistoria o que foi levantado.

O subagente `construtor-imperatriz` segue exatamente as regras desta skill, com uma diferença: como ele não tem canal pra perguntar nada, ao esbarrar num guardrail ou precisar de arquivo fora do escopo ele **para e devolve BLOQUEIO** — quem leva pra Tata é o orquestrador.

## Arquivos de referência

- `references/guardrails.md` — operações que sempre exigem confirmação vs. auto-aprovadas
- `references/skill-map.md` — qual skill usar em cada tipo de tarefa
