Zaawansowane Slash Commands: polecenia świadome kontekstu

Używaj prefiksu ! do wykonywania poleceń shell wewnątrz slash commands — automatycznie wstrzykuj diff, zawartość plików i wyniki testów

Większość slash commands wygląda tak:

Sprawdź jakość kodu w bieżących zmianach i podaj konkretne sugestie.

To działa, ale ma fundamentalne ograniczenie: Claude musi sam wywnioskować, czym są „bieżące zmiany". Jeśli twój command aktywnie wstrzykuje kontekst, wyniki są zupełnie inne.

Ten artykuł pokazuje, jak zamienić commands w instrukcje „widzące" — które po uruchomieniu automatycznie odczytują zawartość plików, stan git i informacje o projekcie, wpychając to wszystko do promptu, żeby Claude nie musiał zgadywać.

Kluczowy mechanizm: !`polecenie` wstrzykuje wyjście Shell

Niestandardowe slash commands pozwalają osadzać polecenia shell bezpośrednio w prompcie. Składnia: polecenie ujęte w backticki, poprzedzone wykrzyknikiem — !`polecenie`. Przy uruchomieniu polecenie wykonuje się jako pierwsze, jego wyjście podstawia się w miejsce zmiennej, a Claude dostaje już złożony prompt.

Oto bieżący git diff:

!`git diff HEAD`

Przejrzyj te zmiany, zwracając uwagę na błędy logiczne i problemy bezpieczeństwa.

