Własne slash commands — skille na jeden klawisz, współdzielone przez repo

Pytanie scorecardu: Ile własnych slash commands masz w .claude/commands/ lub .cursor/skills/ wywoływanych jako /skill-name? Odpowiedź na maksa (3 pkt): 8+, z częścią współdzieloną z zespołem przez repo.

Dlaczego to ma znaczenie w 2026

Slash commands zamieniają wieloetapowy prompt w skill wywoływany jednym klawiszem. Zespół, który ships najszybciej, to zespół z największą liczbą zinternalizowanych skrótów. Za każdym razem, gdy przepisujesz “przejrzyj diff, sprawdź brakujące testy, wyłap sekrety i napisz podsumowanie w stylu PR-ów zespołu” — to slash command, który czeka na narodziny. Gdy taki prompt zamieszka pod /review, ta sama pięcioparagrafowa instrukcja kurczy się do siedmiu znaków i działa identycznie u każdego inżyniera. Efekt skumulowany jest gigantyczny: zespół z 10 dobrze dostrojonymi slash commands robi code review, scaffold testów, draft migracji i release notes w sekundy, podczas gdy zespół bez nich wciąż wkleja te same prompty z prywatnej notatki w Notion. 2026 to rok, w którym ta różnica stała się widoczna na dashboardach velocity.

Jest też efekt drugiego rzędu, ważniejszy niż oszczędność klawiszy. Slash commands to wykonywalne konwencje zespołu. Komenda /pr-description to spisana, wersjonowana i code-review’owana reguła, jak Twój zespół pisze opisy PR-ów. Komenda /migration-plan koduje checklistę, którą seniorzy przechodzą przy każdej zmianie schematu. Gdy dołącza nowa osoba, nie czyta strony wiki — wpisuje /migration-plan i mózg seniora jest w pętli. Dlatego “8+ współdzielonych przez repo” jest odpowiedzią na maksa — współdzielenie jest sednem. Prywatny folder pomaga jednej osobie; zacommitowany podnosi cały zespół.

Jak wygląda “maksymalny wynik” w praktyce

Setup na maksa w Q7 ma katalog .claude/commands/ lub .cursor/skills/ w roocie repo (nie tylko w katalogu domowym), zacommitowany do gita, zawierający co najmniej osiem plików markdown pokrywających workflow, które zespół uruchamia najczęściej. Zawartość jest konkretna i specyficzna dla danego codebase’u, a nie generyczne prompty skopiowane z bloga. Typowy układ wygląda tak:

.claude/commands/
├── review.md              # Code review z checklistą naszego zespołu
├── pr-description.md      # Opis PR-a w naszym szablonie
├── migration-plan.md      # Checklista migracji D1
├── test-scaffold.md       # Scaffold Vitest dla nowych modułów
├── release-notes.md       # Release notes z commit logu
├── security-scan.md       # Skan zmian w stylu OWASP
├── docs-update.md         # Sync dokumentacji MDX ze zmianami w kodzie
└── i18n-check.md          # Sprawdzenie parytetu PL+EN dla nowego copy

Każdy plik to markdown z blokiem YAML frontmatter (description, opcjonalnie allowed-tools, opcjonalnie argument-hint) i body, które jest właściwym promptem — zwykle 20–80 linii. Inżynierowie wywołują je przez /review, /pr-description ścieżka/do/spec.md, /migration-plan add-user-flags-table. Argumenty po nazwie komendy lecą do $ARGUMENTS (lub indeksowanych $1, $2) wewnątrz markdownu. Cały katalog jest zacommitowany, więc git pull na czystym checkoucie daje nowej osobie te same osiem klawiszy co tech leadowi. Część komend jest project-scoped; kilka jest personalnych (~/.claude/commands/) dla nawyków, które nie są jeszcze standardami — proporcja 70/30 to zdrowy podział.

Porównaj to z niższymi poziomami: zero własnych komend (0 pkt), 1–2 trzymane tylko w ~/.claude/commands/ (1 pkt — feature odkryty, nie zinstytucjonalizowany), 3–7 z jedną-dwiema współdzielonymi (2 pkt — mięsień rośnie, brak zgody zespołu na wspólny zestaw). Skok z 2 do 3 pkt jest bardziej socjologiczny niż techniczny: to moment, w którym zespół umawia się “tak my robimy review” i commituje prompt do repo.

Aktualny stan ekosystemu (zweryfikowany web-searchem)

Ekosystem slash commands w 2026 ustandaryzował się wokół plików markdown w znanym katalogu, z trzema narzędziami Tier 1 zbiegającymi się w subtelnie różnych ścieżkach. Zrozumienie różnic dzieli portowalną bibliotekę od takiej, która działa tylko w jednym narzędziu.

Claude Code `.claude/commands/` (pliki markdown, argumenty)

