Isolamento de Skills em Múltiplos Projetos

Como rodar o Projeto A (Bootstrap + Owl) e o Projeto B (Tailwind + React) sem conflitos de contexto.

O Problema

Você tem dois projetos web:

• Projeto A: Site Odoo — Bootstrap 5, framework Owl, templates QWeb, backend Python
• Projeto B: Aplicação SaaS — Tailwind CSS, React 19, Next.js 15, TypeScript

Um único bot de IA não consegue atender ambos com eficiência. Instruções do Odoo poluem o contexto do React. Padrões React vazam para o código Odoo. Dicas de t-call não fazem sentido em JSX. useEffect não tem lugar em QWeb.

A Solução: 3 Níveis de Isolamento

Nível 1: CLAUDE.md (Constituição do Projeto)

Cada Child Bot inicia claude -p no seu próprio diretório de trabalho. Claude Code carrega automaticamente o CLAUDE.md da raiz do projeto. Esse é a "constituição" do bot.

Projeto A (/opt/repos/odoo-site/CLAUDE.md):

# Odoo Website Project

## Tech Stack
- Odoo 17 Community
- Python 3.11
- Bootstrap 5.3
- Owl (Odoo Web Library) framework
- QWeb templating engine
- PostgreSQL 16

## Conventions
- All templates use t-call for i18n
- No inline JavaScript in QWeb templates
- CSS follows BEM naming
- Python follows Odoo coding guidelines

Projeto B (/opt/repos/saas-app/CLAUDE.md):

# SaaS Application

## Tech Stack
- Next.js 15 (App Router)
- React 19
- TypeScript 5.4 (strict mode)
- Tailwind CSS 4.0
- Prisma ORM
- PostgreSQL 16

## Conventions
- Server Components by default, 'use client' only when needed
- Tailwind utility classes via cn() helper (no @apply in components)
- All API routes in app/api/ with Zod validation

Esses arquivos nunca se misturam. Diretórios diferentes, processos diferentes, bots diferentes.

Nível 2: skills/ (Expertise Específica de Tecnologia)

Cada projeto recebe apenas as skills relevantes para sua stack.

Conjunto de skills do Projeto A:

/opt/repos/odoo-site/skills/
├── _registry.json           ← Only Odoo-relevant entries
├── library/
│   ├── odoo-expert.md       ← Odoo module development
│   ├── odoo-owl-expert.md   ← Owl component patterns
│   └── postgres-pro.md      ← PostgreSQL optimization
├── code-review/
│   ├── skill.md
│   └── code-review.evals.json  ← Odoo-specific rules
└── git-manager/
    └── skill.md

Conjunto de skills do Projeto B:

/opt/repos/saas-app/skills/
├── _registry.json           ← Only React-relevant entries
├── library/
│   ├── react-patterns.md    ← RSC, hooks, state management
│   ├── tailwind-expert.md   ← Utility-first CSS patterns
│   └── nextjs-expert.md     ← App Router, middleware, ISR
├── code-review/
│   ├── skill.md
│   └── code-review.evals.json  ← React-specific rules
└── git-manager/
    └── skill.md

Repare: mesmas skills estruturais (code-review, git-manager), mas com regras de eval diferentes por projeto.

Nível 3: _registry.json + Context Router (Seleção Inteligente)

Mesmo dentro de um único projeto, o Context Router garante que apenas as skills relevantes sejam enfatizadas por mensagem.

Registry do Projeto A (odoo-site/skills/_registry.json):

{
  "skills": [
    {
      "name": "odoo-expert",
      "triggers": ["odoo", "module", "QWeb", "t-call", "res.partner"],
      "keywords": ["template", "view", "action", "ORM", "XML", "controller"]
    },
    {
      "name": "odoo-owl-expert",
      "triggers": ["owl", "component", "t-on", "t-set"],
      "keywords": ["lifecycle", "hook", "state", "props", "template"]
    }
  ]
}

Registry do Projeto B (saas-app/skills/_registry.json):

{
  "skills": [
    {
      "name": "react-patterns",
      "triggers": ["component", "hook", "useState", "useEffect", "RSC"],
      "keywords": ["render", "props", "state", "context", "suspense"]
    },
    {
      "name": "tailwind-expert",
      "triggers": ["tailwind", "className", "dark mode", "responsive"],
      "keywords": ["utility", "variant", "breakpoint", "theme", "cn()"]
    }
  ]
}

Quando o CEO envia "Fix the t-call in the product template" para o Projeto A:

Context Router:
  odoo-expert: trigger "t-call" (2) + keyword "template" (1) = 3 pts
  odoo-owl-expert: keyword "template" (1) = 1 pt
  git-manager: 0 pts

