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
Dział zatytułowany „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
Dział zatytułowany „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 copyKaż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)
Dział zatytułowany „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)
Dział zatytułowany „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łuallowed-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 reviewwedł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. W 2026 Anthropic kieruje użytkowników w stronę nowszego formatu .claude/skills/<name>/SKILL.md, który wspiera zarówno /skill-name, jak i autonomiczne wywołanie przez Claude’a. CLI nadal wspiera oba formaty — .claude/commands/ dla wywołania jawnego, .claude/skills/ dla jawnego + sterowanego przez model. Dla Q7 oba liczą się, o ile komenda jest wywoływana jako /skill-name.
Cursor .cursor/skills/
Dział zatytułowany „Cursor .cursor/skills/”Cursor (z Composer 2.5) czyta skille z .cursor/skills/ w roocie projektu. W przeciwieństwie do Claude Code, Cursor nie ma globalnego katalogu skilli — wszystkie są project-scoped, co jest zaletą dla współdzielonych setupów (wymusza commit). Każdy skill to folder z plikiem SKILL.md:
.cursor/skills/├── code-reviewer/│ └── SKILL.md├── test-generator/│ └── SKILL.md└── migration-planner/ └── SKILL.mdSKILL.md używa tej samej konwencji frontmatter + body co Claude Code, a Cursor wywołuje go przez picker / w panelu Agents. Ponieważ wszystko jest w repo, git clone plus reload workspace’u daje każdemu w zespole te same skille bez dodatkowego setupu. To najczystsza historia “shared via repo” z trójki — skille dosłownie nie mają gdzie indziej istnieć.
Praktyczny .cursor/skills/test-generator/SKILL.md dla projektu z Vitestem:
---name: test-generatordescription: 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.
Ograniczenia Codexa + obejście przez Skills
Dział zatytułowany „Ograniczenia Codexa + obejście przez Skills”To gwiazdka przy Q7 dla użytkowników OpenAI. Codex CLI nie wspiera własnoręcznie pisanych slash commands — tylko wbudowane (/init, /skills itd.) działają w menu slash. W repo openai/codex jest otwarty issue #13893 proszący o “Add custom slash commands from SKILL.md”, ale w połowie 2026 wciąż nie został zshipowany. Najbliższy odpowiednik to Skills: Codex czyta je z ~/.codex/skills/<name>/SKILL.md (osobiste) lub .codex/skills/<name>/SKILL.md (project-scoped), aplikowane przez picker /skills lub odwołanie w promptcie — ale nie przez bezpośredni skrót /skill-name.
Jeśli jesteś użytkownikiem primarnie Codexa, oceń Q7 po pokryciu Skillami: 8+ skilli w ~/.codex/skills/ lub .codex/skills/ z częścią zacommitowaną do repo 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-descriptiondescription: 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
Dział zatytułowany „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/commandslubmkdir -p .cursor/skills/<name>. Stwórzreview.mdlubreview/SKILL.mdz frontmatterem i body według przykładów. Pierwszy zachowaj na 20–50 linii. - Dodaj poprawnie YAML frontmatter.
descriptionma 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 dodajallowed-tools. - Przekazuj argumenty przez
$ARGUMENTSlub$1. Użyj$ARGUMENTSdla pełnego stringa lub$1,$2dla pozycyjnych. Dodajargument-hintw 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
/reviewna następnym PR. Użyj/test-generatorprzy następnym module. - Iteruj markdown po każdym użyciu. Gdy
/reviewcoś przegapi, dodaj ten przypadek do pliku. Gdy/pr-descriptionwymaga reformatowania, zmień szablon. Po kwartale Twój/reviewprzewyż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.mddziałał w.claude/skills/<name>/i.cursor/skills/<name>/— dzielą format. Użyj symlinka, kataloguskills/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-descriptioni dostać użyteczny output. Jeśli nie — biblioteka nie jest współdzielona, jest tylko zacommitowana.
Częste pułapki
Dział zatytułowany „Częste pułapki”- Przekombinowanie pierwszej komendy. Nie pisz idealnego
/reviewpierwszego 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.shlub 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.mdmó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 Codex nie wspiera własnych slash commands. Oceń się po pokryciu Skillami.
Jak zweryfikować, że jesteś na miejscu
Dział zatytułowany „Jak zweryfikować, że jesteś na miejscu”.claude/commands/lub.cursor/skills/(lub.codex/skills/) 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$ARGUMENTSlub$1tam, gdzie ma sens. - Inżynierowie wywołują komendy jako
/review,/pr-descriptionitd. w codziennej pracy — nie tylko w dniu napisania. - Nowe osoby dostają te same komendy przy
git clonebez 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.