Izolacja Skilów między Projektami

Jak uruchomić Projekt A (Bootstrap + Owl) i Projekt B (Tailwind + React) bez konfliktów kontekstu.

Problem

Masz dwa projekty webowe:

• Projekt A: Strona Odoo — Bootstrap 5, framework Owl, szablony QWeb, backend Python
• Projekt B: Aplikacja SaaS — Tailwind CSS, React 19, Next.js 15, TypeScript

Jeden bot AI nie może efektywnie obsługiwać obu. Instrukcje Odoo zanieczyszczają kontekst React. Wzorce React wyciekają do kodu Odoo. Porada dotycząca t-call nie ma sensu w JSX. useEffect nie ma miejsca w QWeb.

Rozwiązanie: 3 Poziomy Izolacji

Poziom 1: CLAUDE.md (Konstytucja Projektu)

Każdy Child Bot uruchamia claude -p we własnym katalogu roboczym. Claude Code automatycznie ładuje CLAUDE.md z katalogu głównego projektu. To jest „konstytucja" bota.

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

# Projekt Strony Odoo

## Stack Technologiczny
- Odoo 17 Community
- Python 3.11
- Bootstrap 5.3
- Framework Owl (Odoo Web Library)
- Silnik szablonów QWeb
- PostgreSQL 16

## Konwencje
- Wszystkie szablony używają t-call dla i18n
- Bez inline JavaScript w szablonach QWeb
- CSS zgodnie z nazewnictwem BEM
- Python zgodnie z wytycznymi kodowania Odoo

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

# Aplikacja SaaS

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

## Konwencje
- Server Components domyślnie, 'use client' tylko gdy konieczne
- Klasy narzędziowe Tailwind przez pomocnik cn() (bez @apply w komponentach)
- Wszystkie trasy API w app/api/ z walidacją Zod

Te pliki nigdy się nie mieszają. Różne katalogi, różne procesy, różne boty.

Poziom 2: skills/ (Specjalistyczna Wiedza Technologiczna)

Każdy projekt otrzymuje tylko skille odpowiednie dla swojego stosu technologicznego.

Zestaw skilów Projektu A:

/opt/repos/odoo-site/skills/
├── _registry.json           ← Tylko wpisy związane z Odoo
├── library/
│   ├── odoo-expert.md       ← Tworzenie modułów Odoo
│   ├── odoo-owl-expert.md   ← Wzorce komponentów Owl
│   └── postgres-pro.md      ← Optymalizacja PostgreSQL
├── code-review/
│   ├── skill.md
│   └── code-review.evals.json  ← Reguły specyficzne dla Odoo
└── git-manager/
    └── skill.md

Zestaw skilów Projektu B:

/opt/repos/saas-app/skills/
├── _registry.json           ← Tylko wpisy związane z React
├── library/
│   ├── react-patterns.md    ← RSC, hooks, zarządzanie stanem
│   ├── tailwind-expert.md   ← Wzorce CSS utility-first
│   └── nextjs-expert.md     ← App Router, middleware, ISR
├── code-review/
│   ├── skill.md
│   └── code-review.evals.json  ← Reguły specyficzne dla React
└── git-manager/
    └── skill.md

Uwaga: te same strukturalne skille (code-review, git-manager), ale z różnymi regułami evals na projekt.

Poziom 3: _registry.json + Context Router (Inteligentny Dobór)

Nawet w obrębie jednego projektu Context Router dba o to, żeby w danej wiadomości były podkreślane tylko odpowiednie skille.

Rejestr Projektu 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"]
    }
  ]
}

Rejestr Projektu 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()"]
    }
  ]
}

Gdy CEO wysyła "Napraw t-call w szablonie produktu" do Projektu A:

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

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

Gdy CEO wysyła "Dodaj przełącznik trybu ciemnego z Tailwind" do Projektu B:

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

→ SKILLS_HINT: tailwind-expert, react-patterns

Evals: Reguły Jakości Specyficzne dla Stosu

Każdy projekt może mieć różne reguły evals nawet dla tego samego skilla.

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

{
  "rules": [
    { "id": "cr-odoo-001", "name": "Wymagane t-call dla i18n", "type": "regex_match", "pattern": "t-call|t-esc|_t\\(", "severity": "warning" },
    { "id": "cr-odoo-002", "name": "Bez inline JS w QWeb", "type": "string_not_contains", "value": "<script>", "severity": "warning" },
    { "id": "cr-odoo-003", "name": "Bez bezpośrednich zapytań SQL", "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": "Bez bezpośredniej manipulacji DOM", "type": "string_not_contains", "value": "document.getElementById", "severity": "warning" },
    { "id": "cr-react-002", "name": "Bez typów any", "type": "string_not_contains", "value": ": any", "severity": "warning" },
    { "id": "cr-react-003", "name": "Preferuj server components", "type": "string_not_contains", "value": "'use client'", "severity": "info" }
  ]
}

Ten sam skill. Różne reguły. Ten sam mechanizm zapewnienia jakości.

Learnings: Niezależna Pamięć na Projekt

Korekty akumulują się osobno.

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

- [2026-03-20] [fixit] Zawsze używaj t-call do tłumaczeń w QWeb
- [2026-03-22] [negative] Nie nadpisuj bazowego CSS Odoo — używaj własnej klasy
- [2026-04-01] [fixit] Używaj sudo() tylko gdy kontekst bezpieczeństwa tego wymaga

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

- [2026-03-21] [fixit] Używaj server components domyślnie w Next.js 15
- [2026-03-25] [negative] Nie używaj useEffect do pobierania danych — używaj RSC
- [2026-04-02] [fixit] Zawsze waliduj dane wejściowe API schematem Zod

Learnings Odoo z Projektu A nigdy nie zanieczyszczają kontekstu React z Projektu B. „Pamięć immunologiczna" każdego bota jest w 100% dopasowana do własnego stosu technologicznego.

Metryki: Per-Projekt, Per-Skill

/quality na Projekcie 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 na Projekcie 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

Karpathy Loop analizuje każdy projekt niezależnie. Jeśli code-review jest słaby w projekcie Odoo, ale mocny w projekcie React, tylko projekt Odoo otrzyma propozycję ulepszenia.

Kroki Konfiguracji

1. Utwórz projekty

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

2. Dodaj CLAUDE.md per projekt

Napisz konstytucję projektu opisującą stos technologiczny, konwencje i ograniczenia.

3. Skopiuj odpowiednie skille z biblioteki

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

# Projekt B — utwórz nowe dla swojego stosu
write /opt/repos/saas-app/skills/library/react-patterns.md
write /opt/repos/saas-app/skills/library/tailwind-expert.md

4. Dostosuj _registry.json per projekt

Dodaj triggery i słowa kluczowe odpowiednie dla technologii każdego projektu.

5. Napisz evals specyficzne dla stosu

Utwórz pliki .evals.json z regułami sensownymi dla każdego stosu.

6. Używaj i koryguj

Zacznij pracować. Klikaj Fix It gdy coś jest nie tak. Klikaj thumbs-down na złe odpowiedzi. System uczy się i adaptuje per projekt.

Dlaczego Nie Jeden Bot z „Trybami"?

Podejście sfederowane wymaga więcej infrastruktury (jedna sesja tmux per projekt), ale eliminuje wszelkie mieszanie kontekstu z założenia.