System Reguł

Czym są reguły?

Moje AI usunęło plik konfiguracyjny w 8. dniu. Edytowało kod bez czytania go najpierw w 12. dniu. Uruchomiło serwer deweloperski podczas implementacji w 15. dniu, rozładowując baterię laptopa do zera. Każda z tych porażek stała się regułą — i żadna się więcej nie powtórzyła.

Reguły to pliki markdown w ~/.claude/rules/, które automatycznie ładują się na początku każdej sesji Claude Code. O ile CLAUDE.md definiuje tożsamość, reguły definiują zachowanie. To guardrails zapobiegające odchodzeniu AI od scenariusza. Dla business reguły zapewniają spójną jakość w każdej interakcji.

Konwencja nazewnictwa plików reguł

Reguły mają dwucyfrowy prefix numer. Kontroluje to kolejność ładowania. Niższe numery ładują się pierwsze i mają wyższy priorytet.

00-core-identity.md      # Who the AI is (highest priority)
01-routing.md            # Which agent handles which task
02-enforcement.md        # Tool access restrictions
03-agent-orchestration.md # How to spawn and manage agents
04-context-injection.md  # What context to give agents
05-continuity.md         # Session handoff rules
06-read-before-write.md  # Always check before creating

Niezbędne reguły dla Twojego business

Reguła 1: Tabela routingu

Tabela routingu mówi Twojemu AI, który agent obsługuje jaki typ zapytania. Zapobiega to próbom AI robienia wszystkiego samodzielnie.

# Routing Table

Match task DOMAIN before task OPERATION. Specialist beats generic.

| Trigger | Agent |
|---------|-------|
| Research, find out, analyze | researcher |
| Create file, edit file, write | file-executor |
| Bug, error, fix, debug | code-debugger |
| Plan, break down, strategy | task-planner |
| Morning, status, priorities | chief-of-staff |
| Evening, wrap up, summary | chief-of-staff |

**Rule:** If unsure which agent, ask — do not guess.

Reguła 2: Czytaj zanim zapiszesz

Ta reguła zapobiega tworzeniu zduplikowanych plików lub nadpisywaniu istniejącej pracy. To jedna z najbardziej wartościowych reguł w każdym systemie.

# Read Before Write

Before responding to ANY request:

1. Check existing files for relevant content
2. Read the target file before editing
3. Use existing patterns, not raw generation

## NEVER
- Create a file without checking if it exists
- Edit code without reading it first
- Generate content without checking the knowledge base

Reguła 3: Obserwuj zanim edytujesz

# Observe Before Editing

Before editing code to fix a bug, confirm what the system actually produced.

## DO
1. Check if expected output exists
2. Read logs and error messages
3. Run the failing command to see the actual error
4. Only then edit code

## DON'T
- Assume what the error is without checking
- Edit code based on what you think should happen
- Make multiple changes at once

Reguła 4: Ograniczenia agentów

Stwórz dedykowany plik reguł definiujący, czego każdy agent NIGDY nie może robić. To Twoja pamięć instytucjonalna porażek — za każdym razem, gdy agent popełni błąd, dodaj ograniczenie. Te ograniczenia wiążą się bezpośrednio z agentami zdefiniowanymi w Rozdziale 3: Budowanie Agentów.

# Agent Constraints (DON'Ts)

## {agent_name}
1. DON'T [most common failure mode]
2. DON'T [quality issue to prevent]
3. DON'T [safety boundary]
4. DON'T [scope limitation]
5. DON'T [process skip to prevent]

## Enforcement
These constraints should be:
1. Loaded by agents at startup (via protocol read)
2. Checked by verification hooks
3. Flagged in post-work audits

Reguła 5: Zarządzanie serwerami

Uruchamianie serwerów deweloperskich podczas implementacji marnuje baterię, RAM i może powodować konflikty portów. Zdefiniuj regułę: serwery WYŁĄCZONE podczas budowania, WŁĄCZONE tylko na demo.

# Server Management Protocol

## Before Implementation
Kill any running dev servers before starting work.

## During Implementation
Do NOT start dev servers. Use build commands to verify code compiles.
Fix errors in build output, not in the browser.

## After Implementation (Demo Time)
Only start servers when the human asks to see the result.

Reguła 6: Bezpieczeństwo migracji danych

Gdy dane przenoszą się z jednej lokalizacji do drugiej, nigdy nie zmieniaj protokołu, dopóki dane nie zostaną zmigrowane I zweryfikowane. Ta reguła zapobiega utracie danych podczas ewolucji systemu.

1. 1Stwórz skrypt migracyjny ZANIM dotkniesz jakiegokolwiek protokołu.
2. 2Wykonaj migrację i zweryfikuj kompletność (porównaj liczbę wpisów źródło vs cel).
3. 3Zaktualizuj protokoły z podwójnym źródłem danych (najpierw nowe, fallback na stare).
4. 4Monitoruj przez 3+ udanych sesji z nowym źródłem.
5. 5Dopiero wtedy usuń fallback i zarchiwizuj stare źródło.

Reguły są tak silne, jak ich egzekwowanie. Napisanie 'czytaj zanim zapiszesz' jako reguły to krok pierwszy — Rozdział 6: Egzekwowanie Reguł pokazuje, jak budować hooki, które mechanicznie blokują naruszenia, zamieniając życzenia w gwarancje.