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, que permite criar agentes especializados com instruções persistentes dentro do Cursor. Pense nele como um ChatGPT customizado que vive dentro do Cursor: orquestra Cloud Agents, executa shell, e me avisa o que precisar de atenção. Com Kiro e ChatGPT, sou eu quem carrega o contexto manualmente.
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. A arquitetura (não as ferramentas)
- 2. Por que criei essa arquitetura
- 3. O cérebro: Logseq hub-first
- 4. Skills e steerings: regras que escalam
- 5. Grok Bots e agents: orquestração
- 6. MCPs: o tecido conectivo
- 7. Como isso aparece num dia típico
- 8. O que eu pago
- 9. O que não funcionou
- 10. Como começar
1. 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. O Grok Bot orquestra dentro do Cursor — com Kiro e ChatGPT, sou eu quem conecta os contextos.
2. Por que criei essa arquitetura
O problema que eu tinha:
- Contexto perdido: toda sessão começava do zero
- Ilhas desconectadas: Cursor não sabia o que eu fiz no ChatGPT ontem
- Repetição de regras: mudava uma config, esquecia de mudar nas outras
- Trabalho vazando pro pessoal: às 22h aparecia contexto do trampo no chat pessoal
O que eu queria:
- Uma memória central que todas as ferramentas consultam
- Skills que evoluem e valem em todos os lugares
- Separação clara entre trabalho/dev pessoal/vida
- Um ponto de orquestração que sabe o que vai pra onde
Por que bots especializados (não um bot genérico):
Esses bots vivem no Grok Bot. O ## 5 mostra cada um com seu papel. O ponto aqui é o porquê de criar vários ao invés de um só.
Um bot genérico tenta fazer tudo e acaba medíocre em tudo. Cada bot meu tem contexto delimitado, instruções específicas, e 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)
Enter fullscreen mode Exit fullscreen mode
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.
3. 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.
Scope Hub O que vive alipessoal
pessoal/_hub.md
Identidade, valores, mentoria, hobbies
carreira
carreira/_hub.md
Portfolio, Staff track, artigos
ops
ops/_hub.md
Incidentes, runbooks, squads
meta
meta/rag-contract.md
Regras do vault, contratos
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:
- Pergunta sobre como funciona o
PaymentService? → Graphify (code graph) - Pergunta sobre o que decidi no incidente X? → Logseq (hub-first)
Por que não embeddings? Git-versioned, sem drift, debugável, cross-harness. Embeddings ficam no roadmap. Hub-first resolve a maior parte dos meus casos e custa zero infra.
4. Skills e steerings: regras que escalam
Tenho ~30 skills em ~/.cursor/skills/. Kiro e Cursor apontam pro mesmo path — refino uma vez, vale nos dois.
Skills: ativo manualmente
Skill O que fazsecurity-audit
OWASP ASVS 5.0, três portas de disclosure, hunt mode pra IDOR
clean-code-review
Lentes KISS, YAGNI, DRY, SRP + contexto calibrado pro time
incident-analysis
Fluxo Jira→ADO→Grafana→Sentry→banco, incident graph obrigatório
write-for-dev-community
Voz editorial, gate G0-G3, estrutura DEV.to
O pattern: skill + KB + runbooks. A skill security-audit não é só prompt — ela consulta o vault e tem docs vinculados: triage de falso-positivo, regras de disclosure, filtros de bounty.
Case real: numa sexta-feira, a skill de code review pegou um PR de reembolso com CI verde. Mas consultou as regras de domínio e identificou que faltava uma validação de período de carência. O comentário foi direto, o dev corrigiu, e evitou um bug em produção. Skill pagou o investimento naquela semana.
Exemplo real de skill (sanitizado): clean-code-review no gist — mostra a estrutura, o prompt principal e como o contexto do time é consultado.
Steerings: disparam sozinhas
Steering Tipo O que fazjira-issue-naming
always
Convenção de título padronizada
grafana-dashboard-patterns
fileMatch
10 regras pra criar dashboard
confluence-page-location
always
Sabe onde cada doc deve ir
A diferença:
Skill Steering Ativação Manual Automática Escopo Domínio amplo Tarefa específica Compartilha Kiro + Cursor Só Kiro (por enquanto)5. Grok Bots e agents: orquestração
Grok Bots
Bot Papel Chefe de gabinete Orquestra, corta escopo Código PRs pequenos, CI verde Vitrine GitHub profile, DEV.to Inbox Gmail + Calendar em lote AppSec Dependabot, Sentry quente + 3 side projects Quinto, LotRace, IronToyLimitação honesta: o Grok Bot vive dentro do Cursor — não pilota Kiro nem ChatGPT. Ele executa Cloud Agents e Shell, e me diz o que fazer nos outros harnesses. A conexão entre eles sou eu.
Agents no Kiro
Cap duro: ≤3 agents. Domínio fica em skills, não em mais agents.
Agent Modelo Papelmontanha-staff
Opus 5
Gate Staff: SHIP/REVISE/SPLIT
back-specialist
Sonnet 5
Backend
front-specialist
Sonnet 5
Frontend
Por que só 3? Agent é caro (contexto, latência). Skill é barata (texto sob demanda). O pattern: agent orquestra, skill informa.
6. MCPs: o tecido conectivo
Model Context Protocol permite que Kiro e Cursor falem com sistemas externos.
Cursor: graphify, logseq-kb, jira, azure-devops, grafana, sentry, context7, git, browser-tools
Kiro: graphify, logseq-kb, jira, azure-devops, grafana, sentry, context7, git, browser-tools
ChatGPT: no meu setup, o contexto ainda é manual. Forte em mentorias, planilhas, Canvas.
Exemplo de investigação: recebo um card de bug. No Kiro:
-
jira_get_issue→ descrição e anexos -
repo_pull_request→ PR relacionado -
grafana→ logs do horário -
sentry→ stacktrace - banco → confirma hipótese
-
logseq_write_file→ documenta no vault
Tudo sem trocar de aba. O contexto fica no vault, não no meu cérebro.
7. Como isso aparece num dia típico
Manhã — trabalho técnico (Kiro)
8h — Peço “PRs abertos”. O agent consulta Azure DevOps via MCP, mostra 4 PRs. O steering de contexto do time já carregou — ele sabe o padrão de cada dev e ajusta os comentários de review.
8h30 — Code review. Carrego a skill. O agent lê o diff, aplica as lentes, sugere dois comentários. Um sobre nomenclatura, outro sobre validação que podia ser extraída.
10h — Bug de produção. Troco pra Opus 5. Carrego incident-analysis. Em 3 minutos: hipótese documentada no vault.
Tarde — projetos pessoais (Cursor)
14h — Artigo DEV.to. Chamo o Grok Bot Vitrine: “continua o draft”. Ele sabe onde parou porque o contexto tá no Logseq. A steering editorial define tom, gates, estrutura.
21h — Side project. Cada projeto tem seu próprio steering de contexto. Mesma arquitetura do trabalho, domínio diferente.
Noite — vida (ChatGPT)
18h30 — Mentoria. Canvas pra material colaborativo. Contexto isolado do trabalho.
19h30 — Faculdade. Estudo, exercícios. Se preciso de algo do vault, copio manualmente.
Mobile — consultas rápidas (Grok Bot)
12h — Almoço fora. Alerta no Sentry. Pelo celular: “verifica o alerta X”. Grok Bot roda no Mac, consulta os MCPs, me manda síntese.
O ponto: não copiei um link entre ferramentas o dia inteiro. O contexto fluiu.
8. O que eu pago
Ferramenta Custo/mês Quem paga Pra quê Logseq $0 — RAG central Kiro ~$20 — Trampo Cursor $60 Eu Grok Bots + modelos de ponta ChatGPT $20 Eu PessoalTotal pessoal: $80/mês. O Logseq é gratuito, mas é a peça mais crítica. Sem ele, as outras três são ilhas.
Custo de manter:
- ~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”.
9. O que não funcionou
Tentei Por que não ficou Embeddings Overhead, drift, difícil debugar Mais de 3 agents Latência e custo. Passei de 6 pra 3 Dois code-read tools juntos Confusão de contexto ChatGPT pra trabalho Contexto manual no meu setup, virou cópia/cola Grok Bot pilotando UIs Não existe APIO pattern: começo ambicioso, corto quando o custo supera o benefício.
10. Como começar
- Escolhe um vault: Logseq, Obsidian, pasta de markdown. Git-versioned é bônus.
- Define scopes: ops, carreira, pessoal. Cada scope tem um hub.
- Compartilha skills: aponta Cursor e Kiro pra mesma pasta.
- Configura MCPs: começa com Jira ou GitHub.
- Limita agents: 3 é suficiente.
- Separa pessoal de trabalho: não mistura harnesses.
- Documenta o que não funcionou: evita repetir erro.
Checklist mínimo pra semana 1:
[ ] Criar pasta ~/vault/ com 3 hubs
[ ] Instalar MCP do Jira ou GitHub no Cursor
[ ] Criar 1 skill (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
Enter fullscreen mode Exit fullscreen mode
Gists relacionados:
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?