System slash commands w Claude Code jest najbardziej dojrzały. Współistnieją dwa zakresy: komendy projektowe w .claude/commands/ (zacommitowane, dzielone) i komendy osobiste w ~/.claude/commands/ (katalog domowy, dostępne wszędzie). Oba wywołuje się tak samo — /command-name w promptcie — i oba to pliki markdown. review.md staje się komendą /review automatycznie. Frontmatter jest opcjonalny, ale rekomendowany; description to to, co pojawia się w pickerze menu /, a allowed-tools może ograniczyć narzędzia (przydatne dla komend read-only typu code review).

Argumenty są przekazywane przez $ARGUMENTS (cały string po nazwie komendy) lub indeksowane $1, $2 itd. z cytowaniem w stylu shella:

---
description: Zrób review aktualnego diffa według checklisty naszego zespołu
allowed-tools:
  - Read
  - Bash(git diff:*)
  - Bash(git log:*)
argument-hint: "[zakres, np. 'security' lub 'perf']"
---

Uruchom `git diff --stat` i `git diff`, żeby zobaczyć aktualne zmiany. Następnie zrób review
według checklisty naszego zespołu:

1. **Typy** — Czy wszystkie parametry funkcji mają jawne typy? Czy gdzieś przemyca się `any`?
2. **Testy** — Czy każda nowa funkcja ma co najmniej jeden test Vitest w `tests/unit/`?
3. **i18n** — Jeśli copy zmieniło się w `/en/`, czy tłumaczenie `/pl/` jest zaktualizowane?
4. **Sekrety** — Czy przypadkiem nie zacommitowano kluczy API, tokenów lub wartości `.env`?
5. **Bezpieczeństwo migracji** — Czy są jakieś `ALTER TABLE` lub `DROP` bez ścieżki rollbacku?

Skup szczególną uwagę na: $ARGUMENTS

Format wyjścia: dla każdego problemu podaj ścieżkę pliku, zakres linii, problem i fix.
Zakończ jednolinijkowym werdyktem: SHIP, FIX FIRST lub REWORK.

Wywołuj jako /review lub /review security. Token $ARGUMENTS rozwija się do tego, co inżynier wpisał po nazwie komendy. Uwaga: w 2026 własne slash commands zostały scalone ze skillami — plik .claude/commands/review.md i skill .claude/skills/review/SKILL.md oba tworzą /review i działają tak samo. Istniejące pliki .claude/commands/ nadal działają; forma skilla dokłada katalog na pliki pomocnicze, frontmatter sterujący tym, czy wywołujesz je Ty czy Claude, oraz opcjonalne autonomiczne wywołanie przez Claude’a. Dla Q7 oba formaty liczą się, o ile komenda jest wywoływana jako /skill-name.

Cursor `.cursor/skills/`

Cursor (2.4+) czyta skille z .cursor/skills/ (oraz .agents/skills/) w roocie projektu, plus z katalogów globalnych ~/.cursor/skills/ i ~/.agents/skills/. Dla współdzielonego setupu zespołu to zacommitowany do repo projektowy katalog .cursor/skills/ jest ścieżką, której chcesz — katalogi globalne są na osobiste narzędzia, które nie są jeszcze standardami zespołu. Każdy skill to folder z plikiem SKILL.md:

.cursor/skills/
├── code-reviewer/
│   └── SKILL.md
├── test-generator/
│   └── SKILL.md
└── migration-planner/
    └── SKILL.md

SKILL.md używa tej samej konwencji frontmatter + body co Claude Code, a Cursor wywołuje go przez picker / w panelu Agents. Ponieważ projektowy katalog .cursor/skills/ żyje w repo, git clone plus reload workspace’u daje każdemu w zespole te same skille bez dodatkowego setupu. Trzymaj konwencje zespołu w zacommitowanym .cursor/skills/; zarezerwuj ~/.cursor/skills/ na osobiste nawyki — dokładnie ten sam podział projekt/osobiste, którego używa Claude Code.

Praktyczny .cursor/skills/test-generator/SKILL.md dla projektu z Vitestem:

---
name: test-generator
description: Generuje testy Vitest dla pliku spod $1 zgodnie z konwencjami zespołu
---

Wygeneruj testy jednostkowe Vitest dla pliku spod `$1`.

Nasze konwencje:
- Testy żyją pod `tests/unit/` w lustrzanej ścieżce do źródła.
- Używamy `happy-dom` do dostępu do DOM (już skonfigurowane w `vitest.config.ts`).
- Mockujemy bindingi Cloudflare używając helperów z `tests/utils/mocks.ts`.
- Każda eksportowana funkcja dostaje co najmniej jeden test happy-path i jeden error-path.
- Używamy bloków `describe()` per funkcja i bloków `it()` per przypadek.

