New → research → plan → implement → review → archive. Jedna zmiana, sześć jawnych kroków.
BIBLIOTEKA SKILLI // KATALOG
Wszystkie skille kursu w jednym katalogu
Skille 10x-toolkit pogrupowane modułami kursu: 38 dostarczanych w lekcjach i dwa dodatkowe. Każda karta odpowiada na trzy pytania - co skill robi, po co istnieje i o czym pamiętać - i prowadzi do strony modułu, strony skilla (gdy istnieje) oraz wpisu w dokumentacji.
00PREWORK // GENERAL TOOLKIT
Moduł 0: prompty General Toolkit
Prework dostarcza General Toolkit - koszyk promptów cross-cutting (m.in. skill-explainer i mvp-check). To prompty, dlatego nie mają kart w bibliotece: wklejasz je do rozmowy z agentem zamiast instalować w repozytorium.
01MODUŁ 1 // FUNDAMENT
Fundament: projekt gotowy na agenta
Skille przygotowania projektu: ocena pomysłu, kontekst, wymagania, stack, reguły i infrastruktura, zanim agent napisze pierwszą linię kodu.
/10x-idea-check
M1L1
Co robi
Pięciominutowa rozmowa o pomyśle na projekt kursowy: zestawia go z Twoim doświadczeniem, celami nauki, dostępnym czasem i terminem certyfikacji, a na końcu poleca jeden ruch.
Po co
Zanim zainwestujesz w /10x-shape, wiesz, czy kształtować ten pomysł, jego okrojoną wersję, czy najpierw usunąć konkretną przeszkodę.
O czym pamiętać
Nie wymaga repozytorium ani dokumentów i zadaje maksymalnie trzy pytania; to nie audyt zgłoszenia ani generator PRD.
Prowadzi ustrukturyzowaną rozmowę odkrywczą, która zamienia pomysł w shape-notes.md - wejście do /10x-prd. Tryb greenfield lub brownfield wykrywa z bieżącego repozytorium.
Po co
Ustalenia zapadają przed PRD i kodem, więc kolejne prompty ich nie podważają.
O czym pamiętać
Poprzedza /10x-prd; wynikiem są notatki decyzji, dopiero /10x-prd składa z nich dokument wymagań.
Generuje context/foundation/prd.md z shape-notes.md według zamkniętego schematu; sam wybiera szablon greenfield (10 sekcji) lub brownfield (11 sekcji).
Po co
Jeden dokument wymagań w stałym formacie, czytany przez kolejne skille fundamentu: selector stacku, roadmapę i plan testów.
O czym pamiętać
Przyjmuje też surowe notatki, ale najlepszym wejściem jest shape-notes.md z /10x-shape.
Ocenia stack istniejącego projektu według 4 bramek jakości i zapisuje stack-assessment.md: oceny per komponent, luki i gotowe wpisy do CLAUDE.md/AGENTS.md.
Po co
Zanim agent zacznie pracę w brownfieldzie, warto wiedzieć, gdzie stack będzie mu przeszkadzał.
O czym pamiętać
Brownfieldowy odpowiednik selectora stacku; w łańcuchu brownfield poprzedza /10x-health-check.
Dopisuje jedną powtarzalną regułę do context/foundation/lessons.md w stałym formacie: kontekst, problem, reguła, zastosowanie. Plik zakłada się sam przy pierwszym użyciu.
Po co
Raz opłacona klasa błędu staje się twardym ograniczeniem dla przyszłych planów, implementacji i review.
O czym pamiętać
Wyłącznie dopisywanie, bez edycji istniejących wpisów; zapisuj klasy problemów - jednorazowe poprawki zostają w commitach.
Krótki wywiad plus równoległy, kontrolowany pod kątem biasu research platform deploymentu MVP; zapisuje infrastructure.md z punktowanym porównaniem i rejestrem ryzyk.
Po co
Decyzja o platformie zapada na dowodach z aktualnych źródeł, zanim projekt zwiąże się z konkretnym dostawcą.
O czym pamiętać
Uruchamiany po PRD lub wyborze stacku, przed implementacją; bramkę gotowości do deployu robi później /10x-deployment.
Prowadzi interaktywne, sceptyczne planowanie: skaluje liczbę pytań do złożoności i dostarczonych artefaktów, zapisuje plan.md z etapami, kryteriami sukcesu i sekcją Progress oraz skrót plan-brief.md.
Po co
Kluczowe decyzje zapadają przed kodem, gdzie zmiana zdania kosztuje edycję tekstu.
O czym pamiętać
Każdy dostarczony artefakt (research, frame) to mniej pytań; checkboxy żyją wyłącznie w sekcji Progress.
Recenzuje plan w pięciu wymiarach: zgodność ze stanem docelowym, oszczędność wykonania, dopasowanie architektoniczne, martwe pola i kompletność; zapisuje reviews/plan-review.md.
Po co
Wada planu wychwycona przed implementacją kosztuje edycję dokumentu; wychwycona w kodzie kosztuje refaktor.
O czym pamiętać
Ponowne uruchomienie nadpisuje raport; flaga --quick ogranicza review do samego dokumentu.
Audytuje i poprawia jeden działający widok jako zwykłą zmianę 10x: 3-5 zarzutów (brakujące tokeny, brak wspólnego komponentu, przypadkowa architektura), najpierw kontrakt design systemu, potem piksele.
Po co
Kolejne widoki dziedziczą tokeny i komponenty zamiast literałów, a reguła w pliku agenta pilnuje kontraktu w następnych sesjach.
O czym pamiętać
Działa tylko na widoku, który już się renderuje z prawdziwymi danymi; prowadzi przez /10x-research → /10x-plan → /10x-implement z macierzą 7 stanów i bramką screenshotu.
Zamienia bramki jakości z test-plan.md na działające hooki agenta (Claude Code, Cursor, Codex, Copilot): mapuje każdą bramkę na moment - edycja, koniec tury, commit, push, CI - i generuje konfigurację oraz skrypty.
Po co
Hook ma sens tylko wtedy, gdy jego komunikat trafia kanałem, który agent naprawdę czyta - dlatego każdy skrypt jest uruchamiany na celowo zepsutym pliku przed oddaniem.
O czym pamiętać
Hook po edycji sprawdza tylko edytowany plik; istniejącą konfigurację scala, nie nadpisuje. Git pre-commit/pre-push tylko rekomenduje.
Jednorazowo i powtarzalnie przygotowuje Playwright: wykrywa stack, port i auth, tworzy playwright.config.ts z webServer i logowaniem do storageState, zielony test seed dla realnego ryzyka i podpina playwright-cli do agenta.
Po co
/10x-e2e dostaje gotową infrastrukturę, a seed jest wzorem, na którym agent modeluje każdy kolejny test.
O czym pamiętać
Ponowne uruchomienie na gotowym projekcie nie zmienia żadnego pliku; nie dotyka CI i niczego nie commituje. Stan zapisuje w test-stack.md.
Audytuje kod pod kątem logiki, która ukrywa błędy produkcyjne: połknięte wyjątki, błędy zamienione na redirect lub 200, zgubione stack trace, ścieżki poza trackerem błędów. Dla krytycznych flow pisze datowany raport.
Po co
Odpowiada na pytanie: gdy ten flow padnie na produkcji, czy ktoś się dowie i zrozumie dlaczego - zanim zdarzy się incydent bez logów.
O czym pamiętać
Bada kod aplikacji, nie konfigurację platformy; nigdy nie zmienia audytowanego kodu. Dowód w runtime (--runtime) tylko w izolowanej kopii.
Zrozumienie skilla przez obserwację jego przebiegu i mapa projektu z dowodów: od czego zacząć w repozytorium, którego nikt Ci nie wyjaśnił.
/10x-ray
M4L1
Co robi
Uczy, jak działa skill, pokazując go w akcji: mapuje jego anatomię (kroki, pętle, fan-outy, bramki człowieka, rozgałęzienia), uruchamia go w subagencie i odsłania mapę koncept po koncepcie, gdy przebieg dochodzi do kolejnych kroków.
Po co
Zamiast przewijać wywołania narzędzi, rozumiesz, po co autor postawił dany krok - i możesz przenieść te wzorce do własnych skilli.
O czym pamiętać
Pytania skilla trafiają do Ciebie dokładnie tak, jak zadałby je skill; --mode html pokazuje ten sam widok na żywej stronie w przeglądarce.
Buduje mapę projektu (context/map/repo-map.md) nieznanego lub zastanego repozytorium w jednym przebiegu: zdolności biznesowe uszeregowane wg krytyczności × buzzu, z czterech równoległych agentów dowodowych (historia, dyskusje, struktura, ludzie).
Po co
Wejście w duże repo zaczyna się od dowodów, nie od czytania kodu: strefy ryzyka, lista lektur na pierwszy dzień i jawne niewiadome.
O czym pamiętać
Nie przyjmuje celu - to szerokość, nie głębokość; konkretny feature lub pytanie idzie do /10x-research. Działa na samym gicie, bogaciej z GitHub CLI.
Dalsze lekcje modułu opierają się na promptach analitycznych: research z mapą, analiza feature, refaktoryzacja i DDD. Szczegóły znajdziesz na stronach Legacy i Skalowanie.
05MODUŁ 5 // TEAMWORK
Teamwork: system w zespole
Walidacja pomysłów, review na PR w CI, rejestr paczek AI zespołu i autonomiczna implementacja.
/10x-opportunity-map
M5L1
Co robi
Zamienia powtarzającą się frykcję lub niezaspokojoną potrzebę w artefakt decyzji build / buy / complement / wait, z jednym rekomendowanym kandydatem do sprawdzenia.
Po co
Klasyfikacja bólu przed pisaniem kodu chroni przed budowaniem narzędzi, które już istnieją.
O czym pamiętać
Działa dla dowolnego pomysłu - produkt, feature, narzędzie wewnętrzne, automatyzacja; mapa zawiera zastrzeżenie o ryzyku danych.
Nieinterakcyjny bliźniak /10x-impl-review dla CI: znajduje plan z PR, sprawdza siedem wymiarów łącznie z pokryciem testami, commituje raport na branch PR i zostawia komentarz z podsumowaniem.
Po co
Review trafia na każdy PR automatycznie, jako krok pipeline’u uruchamiany bez Ciebie.
O czym pamiętać
Kod źródłowy czyta bez edycji; werdykt REJECTED blokuje workflow, chyba że PR ma etykietę impl-review-override.
Autonomiczne rodzeństwo /10x-implement pod /goal: deleguje etapy subagentom, przepuszcza każdy przez automatyczny stos bramek jakości i commituje na zielono, bez człowieka między etapami.
Po co
Plan wykonuje się nienadzorowany - interaktywnie pod /goal albo headless przez claude -p.
O czym pamiętać
Odhacza tylko wiersze Automated; wiersze Manual wracają jako checklist dla człowieka. Po dwóch nieudanych próbach naprawy bramki zatrzymuje się ze STOP-em.
