144 lines
6.4 KiB
Markdown
144 lines
6.4 KiB
Markdown
---
|
|
type: workflow
|
|
name: comercial
|
|
description: Criar uma descrição comercial das funcionalidades e do sistema
|
|
scope: global
|
|
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/<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:
|
|
|
|
```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
|
|
|
|
- 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)
|