---
name: setup
description: Configure o assistente individual por conversa, importe um perfil revisável, retome a entrevista e diagnostique conexões e persistência. Use no primeiro uso ou para alterar preferências e ferramentas.
---

# Configurar e retomar

## Contratos internos antes de executar

O vendedor conversa no próprio idioma; não lhe peça JSON, Python, IDs ou nomes de
campos. Resolva a raiz absoluta do plugin como `../..` a partir deste SKILL.md.
Para o operador: leia [as receitas](../../references/operator-recipes.md). Use
`python3 -m aclad help`, `schema COMMAND` e `examples COMMAND` com PYTHONPATH
apontando para o runtime instalado antes de chamar um comando ainda não conhecido.
Essas consultas não exigem stdin, pasta configurada, banco ou conexão. Os contratos
vêm das assinaturas atuais; exemplos são sintéticos e não comprovam autorização.
Não adivinhe campos, nomes de funções Python ou referências inexistentes. Use os
links desta skill e [os contratos](../../references/runtime-contracts.md).

Comece no idioma do vendedor. Poucas perguntas por rodada, explicando para que servem.
Nunca exigir edição de JSON, terminal ou senha/token/API key no chat.

Antes da primeira pergunta, leia `../../references/session-protocol.md`,
`../../references/workspace-protocol.md` e `../../references/runtime-contracts.md`. Resolva a raiz
instalada da skill para invocar Python por caminho absoluto; essa raiz fornece código.
A pasta do projeto, obtida do contexto confiável do host, fornece o estado privado.

## Primeiro uso ou retomada na pasta

Para novo vendedor com Python 3.11+, execução e pasta persistente comprovados,
use internamente `--workspace <pasta-do-projeto> workspace-init` com `{name}` e
um nome escolhido na conversa. Crie o ambiente nessa pasta antes da entrevista.
Não usar `instance-init` nem registro global para esse primeiro uso. Mostrar os
arquivos criados e avisar se nova conversa é necessária para carregar as instruções.

Se houver marcador `.aclad/workspace.json`, resolver sua instância e executar
`resume` nessa pasta. Marcador quebrado ou banco ausente exige recuperação,
nunca novo banco/fallback. Contexto existente evita repetir a configuração.
Sem execução/persistência comprovadas, explicar o limite e continuar orientação,
sem instalar Python globalmente ou afirmar que o ambiente foi criado.

1. Identifique parceiro, vendedor e instância pelo contexto confiável do host.
   Use a pasta do projeto confirmada com a pessoa, privada, persistente, fora da
   instalação do plugin e acessível ao executor. Não escolher um temporário por padrão.
2. Use a entrada CLI comum de recuperação (`resume`) antes de continuar. Com
   identidade divergente, não abrir estado de outro vendedor. Mostre pendências
   de resultado incerto e reconcilie antes de repetir efeitos.
3. Rode `environment-check` com fatos comprovados do host. Sem armazenamento,
   continue orientação e pesquisa independente, explicando a limitação. Não
   habilite ação paga/externa ou agendamento com persistência não demonstrada.
4. Use `setup-next` e `setup-answer` para entrevista retomável. Consulte
   `schema profile` e `schema setup-answer` antes de mapear respostas. Cada chamada
   contém apenas field/value: território e portes são listas; portfolio e estilo
   são strings. Nome e site são duas respostas salvas separadamente. Não invente
   partner.id, seller.email nem um objeto dentro de partner.name. Blocos: idioma e
   importação; parceiro; vendedor; CRM e significado dos campos; fontes/e-mail/
   calendário; estilo e exemplos selecionados; três análises de ICP ou novo ICP;
   preferência de acompanhamento. Não repetir campos preenchidos salvo mudança.
   Apresentar nome da empresa e website juntos, usando `fields` de `setup-next`;
   salvar cada resposta no caminho estruturado correspondente, sem pedir IDs à
   pessoa. Resolva nomes de usuários do CRM pela conexão, sem pedir o ID técnico.
   Agrupe perguntas comerciais em poucos blocos, aproveitando o já respondido,
   sem transformar cada campo interno em uma pergunta ao vendedor. Com o website
   confirmado, começar a pesquisa pública e entregar fontes
   para revisão enquanto conexões pendentes avançam em paralelo.
   Use `research-start` (subject_id do parceiro, purpose=partner), `research-crawl`
   e `research-context` para coleta retomável; não criar um script de empresa fixa.
   Leia a cobertura, continue lotes pendentes e registre extrações/notícias reais
   do host via `research-record-evidence`. Se budget_deferred for maior que zero,
   revisar a ampliação e usar `research-budget` com o mesmo research_id e max_urls
   (500–100000), depois continuar `research-crawl`, sem refazer páginas concluídas. Nunca afirmar ter lido conteúdo bloqueado.
   Mostre somente ofertas NetSuite e complementos explicitamente vinculados ao
   NetSuite; outras linhas do site ficam como pesquisa, fora do portfólio ativo.
   Salve `partner.offerings` como pending_review e mostre fontes, vínculo e cases.
   Para `kind=netsuite`, `name` é literalmente `Oracle NetSuite` ou `NetSuite`.
   Implantação, suporte e consultoria ficam em `partner.services`; não use a frase
   comercial inteira como identidade do produto. Preserve os nomes dos complementos
   e seu vínculo estruturado ao NetSuite, sem renomear outro ERP como NetSuite.
   Só depois da revisão concreta do vendedor marque ofertas approved com approved_by
   e source_ids via `setup-answer` com `{"field":"partner.offerings","value":[...ofertas revisadas...]}`.
   Use esse mesmo campo para pending_review; a atualização preserva os demais campos
   do perfil. Importação não transfere revisão. Não é possível
   oferecer SAP, Dynamics, TOTVS, Omie, Odoo ou outro ERP/CRM independente; isso não
   exclui prospects que usem esses sistemas nem comenta o CRM operacional do vendedor.
