Isolation des skills multi-projets

Comment exécuter le Projet A (Bootstrap + Owl) et le Projet B (Tailwind + React) sans conflits de contexte.

Le problème

Tu as deux projets web :

• Projet A : Site Odoo — Bootstrap 5, framework Owl, templates QWeb, backend Python
• Projet B : Application SaaS — Tailwind CSS, React 19, Next.js 15, TypeScript

Un seul bot AI ne peut pas servir les deux efficacement. Les instructions Odoo polluent le contexte React. Les patterns React s'infiltrent dans le code Odoo. Les conseils t-call n'ont aucun sens en JSX. useEffect n'a pas sa place dans QWeb.

La solution : 3 niveaux d'isolation

Niveau 1 : CLAUDE.md (Constitution du projet)

Chaque child bot lance claude -p dans son propre répertoire de travail. Claude Code charge automatiquement CLAUDE.md depuis la racine du projet. C'est la "constitution" du bot.

Projet 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

Projet 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

Ces fichiers ne se mélangent jamais. Répertoires différents, processus différents, bots différents.

Niveau 2 : skills/ (Expertise spécifique à la technologie)

Chaque projet obtient uniquement les skills pertinents pour son stack.

Ensemble de skills du Projet A :

/opt/repos/odoo-site/skills/
├── _registry.json           ← Uniquement les entrées pertinentes Odoo
├── library/
│   ├── odoo-expert.md       ← Développement de modules Odoo
│   ├── odoo-owl-expert.md   ← Patterns composants Owl
│   └── postgres-pro.md      ← Optimisation PostgreSQL
├── code-review/
│   ├── skill.md
│   └── code-review.evals.json  ← Règles spécifiques Odoo
└── git-manager/
    └── skill.md

Ensemble de skills du Projet B :

/opt/repos/saas-app/skills/
├── _registry.json           ← Uniquement les entrées pertinentes React
├── library/
│   ├── react-patterns.md    ← RSC, hooks, gestion d'état
│   ├── tailwind-expert.md   ← Patterns CSS utility-first
│   └── nextjs-expert.md     ← App Router, middleware, ISR
├── code-review/
│   ├── skill.md
│   └── code-review.evals.json  ← Règles spécifiques React
└── git-manager/
    └── skill.md

À noter : mêmes skills structurelles (code-review, git-manager) mais avec des règles d'évaluation différentes par projet.

Niveau 3 : _registry.json + Context Router (Sélection intelligente)

Même au sein d'un seul projet, le Context Router s'assure que seules les skills pertinentes sont mises en avant par message.

Registre du Projet 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"]
    }
  ]
}

Registre du Projet 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()"]
    }
  ]
}

Quand le CEO envoie "Fix the t-call in the product template" au Projet 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

Quand le CEO envoie "Add dark mode toggle with Tailwind" au Projet 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 : Règles de qualité spécifiques au stack

Chaque projet peut avoir des règles d'évaluation différentes même pour la même skill.

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

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

Même skill. Règles différentes. Même mécanisme d'application de la qualité.

Learnings : Mémoire indépendante par projet

Les corrections s'accumulent séparément.

Projet 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

Projet 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

Les learnings Odoo du Projet A ne contaminent jamais le contexte React du Projet B. La "mémoire immunitaire" de chaque bot est 100% pertinente pour son propre stack technologique.

Métriques : Par projet, par 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

La Karpathy Loop analyse chaque projet indépendamment. Si code-review est faible dans le projet Odoo mais fort dans le projet React, seul le projet Odoo reçoit une proposition d'amélioration.

Étapes de configuration

1. Créer les projets

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

2. Ajouter CLAUDE.md par projet

Rédige la constitution du projet décrivant le stack technologique, les conventions, les contraintes.

3. Copier les skills de bibliothèque pertinentes

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

# Projet B — en créer de nouvelles pour ton stack
write /opt/repos/saas-app/skills/library/react-patterns.md
write /opt/repos/saas-app/skills/library/tailwind-expert.md

4. Personnaliser _registry.json par projet

Ajoute des déclencheurs et des mots-clés pertinents pour la technologie de chaque projet.

5. Écrire des evals spécifiques au stack

Crée des fichiers .evals.json avec des règles qui ont du sens pour chaque stack.

6. Utiliser et corriger

Commence à travailler. Appuie sur Fix It quand c'est incorrect. Appuie sur thumbs-down sur les mauvaises réponses. Le système apprend et s'adapte par projet.

Pourquoi pas un seul bot avec des "modes" ?

L'approche fédérée nécessite plus d'infrastructure (une session tmux par projet), mais élimine tout mélange de contexte par conception.