القائمة
Conduz análise semântica de uma tarefa implementada validando linha a linha contra PRD, TechSpec e task spec, e aplicando padrões do stack. Use no reviewer após flow-quality-checks passar. Não use se o pipeline de qualidade falhou — corrija o build primeiro.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Orquestrador de testes QA end-to-end. Recebe PRD e/ou techspec, conduz entrevista para extrair expectativas do usuario, analisa requisitos, propoe plano de tasks por user story/feature, aguarda aprovacao do usuario, cria estrutura de evidencias, dispara subagentes via qa-task-runner e consolida relatorio final. Usar quando: executar testes QA; validar PRD/techspec; criar plano de testes E2E; orquestrar subagentes de teste.
Sample skill fixture used by installer tests.
Cria API Contracts (OpenAPI 3.1) como ponto de sincronização entre frontend e backend, a partir de um PRD existente. Use esta skill sempre que o usuário quiser definir o contrato de API, gerar OpenAPI spec, criar API-first design, sincronizar front e back, ou quando mencionar "contrato de API", "OpenAPI", "swagger", "API-first", "schema da API", "endpoints da API". Também dispare quando o usuário disser "vamos definir a API antes de implementar", "o front e o back não se encaixam", "quero mockar a API", "preciso do contrato antes de começar o frontend". Esta skill é a etapa 1.5 do pipeline PRD → API Contract → TechSpec (Backend) → TechSpec (Frontend) → Tasks. Requer que o PRD já exista em `tasks/prd-[nome-funcionalidade]/prd.md`.
Cria Domain Documents (Nível 1) para domínios específicos de um sistema complexo. Use esta skill sempre que o usuário quiser detalhar um domínio, módulo ou bounded context após o Vision Doc estar aprovado. Dispare quando o usuário mencionar "domain doc", "detalhar o domínio X", "documentar o módulo X", "bounded context", "quais features do domínio X", "vamos detalhar o financeiro/RH/estoque" ou qualquer variação que indique a necessidade de aprofundar um domínio específico antes de criar PRDs. Esta skill é o Nível 1 do pipeline Vision → Domain → PRD → TechSpec → Tasks. Requer que o Vision Doc já exista em `vision.md`. O documento gerado serve como entrada para a skill `flow-prd-creator`.
Exige evidência fresca de verificação antes de qualquer claim de conclusão, aprovação ou commit. Use quando um agente está prestes a declarar sucesso, aprovar uma tarefa ou fazer commit. Não use para planejamento inicial, brainstorming ou tarefas que ainda não chegaram em um passo concreto de verificação.
Persona e workflow do Finalizer no loop de execução do Looping Agent. Use esta skill quando o orquestrador invocar uma sessão ACP da fase de finalização, ou quando o desenvolvedor quiser fechar manualmente uma task aprovada (commit + integração linear) seguindo o mesmo padrão determinístico do loop. Dispare também quando o input mencionar "finalizar task N", "commitar e mergear", "rodar finalizer", "fechar task aprovada". A skill estabelece a persona, atualiza `tasks.md`, agrega todos os artefatos no commit, aplica o fluxo git linear (rebase + ff-only) e termina invocando o tool_call de conclusão `report_finalizer_result`.
| name | flow-code-review |
| description | Conduz análise semântica de uma tarefa implementada validando linha a linha contra PRD, TechSpec e task spec, e aplicando padrões do stack. Use no reviewer após flow-quality-checks passar. Não use se o pipeline de qualidade falhou — corrija o build primeiro. |
| pipeline_stage | runtime |
| consumed_by | ["reviewer"] |
| requires | ["Quality Pipeline Report PASS"] |
| produces | ["Semantic Review Result","tasks/prd-[slug]/[N]_task_review.md"] |
Guia a análise semântica da revisão — a fase que de fato encontra problemas reais.
Esta skill só deve ser carregada após flow-quality-checks retornar PASS. Se o pipeline falhou, volte para o orchestrator com REJEITADA antes de carregar esta skill.
Valide que a implementação atende linha por linha:
Se a task spec tem bullets ou checklist, cruze cada item com código.
Use flow-stack-selector para carregar as skills de revisão relevantes (dotnet-code-quality, java-testing, react-architecture, etc.).
Para cada skill carregada, aplique sua checklist aos arquivos tocados na tarefa.
Independente do stack, verifique:
afterCommit / deferred dispatch (não @Async dentro da tx)@Retry/@CircuitBreaker/@Transactional não aplicados em self-invocation (método chama outro da mesma classe sem passar pelo proxy)@Retry, @CircuitBreaker) são de integração com proxy ativo, não unitários com new.env.example ou equivalente)depends_on: condition: service_healthy) foram aplicadas em TODOS os pontos aplicáveisPara cada problema, atribua:
Severidade:
Decisão de aprovação:
Ao final, produza um resumo estruturado:
SEMANTIC REVIEW RESULT
----------------------
Alinhamento com task spec: [OK | Divergências encontradas]
Alinhamento com PRD: [OK | Divergências encontradas]
Alinhamento com TechSpec: [OK | Divergências encontradas]
Alinhamento com ADRs: [OK | N/A | Divergências encontradas]
Skills de stack aplicadas:
- [skill-name-1] — [OK | Problemas]
- [skill-name-2] — [OK | Problemas]
Problemas encontrados:
1. [Severidade] [Categoria] — [descrição]
Arquivo: [path:linha]
Trecho: [snippet se aplicável]
2. ...
Verdict: [APROVADA | REJEITADA]
Motivo de rejeição (se aplicável): [descrição curta]
Este output alimenta diretamente:
[task]_task_review.mdflow-quality-ledger (que vai classificar e registrar)Após esta skill, o reviewer deve carregar:
flow-quality-ledger — para registrar telemetria dos problemas encontradosflow-workflow-memory (já carregada) — para decidir promoção de aprendizados para MEMORY.md