W poprzednim wpisie opisałem całe środowisko: 120 plików, 18 agentów, 22 reguły, 11 hooków. Jeden element potraktowałem po macoszemu: 51 własnych slash komend. To najbardziej widoczna część tego setupu, to co faktycznie wpisuję na co dzień. Ten wpis opisuje jak to działa. Kolejne wpisy przejdą przez każdą kategorię.

Czym jest plik komendy

Komenda to plik markdown w .claude/commands/. Kiedy wpiszę /deploy w Claude Code, program znajduje commands/deploy.md, czyta go i traktuje jako moje instrukcje na tę sesję. Nazwa pliku staje się nazwą komendy. To cały mechanizm.

Nie ma kroku rejestracji, żadnego pliku konfiguracyjnego do aktualizowania, żadnego restartu. Wrzucam plik markdown do katalogu i komenda istnieje.

Najprostsza możliwa komenda to po prostu instrukcje:

1
2
3
4
5

# /summarize

Podsumuj poniższą treść w 3 punktach. Konkretnie. Bez wypełniaczy.

Treść: $ARGUMENTS

$ARGUMENTS to jedyna specjalna zmienna. Zostaje zastąpiona tym, co wpiszę po nazwie komendy. Uruchamiam /summarize https://example.com/article i Claude czyta plik z podstawionym URL-em.

Jeśli komenda nie wymaga żadnego wejścia, $ARGUMENTS w ogóle nie jest potrzebne. /morning odpala pełny poranny briefing bez żadnych argumentów.

Frontmatter

Komendy obsługują opcjonalny frontmatter YAML z trzema polami:

1
2
3
4
5

---
allowed-tools: Bash(curl:*)
argument-hint: [opis]
description: Uruchom timer Toggl
---

allowed-tools ogranicza, jakich narzędzi komenda może używać. Komendy Toggl potrzebują tylko curl, więc są zablokowane do Bash(curl:*). To zabezpieczenie i jednocześnie sygnał dla Claude, co jest w zakresie tej komendy.

description pojawia się w pickerze komend, gdy wpisuję /. To jednolinijkowa etykieta obok nazwy komendy.

argument-hint pokazuje podpowiedź w pickerze za nazwą komendy, coś jak sygnatura funkcji. /toggl:start [opis] mówi mi co podać, bez otwierania pliku.

Żadne z tych pól nie jest wymagane. Większość moich komend pomija frontmatter i polega tylko na instrukcjach.

Struktura katalogów i przestrzenie nazw

Podkatalogi tworzą komendy z przestrzeniami nazw. Plik w commands/toggl/start.md staje się /toggl:start, nie /start. Plik w commands/devops/deploy.md staje się /devops:deploy.

Moja struktura:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

.claude/commands/
  analysis/     # 5 komend
  code/         # 3 komendy
  content/      # 6 komend
  devops/       # 11 komend
  docs/         # 3 komendy
  media/        # 6 komend
  productivity/ # 3 komendy
  search/       # 2 komendy
  toggl/        # 8 komend
  comms/        # 1 komenda

Przy 51 komendach przestrzenie nazw sprawiają, że picker pozostaje czytelny. /toggl:start, /toggl:stop, /toggl:current i /toggl:summary są wyraźnie powiązane. /deploy i /devops:deploy byłyby niejednoznaczne. Dwukropek pokazuje grupowanie w miejscu wywołania.

Można też umieścić README.md w podkatalogu. Nie stanie się komendą, to zwykła dokumentacja mieszkająca obok plików, które opisuje. Katalog toggl/ ma taki plik, wyjaśniający konfigurację tokenu API.

Wzorzec wewnątrz komendy

Pliki komend, które faktycznie oszczędzają czas, mają wspólną strukturę. Kroki, nie proza. Konkretne wywołania narzędzi, nie ogólne prośby. Potwierdzenie przed czymkolwiek destruktywnym.

Szkielet wygląda tak:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# /moja-komenda

Krótki opis co to robi.

## Kroki

1. Zbierz dane (uruchom równolegle jeśli możliwe):
   - konkretne narzędzie lub komenda bash
   - kolejne konkretne narzędzie lub komenda bash

2. Przedstaw wyniki. Zapytaj o potwierdzenie przed kontynuowaniem.

3. Zrób to (tylko po potwierdzeniu przez użytkownika):
   ```bash
   właściwa komenda tutaj
  1. Zweryfikuj wynik.
1
2
3
4
5
6
7
8


Instrukcja równoległego wykonywania jest prawdziwa. Claude uruchamia kilka sprawdzeń jednocześnie, gdy plik tak mówi. Potwierdzenie też jest prawdziwe. "Do NOT proceed without explicit user approval" to nie dekoracja, to trzyma.

Referencje narzędzi mają znaczenie. Napisanie `mcp__trigger__list_deploys with environment: "prod"` jest lepsze niż "sprawdź ostatnie wdrożenia." Ogólna wersja działa, dopóki nie przestaje. Konkretne nazwy narzędzi dają spójne zachowanie między sesjami. Prawdziwe przykłady tego pokazuję w poście o [komendach devops](/posts/claude-code-devops-commands/).

## Strategie rozumowania

Większość komend zawiera flagę strategii:

Usage: /deploy [–strategy ] Default strategy: standard.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Strategia kontroluje jak Claude podchodzi do zadania. `reflexion` oznacza szkic, samokrytykę, poprawkę, dobra do tekstu. `cot` (chain-of-thought) sprawdza się lepiej przy diagnozie i debugowaniu. `standard` wystarczy do wszystkiego operacyjnego.

Dla prostych komend to niepotrzebne. Ale dla wszystkiego, gdzie liczy się jakość wyjścia, wbudowanie odpowiedniej strategii daje spójne wyniki bez pamiętania, żeby o to prosić. `/humanize` zawsze używa `reflexion`. `/review-pr` zawsze używa `self-refine`. Już o tym nie myślę.

## Odwoływanie się do reguł zamiast ich powtarzania

Jeszcze jeden wzorzec wart poznania: komendy mogą odwoływać się do innych plików zamiast duplikować logikę.

Komenda `/humanize` nie wypisuje wszystkich 40 zakazanych słów i konstrukcji inline. Mówi:

```markdown
Zastosuj reguły humanizatora z `.claude/rules/humanizer.md`.

Claude czyta ten plik jako część wykonywania komendy. Jeśli zaktualizuję reguły, każda komenda, która się do nich odwołuje, automatycznie je pobiera. Pliki komend zostają krótkie, a reguły są w jednym miejscu.

To samo działa z definicjami agentów. /review-pr mówi Claude, żeby uruchamiał równoległe agenty Explore dla dużych pull requestów. Agenty są zdefiniowane osobno w .claude/agents/. Komenda tylko wywołuje je po nazwie.

Co dalej

To tyle z mechaniki. Plik trafia do katalogu, nazwa staje się komendą, $ARGUMENTS niesie wejście użytkownika, frontmatter dodaje opcjonalne ograniczenia, a treść pliku to po prostu instrukcje.

Ciekawa część to to, co umieszczasz w plikach. Następny wpis: 11 komend devops, które zastąpiły moje runbooki.