Toda semana alguém me pergunta: "qual IDE com IA você usa?". A resposta curta é "Cursor". A resposta real é que Cursor é só a interface. O que faz funcionar é um vault Logseq que serve de memória, skills compartilhadas entre IDEs, e um orquestrador que decide o que vai pra onde.

Esse orquestrador é o Grok Bot — uma feature do Cursor Pro+ que permite criar agentes especializados com instruções persistentes. Pense nele como um ChatGPT customizado que vive dentro do Cursor e pode chamar outros agentes ou te direcionar pra outra ferramenta.

Se você está pagando $20 aqui, $60 ali, e cada ferramenta vive numa ilha sem saber o que a outra fez ontem, esse post é pra você.

Índice

• 1. Um dia típico (como isso funciona na prática)
• 2. O que eu pago (e o que é grátis mas crítico)
• 3. A arquitetura (não as ferramentas)
• 4. Por que criei essa arquitetura (e os bots)
• 5. O cérebro: Logseq hub-first
• 6. Skills compartilhadas
• 7. Grok Bots: os especialistas
• 8. MCPs: o tecido conectivo
• 9. Agents no Kiro: roster enxuto
• 10. Quando uso cada ferramenta
• 11. O que isso me dá
• 12. O que não funcionou
• 13. Como começar

1. Um dia típico (como isso funciona na prática)

Kiro — trabalho técnico do squad

8h — daily do time. Peço: "PRs abertos do projeto". Sonnet 5 consulta o Azure DevOps via MCP, me mostra 4 PRs. Dois são do Iago (micro-PRs de feature, padrão dele), um do Tryelson (fluxo de cadastro), um da Miriam (reembolso). Escolho revisar o da Miriam porque tem regra de negócio.

O steering team-routing já carregou automaticamente. Ele tem uma matriz por dev: "Miriam: back, reembolso/my_purchases, commits às vezes sem escopo. Sugerir escopo no conventional commit quando faltar." O agent sabe que não vai cobrar teste unitário dela (é o padrão do time), mas vai sugerir feat(reembolso): no commit.

8h30 — code review. Carrego clean-code-review (skill). O agent lê o diff, aplica as lentes (KISS, YAGNI, SRP, segurança, LGPD), e sugere dois comentários. Um sobre nomenclatura de variável, outro sobre uma validação que podia ser extraída pra método.

A skill tem 15 versões. A v1 era "aplica KISS e YAGNI". A v15 atual sabe que "Iago faz micro-PRs sem testes (é o padrão dele, não cobrar)", que "Bernardon usa títulos só com código do card (pedir título rastreável)", e que "Tryelson responde bem a apontamento técnico preciso". Não é regra genérica, é contexto calibrado pro time.

10h — bug de produção. Chega card VADM-1234: seller não consegue sacar. Troco pra Opus 5 — correlacionar logs de 4 fontes precisa de raciocínio mais denso. Carrego incident-analysis (skill).

A skill define o fluxo: 1) busca no Jira (descrição, anexos, comentários do QA), 2) acha PR relacionado no Azure DevOps, 3) puxa logs do Grafana no horário do bug, 4) eventos do Sentry, 5) query no banco PRD. Obrigatório: criar pages/incidentes/VADM-1234.md no Logseq antes de codar. Em 3 minutos tenho a hipótese: campo withdrawal_status null em contas criadas antes de março.

Cursor — projetos pessoais e escrita

14h — artigo DEV.to. Chamo o Grok Bot Vitrine com Opus 5 (thinking alto): "continua o draft do AI tools stack". Ele sabe onde parou porque o contexto tá no Logseq.

