Tworzenie poleceń niestandardowych

Każdy zespół ma tego jednego starszego programistę, który zawsze zadaje właściwe pytania podczas przeglądu kodu. Sprawdza przypadki brzegowe obsługi błędów, weryfikuje, że zapytania do bazy danych używają indeksów i wychwytuje zapytanie N+1 zanim trafi na produkcję. Polecenia niestandardowe pozwalają zakodować osąd tego programisty w wielokrotnego użytku polecenie /review, które każdy członek zespołu może uruchomić.

Co zdobędziesz

• Jak tworzyć niestandardowe polecenia slash od prostych szablonów promptów po pełne przepływy pracy agentów
• Wzorce konfiguracji subagentów dla przeglądu kodu, audytu bezpieczeństwa i testowania
• Techniki dzielenia poleceń w zespole przez kontrolę wersji
• Strategie budowania biblioteki poleceń specyficznych dla domeny

Tworzenie niestandardowych poleceń slash

Polecenia niestandardowe w Claude Code to pliki markdown, które znajdują się w określonych katalogach. Gdy wpiszesz / w REPL, pojawiają się obok wbudowanych poleceń.

Struktura plików

Polecenia to pliki .md w tych lokalizacjach:

Lokalizacja	Zakres	Dostępne jako
.claude/commands/review.md	Projekt, współdzielone z zespołem	/project:review
~/.claude/commands/standup.md	Osobiste, wszystkie projekty	/user:standup

Nazwa pliku staje się nazwą polecenia. Podkatalogi tworzą polecenia z przestrzenią nazw: .claude/commands/test/integration.md staje się /project:test:integration.

Proste polecenie przeglądu

Utwórz .claude/commands/review.md:

Przejrzyj zmiany w aktualnym git diff. Dla każdego pliku:

1. Sprawdź obsługę błędów: Czy wszystkie operacje async są opakowane w try/catch? Czy odpowiedzi błędów zawierają znaczące komunikaty?
2. Sprawdź wydajność: Czy są zapytania N+1? Niepotrzebne re-renderowania? Brakujące indeksy dla nowych zapytań?
3. Sprawdź bezpieczeństwo: Czy dane wejściowe użytkownika są walidowane? Czy zapytania SQL są sparametryzowane? Czy sekrety są prawidłowo obsługiwane?
4. Sprawdź testy: Czy zmiany mają odpowiednie pokrycie testami? Czy przypadki brzegowe są przetestowane?

Format wyjścia:
- Zacznij od podsumowania jednoliniowego: PASS, NEEDS CHANGES lub BLOCKING
- Wypisz ustalenia pogrupowane według pliku
- Dla każdego ustalenia wyjaśnij DLACZEGO to ważne i zasugeruj konkretną poprawkę

Teraz każdy członek zespołu może uruchomić /project:review i otrzymać spójny, dokładny przegląd kodu.

Wskazówka

Kopiuj-wklej polecenie dla przeglądu skupionego na bezpieczeństwie:

Utwórz .claude/commands/security-audit.md:

Przeprowadź audyt bezpieczeństwa aktualnych zmian w bazie kodu (git diff HEAD).

Sprawdź:
- Luki injection (SQL, XSS, command injection)
- Ominięcia uwierzytelniania/autoryzacji
- Ujawnienie wrażliwych danych (klucze API, tokeny, PII w logach)
- Niezabezpieczone zależności (sprawdź zmiany package.json)
- Brakująca walidacja wejścia na endpointach API
- Hardcoded credentials lub sekrety

Dla każdego znaleziska oceń priorytet jako CRITICAL, HIGH, MEDIUM lub LOW.
Podaj dokładny plik i numer linii, lukę i konkretną poprawkę.

Dynamiczne polecenia ze zmiennymi

Polecenia mogą zawierać $ARGUMENTS aby przyjmować dane wejściowe podczas wywoływania:

.claude/commands/explain.md

