6.4 KiB
| type | name | description | scope | updatedAt |
|---|---|---|---|---|
| workflow | comercial | Criar uma descrição comercial das funcionalidades e do sistema | global | 2026-06-01 |
Workflow: Criar Descrição Comercial
Este workflow gera uma descrição comercial de funcionalidades ou do sistema completo, escrita na pasta ./COMERCIAL/. Cada módulo ou funcionalidade gera um arquivo separado com o padrão ./COMERCIAL/<nome-do-modulo>.md.
É OBRIGATÓRIO seguir a regra global de Escrita Natural (escrita-natural.global.md) em toda produção textual deste workflow.
Passos
1. Identificar as funcionalidades solicitadas
Perguntar ao usuário quais módulos ou funcionalidades devem ser descritos. Se o pedido for genérico ("descreva o sistema"), listar os módulos principais do projeto e confirmar o escopo antes de redigir.
2. Levantar contexto real de cada funcionalidade
Antes de escrever, ler o código-fonte e os componentes relacionados para entender:
- Qual problema real a funcionalidade resolve?
- Quem são os usuários diretos? (consultor ambiental, gestor ambiental, gestor público, técnico de campo)
- Qual é o fluxo de uso no dia a dia?
- Quais dificuldades operacionais existiam antes da solução?
3. Redigir a descrição comercial
Para cada funcionalidade, produzir dois blocos de texto no arquivo ./COMERCIAL/<nome-do-modulo>.md:
Bloco A — Descrição Resumida (2 a 4 linhas)
Texto curto que pode ser usado em páginas de divulgação, apresentações rápidas ou materiais institucionais.
Estrutura obrigatória:
- Linha 1: o problema/dificuldade que existe sem a solução
- Linha 2-3: como funciona na prática (ação do usuário, sem termos técnicos de TI)
- Linha 4: o impacto concreto (ganho mensurável)
Exemplo:
Sem controle digital, registros de campo ficam em cadernos e planilhas isoladas — sujeitos a perda e erro de transcrição. Com a solução, o técnico registra os dados direto no celular, mesmo sem internet, com validação automática. Isso elimina falhas de preenchimento e garante rastreabilidade completa para auditorias.
Bloco B — Descrição Detalhada
Texto mais completo (5 a 15 linhas) que aprofunda o funcionamento e os diferenciais. Deve incluir:
- Cenário de uso realista (quem faz o quê, quando e onde)
- Recursos técnicos relevantes explicados de forma acessível (offline, sincronização, alertas automáticos)
- Benefícios encadeados (causa → efeito)
- Implicações legais ou normativas (quando aplicável): se a funcionalidade tem relação com legislação, normas regulatórias ou resoluções de órgãos competentes, citar expressamente a norma ou obrigação legal. Isso fortalece o argumento comercial e demonstra que a solução atende requisitos reais de conformidade.
Regra de siglas: toda sigla usada pela primeira vez no texto deve vir acompanhada do nome por extenso. Exemplo: "ANA (Agência Nacional de Águas e Saneamento Básico)". Nas ocorrências seguintes, pode-se usar apenas a sigla.
4. Revisar contra o checklist de qualidade
Antes de entregar, validar cada bloco contra as restrições abaixo:
- O texto do Resumo começa pelo problema, não pela funcionalidade?
- Há pelo menos um cenário de uso prático (quem, onde, como)?
- Os parágrafos são curtos (2 a 4 linhas) com uma ideia principal cada?
- A linguagem soa como alguém que vive o problema, não como manual de software?
- Está LIVRE de jargões de TI e termos em inglês sem tradução?
- Toda sigla está acompanhada do nome por extenso na primeira ocorrência?
- Está LIVRE de termos vazios ("Inovador", "Eficiente", "Solução completa", "O presente projeto")?
- Está LIVRE do padrão repetitivo "O sistema permite / A funcionalidade permite / A ferramenta permite"?
- As frases variam de estrutura? (alternando "Na prática...", "Com isso...", "Isso reduz...", "Como resultado...")
- Quando há implicação legal ou normativa, a norma/lei/resolução está citada e destacada no texto?
- O texto é compreensível pelo público-alvo do produto sem conhecimento de TI?
Público-Alvo
Todo texto produzido por este workflow deve ser compreensível pelo público-alvo do produto. O agente deve identificar quem são os usuários e decisores com base no contexto do projeto.
Regra geral: nenhum dos perfis-alvo tem obrigação de conhecer termos de tecnologia. A linguagem deve ser acessível, direta e sem jargões de TI.
Regras de Tom e Vocabulário
| ✅ Usar | ❌ Evitar |
|---|---|
| "Na prática, o técnico..." | "O sistema permite..." |
| "Com isso, a equipe..." | "A solução inovadora..." |
| "Isso elimina..." | "O presente projeto visa..." |
| "Como resultado..." | "Dessa forma..." |
| "Sem a solução, o gestor precisa..." | "A ferramenta oferece..." |
| "Entregamos controle sobre..." | "Nossa solução oferece..." |
| "O gestor ganha visibilidade de..." | "A plataforma disponibiliza..." |
| "página de divulgação" | "landing page" |
| "frase de abertura" | "hook" |
| "chamada para ação" | "CTA" (isolado, sem explicação) |
| "texto persuasivo" | "copywriting" |
| "linha do tempo, publicações" | "feed" |
Tom geral: profissional, direto, sem burocracia institucional. O texto deve parecer escrito por quem constrói a solução e entende a operação do dia a dia do cliente.
Formato de Saída
Cada módulo ou funcionalidade deve gerar um arquivo próprio dentro da pasta ./COMERCIAL/.
Regra de nomeação do arquivo:
- Usar o nome do módulo em kebab-case (minúsculo, separado por hifens)
O arquivo ./COMERCIAL/<nome-do-modulo>.md deve seguir esta estrutura:
# [Nome do Módulo]
## [Nome da Sub-funcionalidade]
### Resumo
[Bloco A — 2 a 4 linhas: problema → solução → impacto]
### Detalhamento
[Bloco B — 5 a 15 linhas: cenário real + técnico acessível + legal]
---
## [Próxima Sub-funcionalidade]
...
Referências
- Regra global:
.agent/rules/escrita-natural.global.md(padrão obrigatório de redação) - Workflow:
.agent/workflows/orcamento.global.md(texto para documentos de orçamento e proposta — apresentação + lista de funcionalidades) - Workflow:
.agent/workflows/marketing.global.md(peças de marketing digital — LinkedIn, Instagram, WhatsApp, E-mail) - Workflow:
.agent/workflows/otimizar-codigos.global.md(para documentação técnica, não comercial)