Stats
Actions
Tags
From dev-team-kit-fv
Orchestrates development pipeline by classifying tasks, coordinating skill execution order, adapting flow to context, and ensuring no critical steps are skipped.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev-team-kit-fv:09-orchestratorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> ⚠ **Esta é a SKILL 09** (playbook de contexto). Não é o subagent `dev-team-kit-fv:orchestrator`.
⚠ Esta é a SKILL 09 (playbook de contexto). Não é o subagent
dev-team-kit-fv:orchestrator.
- Para carregar este playbook na sessão atual:
Skill({ skill: "dev-team-kit-fv:09-orchestrator" })- Para despachar o subagent orchestrator (turno isolado):
Agent({ subagent_type: "dev-team-kit-fv:orchestrator", ... })- Diferença:
policies/skills-vs-agents.md
O Orquestrador classifica a task, define o pipeline minimo suficiente e coordena as transicoes entre skills.
Esta skill herda comportamento base de GLOBAL.md e destas policies:
policies/constitution.md ← autoridade hierarquica sobre PRD/plan/ADRs quando memory/constitution.md existirpolicies/constitution.md ← autoridade hierarquica sobre PRD/plan/ADRs quando memory/constitution.md existirpolicies/execution.mdpolicies/handoffs.mdpolicies/quality-gates.mdpolicies/token-efficiency.mdpolicies/stack-flexibility.mdpolicies/tool-safety.mdpolicies/evals.mdpolicies/vertical-slices.md ← regra obrigatoria para toda feature multi-camadaAntes de montar pipeline, checar memory/constitution.md do repo consumidor:
/constitution antes de prosseguir/analyze antes de /build quando ha 3+ artefatos (spec + plan + issues)Antes de montar pipeline, checar memory/constitution.md do repo consumidor:
/constitution antes de prosseguir/analyze antes de /build quando ha 3+ artefatos (spec + plan + issues)Se houver conflito entre instrucoes, a hierarquia global do kit prevalece.
Para cenarios extensos e playbook detalhado, consultar docs/skill-guides/orchestrator-playbook.md apenas quando o pipeline fugir do caminho padrao.
GLOBAL.md e policies/O Orquestrador opera em dois modos. Escolher antes de iniciar:
/pipeline ClassicoPara feature pequena/media, equipe conhece o terreno, spec ja clara.
/spec -> /plan -> /build -> /test -> /review -> /ship
docs/specs//pipeline-discovery (com Discovery + Issues + TDD)Para feature grande/nova/ambigua, equipe nova com a area, vai paralelizar com 2+ workers, ou precisa publicar PRD/issues no tracker.
/grill-me -> /to-prd -> /to-issues -> [skill 38 opcional] -> /loop --worktree --parallel N -> /ship
\-> por slice: /build + skill 37 (TDD) + /review
/grill-me)needs-triage/loop --worktree --parallel N/to-issues e /loop se codebase precisa refactor antes| Sinal | Modo |
|---|---|
| feature pequena, briefing claro | A |
| bug fix, refactor localizado | A |
| feature grande, briefing vago | B |
| equipe nova com a area | B |
| precisa tracking em issue tracker | B |
| 2+ workers em paralelo | B |
| codigo critico que merece TDD | B |
| spike/POC throwaway | nem A nem B — /auto direto |
Modos coexistem. Usuario pode comecar em A, perceber que e maior do que parecia, e escalar para B no meio (passar do /spec direto para /grill-me).
For multi-step pipelines, consult programs/ for declarative definitions (6 programs, executable via /run-program):
| Program | When to use |
|---|---|
programs/pipeline-discovery.{yml,md} | Large/ambiguous features needing discovery + TDD by slice |
programs/spec-driven-development.{yml,md} | Feature em projeto com constitution + cross-artifact analyze |
programs/detective-spec.{yml,md} | Legacy codebase reverse-engineering |
programs/loop-polishing.{yml,md} | Autonomous loop with quality polishing |
programs/adversarial-dev.{yml,md} | Greenfield app via planner + adversarial loop |
programs/comprehensive-review.{yml,md} | 5-agent parallel PR review + synthesize + auto-fix |
Use programs as the canonical source when composing pipelines — they define abort conditions, protocol refs, and input contracts that complement the orchestrator's routing logic.
A camada de auto-orquestração funciona em 3 níveis:
intent-classifier (UserPromptSubmit) — analisa prompt do usuário e emite additionalContext sugerindo programAskUserQuestion (dry-run / direto / ad-hoc / cancelar)Ver policies/auto-orchestration.md para níveis de autonomia (manual / sugestão passiva / sugestão ativa / autônomo).
Antes de invocar Backend/Frontend/DB para uma feature multi-camada, o Orquestrador deve quebrar a entrega em vertical slices: cada slice e uma feature ponta-a-ponta (DB + back + front + teste e2e) testavel sozinha.
PROIBIDO despachar plano "front primeiro, back depois, DB depois" ou "Worker A faz todo o front, Worker B faz todo o back". Isso e layer-first paralelizado e quebra integracao.
Para feature multi-camada, primeiro produzir e apresentar a tabela de slices:
## Plano (Vertical Slices)
### Slice 1 — <feature menor/independente>
**Worker:** A (worktree feature/<nome>)
**Inclui:** spec, DB migration, back endpoint, front componente, teste e2e
**Independente de:** todos os outros / apenas Slice X
### Slice 2 — <feature seguinte>
[...]
Apos aprovacao do plano, despachar o pipeline base dentro de cada slice (cada slice roda Backend + Frontend + QA juntos no mesmo worktree).
Slices independentes paralelizam via /worktree ou /loop --worktree --parallel N. Slices dependentes sequencializam pela dependencia.
Detalhes em policies/vertical-slices.md (anti-padroes, heuristicas de tamanho, evidencia de conformidade).
⚠ PROIBIDO passar nome de skill numerada como subagent_type:
// ❌ InputValidationError em runtime — esses nomes são SKILLS, não subagents
Agent({ subagent_type: "dev-team-kit-fv:03-backend-api", ... })
Agent({ subagent_type: "dev-team-kit-fv:04-frontend-integration", ... })
Agent({ subagent_type: "dev-team-kit-fv:05-qa-testing", ... })
CORRETO — 3 caminhos:
A) Worktree + general-purpose (paralelização granular, recomendado para N slices)
⚠ Sempre passar
model:explícito. Sem isso o subagent herda o modelo do parent (geralmente Opus em sessão de orquestração) — desperdiça budget em tarefa que Sonnet/Haiku resolveria. Verpolicies/model-routing-real.mdpara o porquê o hook não consegue forçar isso por nós.
const slices = [/* lista de vertical slices */];
// Um único message com N tool calls — dispatch em paralelo
for (const slice of slices) Agent({
subagent_type: "general-purpose",
isolation: "worktree",
model: "sonnet", // implementação de slice = Balanced tier
description: `Slice ${slice.id} — ${slice.title}`,
prompt: `
PASSO 1 OBRIGATÓRIO: invoque Skill({ skill: "dev-team-kit-fv:04-frontend-integration" }).
PASSO 2: implemente conforme: ${slice.description}
Critérios de aceitação: ${slice.acceptance.join("; ")}
Arquivos esperados: ${slice.files.join(", ")}
Output: commit(s) atômicos + resumo final ≤200 palavras.
`
});
Tabela canônica: que model: passar por tipo de slice
| Tipo de slice | model: | Por quê |
|---|---|---|
| Backend/Frontend impl, QA tests, docs | "sonnet" | Balanced — implementação padrão, sem necessidade de raciocínio profundo |
| Security review, arquitetura, debug cross-layer | "opus" | Deep — exige raciocínio multi-passo, custo justificado |
| Rename, lint fix, boilerplate, microcopy, format | "haiku" | Fast — tarefa mecânica, padrão conhecido, economia 10x |
| Detective spec (4 detectives em paralelo) | "sonnet" | Balanced — análise estrutural sem decisão crítica |
Anti-padrão: spawnar 5 slices sem model: em sessão Opus → custo 10x maior que necessário. Hook avisa mas não bloqueia.
Ver templates/parallel-slice-prompt.md, skills/40-parallel-dispatcher/SKILL.md e policies/model-routing-real.md.
B) /loop --worktree --parallel N (process-based, Ralph loop)
node scripts/auto-loop.mjs --worktree --parallel 5 "feature X em 5 slices"
C) /swarm (autonomia total, do prompt ao PR mergeable)
/swarm "implementar feature X"
Anti-padrão registrado em policies/skills-vs-agents.md#anti-padrão-1 (case real do v2.2.0).
Fluxo padrao dentro de UM slice vertical (uma feature ponta-a-ponta):
Repo Auditor -> CLAUDE.md Generator -> PO -> Design Intelligence -> UI/UX -> Backend -> Frontend -> Motion -> Copy -> SEO -> QA -> Security -> Reviewer -> Deploy -> [Session Summary + Cost Tracker]
Para spec inicial de varias features, primeiro rodar PO + Design Intelligence para producir lista de slices, depois rodar o restante por slice.
Documenter atua de forma transversal quando houver mudanca de regra, contrato, arquitetura ou operacaoAsset Librarian atua quando a task depender de consistencia visual, inventario de assets ou apoio ao Image GeneratorMobile Tauri entra como branch opcional apos Frontend e antes de QAImage Generator atua de forma transversal quando qualquer etapa precisar de asset visual (hero, icone, favicon, mascote, background)Observability SRE entra quando a task tocar deploy, operacao, monitoramento, incidentes ou confiabilidadeData Analytics entra quando a feature precisar de evento, tracking, KPI ou funilAccessibility Specialist entra quando a criticidade de acessibilidade exigir validacao dedicadaRelease Manager entra quando houver liberacao formal, changelog, rollout e comunicacao de releaseAI Integration Architect entra quando a feature integrar texto, imagem ou video no app do usuarioPrompt Engineer entra quando o prompt for parte critica da qualidade ou do custo da featureDesign Intelligence entra antes do UI/UX quando a task envolver construcao ou melhoria de interface, pesquisando concorrentes, tendencias visuais e gerando moodboard. Em melhoria de UI existente, pula o PO e vai direto: Design Intelligence -> UI/UX -> FrontendPlaywright MCP pode ser configurado ou reutilizado em tarefas que exigirem navegacao real, screenshots e verificacao visual do app em execucaoCost Tracker (30) gera relatorio de custo ao final de sessoes longas ou quando solicitadoSession Summary (31) consolida resumo ao encerrar sessao para continuidadeSmart Suggestions (32) sugere proxima acao entre steps ou quando usuario pede orientacaoQuando o repositorio ainda nao tiver auditoria valida em docs/repo-audit/current.md, preferir iniciar por Repo Auditor para mapear stack real, convencoes, assets e riscos antes de seguir o pipeline principal.
Apos o Repo Auditor completar a auditoria, verificar se o projeto consumidor tem um CLAUDE.md util.
Se nao existir ou estiver generico/desatualizado, acionar CLAUDE.md Generator (28) para gerar um CLAUDE.md especifico e acionavel antes de seguir o pipeline principal.
Invoke skill 17 (image-generator) ao identificar necessidade de assets visuais em qualquer etapa:
/swarm em landing/sistema novo (ver phase 2.5 em commands/swarm.md)Regra default (skill 17 aplica automaticamente, fonte: models/image-models.json):
referenceImages → gemini-25-flash ($0.039/img)Como acionar:
Contexto: [tipo de imagem], [onde sera usada], [paleta/estilo do projeto], [pagina/componente de destino]
Assets existentes: [paths de imagens, icones, backgrounds, mascotes ou referencias visuais ja existentes]
Design system: [cores, mood, contraste, linguagem visual]
Output: [onde salvar, ou deixar auto-detectar]
Execucao: node scripts/generate-image.mjs --prompt "..." (zero-dep, lê models/image-models.json). Detalhes em skills/17-image-generator/SKILL.md.
O Orquestrador deve reduzir ou expandir o pipeline conforme risco e impacto:
bugfix: skill afetada -> QA -> Security -> Reviewerhotfix critico: skill afetada -> Security -> Reviewer -> Deploymelhoria de UI: Design Intelligence -> UI/UX -> Frontend -> Motion -> QA -> Security -> Reviewerlanding page: Copy -> Design Intelligence -> UI/UX -> Frontend -> Motion -> SEO -> QA -> Security -> Reviewerrefactor: skill afetada -> QA -> Security -> Reviewerlegacy: Context Manager primeiro para mapear estado antes da skill afetadainfra/operacao: skill afetada -> Observability SRE -> QA/Security conforme risco -> Reviewer -> Deployfeature orientada a metrica: skill afetada -> Data Analytics -> QA -> Reviewerfluxo critico de acessibilidade: UI/UX/Frontend afetado -> Accessibility Specialist -> QA -> Reviewermigracao grande: Repo Auditor -> Migration Refactor Specialist -> skill afetada -> QA -> Security -> Reviewer -> Deployrelease formal: pipeline normal -> Release Manager -> Deployfeature de IA no app: Repo Auditor -> AI Integration Architect -> Prompt Engineer quando necessario -> Frontend/Backend -> QA -> Security -> ReviewerQuando houver rejeicao:
in_progress, completed ou rejected com handoff curtoAntes de classificar e montar pipeline, avaliar se o prompt tem contexto suficiente.
Sinais concretos que bypassam o gate (qualquer um destes = contexto suficiente):
src/lib/auth.ts, #423, .ts, .py com diretorio)#123, issue 42)1., 2., - [ ])force: ou !)Fluxo quando nao ha sinais concretos:
score < 0.4 → prosseguir normalmentescore 0.4-0.7 → ENRICH: inferir escopo do repo-audit, confirmar com 3 opcoesscore > 0.7 → GUIDED ENRICH: fazer 1 pergunta com multipla escolha, inferir o restoPrincipio: Captura minima, enriquecimento maximo. Nunca devolver "escreva mais" — o sistema infere e confirma. Sempre oferecer 3 saidas: "Bora assim? / Quer ajustar ou detalhar algo? / Ou era outra coisa?"
Em Claude Code, o hook pre-execution-gate.mjs faz isso automaticamente. Em outras plataformas, seguir este protocolo manualmente antes de montar pipeline.
Ao iniciar uma task:
policies/search-first.md):
docs/repo-audit/current.md se existirpolicies/source-driven.md):
resolve-library-id → query-docs) para libs conhecidasEntre etapas:
policies/model-routing.md quando houver trade-off real entre custo, latencia e profundidadeQA, Security ou Reviewer sem excecao formal prevista no fluxodocs/repo-audit/current.md antes de reexplorar o repositorio inteiroUsar templates/plan.md como formato padrao.
Incluir sempre:
Comentarios no codigo so fazem sentido quando explicam contexto nao obvio, restricoes externas ou workarounds temporarios. O padrao continua sendo codigo claro atraves de nomes descritivos, funcoes coesas, tipagem forte e testes.
Seguir policies/handoffs.md e, quando util, templates/plan.md e templates/handoff.md.
Se você reconhece um desses pensamentos, PARE e siga o processo. Ver policies/anti-rationalization.md.
| Racionalização | Realidade |
|---|---|
| "Scope é simples demais pra pipeline completo" | Pipeline existe pra garantir qualidade. Simplifique o pipeline, não o elimine |
| "Posso pular a etapa de pesquisa" | Search-first policy é obrigatória. Sem pesquisa = implementação cega |
| "Não precisa de QA pra isso" | QA descobre o que o implementador não imaginou. Sempre |
| "Vou delegar tudo de uma vez" | Delegação sem verificação intermediária multiplica erros silenciosamente |
| "O repo-audit está desatualizado, ignoro" | Desatualizado > inexistente. Use como base e verifique |
npx claudepluginhub felvieira/claude-skills-fv --plugin dev-team-kit-fvGuides developers through the full development pipeline: discover, brainstorm, plan, execute, review, and ship. Invoke when starting work on a bug, feature, improvement, or task.
Orchestrates a full build pipeline from PRD: plans tasks, implements in parallel, and reviews results. Routes simple work to a lighter workflow.
Orchestrates an adversarial plan-implement-review pipeline by spawning agents with separate context windows. Use after intake skills produce a starting document.