🏛️ iAmasters OS

Repo open-source (MIT) em português, multi-cliente nativo, com engine de memória (Sinapsis v4.5) que evolui com o uso.

É a primeira implementação pública e completa de Agentic OS multi-cliente em PT. Receita pronta.

Mantido por Angel Aparicio (IA Masters Academy), v0.6.0, vendor/sinapsis embedded.

Operador = pessoa que entrega trabalho para múltiplos clientes usando Claude Code como ferramenta-mãe.

Define o "shape" do produto. Se você é dev solo, é diferente; se você é freelancer com 5 clientes, é a luva.

Consultor, agência pequena, freelance, in-house de empresa pequena.

Camada 1 = skills do Claude Code pré-instaladas. Camada 2 = engine de memória/aprendizado vivendo em ~/.claude.

Separação importante: skills são "biblioteca", Sinapsis é "kernel". Cada uma evolui sozinha.

.claude/skills/, ~/.claude/skills/_operator-state.json, vendor/ no repo.

Claude Pro/Max + 4-8h de setup primeiro cliente. Cada cliente novo depois leva ~1h.

Te dá um número pra comparar com cobrar do cliente. Margem fica clara.

Custo marginal por cliente cai com escala, valor por skill que economiza minutos.

Script único que instala skills, configura cron diário, popula contexto base.

"Instala em 60s" é princípio de design. Se demora mais, simplifica.

install-gate.sh, install-state.template.json, idempotência total.

Otimizado pra macOS (Keychain, dscl, launchd, /Applications). Linux roda em modo degradado.

Decisão consciente. Foco em 1 plataforma = qualidade. Saber o que falta em outra = honestidade.

REVIEW.md §2 lista degradações, crontab manual em Linux, sem auto-redaction.

Pasta dedicada por cliente. clients/_templates/ tem o esqueleto. Cada cliente tem seus dados, projetos, contexto.

Multi-tenancy via filesystem = simples, auditável, sem ORM. Funciona desde 2 clientes.

Template como contrato, gitignore por cliente, exportar = zip.

Diretório separado com voice.md, positioning.md, icp.md, assets/. Cada cliente carrega o seu.

"Voz" misturada com contexto operacional vira papinha. Separado, vira ativo.

Carregado on-demand, version control natural, brand audit é diff.

me.md, work.md, team.md, current-priorities.md, goals.md, decisions-log.md, learnings.md, soul.md.

CLAUDE.md gigante quebra. 8 arquivos pequenos escalam, evoluem em paralelo.

Cada arquivo tem 1 responsabilidade. SessionStart lê os relevantes.

Cada projeto tem brief.md (status: active/paused/done), arquivos, sub-pastas. Sinapsis lê briefs ativos.

Estado de projeto vive no projeto. Não numa task tracker à parte.

Frontmatter como API, status enum, archive = mv pra pasta done/.

Skills e commands específicos do iAmasters OS vivem dentro do repo, vão pra git.

Skill curada compartilhada com time via git, não copy-paste manual.

six-hats, welcome, visual — 3 exemplos de skills. Comandos /eod, /dream.

Sinapsis (engine de memória) vive em vendor/ — fora dos seus arquivos mas dentro do repo.

Padrão vendor permite pin de versão. Atualiza quando quer, não quando upstream quebra.

Update via bun run vendor:update, semver respeitado, breaking changes auditadas.

Observações entram como nova entry. Editar = nova entry que invalida a anterior.

Histórico preservado. Auditoria trivial. Rollback é só ignorar entries recentes.

Event sourcing simples, timestamp como ordem, supersedes_id.

Job que rola 3h da manhã: pega últimas 24h de observações, escreve daily-summaries/, atualiza learnings.md.

Sem consolidação, dados crescem sem virar conhecimento. Dream = sleep do cérebro.

LLM como compactador, prompt de síntese padronizado, output em pasta dedicada.

Arquivo onde feedback de uso das skills vira regras de comportamento. Lido todo SessionStart.

É como o agente "aprende contigo" sem retreinar modelo. Tudo via texto.

Estrutura "Rule + Why + How to apply", limite ~5k tokens, decay automático.

/dashboard-sinapsis abre HTML com métricas: skills mais usadas, tempo economizado, learnings ativos.

"Acho que tá funcionando" não escala. Dashboard mostra.

SQL agregado, HTML gerado on-demand, abre no browser default.

Comandos instalados global (~/.claude/commands/) que controlam o engine: status, force-evolve, pause.

Controle granular sem editar config. Operador faz manutenção via chat.

Comando = arquivo markdown com prompt, /system-status para tudo.

SQLite (intelecto): busca rápida, dados estruturados. Sinapsis: append-only + sínteses LLM, evolui.

