القائمة
Executa o pipeline completo de qualidade do stack (build, testes, lint, type check) e produz um relatório estruturado. Use no início da revisão, antes da análise semântica. Não use para execução de testes específicos (isso é atribuição do implementer durante desenvolvimento).
التثبيت باستخدام 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.
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.
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.
| name | flow-quality-checks |
| description | Executa o pipeline completo de qualidade do stack (build, testes, lint, type check) e produz um relatório estruturado. Use no início da revisão, antes da análise semântica. Não use para execução de testes específicos (isso é atribuição do implementer durante desenvolvimento). |
| pipeline_stage | runtime |
| consumed_by | ["reviewer"] |
| requires | [] |
| produces | ["Quality Pipeline Report"] |
Executa o pipeline completo de qualidade e produz output estruturado para o reviewer decidir se entra em análise semântica ou rejeita imediatamente.
flow-code-reviewmvn clean verify
Inclui: compile, test, integration-test (se configurado), spotless/checkstyle (se configurado).
Se houver test containers pesados configurados como @Tag("slow"), rode-os separadamente:
mvn verify -Pslow-tests
dotnet build --configuration Release --no-restore
dotnet test --configuration Release --no-build --logger "trx;LogFileName=test-results.trx"
Se o projeto tem dotnet format:
dotnet format --verify-no-changes
npm run build
npm run test -- --run
npm run lint
npm run typecheck
Se houver um único gate (npm run ci ou npm run verify), use-o:
npm run verify
Execute nesta ordem — a ordem é importante para dar feedback rápido:
Regra de short-circuit: se qualquer etapa falha, PARE. Reporte a falha e saia. Não rode as etapas seguintes cegamente.
@Disabled, @Ignore, @Skip (respeitar a marcação original)Produza SEMPRE este formato, independente do resultado:
QUALITY PIPELINE REPORT
-----------------------
Stack: [Java | .NET | React]
Commands executed:
1. [comando 1] → [PASS | FAIL] (exit code: N, duration: Xs)
2. [comando 2] → [PASS | FAIL] (exit code: N, duration: Xs)
...
Summary:
- Build: [PASS | FAIL]
- Type check: [PASS | FAIL | N/A]
- Lint: [PASS | FAIL | N/A]
- Unit tests: [N passed, M failed, K skipped]
- Integration tests: [N passed, M failed, K skipped | N/A]
Failure details (se houver):
[output literal das falhas — copy/paste do stderr/stdout]
Verdict: [PASS | FAIL]
Com base no Verdict:
flow-code-review)REJEITADA: build_failure com o output literalREJEITADA: test_failure com os testes que falharam e o motivoREJEITADA: build_failure (agrupado) com a saída do linterUse os labels exatos — o orchestrator usa esses tipos para roteamento.
O implementer devolve um Verification Report via skill flow-final-verify. Você (reviewer) deve:
flow-quality-ledger com categoria "Teste inadequado" ou "Lógica incorreta" e origem "Limitação do modelo"REJEITADA: build_failure com a descrição do que faltoumemory/[task]_task.md mas NÃO rejeite