dataagile-agent-kit

Ciclo completo de testes E2E do TOTVS Protheus via MCP Playwright com evidências e documentação. Cobre roteiro → aprovação → execução com screenshots → validação → error handling → persistência na base de conhecimento → geração de MIT010. Substitui TIR. Use quando precisar testar rotinas Protheus, validar regras de negócio, coletar evidências ou gerar documentação de testes.

Revisa código ADVPL/TLPP verificando: nomenclatura de arquivo (R[MOD][TYPE][SEQ].prw), ProtheusDoc completo, notação húngara, declaração de variáveis, BEGIN SEQUENCE, RecLock/MsUnlock, xFilial, campos customizados (prefixo X), parâmetros (TB_), Pontos de Entrada (lógica em função externa). Gera relatório CRÍTICO/AVISO/SUGESTÃO.

Deploy de artefatos Fluig no servidor de teste. Lê CLAUDE.md para identificar ambiente, confirma com o dev, aciona fluig-deployer teammate e verifica logs. Acione após /fluig:implement. Próximo passo obrigatório: /fluig:qa.

Orquestra Agent Team para executar plano Fluig — fluig-implementer (haiku) implementa em worktree isolado, fluig-spec-reviewer (sonnet) verifica spec, fluig-reviewer (sonnet) revisa qualidade. Comunicação bidirecional entre teammates. Próximo passo obrigatório: /fluig:deploy.

Testes de integração e E2E (Playwright) contra servidor Fluig deployado. Aciona fluig:test e fluig-qa teammate. Se riscos ALTOS encontrados, retorna para /fluig:implement. Acione após /fluig:deploy. Próximo passo: /fluig:verify.

Atalho que orquestra o pipeline completo de qualidade Fluig. Executa sequencialmente: (1) revisão estática via fluig-reviewer, (2) testes unitários, (3) /fluig:deploy, (4) /fluig:qa. Use como atalho após mudanças ad-hoc ou quando quiser executar o pipeline completo de uma vez. Para o fluxo guiado, use /fluig:implement → /fluig:deploy → /fluig:qa.

Gera e orienta execução de testes para widgets TOTVS Fluig. Unit tests com Jasmine + Karma e E2E com Playwright. Sempre questiona a URL do servidor antes de gerar configurações E2E. O E2E requer build + deploy antes de executar.

Gate de deploy final para artefatos Fluig. Checklist adaptativo baseado no ambiente do projeto (HML vs servidor único). Acione após fluig-review aprovado, antes de declarar o artefato pronto para produção. Confirma ambiente, valida checklist e aciona o deploy final via fluig-deployer.

Compila artefatos ADVPL/TLPP no AppServer e gera patch .ptm para aplicação no ambiente. Lê CLAUDE.md para parâmetros, confirma com o dev, aciona protheus-deployer teammate e verifica logs. Acione após /protheus:implement. Próximo passo obrigatório: /protheus:qa.

Orquestra Agent Team para executar o plano ADVPL/TLPP — protheus-implementer (haiku) implementa em worktree isolado, protheus-spec-reviewer (sonnet) verifica spec, protheus-reviewer (sonnet) revisa qualidade. Comunicação bidirecional entre teammates. Gate de compilação via lint. Use após /protheus:plan. Próximo passo: /protheus:deploy.

Gate de QA E2E contra ambiente Protheus compilado. Aciona /protheus:test-web (Playwright — visão real + evidências MIT010) e analisa qualidade. Se falhas, retorna para /protheus:implement. Acione após /protheus:deploy. Próximo passo: /protheus:verify.

Gate final antes de produção. Checklist de conformidade TOTVS (MIT043, Code Analysis, patch .ptm), confirma com o dev e orienta distribuição ao cliente. Acione após /protheus:qa.

Planejamento de desenvolvimento ADVPL/TLPP — intake de MIT044, explora o projeto, faz perguntas, propõe abordagens e gera design aprovado antes de qualquer código. Encadeia /protheus:plan.

Inicializa um projeto Protheus ADVPL — explora o projeto existente, entrevista o desenvolvedor e gera CLAUDE.md com configuração do cliente (AppServer, ambiente, prefixo de tabelas).

Decompõe o design aprovado do brainstorm em tasks concretas para teammates ADVPL. Gera plano tipado com artefatos R[MOD][TYPE][SEQ].prw/.tlpp, gates de lint e testes E2E Playwright (test-web). Use após /protheus:brainstorm.

