134 lines
5.2 KiB
Text
134 lines
5.2 KiB
Text
---
|
|
type: workflow
|
|
name: orcamento
|
|
description: Criar texto de orçamento pronto para copiar e colar em peças de orçamento/proposta
|
|
scope: local
|
|
updatedAt: "2026-06-01"
|
|
---
|
|
|
|
# Workflow: Criar Texto de Orçamento
|
|
|
|
Este workflow gera textos prontos para **copiar e colar dentro de documentos de orçamento e propostas comerciais**. O resultado é salvo na pasta `./COMERCIAL/` com o sufixo `-orcamento` (ex: `./COMERCIAL/<nome-do-modulo>-orcamento.md`).
|
|
|
|
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural`) em toda produção textual deste workflow.
|
|
|
|
---
|
|
|
|
## Público-Alvo
|
|
|
|
O documento de orçamento será lido pelo **público-alvo do produto**. O agente deve identificar quem são os usuários e decisores com base no contexto do projeto.
|
|
|
|
A linguagem deve ser **acessível, direta e sem jargões de TI**. Siglas devem vir acompanhadas do nome por extenso na primeira ocorrência.
|
|
|
|
---
|
|
|
|
## Pré-requisitos
|
|
|
|
Antes de gerar o texto de orçamento, o agente deve ler o código-fonte do módulo para entender quais funcionalidades existem de fato. Se já existir o arquivo comercial (`./COMERCIAL/<nome-do-modulo>.md`), usá-lo como base para extrair contexto.
|
|
|
|
---
|
|
|
|
## Passos
|
|
|
|
### 1. Identificar o módulo
|
|
|
|
Perguntar ao usuário qual módulo ou funcionalidade será orçado.
|
|
|
|
### 2. Levantar contexto
|
|
|
|
Ler o código-fonte e os componentes relacionados para mapear:
|
|
- Quais **funcionalidades** o módulo oferece de fato?
|
|
- Existe **legislação ou norma** relevante que o módulo atende?
|
|
- Quem são os **usuários diretos**? (consultor, gestor, técnico de campo)
|
|
|
|
### 3. Redigir o texto de orçamento
|
|
|
|
O texto deve ser **autocontido** — pronto para colar diretamente dentro de um documento de orçamento sem necessidade de edição. Estrutura obrigatória:
|
|
|
|
#### Apresentação do Módulo (2 a 4 linhas)
|
|
|
|
Texto que descreve o módulo de forma direta, mostrando **o que ele faz** e **qual problema resolve**. Se houver legislação ou norma relevante, **citar aqui** para demonstrar conformidade regulatória e fortalecer o argumento.
|
|
|
|
Regras:
|
|
- Começar pelo que o módulo entrega, não pelo problema
|
|
- Se houver lei/norma relevante, citar com nome por extenso e artigo
|
|
- Tom confiante e profissional — adequado para documento formal
|
|
- Não usar termos de tecnologia
|
|
|
|
#### Lista de Funcionalidades
|
|
|
|
Após a apresentação, listar as funcionalidades do módulo em formato de **itens curtos** (1 a 2 linhas cada). Cada item deve:
|
|
|
|
- Descrever **o que a funcionalidade faz na prática** (ação concreta, não conceito abstrato)
|
|
- Ser compreensível por alguém que **nunca viu o sistema**
|
|
- Ser suficientemente específico para justificar o valor cobrado
|
|
|
|
Regras para cada item:
|
|
- Começar com o **nome da funcionalidade** em negrito
|
|
- Seguir com uma descrição curta do que ela faz
|
|
- Opcionalmente, incluir o benefício direto entre parênteses ou traço
|
|
|
|
### 4. Revisar contra o checklist de qualidade
|
|
|
|
Antes de entregar, validar:
|
|
|
|
- [ ] A apresentação do módulo é autocontida e compreensível isoladamente?
|
|
- [ ] Cada funcionalidade está descrita de forma concreta (o que faz, não o que é)?
|
|
- [ ] O texto está **pronto para copiar e colar** sem edição?
|
|
- [ ] 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?
|
|
- [ ] Legislação/norma relevante está **citada na apresentação** com nome por extenso?
|
|
- [ ] O tom é profissional e adequado para um documento formal de orçamento?
|
|
- [ ] É compreensível pelo **público-alvo do produto** sem conhecimento de TI?
|
|
|
|
---
|
|
|
|
## Regras de Redação
|
|
|
|
- **Sem jargões de TI**: trocar termos técnicos por equivalentes acessíveis (ex: "painel" em vez de "dashboard", "código QR" em vez de "QR Code")
|
|
- **Siglas por extenso**: toda sigla deve vir acompanhada do nome por extenso na primeira ocorrência
|
|
- **Tom formal mas acessível**: adequado para um documento de orçamento/proposta enviado a um diretor ou secretário
|
|
- **Funcionalidades concretas**: "Registro de leituras com cálculo automático de volume", não "Módulo de coleta de dados parametrizável"
|
|
|
|
---
|
|
|
|
## Formato de Saída
|
|
|
|
O arquivo `./COMERCIAL/<nome-do-modulo>-orcamento.md` deve seguir esta estrutura:
|
|
|
|
```markdown
|
|
# [Nome do Módulo]
|
|
|
|
[Apresentação do módulo — 2 a 4 linhas com legislação relevante, se aplicável]
|
|
|
|
## Funcionalidades incluídas
|
|
|
|
- **[Nome da funcionalidade 1]**: [descrição curta do que faz na prática]
|
|
- **[Nome da funcionalidade 2]**: [descrição curta do que faz na prática]
|
|
- **[Nome da funcionalidade 3]**: [descrição curta do que faz na prática]
|
|
- ...
|
|
```
|
|
|
|
*Exemplo:*
|
|
|
|
```markdown
|
|
# [Nome do Módulo]
|
|
|
|
[Apresentação do módulo com descrição direta do que faz, qual problema resolve e,
|
|
se aplicável, legislação ou norma relevante citada por extenso.]
|
|
|
|
## Funcionalidades incluídas
|
|
|
|
- **[Funcionalidade 1]**: [descrição curta do que faz]
|
|
- **[Funcionalidade 2]**: [descrição curta do que faz]
|
|
- **[Funcionalidade 3]**: [descrição curta do que faz]
|
|
- ...
|
|
```
|
|
|
|
---
|
|
|
|
## Referências
|
|
|
|
- Workflow: `agents/comercial/workflows/comercial` (descrição comercial detalhada — Resumo e Detalhamento)
|
|
- Workflow: `agents/comercial/workflows/marketing` (peças de marketing digital)
|
|
- Rule: `global/rules/escrita-natural` (padrão obrigatório de redação)
|