Multi-Projekt Skill-Isolation

So betreibst du Projekt A (Bootstrap + Owl) und Projekt B (Tailwind + React) ohne Kontext-Konflikte.

Das Problem

Du hast zwei Web-Projekte:

• Projekt A: Odoo-Website — Bootstrap 5, Owl-Framework, QWeb-Templates, Python-Backend
• Projekt B: SaaS-Anwendung — Tailwind CSS, React 19, Next.js 15, TypeScript

Ein einzelner KI-Bot kann nicht beide Projekte effektiv bedienen. Odoo-Anweisungen verunreinigen den React-Kontext. React-Muster sickern in Odoo-Code ein. t-call-Hinweise ergeben in JSX keinen Sinn. useEffect hat in QWeb nichts zu suchen.

Die Lösung: 3 Isolationsebenen

Ebene 1: CLAUDE.md (Projekt-Verfassung)

Jeder Child Bot startet claude -p in seinem eigenen Arbeitsverzeichnis. Claude Code lädt automatisch CLAUDE.md aus dem Projektstamm. Das ist die „Verfassung" des Bots.

Projekt 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

Projekt 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

Diese Dateien vermischen sich nie. Unterschiedliche Verzeichnisse, unterschiedliche Prozesse, unterschiedliche Bots.

Ebene 2: skills/ (Technologie-spezifisches Fachwissen)

Jedes Projekt erhält nur die Skills, die für seinen Tech-Stack relevant sind.

Skill-Set von Projekt 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

Skill-Set von Projekt 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

Hinweis: dieselben strukturellen Skills (code-review, git-manager), aber mit unterschiedlichen Eval-Regeln pro Projekt.

Ebene 3: _registry.json + Context Router (Intelligente Auswahl)

Auch innerhalb eines einzelnen Projekts stellt der Context Router sicher, dass pro Nachricht nur relevante Skills hervorgehoben werden.

Projekt A Registry (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"]
    }
  ]
}

Projekt B Registry (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()"]
    }
  ]
}

Wenn CEO „Fix the t-call in the product template" an Projekt A sendet:

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

Wenn CEO „Add dark mode toggle with Tailwind" an Projekt B sendet:

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: Stack-spezifische Qualitätsregeln

Jedes Projekt kann unterschiedliche Eval-Regeln haben — selbst für denselben Skill.

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

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

Gleicher Skill. Unterschiedliche Regeln. Gleicher Qualitätssicherungsmechanismus.

Learnings: Unabhängiger Speicher pro Projekt

Korrekturen sammeln sich separat an.

Projekt 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

Projekt 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

Die Odoo-Learnings von Projekt A verunreinigen nie den React-Kontext von Projekt B. Das „Immungedächtnis" jedes Bots ist zu 100 % auf seinen eigenen Tech-Stack zugeschnitten.

Metriken: Pro Projekt, pro 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

Der Karpathy Loop analysiert jedes Projekt unabhängig. Ist code-review im Odoo-Projekt schwach, aber im React-Projekt stark, erhält nur das Odoo-Projekt einen Verbesserungsvorschlag.

Einrichtungsschritte

1. Projekte erstellen

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

2. CLAUDE.md pro Projekt hinzufügen

Schreibe die Projekt-Verfassung mit Tech-Stack, Konventionen und Einschränkungen.

3. Relevante Library-Skills kopieren

# 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. _registry.json pro Projekt anpassen

Füge Trigger und Keywords hinzu, die für die Technologie des jeweiligen Projekts relevant sind.

5. Stack-spezifische Evals schreiben

Erstelle .evals.json-Dateien mit Regeln, die für den jeweiligen Stack sinnvoll sind.

6. Nutzen und korrigieren

Fang an zu arbeiten. Drücke „Fix It", wenn etwas falsch ist. Drücke Daumen runter bei schlechten Antworten. Das System lernt und passt sich pro Projekt an.

Warum nicht ein Bot mit „Modi"?

Der föderierte Ansatz erfordert mehr Infrastruktur (eine tmux-Sitzung pro Projekt), eliminiert aber jegliche Kontext-Vermischung durch Design.