💬 Comandos e conversa

Toda mensagem que começa com / é comando. O orquestrador responde na hora, sem roteador, sem modelo, sem custo, e o texto nunca vira memória. O que não começa com / é conversa: passa pelo roteador em llama3.2 e vira resposta direta no Ollama ou job de agente. Os comandos se organizam em sete grupos, e é assim que o /ajuda os mostra.

Legenda: o caminho da esquerda para a direita é sempre o mesmo. O grupo só diz o que você está operando. Controle da conversa é a Trilha 4; os outros seis são deste módulo e do próximo.

Tudo que demora vira job numa fila em SQLite, separada em cinco lanes com concorrência própria. Jobs nunca são apagados: são o histórico. Quando um pedido "não responde", quase sempre ele está enfileirado atrás de outro na lane agente, que roda um por vez porque cada claude -p consome cerca de 500 MB de RAM.

Legenda: a coluna do meio é o que explica a espera. Duas respostas diretas em paralelo cabem; dois agentes, não.

Legenda: a primeira parte é o retrato por lane; a segunda, os 5 jobs mais recentes com #id lane/tarefa status. O #id é o que você usa em /status, /cancelar e /prioridade.

/status
/status <id-do-job>
/prioridade <id-do-job> 10
/cancelar <id-do-job>

Tarefas aqui são suas, não do bot: ficam na tabela tarefas_usuario, por chat. /tarefa add [quando] <texto> cria; se o começo do texto for uma data que o bot reconhece, ela vira lembrete e o resto vira o texto da tarefa. Sem data reconhecida, a frase inteira é a tarefa e não há lembrete.

Legenda: a data precisa vir no início, logo depois de add. "pagar o domínio amanhã 9h" não vira lembrete; "amanhã 9h pagar o domínio" vira. O fuso é o do processo (a máquina).

/tarefa add em 2 min <texto-da-sua-tarefa>
/tarefa lista
/tarefa feita <id-que-o-bot-devolveu>
/daily

Cron no v3 não é um processo à parte: cada ocorrência vira um job na fila com idem_key = nome@ocorrência. Se o serviço reiniciar no meio, a mesma ocorrência não dispara duas vezes. Cada cron declara a sessão: isolada (contexto limpo) ou principal (continua a conversa do chat, como o daily-8h). Os padrão são criados no boot, uma vez por nome; o que você desligar fica desligado.

Legenda: a ordem da madrugada importa: 3h30 decai, 4h consolida, 4h15 copia. O backup é sempre do estado já consolidado.

Dois comandos mostram o que está instalado e dois controlam o quanto o bot "carrega" da conversa anterior. /agentes lista cada agente de agents/<id>/ com o modelo e a marca "só leitura" quando for especialista; /skills lista as skills de skills/, e as de skills/_rascunhos/ aparecem com 📝 na frente. Skills entram no prompt só pela metadata (nome e descrição), não pelo corpo: é assim que o prompt não incha.

Legenda: nenhum dos dois toca a memória de longo prazo. O que se perde é conversa, não fato.

/agentes
/skills
/compress

Você não escolhe a rota: o roteador escolhe. Pedido que precisa de ferramenta (arquivo, shell, repo, web, skill, calendário) vai para a rota agente. O bot responde na hora com um briefing curto: o nome do agente, o número do job, quantos estão na frente e o lembrete de que /status N acompanha. Depois o worker roda claude -p --output-format json com o prompt em camadas (identidade, agente, memória, skills, mensagem), e a resposta volta pelo bus ao mesmo chat, com o custo real registrado.

Legenda: o caminho de cima é o comum. O ramo ciano acontece quando o roteador marca consultar: até 2 especialistas só leitura (ex.: research) rodam antes e o lead escreve a resposta final. Só o lead escreve.

Lê o README.md do repo ~/projetos/<nome-do-seu-repo> e me devolve, em 5 linhas, o que o projeto faz e como se roda. Não altera nada.
/status <numero-do-job-que-veio-no-briefing>
/usage