→ SKILLS_HINT: odoo-expert, odoo-owl-expert

Quando o CEO envia "Add dark mode toggle with Tailwind" para o Projeto B:

Context Router:
  tailwind-expert: trigger "tailwind" (2) + trigger "dark mode" (2) = 4 pts
  react-patterns: keyword "component" (1) = 1 pt

→ SKILLS_HINT: tailwind-expert, react-patterns

Evals: Regras de Qualidade Específicas da Stack

Cada projeto pode ter regras de eval diferentes, mesmo para a mesma skill.

Projeto A (odoo-site/skills/code-review/code-review.evals.json):

{
  "rules": [
    { "id": "cr-odoo-001", "name": "Must use t-call for i18n", "type": "regex_match", "pattern": "t-call|t-esc|_t\\(", "severity": "warning" },
    { "id": "cr-odoo-002", "name": "No inline JS in QWeb", "type": "string_not_contains", "value": "<script>", "severity": "warning" },
    { "id": "cr-odoo-003", "name": "No direct SQL queries", "type": "string_not_contains", "value": "cr.execute", "severity": "warning" }
  ]
}

Projeto B (saas-app/skills/code-review/code-review.evals.json):

{
  "rules": [
    { "id": "cr-react-001", "name": "No direct DOM manipulation", "type": "string_not_contains", "value": "document.getElementById", "severity": "warning" },
    { "id": "cr-react-002", "name": "No any types", "type": "string_not_contains", "value": ": any", "severity": "warning" },
    { "id": "cr-react-003", "name": "Prefer server components", "type": "string_not_contains", "value": "'use client'", "severity": "info" }
  ]
}

Mesma skill. Regras diferentes. Mesmo mecanismo de garantia de qualidade.

Learnings: Memória Independente por Projeto

As correções se acumulam separadamente.

Projeto A (odoo-site/learnings.md):

- [2026-03-20] [fixit] Always use t-call for translations in QWeb
- [2026-03-22] [negative] Don't override base Odoo CSS — use custom class
- [2026-04-01] [fixit] Use sudo() only when security context requires it

Projeto B (saas-app/learnings.md):

- [2026-03-21] [fixit] Use server components by default in Next.js 15
- [2026-03-25] [negative] Don't use useEffect for data fetching — use RSC
- [2026-04-02] [fixit] Always validate API input with Zod schema

Os learnings do Odoo do Projeto A nunca contaminam o contexto React do Projeto B. A "memória imune" de cada bot é 100% relevante para sua própria stack.

Métricas: Por Projeto, Por Skill

/quality on Project A:
  odoo-expert: 47x, 93% ok, thumbs-up 15/thumbs-down 1, avg 9.2s
  code-review: 12x, 83% ok, thumbs-up 4/thumbs-down 2, avg 5.1s

/quality on Project B:
  react-patterns: 31x, 87% ok, thumbs-up 8/thumbs-down 3, avg 6.7s
  tailwind-expert: 18x, 94% ok, thumbs-up 7/thumbs-down 0, avg 3.4s

O Karpathy Loop analisa cada projeto de forma independente. Se code-review está fraco no projeto Odoo mas forte no projeto React, apenas o projeto Odoo recebe uma proposta de melhoria.

Passos de Configuração

1. Crie os projetos

In Master Bot Telegram:
/new_project odoo-site
/new_project saas-app

2. Adicione o CLAUDE.md por projeto

Escreva a constituição do projeto descrevendo a stack, convenções e restrições.

3. Copie as skills de biblioteca relevantes

# Project A
cp citadel-v2/skills/library/odoo-expert.md /opt/repos/odoo-site/skills/library/
cp citadel-v2/skills/library/odoo-owl-expert.md /opt/repos/odoo-site/skills/library/

# Project B — create new ones for your stack
write /opt/repos/saas-app/skills/library/react-patterns.md
write /opt/repos/saas-app/skills/library/tailwind-expert.md

4. Personalize o _registry.json por projeto

Adicione triggers e palavras-chave relevantes para a tecnologia de cada projeto.

5. Escreva evals específicos da stack

Crie arquivos .evals.json com regras que façam sentido para cada stack.

6. Use e corrija

Comece a trabalhar. Pressione Fix It quando algo estiver errado. Pressione thumbs-down em respostas ruins. O sistema aprende e se adapta por projeto.

Por Que Não Um Único Bot com "Modos"?

A abordagem federada exige mais infraestrutura (uma sessão tmux por projeto), mas elimina toda mistura de contexto por design.