Polecenia wieloliniowe oformuj jako fenced code block zaczynający się od ```!:

```!
node --version
git status --short
```

Gdy uruchamiane jest /review, to, co Claude faktycznie dostaje, wygląda tak:

Oto bieżący git diff:

diff --git a/app/models/user.rb b/app/models/user.rb
index 3a2f1c8..9b4e2d1 100644
--- a/app/models/user.rb
+++ b/app/models/user.rb
@@ -12,6 +12,9 @@ class User < ApplicationRecord
...

Przejrzyj te zmiany, zwracając uwagę na błędy logiczne i problemy bezpieczeństwa.

Żadnego ręcznego kopiowania — w momencie uruchomienia commanda diff jest już w środku.

Praktyczne wzorce

Wstrzykiwanie zawartości bieżącego pliku

---
allowed-tools: Bash(cat:*)
---

Oto pełna zawartość bieżącego pliku:

!`cat $ARGUMENTS`

Znajdź wszystkie potencjalne problemy z wydajnością w tym pliku. Podaj konkretne numery linii i poprawki.

Użycie: /perf app/models/order.rb

$ARGUMENTS przyjmuje ścieżkę pliku, a cat odczytuje jego zawartość i ją wstrzykuje. Claude widzi prawdziwy kod, a nie mglisty opis w stylu „spójrz na bieżący plik".

allowed-tools we frontmatterze z góry autoryzuje polecenie cat, więc przy uruchomieniu nie pojawia się prośba o pozwolenie. Bez tej linii musiałbyś klikać „Zezwól" przy każdym uruchomieniu. Wszystkie przykłady poniżej wymagają tej samej deklaracji.

Wstrzykiwanie stanu git

Bieżąca gałąź i stan zmian:

!`git status --short`
!`git log --oneline -10`

Na podstawie powyższego wygeneruj zwięzły opis PR obejmujący co się zmieniło i dlaczego.

Ten /pr command nie prosi cię o opisanie „co zmieniłem" — sam to czyta.

Wstrzykiwanie informacji specyficznych dla projektu

Stos technologiczny projektu:

!`cat .claude/context/stack.md`

Bieżący schemat bazy danych (kluczowe tabele):

!`head -100 db/schema.rb`

W oparciu o ten kontekst napisz skrypt migracji dla $ARGUMENTS zgodny z konwencjami projektu.

Umieść kontekst projektu w .claude/context/ z wyprzedzeniem, a command będzie go czytał na żądanie przy uruchomieniu, bez konieczności opisywania projektu od nowa za każdym razem.

Dynamiczne odczytywanie wyników testów

Ostatnie uruchomienie testów:

!`bundle exec rspec --format progress 2>&1 | tail -30`

To są niezdane testy. Przeanalizuj przyczynę źródłową i zaproponuj poprawki. Nie modyfikuj samych testów.

Gdy /fix-tests się uruchamia, testy są odpalane od razu, a wynik zbierany na miejscu — Claude widzi prawdziwe komunikaty błędów.

Kompletny przykład: przegląd kodu świadomy kontekstu

Łącząc wszystko powyższe, /review może być wyjątkowo precyzyjny:

---
description: Przegląd bieżących zmian z automatycznym wstrzykiwaniem diffa i kontekstu
allowed-tools: Bash(git diff:*), Bash(cat:*)
---

## Bieżące zmiany

!`git diff HEAD`

## Lista zmienionych plików

!`git diff HEAD --name-only`

## Standardy kodowania projektu

!`cat .claude/context/coding-standards.md 2>/dev/null || echo "(brak pliku standardów)"`

---

Przejrzyj powyższe zmiany:

1. Poprawność logiczna: nieobsłużone przypadki brzegowe, błędy logiczne
2. Bezpieczeństwo: SQL injection, kontrole autoryzacji, ekspozycja wrażliwych danych
3. Zgodność ze standardami: czy przestrzega standardów kodowania projektu?
4. Czytelność: nazewnictwo, komentarze, struktura

Dla każdego problemu podaj nazwę pliku, numer linii i konkretną sugestię. Jeśli nie ma problemów — powiedz to, nie wymyślaj na siłę.

Ten command nie wymaga od ciebie żadnego przygotowania — przy uruchomieniu diff, lista plików i standardy kodowania są wstrzykiwane automatycznie.

Obsługa niepowodzeń poleceń

Polecenia shell mogą się wywalić (plik nie istnieje, polecenia nie ma w PATH itd.). Użyj ||, żeby dostarczyć wartość domyślną i nie pozwolić commandowi się przerwać:

!`git diff HEAD 2>/dev/null || echo "(brak zmian git lub to nie repozytorium git)"`

!`cat .env.example 2>/dev/null || echo "(brak pliku .env.example)"`

!`which rspec > /dev/null 2>&1 && bundle exec rspec --dry-run 2>&1 | head -20 || echo "(nie wykryto RSpec)"`

Gdy polecenie się wywala, Claude dostaje tekst wyjaśniający zamiast pustki i może odpowiednio dostosować strategię odpowiedzi.

Rozważania wydajnościowe: nie wstrzykuj za dużo

Cały wynik poleceń ! trafia do okna kontekstu. Kilka typowych pułapek:

Nie rób cat na całym dużym pliku

# Niebezpieczne: może wstrzyknąć dziesiątki tysięcy linii
!`cat db/schema.rb`

# Lepiej: wyciągnij tylko to, co potrzebujesz
!`grep -A 5 "create_table \"orders\"" db/schema.rb`

Pliki logów — z limitem linii

!`tail -50 log/development.log`

Wyjście testów ucinaj

!`bundle exec rspec 2>&1 | tail -40`

Im precyzyjniejszy kontekst, tym lepsze odpowiedzi Claude. Wepchanie w niego całego repozytorium nie sprawi, że stanie się mądrzejszy — sprawi, że zgubi się w szumie.

Podział pracy z CLAUDE.md

Częste pytanie: kontekst projektu wkładać do CLAUDE.md czy wstrzykiwać dynamicznie przez !?

Kryterium:

Typ informacji Gdzie
Zawsze potrzebny kontekst projektu (stos, struktura katalogów, konwencje) CLAUDE.md
Stan zmieniający się w czasie (bieżący diff, wyniki testów, zawartość plików) Dynamiczne wstrzykiwanie przez !
Kontekst specyficzny dla zadania (dokumentacja designu konkretnego modułu) !cat na żądanie

CLAUDE.md to trwała wiedza tła, ! to migawka z momentu zadania. Uzupełniają się — nie duplikuj.

Kompletny katalog .claude/commands/

.claude/
├── commands/
│   ├── review.md        # Przegląd: wstrzykuje diff + standardy
│   ├── test.md          # Pisanie testów: wstrzykuje plik docelowy
│   ├── fix-tests.md     # Naprawa testów: wstrzykuje wyniki niezdane
│   ├── pr.md            # Opis PR: wstrzykuje git log + status
│   ├── explain.md       # Wyjaśnianie kodu: wstrzykuje zawartość pliku
│   └── migrate.md       # Pisanie migracji: wstrzykuje fragment schema
├── context/
│   ├── stack.md         # Opis stosu technologicznego
│   └── coding-standards.md  # Standardy kodowania
└── settings.json

W katalogu context/ leżą statyczne pliki kontekstowe, które poszczególne commands odczytują na żądanie. Tę strukturę można od razu commitować do gita i dzielić z zespołem.

Różnica w praktyce

Statyczny command:

Przejrzyj bieżące zmiany kodu.

Claude musi najpierw zapytać „gdzie są zmiany?" albo szukać ich sam — niestabilne wyniki.

Command świadomy kontekstu:

Oto diff (z prawdziwą zawartością), oto odpowiednie standardy (z prawdziwą zawartością), przejrzyj.

Claude od razu przechodzi do analizy. Precyzyjne odpowiedzi, bez lania wody, bez ciągłych dopytań.

Różnica nie tkwi w możliwościach Claude, ale w tym, ile prawdziwych informacji mu dałeś.