A engenharia 10x.
Lead único, decision tree de roteamento, 5 workflows canônicos, hooks de quality gate, princípios Karpathy. Software como deveria ser feito — não como é normalmente feito.
Princípios fundadores
Lead único é não-negociável
O @engineering-chief é a porta de entrada para TUDO. Análogo ao @theboss do MSE. Sem chief, sem entrega — porque sem chief não tem briefing, triage, review nem delivery padronizados.
Karpathy guidelines aplicados
Think Before Coding (premissas explícitas), Simplicity First (zero abstração especulativa), Surgical Changes (toca só o necessário), Goal-Driven Execution (critério de sucesso verificável antes de loopar).
YAGNI · KISS · DRY
You Aren't Gonna Need It (zero feature pra hipotético futuro). Keep It Simple Stupid (3 linhas similares vence abstração prematura). Don't Repeat Yourself (apenas se o repeat for o MESMO conceito, não a mesma sintaxe).
TDD em features novas
Skill tdd-mastery ativa por padrão. Em features novas, testes primeiro. Em bug fixes, teste que reproduz o bug primeiro. Cobertura mínima 70% — bloco se cair abaixo.
Security-first, não last
Hook secret-scanner HARD FAIL em commit. @security-auditor revisa código sensível ANTES de merge. Threat modeling pra novos endpoints. OWASP top 10 enforcement.
Observability nasce com a feature
Logs estruturados, métricas RED/USE, traces, SLOs definidos. Skill monitoring-observability guia. Alertas acionáveis (zero barulho).
Decision tree de roteamento
O @engineering-chief consulta esta árvore antes de delegar. Cada folha tem agente(s) responsáveis e command associado quando aplicável.
Tarefa de engineering?
├── Incidente prod (P0/P1)? → /incident-triage + incident-responder
├── Deploy? → /deploy-check + deployment-engineer
├── Segurança/auditoria? → /security-audit + security-auditor
├── Performance/lentidão? → /perf-audit + performance-engineer + postgres-pro
├── Refactor/tech debt? → /refactor-pass + code-simplifier + complexity-reducer
├── DB/queries/RLS? → /db-optimize + postgres-pro
├── PR/merge/quality gate? → /code-quality-gate + code-reviewer
├── Decisão complexa/tradeoffs? → ultrathink + brainstormer
├── Validação cruzada? → double-check
├── Cleanup pre-release? → dead-code-finder
├── Feature nova:
│ ├── Next.js 16/App Router/RSC → nextjs-developer
│ ├── Node.js backend → node-specialist
│ ├── Python/FastAPI → fastapi-developer
│ ├── React Native/Expo → expo-react-native-expert
│ ├── JS moderno/tooling → javascript-pro
│ └── Genérico → planner → fullstack-developer
├── Infra:
│ ├── Cloud architecture → cloud-architect
│ ├── Cloudflare/Vercel/AWS → deployment-engineer
│ └── Docker/containers → docker-expert
├── QA:
│ ├── Test strategy → qa-expert
│ ├── Automação → test-automator
│ └── Resiliência/chaos → chaos-engineer
├── AI/LLM:
│ ├── Sistema multi-LLM/RAG → ai-engineer
│ ├── Arquitetura LLM → llm-architect
│ └── Otimização de prompt → prompt-engineer
├── Erro distribuído/correlação → error-detective + error-coordinator
├── Multi-agente paralelo → multi-agent-coordinator + context-manager
└── Síntese cross-agente → knowledge-synthesizer
5 workflows canônicos
WORKFLOW 01
Feature Development
Pipeline: @engineering-chief → @planner → @researcher (paralelo) → specialist → @tester → @code-reviewer (+ @security-auditor se sensível) → @docs-manager → @git-manager.
Quando usar: features novas, mudanças não-triviais, código de produção.
WORKFLOW 02
Incidente Produção (P0/P1)
Pipeline: @incident-responder (lead) → @error-detective + @error-coordinator (paralelo correlação logs) → mitigation imediata → RCA → @journal-writer (postmortem blameless).
Quando usar: sistema fora do ar, alertas P0/P1, perda de dados.
WORKFLOW 03
Performance Audit
Pipeline: /perf-audit → @performance-engineer (CWV, latency, profiling) + @postgres-pro (queries, índices) em paralelo → relatório consolidado → fixes priorizados → re-medição.
Quando usar: latência alta, query lentas, p99 fora do SLO, Core Web Vitals ruim.
WORKFLOW 04
Security Hardening
Pipeline: /security-audit → @security-auditor (OWASP + CVEs + threat model) → fixes → @code-reviewer revalida → re-audit.
Quando usar: antes de release sensível, após incidente de segurança, audit periódico (trimestral).
WORKFLOW 05
Multi-Agent Parallel
Pipeline: @multi-agent-coordinator (orchestrator) → 3+ specialists em paralelo com context-manager → @knowledge-synthesizer agrega findings → @engineering-chief delivery.
Quando usar: tarefas grandes com partes independentes, audits cross-cutting, refactors em múltiplas camadas.
Hooks ativos automaticamente
20 hooks distribuídos em momentos estratégicos. 8 são ativos por padrão; 12 disponíveis pra ativação contextual.
| Hook | Trigger | Severity | O que faz |
|---|---|---|---|
secret-scanner | Pre-commit / Pre-push | HARD FAIL | Bloqueia se detectar API_KEY, SECRET, TOKEN, password hard-coded |
commit-guard | Pre-commit | HARD FAIL | Valida conventional commit (feat/fix/docs/chore/etc) |
type-check | Pós-edit .ts/.tsx | SOFT | tsc --noEmit nos arquivos alterados |
lint-fix | Pós-edit | SOFT | ESLint --fix / ruff format |
auto-test | Pós-edit src/ | SOFT | Roda testes relevantes ao diff |
prompt-check | UserPromptSubmit | SOFT | Detecta prompts vagos e pede mais contexto |
learning-log | SessionEnd | SOFT | Log diário de aprendizados em ~/.claude/learnings/ |
pre-compact | PreCompact | SOFT | Salva contexto crítico antes do compact |
Padrões enforcados (15 rules)
Code quality
naming, error-handling, dependency-management, testing, performance.
Production-ready
security, accessibility, monitoring, api-design, database.
Workflow
karpathy-guidelines, surgical-changes, no-fake-data, accentuation-pt-br.
O que NÃO é
❌ Não é "AI pair programming"
Não é assistente passivo. É squad com autoridade — chief reprova entrega que não bate o quality gate, mesmo se você reclamar.
❌ Não pula testes "porque tá apertado"
Sem testes = sem merge. Testes "porque o cliente tá esperando" é a forma mais cara de economizar tempo.
❌ Não inventa solução
Se um framework/API/MCP não é conhecido, o squad faz research (Context7, docs-seeker, web search) ANTES de aplicar. Zero chute.
❌ Não silencia erro
Try/catch que engole erro e retorna sucesso = REPROVADO. Erro precisa ser logado, classificado e tratado — ou propagado.