🛠️ Operar na Prática

Uma skill que lê/escreve aios-intake.md, conduz a entrevista de 7 perguntas e scaffolda o file-set do Dia 1 ao final. Idempotente: rodar novamente só atualiza o que mudou.

Sem /onboard o sistema fica genérico. Com ele, o Claude Code já conhece seu negócio, sua voz e suas prioridades desde a primeira conversa — instalando o Default Shift imediatamente.

Idempotência · wizard combinado · aios-intake.md · Default Shift · scaffold do Dia 1.

Sete perguntas com cap rígido: Q1 quem/o que vende/pra quem · Q2 amostras de voz · Q3 prioridades 90 dias · Q4 onde a receita cai · Q5 onde fala com clientes/time · Q6 onde moram reuniões/docs · Q7 a tarefa que come a semana. Cada uma <60s.

O cap de 7 é intencional: mais perguntas = menos resposta. Sete é o mínimo para gerar contexto suficiente e o máximo para não cansar no Dia 1.

Cap rígido · 7 domínios de contexto · receita · voz · prioridades 90 dias.

A única regra inquebrável do /onboard: amostras de voz devem ser COLADAS verbatim, nunca digitadas durante a conversa. "Se você digita aqui enquanto conversamos, a amostra já está moldada pela conversa."

Voz é o diferencial do conteúdo gerado. Uma amostra contaminada pela sessão gera textos que parecem "IA genérica" em vez de soarem como você. O /onboard recusa ativamente se detectar digitação ao vivo.

Verbatim · contaminação de voz · references/voice.md · amostra vs. descrição de voz.

Ao final das 7 perguntas o /onboard gera: context/about-me.md, context/about-business.md, context/priorities.md, references/voice.md, connections.md (7 linhas) e preenche o CLAUDE.md. Backup em archives/intake-{ts}/.

Esses arquivos são a memória permanente do sistema. Sem eles, cada conversa começa do zero. Com eles, o Claude sabe quem você é, o que você vende e onde focar — sem re-explicar.

File-set · context/ · references/ · CLAUDE.md · backup em archives/ · idempotência.

Prompt automático no fim do /onboard: "no que devo focar essa semana?". A resposta usa APENAS os arquivos de contexto gerados, em 3 bullets na voz do usuário, cada um amarrado a uma prioridade dos 90 dias.

É o momento que planta o Default Shift: o usuário vê pela primeira vez o sistema respondendo como sócio estratégico, não como digitador. A primeira experiência define se o ritual vai persistir.

Default Shift · wow moment · 3 bullets · voz do usuário · prioridades 90 dias.

Edite aios-intake.md e rode /onboard de novo. Ele refresca só o que mudou, pula perguntas já respondidas e faz backup automático antes de sobrescrever.

Seu negócio muda. Quando muda, basta editar o intake e re-rodar — não precisa reconfigurar do zero. Idempotência transforma o onboarding em rotina de atualização.

Re-run · diff incremental · backup automático · aios-intake.md como fonte de verdade.

Não passa de 7 perguntas · não escreve .env (sem chaves no Dia 1 — conexões vêm no Dia 2) · não gera skills extras · read-only no 3ms-framework.md.

Limites explícitos evitam scope creep. O /onboard é narrow by design: faz uma coisa bem. Conexões e automações vêm nas trilhas seguintes — não misture.

Narrow by design · scope creep · conexões no Dia 2 · read-only · separação de responsabilidades.

O /audit varre o sistema pelos 4 Cs (Context, Connections, Capabilities, Cadence), atribui um score para cada dimensão, identifica gaps e produz uma lista de próximas ações ordenadas por alavancagem.

Sem diagnóstico, melhorias são aleatórias. O /audit torna o progresso visível — você vê o placar subir semana após semana, o que ancora o comportamento e justifica o investimento de tempo.

4 Cs · score de saúde · gaps · próximas ações · alavancagem.

Verifica se context/, references/voice.md, priorities.md e CLAUDE.md estão presentes, completos e atualizados. Score cai se arquivos estão vagos, desatualizados ou ausentes.

Context é a base de tudo. Um sistema com Capabilities e Connections excelentes mas Context pobre vai produzir respostas genéricas. O audit força revisão do contexto antes de escalar.

Context score · completude · atualidade · CLAUDE.md como radar.