Najpierw przeczytaj plik źródłowy. Zidentyfikuj każdą eksportowaną funkcję i jej sygnaturę.
Zapisz plik z testami w lustrzanej ścieżce. Uruchom `npm test` i potwierdź, że wszystko zielone.

Wywołaj jako /test-generator src/lib/db/queries.ts. Zauważ, że substytucja argumentów w Cursorze używa tej samej konwencji $1 / $ARGUMENTS co Claude Code, co sprawia, że kopiowanie skilla między oba narzędzia jest niemal mechaniczne.

Własne prompty Codexa i Skills

To gwiazdka przy Q7 dla użytkowników OpenAI. Codex CLI wspiera własnoręcznie pisane slash commands na dwa sposoby: własne prompty (pliki Markdown w ~/.codex/prompts/<name>.md, wywoływane jako /prompts:<name>; obecnie deprecated na rzecz skilli, ale wciąż funkcjonalne) oraz skille wywoływane z menu slash przez /skills albo przez wpisanie $, by jeden wzmiankować. Czego dziś brakuje, to gołego skrótu /skill-name dla własnoręcznego SKILL.md — tę lukę śledzi otwarty issue openai/codex #13893 (“Add custom slash commands from SKILL.md”). Skille to ścieżka naprzód: Codex czyta je z ~/.agents/skills/<name>/SKILL.md (user-scoped) oraz .agents/skills/<name>/SKILL.md w repo ($REPO_ROOT/.agents/skills dla wszystkich, zagnieżdżone .agents/skills dla podfolderu), aplikowane przez picker /skills, wzmiankę $ albo niejawne dopasowanie po description skilla.

Jeśli jesteś użytkownikiem primarnie Codexa, oceń Q7 po pokryciu Skillami: 8+ skilli pod ~/.agents/skills/ lub w repozytoryjnym .agents/skills/, z częścią zacommitowaną, to ekwiwalentna odpowiedź na maksa. Codexowy SKILL.md wygląda identycznie jak skill Cursora lub Claude Code — ten sam frontmatter, to samo body — więc dobrze zaprojektowana biblioteka jest portowalna między wszystkimi trzema narzędziami z drobnymi korektami ścieżek.

---
name: pr-description
description: Draft opisu PR-a w szablonie zespołu z commit logu
---

Uruchom `git log $(git merge-base HEAD main)..HEAD --oneline`, żeby zobaczyć commity.
Potem `git diff $(git merge-base HEAD main)..HEAD --stat` dla zakresu plików.

Napisz opis PR-a z tymi sekcjami:
- **Summary** — 1-2 zdania. Co się zmieniło i dlaczego.
- **Changes** — punktowana lista znaczących zmian w plikach (pomiń szum lockfile/config).
- **Testing** — Jak reviewer może zweryfikować, że to działa. Włącz komendę testową.
- **Risk** — Jakieś caveat dotyczące kolejności deployu, migracji lub rollbacku.

Wypluj tylko markdown, bez komentarza.

Krok po kroku: budowanie biblioteki slash commands

Wypisz prompty, które przepisujesz najczęściej w tym tygodniu. Otwórz historię shella, folder transcriptów agenta (~/.claude/projects/) i notatki. Wypisz każdą wieloetapową instrukcję wklejoną więcej niż dwa razy w ostatnich siedmiu dniach. Typowy inżynier wymyśla 12–18 kandydatów.
Wybierz osiem, które mapują się na workflow zespołu. “Wygeneruj test Vitest dla tego pliku” — workflow zespołu. “Przetłumacz tytuł PR-a na zwięźlejszą wersję” — nawyk osobisty. Osiem to dolna granica; zwykle znajdziesz 10–12 wartych commita.
Stwórz katalog i pierwszy plik. Z roota repo: mkdir -p .claude/commands lub mkdir -p .cursor/skills/<name>. Stwórz review.md lub review/SKILL.md z frontmatterem i body według przykładów. Pierwszy zachowaj na 20–50 linii.
Dodaj poprawnie YAML frontmatter. description ma największe znaczenie — pojawia się w pickerze / i pomaga modelowi zdecydować, kiedy skill jest istotny. Zrób go konkretnym (“Review diffa według checklisty Vitest + Drizzle + i18n”, a nie “Robi review kodu”). Dla komend read-only dodaj allowed-tools.
Przekazuj argumenty przez $ARGUMENTS lub $1. Użyj $ARGUMENTS dla pełnego stringa lub $1, $2 dla pozycyjnych. Dodaj argument-hint w frontmatterze, żeby picker pokazywał, co wpisać.
Zacommituj do repo i PR-uj. To zamienia osobistego hacka w standard zespołu. PR z katalogiem i krótkim README opisującym każdą komendę. Zaproś teammate’ów do dodawania swoich. Pierwszy commit odblokowuje połowę “shared via repo” odpowiedzi na maksa.
Uruchom każdą komendę w prawdziwym workflow w ciągu 48 godzin. Slash command, którego nigdy nie użyłeś, to martwy artefakt. Użyj /review na następnym PR. Użyj /test-generator przy następnym module.
Iteruj markdown po każdym użyciu. Gdy /review coś przegapi, dodaj ten przypadek do pliku. Gdy /pr-description wymaga reformatowania, zmień szablon. Po kwartale Twój /review przewyższa prompt bez wsparcia większości inżynierów — bo ma wpieczone wszystkie zespołowo-specyficzne uczenia.
Sprawdzenie portowalności. Jeśli zespół używa więcej niż jednego z Claude Code / Cursor / Codex, zaprojektuj skille tak, by ten sam SKILL.md działał w .claude/skills/<name>/ i .cursor/skills/<name>/ — dzielą format. Użyj symlinka, katalogu skills/ lub kroku buildu. Nie pisz trzech wersji.
Test onboardingu. Daj nowej osobie świeży clone. W pierwszej godzinie powinna móc wpisać /review, /test-generator, /pr-description i dostać użyteczny output. Jeśli nie — biblioteka nie jest współdzielona, jest tylko zacommitowana.