Wyjaśnij następujący kod lub koncept w kontekście tego projektu: $ARGUMENTS

Skup się na:
- Co robi i dlaczego istnieje
- Jak łączy się z otaczającym kodem
- Wszelkie nieoczywiste decyzje projektowe
- Potencjalne pułapki dla przyszłych maintainerów

Użycie: /project:explain logika ponownego połączenia WebSocket w src/realtime/

Budowanie subagentów

Subagenty to wyspecjalizowane instancje Claude Code z własnym oknem kontekstu, narzędziami i instrukcjami. Są idealne do zadań wymagających skoncentrowanej analizy bez zanieczyszczania kontekstu głównej sesji.

Format pliku subagenta

Utwórz .claude/agents/reviewer.md:

---
description: "Ekspertowy recenzent kodu. Wyzwala się automatycznie po zmianach w kodzie lub gdy wymagany jest przegląd."
tools:
  - Read
  - Grep
  - Glob
  - Bash
model: sonnet
---

Jesteś starszym recenzentem kodu z ekspertyzą w TypeScript i Node.js.

Podczas przeglądania kodu:
1. Najpierw przeczytaj git diff aby zrozumieć zakres zmian
2. Sprawdź każdy zmodyfikowany plik pod kątem:
   - Problemów z bezpieczeństwem typów (typy any, brakujące sprawdzenia null)
   - Luk w obsłudze błędów
   - Problemów wydajnościowych (niepotrzebne iteracje, brakująca memoizacja)
   - Pokrycia testami
3. Bądź konkretny: odwołuj się do dokładnych ścieżek plików i zakresów linii
4. Sugeruj konkretne poprawki, nie niejasne ulepszenia
5. Doceniaj dobre wzorce gdy je widzisz

Wyprodukuj strukturalizowany przegląd z werdyktem APPROVE, REQUEST_CHANGES lub COMMENT.

Opcje konfiguracji subagenta

Pole	Wymagane	Opis
description	Tak	Kiedy agent powinien być wyzwalany (Claude czyta to aby zdecydować)
prompt	Nie	Prompt systemowy (alternatywnie, napisz w treści pliku)
tools	Nie	Ograniczenia narzędzi. Domyślnie dziedziczy wszystkie narzędzia
model	Nie	sonnet, opus, haiku lub inherit
maxTurns	Nie	Maksymalna liczba agentycznych tur przed zatrzymaniem agenta
disallowedTools	Nie	Narzędzia do jawnego zablokowania

Wskazówka

Kopiuj-wklej subagent dla automatycznego generowania testów:

Utwórz .claude/agents/test-writer.md:

---
description: "Generuje kompleksowe zestawy testów. Użyj gdy nowy kod potrzebuje testów lub istniejące testy wymagają rozszerzenia."
tools:
  - Read
  - Grep
  - Glob
  - Edit
  - Write
  - Bash
model: sonnet
---

Jesteś specjalistą od testowania. Gdy poproszono o napisanie testów:

1. Przeczytaj plik źródłowy i zrozum jego publiczne API
2. Sprawdź istniejące testy pod kątem wzorców (framework testowy, styl asercji, podejście do mockowania)
3. Wygeneruj testy pokrywające:
   - Ścieżkę happy path dla każdej publicznej funkcji/metody
   - Przypadki brzegowe (puste wejścia, wartości null, warunki graniczne)
   - Przypadki błędów (nieprawidłowe wejścia, awarie sieci, timeouty)
   - Punkty integracji (wywołania bazy danych, wywołania API)
4. Przestrzegaj istniejących konwencji testowych w tym projekcie
5. Uruchom testy po ich napisaniu aby zweryfikować, że przechodzą

Nigdy nie mockuj tego, co możesz przetestować bezpośrednio. Preferuj testy integracyjne nad testami jednostkowymi dla operacji bazodanowych.

Wyzwalanie subagentów

Subagenty wyzwalają się na dwa sposoby:

1. Automatycznie: Claude czyta pole description i decyduje, kiedy subagent byłby pomocny. Dobre opisy poprawiają automatyczne wyzwalanie.
2. Jawnie: Poproś Claude aby “uruchomił agenta reviewer” lub “użył test-writer do dodania testów dla auth.ts.”

Subagenty zdefiniowane w CLI

Dla tymczasowych lub eksperymentalnych agentów, zdefiniuj je w linii poleceń:

claude --agents '{
  "performance": {
    "description": "Analizuje kod pod kątem wąskich gardeł wydajnościowych",
    "prompt": "Jesteś inżynierem wydajności. Profiluj i analizuj kod pod kątem wąskich gardeł. Skup się na złożoności algorytmicznej, alokacji pamięci i wzorcach I/O.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Budowanie biblioteki poleceń zespołowych

Organizowanie poleceń według przepływu pracy

.claude/
  commands/
    review.md          # Ogólny przegląd kodu
    security-audit.md  # Przegląd skupiony na bezpieczeństwie
    explain.md         # Wyjaśnienie kodu z kontekstem
    refactor.md        # Przepływ pracy refaktoryzacji z przewodnikiem
    test/
      unit.md          # Generuj testy jednostkowe
      integration.md   # Generuj testy integracyjne
      e2e.md           # Generuj testy end-to-end
    deploy/
      checklist.md     # Weryfikacja przed wdrożeniem
      rollback.md      # Asystent wycofania
  agents/
    reviewer.md        # Subagent przeglądu kodu
    test-writer.md     # Subagent generowania testów
    debugger.md        # Specjalista od debugowania

Dzielenie poleceń przez Git

Ponieważ .claude/commands/ i .claude/agents/ to zwykłe pliki w twoim repozytorium, są automatycznie współdzielone gdy je committujesz:

git add .claude/commands/ .claude/agents/
git commit -m "Add team review and test-writing commands"

Nowi członkowie zespołu otrzymują całą bibliotekę poleceń gdy klonują repo.

Notatka

Polecenia osobiste w ~/.claude/commands/ nie są współdzielone. Używaj tego do osobistych skrótów produktywności, które odzwierciedlają twoje indywidualne preferencje przepływu pracy zamiast standardów zespołowych.

Gdy to się psuje

Subagent nie wyzwala się automatycznie: Popraw pole description. Claude potrzebuje jasnych wskazówek kiedy używać każdego agenta. Dodaj frazy jak “Użyj proaktywnie po zmianach w kodzie” lub “Wyzwala się gdy testowanie jest omawiane.”

Polecenie jest za długie i zostaje obcięte: Claude Code ładuje pełny plik polecenia do kontekstu. Bardzo długie polecenia (więcej niż 500 linii) mogą wyprzeć inny ważny kontekst. Utrzymuj polecenia skoncentrowane i deleguj złożoną logikę do subagentów.

Agent dziedziczy zbyt wiele narzędzi: Domyślnie subagenty dziedziczą wszystkie narzędzia z sesji nadrzędnej. Jeśli twój agent nie powinien modyfikować plików, jawnie ogranicz jego narzędzia do ["Read", "Grep", "Glob", "Bash"].

Polecenia zespołowe kolidują z poleceniami osobistymi: Polecenia projektowe używają prefiksu /project:, polecenia osobiste używają /user:. Jeśli masz oba, są wyraźnie oddzielone. Jednakże jeśli definicja agenta istnieje zarówno w .claude/agents/ jak i ~/.claude/agents/ z tą samą nazwą, wersja projektowa ma pierwszeństwo.

Co dalej

• Hooks i automatyzacja — Połącz hooks z poleceniami dla w pełni zautomatyzowanych przepływów pracy
• System pamięci — Spraw, aby twoje polecenia były świadome kontekstu dzięki pamięci projektu
• Inżynieria promptów — Pisz lepsze prompty wewnątrz swoich niestandardowych poleceń