Nawyki Claude Code jako komendy: hook, /goal, recenzent i checklista

TL;DR i werdykt

Reguła zapisana w CLAUDE.md to rada, którą Claude waży. Reguła zamieniona w komendę działa niezależnie od tego, czy Claude ją przeczyta. Wzięliśmy API do faktur (Node 20, TypeScript, vitest) na własnej maszynie, z Claude Code 2.1.294, i uruchomiliśmy pięć nawyków jako pięć komend.

• Gotowe: z /goal odpowiedź wypisała pełny wynik vitest, "Tests 44 passed (44)", a cel został oznaczony jako osiągnięty po 1 turze. Bez niego Claude powiedział tylko "pnpm test passes (37/37)", a wynik został zwinięty w wywołaniu narzędzia.
• Reguła, która musi działać: hook PreToolUse zablokował 2 edycje chronionego pliku migracji, a Claude zedytował resztę.
• Jedno zadanie na kontekst: /clear zmniejszył rozmowę z 26.4k do 130 tokenów.
• Ładuj to, czego używasz: /skill-doctor znalazł 52 skille załadowane i nigdy niewywołane (13 + 14 + 25).
• Świeża recenzja: recenzent tylko do odczytu znalazł ten sam błąd kolejności przy remisie co sesja autora, plus brakujący test, i twierdził, że sprawdzenie typów przeszło, choć nie mógł go uruchomić.

Werdykt: ustaw najpierw hook, na regule, która w twoim repo została już złamana. /clear i /skill-doctor nic nie kosztują. /goal zachowaj na długie przebiegi, a recenzenta na merge. Paczka daje ci pliki.

Synteza ze źródłami

Linia w CLAUDE.md nie jest wymuszana. Best practices Anthropic mówią, że linia w stylu Always typecheck before you finish działa przez większość czasu, nie za każdym razem s1. Dokumentacja pamięci podaje cel poniżej 200 linii na CLAUDE.md, bo dłuższe pliki zużywają więcej kontekstu i obniżają przestrzeganie reguł s6. Nasz plik testowy miał cztery reguły, jedną wielkimi literami: "NEVER edit src/store/migrations.ts".

/goal ocenia to, co jest na ekranie. Oceniający nie uruchamia komend ani nie czyta plików, więc warunek musi być czymś, co może wykazać sam output Claude s2. Dlatego nasz warunek żąda wypisania pełnego wyniku testów w rozmowie. Raport z zespołu z około 600 PR wykazał, że jego najgorszy błąd przeszedł tsc, lint i własne testy agenta s8. Sprawdzenie ukończenia, którego nie da się spełnić, kręci się w pętli aż do limitu blokad s9.

Hook kończący się kodem 2 blokuje wywołanie. W przewodniku po hookach kod 2 oznacza zablokowanie akcji s3. W naszym przebiegu, po usunięciu reguły z CLAUDE.md, Claude dwa razy sięgnął po plik migracji i obie edycje wróciły zablokowane z naszym komunikatem. Z linią wielkimi literami Claude sam odmówił, a w 2 późniejszych przebiegach najpierw przeczytał skrypt hooka i nigdy nie próbował tego pliku. Wątek na Hacker News zgłasza najostrzejszy zarzut: blokada jest deterministyczna, to, co model zrobi dalej, już nie s10.

/clear jest darmowe i opróżnia właściwą rzecz. Best practices mówią, że /clear między niepowiązanymi zadaniami nic nie kosztuje s1. Po naszej funkcji /context pokazał 57.5k z 1m tokenów, z Wiadomościami na 26.4k. Po /clear pokazał 31.1k, z Wiadomościami na 130 tokenów. Instrukcje, narzędzia i skille zostały.

/skill-doctor wskazuje to, czego nigdy nie używasz. Oznacza skille na liście, które nigdy nie zostały wywołane, i mówi, gdzie je wyłączyć s7. Na naszej maszynie zgłosił 13 skilli załadowanych, ale niewywołanych, 14 zsynchronizowanych z claude.ai i 25 skilli z pluginów: razem 52, plus 4 pluginy nieużywane od jakiegoś czasu. Miejsce na liście jest ciasne: jeden opis wykazał, że 267 dodatkowych znaków w jednym opisie zredukowało 7 innych skilli do samych nazw s12. Zyskiem jest mniej szumu, a nie połowa kontekstu.

Świeży recenzent pomaga, bo nie widział twojego rozumowania. Best practices mówią to wprost i dodają, że oddanie tego samego zadania subagentowi nie poprawia odpowiedzi s1. Każdy subagent startuje ze świeżym, izolowanym oknem kontekstu s5. Ma to swoją cenę: jeden użytkownik zmierzył każdego subagenta na około 51k tokenów na starcie s14, więc wołaj go raz na funkcję. Nasz recenzent działał 28 s w tle.

Kod

• goal-conditions.md

# /goal conditions

The /goal judge reads only the conversation. It does not run commands or read files, so write the condition as something Claude's own output can demonstrate. Name one end state and the proof you want printed on screen.

## 1. The one we used (overdue invoices endpoint)

```
/goal GET /invoices/overdue returns the overdue invoices with page and pageSize query params, new tests cover it, and the full pnpm test output showing every test passing is printed in this conversation
```

Result on our run: the reply printed the full vitest output, then the goal was marked achieved.

## 2. Template: a bug fix

```
/goal <the failing behaviour> no longer happens, a new test reproduces it and passes, and the full <your test command> output showing every test passing is printed in this conversation
```

## 3. Template: a refactor