Sabendo onde cada um brilha, você compõe (SQLite pra cache, Sinapsis pra contexto).

SQLite = working memory, Sinapsis = long-term memory.

Script que verifica em que fase do setup você está, executa só o próximo passo, salva estado.

Onboarding "rode esse comando 7 vezes em ordem" não funciona. Gate é a solução.

Fases nomeadas (welcome, install-skills, configure-brand), idempotente, resume.

JSON com phase, completed_steps[], pending_steps[], started_at, version.

Estado em arquivo (não em memória) sobrevive a crash, interrupção, restart.

Template separado da instância, versionamento do schema, migrations.

Algumas fases (ex: configurar brand-context) bloqueiam o uso até completarem. Outras são opcionais.

Sem bloqueio, user pula essencial e depois reclama que "não funciona".

required: true no schema, mensagem clara do que falta.

Após install, o sistema executa 1 demo concreta (ex: gerar daily summary do dia 1).

"Funcionou" precisa ser visível em <5min, ou user nunca volta.

projects/welcome/, exemplo real, fallback se vazio.

install.sh roda quantas vezes precisar. Detecta o que já foi feito e só executa o resto.

User vai rodar de novo (errou senha, mudou de máquina). Não pode quebrar dados.

"if already exists, skip", backup antes de modificar, force flag explícita.

Detecta install_state.fresh=true e cumprimenta com checklist dos próximos 5 passos.

User cara a cara com terminal vazio = perdido. Mensagem de boas-vindas = ancoragem.

SessionStart hook, mensagem pull não push, fresh=false após primeiro turno.

Arquivo .md por dia com o que foi feito, decisões, próximos passos. Gerado pelo dream cycle.

Memória episódica acessível. Quando user pergunta "o que fizemos terça?", tem resposta.

Template fixo (achievements, decisions, blockers, next), formato markdown.

Primeira mensagem de cada sessão lê daily de ontem + briefs ativos e propõe continuação.

Fricção zero entre sessões. User não precisa lembrar onde parou.

SessionStart greeting, fallback se sem daily, respeitar /clear.

Comando manual que dispara o daily summary agora, sem esperar 3h. Útil antes de fechar laptop.

Fecha o dia explicitamente. Próxima sessão lê esse resumo, não o vazio.

Mesma lógica do cron, overwrite se rodar 2x no mesmo dia.

Dispara o dream cycle inteiro on-demand. Pega obs das últimas 24h e gera learnings + summary.

Útil em sessão de aprendizado intensa. "Acabei de descobrir algo, /dream agora pra fixar."

Síncrono (espera), custo de tokens visível, retry se LLM falhar.

/system-status: skills ativos, hooks, último dream, tamanho da memória. /analyze-session: resume a sessão atual.

Self-diagnóstico. User identifica problemas sem precisar ler logs.

Output formatado, indicadores de saúde (verde/amarelo/vermelho), CTAs.

Comando que olha learnings.md e promove os mais recorrentes para CLAUDE.md (regra firme).

Aprendizado vira regra. Sistema melhora sozinho ao longo do tempo.

Threshold de recorrência, confirmação humana antes de promover, audit log.

clients/_templates/, install-gate, context/ sectorizado, daily summary — esses não precisa reinventar.

São genéricos por design. Customizar = perder tempo sem ganho.

Estruturais, não opinativos. Fácil de manter (vendor update funciona).

brand-context é 100% seu. Skills incluídas (welcome, visual) são exemplos — substitua pelas suas.

Customização errada destrói valor. Customização certa é onde mora a diferenciação.

Brand-context evolui semana a semana, skills evolvem mês a mês.

Hooks macOS-only se você é Linux. Integração Skool se você não usa. Six-hats se não é seu método.

Carregar peso morto polui. Repo limpo = manutenção barata.

Fork primeiro, remova depois, fork limpo no GitHub.

Semana 1: fork + install. Semana 2: brand-context. Semana 3: 1 cliente real. Semana 4: 1 skill própria.

"Quando adaptar?" tem resposta concreta. Sem isso, fica no eterno "depois".

1 entrega/semana, métrica de sucesso clara, revisão no day 30.

Não é para times >5 pessoas, não tem multi-user real, não tem dashboard web público.

Quando seu negócio crescer, vai precisar mais (vá para a Trilha 3 ou construa).

Operator-centric, single-machine, single-user (com multi-cliente lógico).

Repo é MIT. Bugs viram issues, melhorias viram PRs, learnings viram posts no Skool da comunidade.

Ecossistema vive de contribuição. Você ganha mais voltando do que pegando só.

CITATION.cff, CHANGELOG.md, comunidade Skool ativa.