7. Comandos do agente (slash commands)
Escreves / no início da mensagem para abrir o menu de comandos. Tab/Enter para seleccionar.
Comando | Descrição | Plano |
---|---|---|
/init | Analisa o projecto, detecta framework, gera TMS.md | Todos |
/plan | Arquitecta uma feature ou app completa: gera PLAN.md + tasks, pede aprovação | Todos |
/debug | Investiga um erro de forma hipótese-driven | Todos |
/review | Code review crítico por sub-agente fresh, ranked por severidade | Todos |
/payments | Integra MoMenu Payments (MCX, E-kwanza, Referência) | Todos |
/te2e | Valida a app fazendo o agente conduzir um browser real | Pago |
/init <opcional: descrição>
Mapeia o teu projecto. Lê estrutura, package.json, git history, e gera um TMS.md na raiz. O TMS.md é a "memória do projecto" — o agente lê-o em cada sessão para saber:
- O stack do projecto
- Convenções (naming, estrutura de pastas)
- Decisões arquitecturais já tomadas
- Patterns específicos da equipa
Corre uma vez por projecto. Quando há mudanças estruturais grandes, podes correr de novo.
/plan <descrição>
Para qualquer trabalho não-trivial — desde uma feature isolada a uma aplicação completa from-scratch. O agente classifica o pedido em STATIC (landing/portfolio), INTERACTIVE (dashboards, ferramentas, calculadoras sem backend) ou FULLSTACK (e-commerce, SaaS, app com auth + persistência) e adapta a profundidade do plano à categoria.
1. Lê código relevante (ou regista "projecto vazio" se for greenfield)
2. Considera ≥2 abordagens arquitecturais; escolhe uma com trade-offs explícitos
3. Escreve PLAN.md na raiz do projecto, secção por secção (context, goals, system design, data model, API surface, UI/UX, security, observability, implementation phases, riscos, open questions)
4. Apresenta uma plan approval card quando o plano está completo
5. Tu aprovas / pedes alterações / rejeitas antes de qualquer escrita de código fora do PLAN.md
6. Após aprovação, seeda o task tracker com as phases do PLAN.md. As tasks são tracked no painel do agente; tu disparas a execução com "Start execution".
Reasoning ON (forçado, via header X-Request-Type: plan). Hard cap de 3 web fetches por plan run — questions não respondíveis ficam em §14 Open Questions para tu decidires na review.
Modo arquitecto: durante /plan, o agente fica restringido mecanicamente — só pode ler código, escrever/editar o PLAN.md na raiz, e correr update_tasks. Tentativas de scaffold, install, ou provisionamento são bloqueadas pelo executor. /plan planeia; não implementa.
Quando usar: features não-triviais, refactors significativos, integrações complexas, ou app inteira from-scratch (passa a descrição completa — *"/plan e-commerce SaaS B2B com auth, multi-tenant, Stripe, exports CSV"* — e o /plan classifica como FULLSTACK e gera as phases).
/debug <sintoma ou stack trace>
Para erros. O agente:
1. Lê stack trace
2. Localiza o código relevante
3. Forma 2-3 hipóteses sobre a causa
4. Verifica cada uma (logs, testes pontuais, queries)
5. Propõe o fix mínimo sobre a causa verificada
6. Verifica que o fix resolve sem introduzir regressões
Reasoning ON (forçado).
Quando usar: erros runtime, comportamento errado, falhas de testes, problemas de produção.
/review [scope]
Code review crítico, executado por um sub-agente fresh. O sub-agente não vê o histórico do chat — só o código no disco — para evitar o viés de confirmação típico (o agente que escreveu o código tende a justificar as suas próprias decisões em vez de criticar).
Scope (em ordem de prioridade):
Argumento | Significado |
---|---|
/review | Ficheiros tocados nesta sessão (via checkpoints) |
/review @path/to/file.ts | Ficheiro específico |
/review last commit | Ficheiros do último commit (git diff HEAD~1) |
/review login flow | Free-form: o sub-agente decide o que está em scope |
O sub-agente:
1. Lê os ficheiros no scope completos (não skimm)
2. Lê TMS.md se existir, para honrar decisões arquitecturais documentadas
3. Para cada finding candidato, verifica contra o código antes de reportar (evita falsos positivos)
4. Classifica em uma de quatro severidades:
- Crítico — bugs reais, security holes, data loss, race conditions
- Alto — anti-patterns que vão morder, tech debt grave
- Médio — workarounds frágeis, code smell, separação de responsabilidades
- Baixo — naming, organização, micro-readability
5. Limita o output a top-10 por severidade; resto fica em sumário agregado
6. Cada finding inclui: localização (file:line), porque importa, recomendação one-liner
Reasoning ON forçado em todos os turns (não só o primeiro).
Read-only: o /review não escreve, edita ou apaga código. Para implementar uma correção, fazes um pedido normal ao agente principal depois de leres o relatório.
Quando usar:
- Antes de abrir um PR
- Antes de um deploy
- Após uma feature grande, para apanhar bugs e anti-patterns que escaparam
- Quando suspeitas que há algum workaround acumulado num módulo
Quando NÃO usar:
- Logo a seguir a o agente principal acabar de escrever uma feature grande nesta sessão — fazer review do output recente do mesmo agente principal é teatro (mesmo com sub-agente fresh, há overlap de patterns recentes na cabeça do user). Espera um pouco, ou usa para code que não foi escrito agora.
Custo: reasoning ON em todos os turns + leitura de muitos ficheiros = consumo significativo do plano. No Explorer (consumo apertado) uma sessão de review pode pesar — usa com critério.
/payments
Integra MoMenu Payments. O agente:
1. Lê os skills de pagamento (MCX, E-kwanza, Referência)
2. Pergunta qual método queres
3. Implementa a integração
4. Adiciona endpoints, componentes UI, e testes manuais
/te2e <o que validar> *(pago)*
Validação adversarial. O agente:
1. Lê o código da feature primeiro (sem inventar selectors)
2. Deriva uma matriz de cenários do código observado: happy path + edge cases + estados de erro + auth states + persistence + concorrência + autorização
3. Conduz cada cenário num browser real (Chrome do sistema)
4. Reporta bugs com severidade, repro mínima, e localização (file:line)
Cada acção do browser pede a tua permissão (Sim/Não). Reasoning ON em todos os turns.
Quando usar: antes de shipar uma feature; para validar regressões; quando suspeitas que há bugs escondidos.
Antes da primeira utilização: o TM Code abre Chrome (visível) — faz login na tua app uma vez, a sessão fica guardada no profile dedicado para sempre.
> O /te2e requer Chrome (ou Edge / Brave) instalado. Se nenhum for detectado, o TM Code mostra um diálogo a oferecer o link para instalar.
← Toda a documentação · versão markdown