📋 O que copia tal-qual (esqueleto estrutural)
Tem partes do iAmasters OS que são genéricas o suficiente pra qualquer consultoria/agência. Não reinvente — copie, commit no seu repo, siga adiante. É o esqueleto que segura o resto.
✅ Checklist do que copia direto
- ☑clients/_templates/ — estrutura de pasta por cliente. Funciona pra qualquer consultoria.
- ☑_install-gate.sh — script que valida dependências antes de rodar. Genérico, não tem nada seu específico.
- ☑context/ sectorizado — divisão por setor (cliente, projeto, sessão). Só renomeie os setores se o seu negócio usa outros nomes.
- ☑Daily summary — script que resume o dia. Lógica é genérica; só o destino muda.
- ☑/eod, /dream, /system-status — comandos de orquestração. Use como estão; ajusta texto depois.
Esqueleto é commodity. Copia, não constrói.
~80 horas de setup virou 1 hora de fork.
Bug que você acha, devolve via PR. Combinado.
🎨 O que customiza (precisa ser seu)
Aqui mora a diferença entre "uso o iAmasters OS" e "tenho o meu OS baseado nele". Estas partes obrigatoriamente precisam refletir o seu negócio — senão você está só vestindo a roupa de outro.
🪪 brand-context (100% seu)
Tom de voz, posicionamento, frases proibidas, jargão do seu nicho. Nada do meu serve.
- • Reescreve do zero baseado em material seu (site, propostas, decks).
- • Inclua exemplos de "como você falaria" e "como NÃO falaria".
- • Revise a cada 90 dias — marca muda, o arquivo precisa acompanhar.
🧩 Skills incluídas = exemplos
As skills do repo são casos de uso meus. Servem de molde, não de produto final.
- • Mantenha 1-2 como referência de estrutura.
- • Apague o resto (sem dó) e construa as suas.
- • Cada skill própria = ativo do seu negócio, não meu.
💡 Regra de ouro da customização
Se alguém ler 3 arquivos do seu OS e conseguir identificar que é fork meu — você customizou pouco. Se ler e achar que foi construído pra empresa de outro segmento — customizou demais o errado. O alvo: "é claramente o OS da [SEU NEGÓCIO]" em <5 min de leitura.
100% reescrito.
Suas, do seu workflow.
Sua carteira, sua nomenclatura.
Seu layout, sua marca.
🚫 O que NÃO copia (peso morto)
O maior erro de fork é arrastar tudo "por garantia". Resultado: você herda problemas que não são seus, debuga código que não usa, e o repo incha. Apague na primeira semana.
✓ Fork limpo
- ✓Roda
rm -rfem hooks/skills que você não vai usar antes do primeiro commit. - ✓Faz 1 commit "remove o que não uso" justificando cada apagada no PR description.
- ✓Repo enxuto = onboarding rápido pro próximo dev seu.
✗ Fork sem remover peso
- ✗Carrega 200 arquivos que você não entende "porque pode precisar".
- ✗Toda atualização do upstream gera conflito em coisa que você nunca usou.
- ✗Onboarding novo dev = 2 semanas perguntando "isso aqui faz o quê?".
Candidatos a apagar (lista honesta)
🖥️ Hooks macOS-only (se você está em Linux)
Tem hooks que rodam osascript, say, integrações com app nativo da Apple. Em Linux não roda — só polui logs. Apaga.
📚 Skool integration (se você não usa Skool)
Tem skill pp-skool conectada à minha comunidade. Se você não opera lá, apaga junto com credenciais de exemplo.
🎩 Six-hats (se não é seu método de análise)
A skill fs-seis-chapeus é metodologia De Bono que eu uso. Se você analisa decisões de outro jeito (SWOT, OKR, RAPID), apaga e cria a sua.
"Vou usar nas próximas 4 semanas?" Não? Apaga.
Está no Git do upstream. Sempre dá pra recuperar.
Se você não sabe o que faz, está dando manutenção em código de outro.
📅 Plano 30 dias (timeline real)
4 semanas. Cada uma com 1 objetivo claro. Você não termina o mês com tudo, mas termina com algo rodando em produção pra 1 cliente real — que é o que importa.
Semana 1 — Fork, install, remove peso morto
"Repo enxuto rodando na minha máquina."
Fork no GitHub. _install-gate.sh passando. Apaga hooks/skills que não usa (tópico 3). Faz commit "remove o que não uso". Saída: repo seu, <50% do tamanho original, todos os comandos funcionando.
Semana 2 — brand-context
"O OS soa como o meu negócio."
Reescreve brand-context.md do zero. Tom de voz, posicionamento, jargão. Roda 5 prompts de teste e verifica se a saída soa como você. Itera. Saída: arquivo de marca seu, testado em 5 prompts reais.
Semana 3 — 1 cliente real onboardeado
"Tem um cliente vivo dentro do OS."
Escolhe 1 cliente (não 5). Cria pasta em clients/. Importa contexto, decisões, próximos passos. Roda /eod 3 dias seguidos. Saída: 1 cliente operando, daily summary chegando no destino certo.
Semana 4 — 1 skill própria (vira ativo)
"O OS deixou de ser meu, passou a ser seu."
Constrói 1 skill que resolve dor específica do seu negócio (cotação, follow-up, relatório). Não copia minha — cria do zero. Este é o momento que o OS vira ativo da sua empresa — porque tem código que nenhum outro fork tem.
💡 Por que 4 semanas é o sweet spot
Menos que isso (1-2 sem) = raso. Você só forka e abandona — não chega no cliente real, que é onde o ROI aparece. Mais que isso (60-90 dias) = procrastinação disfarçada de planejamento; o OS nunca sai do "estou ajustando". 4 semanas força você a colocar 1 cliente em produção com o mínimo viável.
🚨 Alerta: a armadilha do "vou começar quando estiver perfeito"
Esperar o caso "perfeito" pra começar (cliente premium, contexto limpo, processo documentado) = nunca começa. A versão perfeita só existe depois de 3 clientes reais te ensinarem onde dói.
Antídoto: Escolha o cliente mais bagunçado que tem hoje. Se funcionar com ele, funciona com qualquer outro.
Repo enxuto.
Marca sua.
1 cliente vivo.
1 skill própria.
⚖️ Trade-offs honestos (o que NÃO resolve)
O iAmasters OS é otimizado pra operador solo ou time pequeno (≤5 pessoas) com clientes consultivos. Não é silver bullet. Aqui vai a tabela do que cabe e do que não cabe — pra você não descobrir errado depois de 2 meses de implementação.
📊 iAmasters OS: resolve / não resolve
| ✓ Resolve bem | ✗ Não resolve (volte à T3) |
|---|---|
| Solo ou time até 5 pessoas | Times grandes (>5) sem governança custom |
| Memória persistente por cliente | Multi-user real com auth/SSO/RBAC |
| Operação via CLI/terminal | Dashboard web público pra clientes finais |
| Daily summary, eod, dream loops | SLA garantido 24/7 com on-call rotation |
| Brand voice consistente | Compliance pesado (LGPD enterprise, SOC2) |
| Setup de cliente em minutos | Self-service por clientes não-técnicos |
🎯 Sinais de que serve pra você
- • Você opera no terminal todo dia.
- • Tem 2-15 clientes ativos, cada um com contexto próprio.
- • Quer reduzir trabalho repetitivo seu, não substituir time.
- • Aceita que o "produto" é teu fork, não SaaS pronto.
🚩 Sinais de que NÃO serve
- • Time >20 pessoas precisando de tooling unificado.
- • Clientes finais vão usar diretamente o sistema.
- • Auditoria externa exige compliance certificado.
- • Você não tem ninguém confortável em terminal.
Consultoria/agência pequena.
Multi-user com auth real.
Volte à T3 e arquitete custom.
🤝 Contribuir de volta (MIT + comunidade)
O iAmasters OS é MIT. Você pode forkar, vender, fechar o seu fork, white-label. Sem royalty, sem permissão. Em troca, peço uma coisa: quando você achar um bug ou tiver uma ideia melhor, devolva. Não é obrigação contratual — é higiene de comunidade.
🐛 Issues
Achou bug? Comportamento esquisito? Abre issue no GitHub com repro mínimo. Não precisa ter solução — só o problema descrito ajuda.
🔀 Pull Requests
Corrigiu algo? Adicionou feature genérica útil pros outros? PR pequeno, descritivo, com 1 commit por mudança lógica. Reviso na mesma semana.
💬 Posts no Skool
Comunidade IA Masters Academy no Skool. Posta o que funcionou, o que quebrou, o que adaptou. Outros forks aprendem com seu caso.
🌱 A lógica do open source aplicado
Toda contribuição que volta deixa o repo melhor pro próximo fork — que pode ser de um cliente seu, de um parceiro, ou de você mesmo daqui 6 meses começando outro vertical. Quem contribui aparece no CONTRIBUTORS.md — vira referência pública no nicho. Custo: 10 minutos. Retorno: posicionamento.
MIT. Use como quiser.
Bug → issue. Fix → PR.
Skool IA Masters Academy.
🎓 Curso completo concluído
Você chegou ao fim das 4 trilhas. Da virada conceitual ao fork em produção. Aqui vai o resumo do que você aprendeu — e os próximos passos pra continuar.
O que você aprendeu nas 4 trilhas
🚀 Próximos passos
Repo iamasters-os
Forka no GitHub. Comece pelo _install-gate.sh.
AutomationsAI
Comunidade. Posta o que funcionou e quebrou no seu fork.
Curso agenticos (original)
Versão técnica detalhada em automationsai.net/agenticos.
"O melhor OS é o que está rodando no seu cliente sexta-feira de manhã — não o que está perfeito na sua cabeça."