Generate TIR (TOTVS Interface Robot) end-to-end test scripts in Python for Protheus SmartClient/Webapp screens. Supports CRUD screen tests, MVC screen tests, grid interaction, report tests, field validation, and message box assertions. Use when a user says "TIR test", "interface test", "e2e test Protheus", "SmartClient test", "Webapp test", "screen test", "create Python test for Protheus screen", or "automate Protheus UI test".

Aplica os princípios de Clean Architecture (livro de Robert Martin, o Uncle Bob) ao desenvolvimento Fluig — regra de dependência e camadas no widget Angular + PO-UI (component → service de aplicação → domínio puro → adapter HTTP/Dataset), datasets server-side e eventos de workflow como adaptadores finos, SOLID em TypeScript com a DI do Angular. Use quando o dev pedir para "organizar o widget em camadas", "desacoplar regra de negócio do componente", "aplicar clean architecture", "aplicar SOLID", "onde colocar essa regra", "dataset está gigante" ou quando o brainstorm/plan/review precisar de critério estrutural de design.

Aplica Domain-Driven Design (baseado em Implementing DDD, de Vaughn Vernon) ao desenvolvimento Fluig — linguagem ubíqua em processos BPM, formulários e widgets; bounded contexts entre processos; context mapping com ACL nas integrações (Protheus/terceiros); e padrões táticos adaptados (value objects em TypeScript, o documento do processo como agregado, invariantes validadas no servidor, eventos de domínio via movimentação do workflow). Use quando o dev pedir para "modelar o processo", "aplicar DDD", "definir os contextos", "organizar integração com Protheus", "modelar formulário complexo" ou no brainstorm de processos com regra de negócio rica.

Aplica os princípios de Clean Architecture (livro de Robert Martin, o Uncle Bob) ao desenvolvimento ADVPL/TLPP — regra de dependência, separação em camadas (domínio, caso de uso, adaptador, framework Protheus), SOLID em TLPP OO e organização de fontes por domínio. Use quando o dev pedir para "organizar em camadas", "desacoplar regra de negócio", "aplicar clean architecture", "aplicar SOLID", "onde colocar essa regra", "separar SQL da regra", "estruturar um desenvolvimento grande" ou quando o brainstorm/plan/reviewer precisar de critério estrutural de design.

Aplica Domain-Driven Design (baseado em Implementing DDD, de Vaughn Vernon) ao desenvolvimento Protheus — linguagem ubíqua com o cliente, bounded contexts para organizar customizações, context mapping para integrações, e padrões táticos em TLPP (entidades, value objects, agregados, repositórios, serviços e eventos de domínio). Use quando o dev pedir para "modelar o domínio", "aplicar DDD", "definir bounded context", "organizar uma customização grande por contexto", "modelar integração entre sistemas", "criar value object/agregado", ou no brainstorm de desenvolvimentos com regra de negócio rica.

Gera um relatório TOTVS SmartView de ponta a ponta, do código ao artefato renderizando dados. A partir de uma especificação (tabelas/campos Protheus, query SQL ou dados literais), gera o Business Object TLPP (IntegratedProvider), compila no AppServer via advpls (TDS CLI remoto), registra na discovery e monta o artefato no SmartView (Data Grid, Tabela Dinamica/Pivot ou Report). Esta skill deve ser usada quando o usuario pedir para criar ou gerar um relatorio SmartView, fazer um Business Object para o SmartView, publicar um IntegratedProvider, gerar Data Grid, Pivot ou Report no SmartView, ou desenvolver relatorios SmartView com agentes de IA. Cobre um ambiente SmartView (TReports) self-hosted ligado a um AppServer Protheus.

Gera código ADVPL/TLPP para Protheus seguindo obrigatoriamente: nomenclatura de arquivo R[MOD][TYPE][SEQ].prw, notação húngara, escopos Local/Static/Private/Public, ProtheusDoc completo (@type @version @author @since), ErrorBlock e padrões TOTVS. Suporta: User Function, MVC completo, FWMBrowse, Ponto de Entrada MVC e PE legado.

Inicializa um projeto Fluig — entrevista o desenvolvedor e gera CLAUDE.md com contexto do cliente (URL servidor, prefixos, ambiente, integração Protheus). Invoque explicitamente ao iniciar projeto novo: /fluig:init-project