```
/goal <the old name or pattern> no longer appears in the code, the output of <your search command> showing no matches is printed in this conversation, and the full <your test command> output showing every test passing is printed too
```

## Rules for all three

- One end state, not a list of wishes.
- The proof is output Claude prints (test results, a search result), never "it works".
- Do not write a condition Claude cannot meet; an unsatisfiable goal loops.
- Check it with `/goal` alone; remove it with `/goal clear`.

goal-conditions.md on GitHub

protect-migrations.sh

#!/bin/sh
# Block edits to the append-only migrations file
path=$(jq -r '.tool_input.file_path // empty')
case "$path" in
  *src/store/migrations.ts)
    echo "migrations.ts is append-only: add a new migration file instead" >&2
    exit 2 ;;
esac
exit 0

protect-migrations.sh on GitHub

settings.json

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Edit|Write",
        "hooks": [ { "type": "command", "command": ".claude/hooks/protect-migrations.sh" } ] }
    ]
  }
}

settings.json on GitHub

reviewer.md

---
name: reviewer
description: Read-only code reviewer. Use it to review the current git diff before a merge, against the conventions in README.md.
tools: Read, Grep, Glob, Bash(git diff:*), Bash(git status:*)
---

You review a diff you did not write. You never edit files.

1. Run `git diff` and read every changed file in full.
2. Read README.md and check the diff against each of its conventions.
3. Look for bugs: wrong edge cases, missing validation, untested branches, behaviour that breaks existing routes.

Report each finding with the file, the line, what is wrong and why it matters. Say plainly when you find nothing real. No style nits.

reviewer.md on GitHub

checklist.md

# Clear and skill-doctor checklist

After every finished task
1. Run `/context` and read what the session carries.
2. Run `/clear` before the next unrelated task.
3. Run `/context` again; the conversation should be near empty while instructions, tools and skills stay.
4. In the middle of a task, do not clear: use `/compact` with a focus instead.

Once a month
1. Run `/skill-doctor` (needs a recent Claude Code release).
2. Skills loaded but never invoked: turn them off in `/skills` (space bar cycles).
3. Skills synced from claude.ai: switch them off on the web side, deleting them locally brings them back.
4. Plugin skills: disable the plugin in the Installed tab.
5. Keep what you use rarely but still need.

checklist.md on GitHub

Zrób to w poniedziałek

• Otwórz swój CLAUDE.md i zaznacz każdą linię, która musi działać za każdym razem, a nie przez większość czasu.
• Skopiuj protect-migrations.sh i settings.json do .claude/, wskaż ścieżkę swojego chronionego pliku, potem poproś Claude o jego edycję i obserwuj blokadę.
• Przed następną funkcją wpisz /goal z warunkiem, który żąda wypisania pełnego wyniku testów.
• Gdy to zadanie jest skończone, uruchom /context, potem /clear, potem znów /context.
• Uruchom /skill-doctor i wyłącz to, czego nigdy nie wywołałeś. W zsynchronizowanych skillach zrób to po stronie webowej.
• Skopiuj reviewer.md do .claude/agents/ i poproś o recenzję diffu przed następnym merge'em.
• Po recenzji sam uruchom sprawdzenie typów. Nasz recenzent twierdził, że je zrobił, choć nie mógł go uruchomić.

Idź dalej

Te tematy pominęliśmy.

• Audyt promptu. /doctor prompt-audit i argument "głośniejsza reguła, dłuższy plik". Sprawdź w opisie komend minimalną wersję s4.
• Skille, które nigdy się nie wyzwalają. To dotyczy opisów, a nie tego, co się ładuje. Dobrym początkiem jest tekst primeline s12.
• Przycinanie MCP. Jeden artykuł zmierzył 12 serwerów MCP na 5.8k tokenów z wyszukiwaniem narzędzi i 63k bez niego, więc liczy się to mniej niż kiedyś s13.
• Większe pliki CLAUDE.md. Jeden wpis zmniejszył 455,530 znaków do 88,584 w dziewięciu plikach i zauważa, że importy @path ładują się od razu, a zwykłe linki leniwie s11.
• /batch. Przy dużych refaktoryzacjach opis komend podaje 5 do 30 jednostek, po jednym worktree s4. Nie uruchamialiśmy go.
• Ręczne progi /compact. Nie znaleźliśmy źródła dla stałego procentu, więc żadnego nie podajemy.

FAQ

Czy /goal zastępuje samodzielne uruchamianie testów? Nie. Oceniający czyta tylko rozmowę. Sprawdza, czy wynik został pokazany, a nie czy jest prawdziwy.

Czy hook powstrzymuje Claude przed próbą edycji? Nie. Zatrzymuje edycję, gdy tylko Claude ją podejmie. W naszym przebiegu Claude bez reguły w CLAUDE.md dwa razy sięgnął po plik, a obie edycje zostały zablokowane.

Czy po dodaniu hooka powinienem usunąć reguły z CLAUDE.md? Nie. Z linią wielkimi literami Claude sam odmówił edycji, co oszczędza zablokowane wywołanie. Zachowaj je na to, czego Claude nie wywnioskuje z twojego kodu.

Dlaczego nie używać recenzenta przy każdej edycji? Każdy subagent startuje z własnym pełnym kontekstem, więc kosztuje prawdziwe tokeny. Używaj go raz na funkcję, przed merge'em.

Czy /skill-doctor zadziała na mojej wersji? Według opisu komend zależy od flagi funkcji i niedawnego wydania s4. Na 2.1.294 działał na naszej maszynie, ale jeśli u ciebie nie działa, najpierw zaktualizuj Claude Code.