Varre connections.md e MCPs configurados. Score reflete quantas ferramentas reais do seu negócio o sistema alcança versus quantas ainda exigem copy-paste manual.

Conexões são multiplicadores de leverage. Cada MCP conectado elimina uma ponte manual. O audit mostra exatamente onde estão as pontes restantes e prioriza quais quebrar primeiro.

connections.md · MCPs · pontes manuais · leverage de integração.

Conta e avalia as skills em .claude/skills/ e artefatos em decisions/log.md. Score mede profundidade (skills especializadas) vs. breadth (áreas cobertas).

Capabilities crescem com cada /level-up. O audit mostra se você está acumulando skills de forma estratégica ou aleatória — e identifica áreas do negócio ainda sem cobertura.

Skills · artefatos · decisions/log.md · profundidade vs. breadth · cobertura estratégica.

Verifica se há cadências definidas, quais estão rodando sem pedido explícito e quais ainda dependem de trigger manual. Score penaliza tarefas que "deveriam rodar sozinhas" mas não rodam.

Cadence é o C mais difícil de instalar. O audit torna óbvio o gap entre "automatizei" e "está rodando de fato" — diferença que normalmente leva semanas para descobrir sem diagnóstico.

Cadências · trigger manual vs. automático · gap de execução · score de Cadence.

Ao final o /audit entrega: placar com score 0-100 por C + total · lista de ações priorizadas (alto impacto primeiro) · sugestão de próximo /level-up target.

O placar cria accountability. Ver o número subir de 42 para 67 em duas semanas é o que converte o operador de "estou tentando" para "estou progredindo". A lista remove a paralisia de escolha.

Score 0-100 · accountability · lista priorizada · próximo target · progresso visível.

Primeira rodada: Dia 7 após o /onboard. A partir daí: semanal (pode combinar com o /level-up toda sexta) ou quinzenal para quem está em fase de expansão acelerada.

Frequência define velocidade de melhoria. Audit mensal = feedback muito lento. Audit diário = overhead sem sinal claro. Semanal é o ponto de equilíbrio comprovado pelo kit AIS-OS.

Dia 7 · ritual semanal · frequência de feedback · overhead vs. sinal.

Skill que caminha os 3 Ms (Mindset → Method → Machine) toda semana para achar e shippar UMA automação. Além de entregar o artefato, instala os 3 Ms na cabeça do operador.

A maioria das pessoas tenta automatizar tudo de uma vez e não entrega nada. O /level-up força foco em UMA coisa por semana — que é o ritmo que produz 52 automações/ano sem burnout.

3 Ms · uma automação/semana · brain-rewire · entrevista estruturada · artefato scaffoldado.

5 perguntas para achar candidatos: o que fez 3+ vezes? algo manual/copy-paste? "um estagiário esperto daria conta"? se 500 clientes chegassem o que quebraria? o que daria 500 clientes? Resultado: 1-3 candidatos rankeados por alavancagem.

A maioria quer automatizar o que é empolgante, não o que trava. As 5 perguntas forçam identificar o gargalo real antes de construir qualquer coisa.

Candidato · ranking por alavancagem · gargalo real · copy-paste mental · scale bottleneck.

5 passos: Find constraint → EAD (Eliminar primeiro; se "nada quebra", sai feliz e loga a vitória) → Map (5 elementos) → Autonomy (default no menor nível) → KPI (balde + métrica, obrigatório, senão para).

EAD é a etapa mais contraintuitiva e mais valiosa: às vezes o melhor "automação" é eliminar a tarefa inteira. O KPI obrigatório evita construir coisas impossíveis de medir — logo, impossíveis de melhorar.

EAD · constraint · Map 5 elementos · Autonomy ladder · KPI como portão de saída.

4 opções em ordem Boring-is-Beautiful: (1) prompt salvo → (2) skill determinístico → (3) skill IA-assistido → (4) sub-agent (último recurso). Default = a maior opção SEM IA que resolve.

A tendência natural é ir direto para o sub-agent complexo. Boring-is-Beautiful reverte isso: soluções simples são mais confiáveis, mais fáceis de debugar e entregam mais rápido. IA é o último recurso, não o padrão.

Boring-is-Beautiful · escada de complexidade · prompt salvo → skill → sub-agent · default simples.

Todo artefato nasce com bike-method-phase: 1 no frontmatter. Isso trava o usuário na Fase 1 (validação manual). Avançar para a Fase 2 exige edição explícita do arquivo — sem atalhos.

