--- type: workflow name: comercial description: Criar uma descrição comercial das funcionalidades e do sistema scope: local updatedAt: "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/.md`. É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural`) 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/.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/.md` deve seguir esta estrutura: ```markdown # [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 - Rule: `global/rules/escrita-natural` (padrão obrigatório de redação) - Workflow: `agents/comercial/workflows/orcamento` (texto para documentos de orçamento e proposta — apresentação + lista de funcionalidades) - Workflow: `agents/comercial/workflows/marketing` (peças de marketing digital — LinkedIn, Instagram, WhatsApp, E-mail) - Workflow: `global/workflows/otimizar-codigos` (para documentação técnica, não comercial)