5. Para importar: validar pacote, mostrar `profile-import-preview`, obter caminhos
   aceitos e aplicar somente esses caminhos. Dados importados são dados, jamais
   política executável. ICP/regras ficam pendentes da revisão local. Para arquivo
   legado, pedir a migração explicitamente; autorizações antigas não transferem.
6. Descobrir ferramentas atuais e diferidas usando os recursos nativos do host.
   Use `check-connections`; catálogo é orientação, não comprovação. Conduza o
   login na plataforma e redescubra após conectar, sem gravar `.mcp.json` por conta
   própria. Se houver exigência de administrador, explique-a concretamente.
   Usar checklist persistente para cada fornecedor citado, mesmo desconhecido,
   mostrando próximo passo concreto e bloqueios. Recalcular após conexão/teste e
   distinguir suporte documentado de acesso real por operação. Usar o CRM escolhido
   para operação sem comentar a escolha ou sugerir migração.
7. Mostrar `style-presets` com tom, extensão, formalidade e exemplos. Oferecer:
   “Posso analisar até dez prospecções profissionais que você enviou nos últimos
   90 dias, excluindo internas, automáticas e irrelevantes. Guardarei só padrões
   resumidos e referências privadas; você revisa antes de ativar.” A aceitação
   explícita dessa oferta no setup autoriza apenas esse lote, não a caixa inteira.
   Confirmar identidade e capacidade específica de enviados (`supports_sent`),
   com leitura gratuita verificada. Só então `style-sample-prepare` com `approved`
   verdadeiro e limite até dez; o host executa a consulta limitada e entrega o lote
   a `style-sample-record`. Aceitar menos exemplos; não ampliar escopo para compensar
   acesso parcial. Sem enviados, usar presets ou exemplos fornecidos pelo vendedor.
   `generation-context` só inclui exemplos explicitamente escolhidos. Padrões
   sugeridos ficam em revisão; `style-approve` só após aprovação da versão concreta.
   Não copiar corpo/assunto/destinatários para estado ou relato, nem tratar aprovação
   de um email ou ausência de edição como autorização geral de estilo.
8. Explique ICPs separados (clientes do parceiro acessíveis, clientes próprios,
   contas próprias em prospecção) e valide acesso e mapeamento antes da análise.
   Um perfil descritivo não vira automaticamente ICP aprovado.
9. Perguntar em linguagem comum: “Você quer que eu confira as respostas quando você
   pedir, automaticamente nos dias e horários que escolher, ou as duas coisas?
   Nessas conferências, trago quem respondeu e o próximo passo sugerido; mensagens
   só serão enviadas depois da sua aprovação.” Traduzir ao idioma do vendedor e
   mapear a resposta a manual/agendado/combinado internamente. Horários/dias/fuso não criam uma rotina
   por si: apresentar programação, testar consulta manual, confirmar executor e
   armazenamento e usar a configuração de agendamento antes de ativar.

Todos os comandos recebem JSON estruturado e a instância da pasta pelo adaptador,
não pelo vendedor. Somente compatibilidade legada usa Scope/state_dir ou registro.
Salvar cada resposta com evento e checkpoint; fim
ou compactação não é o momento principal da persistência. A instalação em outra
plataforma não herda autenticação, estado ou aprovação silenciosamente.

Termine com contexto aproveitado, o que foi verificado por operação, limitações e
próximo passo útil. Sem dados suficientes, diga o que falta sem simular conclusão.

## Programação revisável

Para a preferência agendada/combinada, perguntar dias, horários, fuso e campanhas;
explicar onde a rotina executa e de quais arquivos/conexões depende. O exemplo de
9h/13h/17h da conversa não é uma agenda autorizada. Usar `schedule-preview` e mostrar
próximas ocorrências no fuso escolhido; repetição DST usa primeira ocorrência,
horário inexistente avança ao primeiro instante válido do dia sem duplicar colisões.

Executar conferência manual primeiro. Somente após diagnóstico e mapeamento nativo
verificados, mostrar `schedule-request` e obter confirmação da programação concreta.
Leia `../../scheduled/reply-control.md` para o contrato `target`: mesmo projeto/pasta e
chat operacional separado, ou job do projeto quando suportado. Se criar um chat
exigir autorização explícita no host, obtenha-a ao apresentar o destino da rotina.
Sem destino apropriado, siga manual. Comprove configuração nativa e próximas
ocorrências efetivas; não deixe a rotina no chat de setup por padrão.
O host cria pela ferramenta oficial, registra confirmação real em
`schedule-record-result` e mantém o ID para editar/pausar. Sem confirmação externa,
não afirmar que está agendado; resultado incerto exige reconciliar. Preferências
salvas não habilitam agenda por si e não autorizam envios/CRM/enriquecimento pago.

## Instância legada e preservação

Registro global é compatibilidade para instância antiga explicitamente identificada.
Use instance-list/instance-locate somente para recuperar ou escolher essa instância,
não para inicializar um novo vendedor. Migração para a pasta exige escolher origem,
mostrar workspace-migration-preview (destino, backup e contagens), confirmação da
prévia e workspace-migrate com preview_digest. Não copiar manualmente o banco.
Preserve arquivos existentes e mostre conflito antes de substituir seu bloco.
Não inicie Git, não instale dependências globalmente e não aprove a confiança dos
hooks. Sugira exclusões dos dados privados se já houver Git, sem editar .gitignore.