2026-09-28 22:18:39 -03:00

6.5 KiB

Raw Blame History

type	name	description	scope	updatedAt
workflow	comercial	Criar uma descrição comercial das funcionalidades e do sistema	local	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) em toda produção textual deste workflow.

Passos

1. Identificar as funcionalidades e contexto do módulo

Consultar <base_projeto>/memorias-ia/modulo.yml para obter modulo-descricao, modulo-tipo e modulo-id. Perguntar ao usuário quais módulos ou funcionalidades devem ser descritos. Se o pedido for genérico ("descreva o sistema"), usar o escopo oficial de memorias-ia/modulo.yml e confirmar 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

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/codigo-limpo (ou global/workflows/otimizar-codigos) (para documentação técnica, não comercial)

6.5 KiB Raw Blame History