Consulta componentes, inputs/outputs, exemplos e guias da biblioteca PO-UI (Angular TOTVS) via MCP server oficial. Use antes de escrever ou modificar qualquer UI que utilize PO-UI.

Referência das APIs TOTVS Fluig — DatasetFactory, DatasetBuilder, CardAPI, WCMAPI, fluigc, WFMovementDTO, getValue/setValue. Use quando tiver dúvida sobre qual API usar no Fluig, sintaxe de dataset, como manipular formulário, ou diferença entre APIs de workflow e formulário.

Gate de design para desenvolvimento Fluig. Use ANTES de criar qualquer artefato (widget, form, dataset, workflow). Entrevista o desenvolvedor, mapeia integrações e produz um design aprovado antes de acionar qualquer skill de scaffolding. Invoque ao iniciar qualquer nova funcionalidade Fluig.

Cria dataset JavaScript para TOTVS Fluig com defineStructure(), createDataset(), try/catch e logging completo. Use quando precisar consultar dados no Fluig, integrar com Protheus via REST, consulta SQL, atualizar dados externos ou dataset com constraints. Suporta: SQL simples, REST Protheus (GET/POST), SQL dinâmico com validação anti-injection.

Debugging sistemático para Fluig. Guia investigação de root cause em 4 fases: reproduzir, investigar, hipótese, corrigir com teste. Usa logs Docker, Playwright traces, Karma output.

Registra um aprendizado de correção na base de conhecimento Fluig. Usar quando Claude erra e o dev corrige, para que o erro não se repita com outros devs. Conduz diálogo de confirmação antes de persistir.

Cria formulário HTML para TOTVS Fluig com events/ e Util/. Use quando precisar criar formulário Fluig, adicionar validações, máscaras CPF/CNPJ/CEP/telefone, campos condicionais ou integrar SweetAlert2. Gera: HTML responsivo, events/enableFields.js, events/displayFields.js, events/validateForm.js, Util/UtilsHandler.js, Style/custom.css.

Escreve plano de implementação para artefatos Fluig. Mapeia arquivos, define tasks com TDD, e salva em docs/fluig/plans/. Acione após /fluig:brainstorm aprovar o design. Próximo passo obrigatório: /fluig:implement.

Cria widget Angular 19 + PO-UI 19.36.0 para TOTVS Fluig. Estrutura completa com components, pages, services, testes Jasmine+Karma. Padrão: wg_[nome-kebab-case].

Cria scripts de eventos BPM para workflow TOTVS Fluig. Use quando precisar de afterStateEntry, beforeStateEntry, afterProcessCreate, afterProcessFinish, subProcessCreated ou lógica de aprovação. Gera evento completo com try/catch, log.info/error, integração dataset e envio de email. Nunca hardcoda login do responsável.

Registra um aprendizado de correção na base de conhecimento Protheus. Usar quando Claude erra e o dev corrige, para que o erro não se repita com outros devs. Conduz diálogo de confirmação antes de persistir.

Especialista ADVPL/TLPP que consulta a Knowledge Base TBC (MCP), a documentação TDN (RAG) e os padrões TBC para gerar código Protheus de qualidade.

Setup completo, CLI e test-agents do Playwright. Cobre instalação, playwright.config.ts, todos os comandos npx playwright, fluxo planner/generator/healer com --loop=claude, e autenticação via storageState. Use quando precisar criar, executar ou reparar testes E2E com Playwright CLI.

Compila fontes ADVPL/TLPP no AppServer Protheus via TDS-CLI (advpls). AÇÃO COM EFEITO COLATERAL — nunca auto-ativa, requer invocação explícita com namespace completo.

Diagnostica e resolve problemas em código ADVPL/TLPP para Protheus. Classifica erros de compilação, runtime, performance e locks de banco de dados. Propõe correção precisa e valida a solução.

Migra código ADVPL procedural (.prw) para TLPP orientado a objetos (.tlpp). Analisa dependências, propõe estrutura de classes com namespaces FSW.TBC.*, mantém wrappers para compatibilidade retroativa e gera checklist de validação.

Referência de padrões ADVPL/TLPP para Protheus: nomenclatura de arquivos (R[MOD][TYPE][SEQ].prw), notação húngara, dicionário de dados (SZ?, prefixo X, TB_), Pontos de Entrada (MVC e legado), MVC, FWMBrowse, namespaces, estrutura de pastas e Code Analysis.