Aislamiento de skills entre proyectos

Cómo ejecutar el Proyecto A (Bootstrap + Owl) y el Proyecto B (Tailwind + React) sin conflictos de contexto.

El problema

Tienes dos proyectos web:

Proyecto A: Sitio web en Odoo — Bootstrap 5, framework Owl, plantillas QWeb, backend Python
Proyecto B: Aplicación SaaS — Tailwind CSS, React 19, Next.js 15, TypeScript

Un único bot de IA no puede servir a ambos con eficacia. Las instrucciones de Odoo contaminan el contexto de React. Los patrones de React se filtran en el código de Odoo. Los consejos de t-call no tienen sentido en JSX. useEffect no tiene cabida en QWeb.

La solución: 3 niveles de aislamiento

Nivel 1: CLAUDE.md (Constitución del proyecto)

Cada child bot inicia claude -p en su propio directorio de trabajo. Claude Code carga automáticamente CLAUDE.md desde la raíz del proyecto. Esta es la "constitución" del bot.

Proyecto 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

Proyecto 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

Estos archivos nunca se mezclan. Directorios diferentes, procesos diferentes, bots diferentes.

Nivel 2: skills/ (Experiencia específica por tecnología)

Cada proyecto recibe únicamente las skills relevantes para su stack tecnológico.

Conjunto de skills del Proyecto A:

/opt/repos/odoo-site/skills/
├── _registry.json           ← Solo entradas relevantes para Odoo
├── library/
│   ├── odoo-expert.md       ← Desarrollo de módulos Odoo
│   ├── odoo-owl-expert.md   ← Patrones de componentes Owl
│   └── postgres-pro.md      ← Optimización PostgreSQL
├── code-review/
│   ├── skill.md
│   └── code-review.evals.json  ← Reglas específicas de Odoo
└── git-manager/
    └── skill.md

Conjunto de skills del Proyecto B:

/opt/repos/saas-app/skills/
├── _registry.json           ← Solo entradas relevantes para React
├── library/
│   ├── react-patterns.md    ← RSC, hooks, gestión de estado
│   ├── tailwind-expert.md   ← Patrones CSS de utilidades
│   └── nextjs-expert.md     ← App Router, middleware, ISR
├── code-review/
│   ├── skill.md
│   └── code-review.evals.json  ← Reglas específicas de React
└── git-manager/
    └── skill.md

Observa que se usan las mismas skills estructurales (code-review, git-manager) pero con reglas de evaluación diferentes por proyecto.

Nivel 3: _registry.json + Context Router (Selección inteligente)

Incluso dentro de un único proyecto, el Context Router garantiza que solo las skills relevantes se enfaticen por mensaje.

Registro del Proyecto 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"]
    }
  ]
}

Registro del Proyecto 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()"]
    }
  ]
}

Cuando el CEO envía "Fix the t-call in the product template" al Proyecto 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

Cuando el CEO envía "Add dark mode toggle with Tailwind" al Proyecto 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: reglas de calidad específicas del stack

Cada proyecto puede tener reglas de evaluación diferentes incluso para la misma skill.

Proyecto 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" }
  ]
}

Proyecto 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" }
  ]
}

Misma skill. Reglas diferentes. Mismo mecanismo de control de calidad.

Learnings: memoria independiente por proyecto

Las correcciones se acumulan por separado.

Proyecto 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

Proyecto 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

Los learnings de Odoo del Proyecto A nunca contaminan el contexto de React del Proyecto B. La "memoria inmune" de cada bot es 100% relevante para su propio stack.

Métricas: por proyecto y por skill

/quality en Proyecto 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 en Proyecto 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

El Karpathy Loop analiza cada proyecto de forma independiente. Si code-review es débil en el proyecto Odoo pero fuerte en el de React, solo el proyecto Odoo recibe una propuesta de mejora.

Pasos de configuración

1. Crea los proyectos

En el Master Bot de Telegram:
/new_project odoo-site
/new_project saas-app

2. Añade CLAUDE.md por proyecto

Escribe la constitución del proyecto describiendo el stack, las convenciones y las restricciones.

3. Copia las skills de biblioteca relevantes

# Proyecto 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/

# Proyecto B — crea nuevas para tu stack
write /opt/repos/saas-app/skills/library/react-patterns.md
write /opt/repos/saas-app/skills/library/tailwind-expert.md

4. Personaliza _registry.json por proyecto

Añade triggers y keywords relevantes para la tecnología de cada proyecto.

5. Escribe evals específicos del stack

Crea archivos .evals.json con reglas que tengan sentido para cada stack.

6. Usa y corrige

Empieza a trabajar. Pulsa Fix It cuando algo esté mal. Pulsa thumbs-down en las respuestas malas. El sistema aprende y se adapta por proyecto.

¿Por qué no un único bot con "modos"?

Enfoque	Problema
Un bot, cambiar contexto manualmente	Contaminación entre proyectos, sin aislamiento persistente
Un bot, prefijo en cada mensaje	Tedioso, propenso a errores, sin aislamiento de skills
Un bot, múltiples CLAUDE.md	Claude Code carga un CLAUDE.md por cwd
Arc OS: child bots separados	Aislamiento completo a nivel de proceso

El enfoque federado requiere más infraestructura (una sesión tmux por proyecto), pero elimina por diseño toda mezcla de contexto.