Częste pułapki

Przekombinowanie pierwszej komendy. Nie pisz idealnego /review pierwszego dnia z 200 liniami logiki gałęzi. Wyślij draft na 30 linii, użyj dziesięć razy, potem iteruj. Wersja 200-linijkowa po miesiącu realnego użytku jest dramatycznie lepsza niż napisana w próżni.
Ukryte zależności od osobistego setupu. Komenda odwołująca się do ~/scripts/my-linter.sh lub zakładająca narzędzie spoza zespołu nie jest komendą zespołu. Czy zadziała na świeżej maszynie po czystym clone’ie?
Brak version control komend. Trzymanie ~/.claude/commands/ prywatnie jest ok dla osobistych nawyków, ale każdy zespołowy workflow należy do repo. Failure mode: “na razie potrzymam lokalnie” — sześć miesięcy później zespół ma 30 prywatnych komend i zero współdzielonych, co daje 1 pkt zamiast 3.
Generyczne komendy z bloga. review.md mówiący “Przejrzyj kod uważnie” jest gorszy niż brak komendy — zajmuje namespace bez wartości. Każda komenda powinna odzwierciedlać konwencje Twojego codebase’u.
Mieszanie projektu i osobistych w tym samym katalogu. Osobiste nawyki zostają w ~/.claude/commands/. Konwencje zespołu idą do .claude/commands/. Jeśli nie potrafisz powiedzieć “każdy inżynier powinien tego używać”, to komenda osobista.
Traktowanie slash commands jako niezmiennych. Komenda, która nie zmieniała się przez trzy miesiące, jest spleśniała. Zaplanuj kwartalny review — wyrzuć nieużywane, naostrz najczęściej używane.
Codexowcy olewający to pytanie. Nie wystawiaj sobie 0 na Q7 dlatego, że Codexowi brakuje gołego skrótu /skill-name. Wspiera własne prompty (/prompts:<name>) i skille (/skills albo $) — oceń się po pokryciu Skillami w .agents/skills/.

Jak zweryfikować, że jesteś na miejscu

.claude/commands/ lub .cursor/skills/ (lub .agents/skills/ dla Codexa) istnieje w roocie aktywnego repo i jest zacommitowane.
Katalog zawiera 8+ plików markdown, każdy to prawdziwy workflow uruchamiany przez zespół.
Każdy plik ma YAML frontmatter z konkretnym description, a body używa $ARGUMENTS lub $1 tam, gdzie ma sens.
Inżynierowie wywołują komendy jako /review, /pr-description itd. w codziennej pracy — nie tylko w dniu napisania.
Nowe osoby dostają te same komendy przy git clone bez dodatkowego setupu.
Biblioteka była edytowana co najmniej raz w ostatnich 30 dniach — żywy artefakt, nie jednorazowy commit.
Potrafisz wymienić te osiem komend i wyjaśnić, kiedy każda jest używana, bez zaglądania do plików.

Dalsza lektura

Q4 · Kontekst CLAUDE.md / AGENTS.md Plik kontekstu na poziomie repo, który dopełnia bibliotekę slash commands.

Q8 · Agent skills z autonomicznym wywołaniem Krok wyżej: skille, które model wywołuje sam.

Q13 · Hooki agenta (Stop, PostToolUse) Automatyzuj, co dzieje się przed i po każdym wywołaniu narzędzia.

Wypełnij Developer Scorecard Sprawdź, jak wypadasz we wszystkich 25 pytaniach.