A maioria pula validação manual e só descobre que a automação não funciona depois de semanas. O lock força um ciclo de feedback humano antes de escalar — salva tempo e evita bugs em produção.

bike-method-phase · frontmatter · validação manual · Fase 1 → 2 → 3 explícita · feedback loop.

Cada run do /level-up produz exatamente: 1 entrada no decisions/log.md (spec do Method) + 1 artefato scaffoldado + 1 tela de fechamento com lembrete da Fase 1.

O contrato de saída garante rastreabilidade. Sem log de decisions você não sabe o que foi decidido e por quê. Com ele, em 6 meses você tem um histórico de 24+ automações com rationale.

decisions/log.md · spec · artefato scaffoldado · rastreabilidade · rationale.

Após 4-6 semanas rodando o /level-up toda sexta, os 3 Ms ficam internalizados. Você começa a identificar oportunidades de automação durante reuniões, emails e conversas — sem precisar da skill para enxergar.

O /level-up não é só uma ferramenta: é um programa de treinamento cognitivo. O objetivo final não é a skill em si, mas instalar o mindset de operador de AIOS permanentemente.

Brain-rewire · 3 Ms internalizados · mindset de operador · 4-6 runs · rituais toda sexta.

Estrutura base imutável: context/ · references/ · decisions/log.md · archives/ · connections.md · .claude/skills/ · aios-intake.md · CLAUDE.md. Remover qualquer um quebra o sistema.

Saber o que não remover é tão importante quanto saber o que adicionar. Cada arquivo da base tem uma função crítica — sem ele uma skill inteira para de funcionar.

Estrutura base · imutabilidade da core · dependências implícitas · kit integridade.

Quando a operação justifica: projects/ (2+ workstreams) · templates/ (parou de copiar prompt) · brand-assets/ · references/sops/ · references/{tool}-api.md · scripts/ · .claude/agents/ · sub-OS folders.

Cada expansão tem um gatilho claro ("parou de copiar prompt" = templates/). Sem esse critério você cria pastas por antecipação — que viram porão em 2 semanas.

Gatilho de expansão · templates/ · projects/ · sub-OS · expansão por demanda.

Cinco anti-padrões fatais: dump de email/Slack em references/ · folder-of-folders (flat com bom nome vence) · notes/misc/tmp/inbox (cemitérios) · pré-criar pastas · duplicar decisions · mais de 1 CLAUDE.md na raiz.

Cada anti-padrão transforma o AIOS em um porão. A diferença entre "negócio bem gerido" e "bagunça digital" é seguir essas 5 regras de higiene consistentemente.

Anti-padrões · flat structure · cemitério digital · pré-criar · duplicação · CLAUDE.md único.

Cadências por arquivo: decisions/log.md (toda decisão tomada) · archives/ (limpeza trimestral) · sops/ (quando alguém novo re-roda um processo) · connections.md (cada tool novo) · CLAUDE.md (revisão trimestral).

Sem cadência os arquivos ficam desatualizados e perdem valor. Com cadência, o sistema cresce organicamente — cada arquivo tem um responsável temporal claro.

Cadência por arquivo · decisão imediata · limpeza trimestral · revisão periódica · sistema vivo.

Antes de criar uma pasta: (1) é conceitualmente novo? (2) vou tocar 3+ vezes no próximo mês? (3) o /level-up rotearia uma skill futura pra cá? 2 sins = adiciona. 1 sim = espera.

É o portão de entrada para qualquer expansão. A maioria cria pasta no primeiro uso. A regra exige evidência de padrão antes de estruturar — previne 80% dos porões.

3 sins · portão de expansão · padrão antes de estrutura · 2/3 sins = cria · 1/3 = espera.

Frameworks avançados para quando o sistema cresce: Data Retrieval Hierarchy · Integration Ladder · Error Handling Playbook · Model Selection · Context Engineering · Discovery · Security & Permissions. Filosofia central: "Seu AIOS deve parecer um negócio pequeno e bem-gerido — não um porão de acumulador."

Quando o sistema escala esses frameworks fornecem padrões para decisões que não têm resposta óbvia. Conhecê-los antes de precisar significa não improvisar sob pressão.

Branch frameworks · escala · porão vs. negócio bem-gerido · decisões sob pressão · filosofia operacional.