Carrega write-for-dev-community (steering). Essa steering define: voz Montanha (tech + empatia + clareza), gate editorial (G0: simplifica, G1: máximo 1 bloco defensivo, G2: título responde o hook, G3: CTA comentável), estrutura DEV.to (H2 numerados com tese, artefato no miolo, sem ## Introdução). Antes de entregar, o agent roda o checklist: "soa dev pra dev? admite limite? parece Montanha ou clone de Deschamps?". Se falhar, reescreve.

21h — side project. Abro o Quinto (app de gastos da família) ou o LotRace (jogo de tabuleiro PWA, 2–6 jogadores por código). Opus 5 no Composer.

O Quinto tem seu próprio steering: quinto-context (stack: React Native, SQLite local, sync opcional). O LotRace tem lotrace-context (stack: Vite React, boardgame.io, Railway + Vercel). Mesma arquitetura do trabalho, contexto diferente. Codar em casa com a mesma fluidez.

ChatGPT — comunicação, estudos e planning

18h30 — mentoria. Uso GPT-6 Astra. Preparo o material da sessão com o mentorado. Crio uma planilha de acompanhamento. ChatGPT não tem MCP nem skills, mas Canvas funciona bem pra documentos colaborativos. O contexto de mentoria fica isolado do trabalho.

19h30 — faculdade. Ainda no ChatGPT, agora como Agentic IA. Estudo pra disciplina da semana, peço explicações, resolvo exercícios. O modelo pensa junto, não só responde. Se preciso de algo do vault, copio manualmente — é o preço da separação.

Grok Bot — orquestração e acesso remoto (Mac + celular)

12h — almoço fora do escritório. Recebo notificação de alerta no Sentry pelo celular. Abro o Grok Bot no app do Cursor (iOS), peço "verifica o alerta X no Sentry e me dá o resumo". Ele acessa o Mac remotamente, roda os MCPs, e me manda a síntese: erro de timeout no serviço Y, 23 ocorrências, não é crítico. Decido esperar voltar.

16h — na fila do banco. Lembro que preciso revisar o draft do artigo. Pelo celular: "qual o status do draft AI tools stack?". Grok Bot consulta o Logseq via MCP, me diz que falta a seção de MCPs. Anoto mentalmente, não preciso abrir laptop.

22h — no Mac, fechando o dia. Abro o Grok Bot no Cursor: "o que ficou pendente hoje?". Ele carrega o steering daily-vadm (relatório diário, visão de TL) e lista: 1 PR aguardando CI, draft do artigo precisa de revisão, email do mentorado sem resposta. Priorizo o que vai pra amanhã.

O Grok Bot é o único que uso em dois contextos: no Mac (orquestração pesada, execução via Cloud Agents e shell) e no celular (consultas rápidas, acesso remoto aos MCPs). É o hub que conecta os outros harnesses.

O ponto: não copiei um link entre ferramentas o dia inteiro. O contexto fluiu. As skills e steerings fizeram o trabalho pesado: saber o estilo de cada dev, o tom do artigo, o fluxo de investigação, o contexto de cada projeto.

2. O que eu pago (e o que é grátis mas crítico)

Total pessoal: $80/mês. O Logseq é gratuito, mas é a peça mais crítica. Sem ele, as outras três são ilhas.

O Cursor Pro+ a $60 parece caro comparado com outras opções, mas é o único que me dá acesso aos Grok Bots — agentes especializados com instruções persistentes.

3. A arquitetura (não as ferramentas)

A maioria dos artigos de "Cursor vs Copilot vs Kiro" trata cada ferramenta como ilha. O meu setup funciona diferente:

O ponto: Kiro e Cursor consultam o mesmo cérebro e seguem as mesmas regras. ChatGPT fica isolado pro pessoal. Grok Bot decide o que vai pra onde.

4. Por que criei essa arquitetura (e os bots)

A pergunta óbvia: "por que não usar só Cursor e pronto?".

O problema que eu tinha:

• Contexto perdido: toda sessão começava do zero. Explicava o projeto, as convenções do time, as decisões passadas.
• Ilhas desconectadas: Cursor não sabia o que eu fiz no ChatGPT ontem. ChatGPT não sabia do PR que fechei no Kiro.
• Repetição de regras: cada ferramenta tinha suas regras. Mudava uma, esquecia de mudar nas outras.
• Trabalho vazando pro pessoal: às 22h no ChatGPT aparecia contexto do trabalho. Às 8h no Cursor aparecia coisa pessoal.

O que eu queria:

1. Uma memória central que todas as ferramentas consultam
2. Skills que evoluem e valem em todos os lugares
3. Separação clara entre trabalho/dev pessoal/vida
4. Um ponto de orquestração que sabe o que vai pra onde

Por que bots especializados (não um bot genérico):

Um bot genérico tenta fazer tudo e acaba medíocre em tudo. Cada bot meu tem:

• Contexto delimitado: o bot de artigos não sabe do trabalho, o bot do trabalho não sabe dos hobbies
• Instruções específicas: o Vitrine sabe do tom DEV.to, o Código sabe do CI da empresa
• Menos alucinação: quanto mais específico o domínio, menos o modelo inventa

O pattern que emergiu:

Generalista (Chefe de gabinete)
    └── decide qual especialista chamar
         ├── Código (PRs, CI)
         ├── Vitrine (artigos, GitHub)
         ├── Inbox (emails, agenda)
         └── [domínio] (hobby, side project)

Não planejei assim. Comecei com 1 bot, vi que ficava sobrecarregado, fui separando por domínio. Depois de 6 meses: 8 bots, cada um com sua especialidade.

O custo de manter isso:

• ~2h/mês refinando skills
• ~1h/mês ajustando steerings
• ~30min/semana sincronizando vault

Compensa porque economizo isso toda semana em "deixa eu te explicar o contexto de novo".

5. O cérebro: Logseq hub-first

Muita gente associa RAG com embeddings e pgvector. O meu é mais simples: um vault Logseq com convenção de hubs.

5 scopes, 5 hubs:

Regra hub-first: qualquer pergunta de domínio começa pelo hub do scope. O agent abre o _hub.md, segue os links canônicos, e só então faz grep se precisar.

Separação código vs memória:

Código/arquitetura  →  Graphify (code graph)
Memória/domínio     →  Logseq (hub-first)

Pergunta sobre como funciona o PaymentService? Graphify. Pergunta sobre o que decidi no incidente VSUS-755? Logseq.

Por que não embeddings?

• Git-versioned: posso ver o que mudou e quando
• Sem drift: o texto é o texto, não um vetor que dessincroniza
• Debugável: se o agent errou, leio o hub e vejo o que ele devia ter seguido
• Cross-harness: Kiro e Cursor leem via MCP; ChatGPT recebe contexto manual

Embeddings ficam no roadmap. Hub-first resolve 95% dos casos e custa zero infra.

6. Skills compartilhadas

Tenho ~30 skills em ~/.cursor/skills/. Kiro e Cursor apontam pro mesmo path — refino uma vez, vale nos dois.

As que mais uso

AppSec: a skill que mais evoluiu

A security-audit é a skill que mais refinei. Ela audita código contra OWASP ASVS 5.0 com dois modos:

• STATIC (padrão): lê código, não faz request. Busca auth, input validation, secrets, injection, data exposure.
• DYNAMIC-AUTHORIZED: só em lab/CTF ou com autorização explícita. Humano no loop antes de qualquer request.

Não é só prompt. A skill consulta o KB (Logseq) e tem runbooks vinculados:

security-audit/
├── SKILL.md              # prompt principal
├── PROMPT.md             # procedimento de auditoria (o SKILL.md manda seguir)
├── docs/
│   ├── falso-positivo.md      # triage: código existe? requisito existe? path alcançável?
│   └── uso-em-codigo-terceiros.md  # regras de disclosure
├── bounty-exclusions.md       # filtro pra bug bounty (Stripe HackerOne)
└── references/sources.md      # fontes primárias (OWASP, Google Eng Practices)

O framework de disclosure tem três portas:

1. Exploitable → canal privado (SECURITY.md, email do maintainer). Nunca issue público.
2. Hardening → issue público (lockfile, versões flutuantes). Não é exploitable, é higiene.
3. Dúvida → trata como exploitable.

Hunt mode: uma invariante por vez, todos os paths que chegam no recurso protegido, denominador no resultado ("verificado 47 de 52 paths, 1 gap"). Uso pra IDOR cross-tenant, idempotência de operações de dinheiro, verificação de assinatura de webhook.

Code review: o case que impediu um go-live

A clean-code-review também consulta KB e tem runbooks vinculados:

clean-code-review/
├── SKILL.md              # prompt + lentes (KISS, YAGNI, DRY, SRP, segurança, LGPD)
├── team-profiles/        # perfil por dev (consultado via KB)
│   └── vadm.md           # Iago: micro-PRs; Bernardon: título só com card; Miriam: commits sem escopo
├── domain-rules/         # regras por domínio
│   └── payment.md        # idempotência, retry, validação de período
└── checklists/
    └── pre-approve.md    # checklist antes de aprovar (segurança, LGPD, regra de negócio)

O case: numa sexta-feira, a skill revisou um PR de reembolso. O código estava limpo, testes passando, CI verde. Mas a skill consultou domain-rules/payment.md e identificou que faltava uma validação: o período de carência de 7 dias pós-graduação não estava sendo checado.

O comentário foi direto: "Regra de negócio incompleta. O fluxo de reembolso pós-graduação exige validação de carência de 7 dias. Esse path não verifica." O dev confirmou, adicionou a validação, e o PR foi aprovado na segunda.

Se tivesse ido pra produção, sellers de pós-graduação teriam conseguido reembolso fora do período permitido. A skill pagou o investimento naquela semana.

O pattern: skill + KB + runbooks

Skill (prompt)
    ├── consulta KB (Logseq via MCP)
    │     └── domínio, decisões passadas, contexto do time
    ├── runbooks vinculados
    │     └── checklists, triage, disclosure, regras por domínio
    └── evolução versionada
          └── v1 → v15, calibrada pro contexto real

Skill sem KB é prompt genérico. Skill com KB conhece o projeto.

Steerings: regras que disparam sozinhas

Skills eu ativo manualmente. Steerings disparam por contexto — quando leio um arquivo, quando o assunto casa com a descrição, ou estão sempre ligadas.

As que mais economizam tempo no Kiro:

Exemplo real: dashboard de monitoramento em 20 minutos.

Pedi pro Kiro criar um dashboard de acompanhamento de task VGAT-622. A steering grafana-dashboard-patterns disparou porque o assunto casou com o fileMatch. Ela trouxe:

• Regra 1: "Nunca usar patches incrementais. Upload JSON completo com overwrite: true."
• Regra 2: "Labels obrigatórios Loki: container + namespace. Só namespace não renderiza."
• Regra 10: "Títulos em linguagem de negócio: '📄 Boletos Enviados (de 322)', não 'sales_count_prd'."

O agent gerou o JSON seguindo as 10 regras. Eu validei, fiz upload, funcionou de primeira. Sem a steering, eu teria descoberto essas regras por tentativa e erro.

Exemplo real: card de bug do Sentry em 30 segundos.

Chegou alerta no Sentry: erro 500 no checkout. Mencionei no Kiro. A steering jira-issue-naming (always-on) já estava carregada. O agent consultou a convenção:

Origem Sentry → título: [ Sentry - FRONT ] [ÁREA] Descrição
Sistemas: ADM, CHECKOUT, KYC
Módulo inferido do domain tag: payment → [Checkout]

Criou o card: [ Sentry - FRONT ] [CHECKOUT] Erro 500 ao processar pagamento PIX. Com link pro issue Sentry na descrição, stacktrace formatado, labels Sentry + frontend + payment. Eu só revisei e confirmei.

A diferença skill vs steering:

Tenho ~40 steerings. A maioria é always-on (regras gerais como language-pt-br, no-assumptions). Umas 10 são fileMatch ou auto (disparam por contexto).

7. Grok Bots: os especialistas

O Grok Bot do Cursor Pro+ me dá acesso a criar bots especializados. Meu time:

Limitação honesta: o Grok Bot não pilota as UIs. O que ele faz:

• Cursor Cloud Agents → cria PRs no GitHub (funciona)
• Shell Mac → executa CLI com minha aprovação
• Handoff estruturado → me diz o que fazer, eu abro a UI

Não é mágica. É orquestração com humano no loop.

8. MCPs: o tecido conectivo

Model Context Protocol permite que Kiro e Cursor falem com sistemas externos.

Cursor (10 MCPs):
graphify, logseq-kb, mcp-atlassian, azure-devops, grafana, sentry, context7, git, browser-tools, teams

Kiro (14 MCPs, mais produção):
graphify, logseq-kb, mcp-atlassian, azure-devops, sentry, mysql-prd-readonly, dev-to, datadog, context7 + bancos DEV/HML, OneSignal, Playwright (disabled)

ChatGPT: sem MCP. Contexto manual. Forte em mentorias, planilhas, Canvas.

Exemplo real de investigação de bug: recebo o card no Slack. No Kiro:

1. jira_get_issue → pega descrição, anexos, comentários do QA
2. repo_pull_request → acha o PR relacionado (se existir)
3. grafana → logs do serviço no horário do bug
4. sentry → stacktrace se teve exception
5. mysql_query → query no banco pra confirmar hipótese
6. logseq_write_file → documenta hipótese no vault

Tudo sem trocar de aba. O contexto fica no vault, não no meu cérebro.

9. Agents no Kiro: roster enxuto

Cap duro: ≤3 agents. Domínio fica em skills, não em mais agents.

Por que só 3? Agent é caro (contexto, latência). Skill é barata (texto sob demanda). O pattern: agent orquestra, skill informa.

10. Quando uso cada ferramenta

A regra: trampo → Kiro. Dev pessoal → Cursor. Vida → ChatGPT. Fora do PC → Grok Bot mobile.

11. O que isso me dá

1. Contexto persistente: não re-explico o projeto a cada sessão
2. Skills que evoluem: refinei code review 15 vezes, vale em todos os harnesses
3. Separação clara: trabalho não vaza pro ChatGPT
4. Orquestração real: Chefe de gabinete sabe quando me chamar
5. Custo justificado: $80/mês = menos de 2 horas de freela

12. O que não funcionou

Nem tudo virou padrão:

O pattern: começo ambicioso, corto quando o custo supera o benefício.

13. Como começar

1. Escolhe um vault: Logseq, Obsidian, pasta de markdown. Git-versioned é bônus.

2. Define scopes: ops, carreira, pessoal. Cada scope tem um hub.

3. Compartilha skills: aponta Cursor e Kiro pra mesma pasta.

4. Configura MCPs: começa com Jira ou GitHub.

5. Limita agents: 3 é suficiente.

6. Separa pessoal de trabalho: não mistura harnesses.

7. Documenta o que não funcionou: evita repetir erro.

Checklist mínimo pra semana 1:

[ ] Criar pasta `~/vault/` com 3 hubs: ops/_hub.md, carreira/_hub.md, pessoal/_hub.md
[ ] Instalar MCP do Jira ou GitHub no Cursor
[ ] Criar 1 skill em `~/.cursor/skills/` (pode ser só o contexto do projeto)
[ ] Definir regra: "trabalho = IDE X, pessoal = IDE Y"
[ ] Usar uma semana e anotar o que não funcionou

Gists relacionados:

• Diagrama completo da arquitetura
• Token layers — o que corta token vs o que protege o mapa
• Tool access gate — 7 perguntas antes da tool entrar no agente

A pergunta "qual IDE com IA você usa?" está errada. A pergunta certa é: "como suas ferramentas de IA conversam entre si?".

Se não conversam, você está pagando por ilhas.

Qual é o primeiro passo que faz sentido pra você — vault unificado, skills compartilhadas, ou MCPs?