CSC // CORE SKILL CHAIN // MODUŁ 2
Rdzeń 10x Workflow: pięć skoków jednej jednostki pracy - new → research → plan → implement → review. Każdy krok zostawia artefakt na dysku.
cscworkflowłańcuchmoduł 2landing
Detal
- Po co istnieje
- Jedna mapa całego łańcucha: pokazuje, po co istnieje każdy krok i co gwarantuje, zanim wejdziesz w szczegóły pojedynczego skilla.
- Wejście → wyjście
- Wejście: jednostka pracy z fundamentu (prd.md, roadmap.md). Wyjście: przejście new → review z artefaktem na dysku po każdym kroku.
- Mechanizm
- Kroki komunikują się plikami w context/changes/<change-id>/ - artefakt zatrzymuje maszynę, człowiek zatwierdza, łańcuch rusza dalej.
Pytanie: jedna jednostka pracy. Gwarancja: jasny, odwracalny zakres. Tnie zamiar na zmianę na tyle małą, że da się ją ogarnąć i cofnąć.
krok 01newzakreschange.md/10x-new
Detal
- Po co istnieje
- Bez bramy zadanie „popraw onboarding" rozlewa się na całe repo i nigdy nie wiadomo, co znaczy „zrobione".
- Wejście → wyjście
- Wejście: luźny pomysł lub zgłoszenie. Wyjście: folder context/changes/<change-id>/ z plikiem change.md - tożsamością zmiany.
- Mechanizm
- Artefakt zatrzymuje maszynę: człowiek patrzy na zakres i decyduje, czy to jest ta bitwa, zanim cokolwiek poleci dalej.
Pytanie: dowody do planu. Gwarancja: fakty zamiast założeń. Plan ma powstać na dowodach z repozytorium, nie na pamięci sprzed trzech refaktorów.
krok 02researchdowodyresearch.md/10x-research
Detal
- Po co istnieje
- Największy sabotażysta planu to własne „wiem, jak to działa" - research zastępuje je pomiarem repozytorium.
- Wejście → wyjście
- Wejście: change.md. Wyjście: research.md - ścieżki plików, konwencje, realne punkty zaczepienia.
- Mechanizm
- Równolegli subagenci przeczesują repo, każdy swój obszar; wynik ląduje na dysku, więc kolejne kroki czytają fakty z pliku zamiast polegać na pamięci rozmowy.
Pytanie: kluczowe decyzje deva. Gwarancja: etapy + warunki sukcesu. Decyzje zapadają przed kodem, gdzie są tanie do zmiany.
krok 03planfazyplan.md/10x-plan
Detal
- Po co istnieje
- Usuwa ból implementacji „na żywioł", w której kluczowe decyzje zapadają mimochodem, w środku pisania kodu.
- Wejście → wyjście
- Wejście: research.md. Wyjście: plan.md - fazy z warunkami sukcesu (automatycznymi i ręcznymi) plus sekcja Progress.
- Mechanizm
- Plan iteruje z człowiekiem, dopóki jest tekstem; zatwierdzony staje się kontraktem, a Progress maszyną stanów dla implementacji.
Pytanie: implementacja etap po etapie. Gwarancja: commitowane, weryfikowalne kroki. Każda faza to punkt powrotu zamiast jednego wielkiego diffa.
krok 04implementcommityprogress/10x-implement
Detal
- Po co istnieje
- Usuwa ból jednej wielkiej zmiany bez punktów kontrolnych, której nie da się ani przerwać, ani cofnąć.
- Wejście → wyjście
- Wejście: zatwierdzony plan.md. Wyjście: commity per faza i odhaczona sekcja Progress.
- Mechanizm
- Progress jako maszyna stanów - faza kończy się dopiero, gdy warunki sukcesu są zielone i zmiana jest zacommitowana; przerwana sesja wraca od ostatniego zielonego etapu.
Pytanie: czy implementacja realizuje plan? Gwarancja: analiza subagentów: plan vs kod. Konkretny raport rozbieżności zamiast rytualnego „wygląda dobrze".
krok 05reviewdryfplan vs kod/10x-impl-review
Detal
- Po co istnieje
- Odpowiednikiem rytuału nad niezrozumianą maszyną jest „działa, mergujemy" - review sprawdza, czy kod dotrzymał obietnic planu.
- Wejście → wyjście
- Wejście: plan.md i gotowy diff. Wyjście: raport review - dryf względem planu, niebezpieczne decyzje, zgodność z konwencjami repo.
- Mechanizm
- Analiza subagentów - każdy porównuje inny wymiar planu z kodem; człowiek dostaje listę konkretnych rozbieżności.
SKILL
/10x-new
change.md
Inicjalizuje folder zmiany context/changes/<change-id>/ z plikiem change.md - tożsamością jednostki pracy.
skillkrok 01 · newchange.md
Detal
- Po co istnieje
- Każda zmiana potrzebuje tożsamości na dysku, zanim ruszy jakakolwiek praca - inaczej zakres żyje tylko w oknie czatu.
- Wejście → wyjście
- Wejście: identyfikator zmiany plus luźny opis zamiaru. Wyjście: context/changes/<change-id>/change.md.
- Mechanizm
- Jeden plik z frontmatterem i opisem zakresu; kolejne skille łańcucha czytają go jako punkt startowy.
SKILL
/10x-research
research.md
Przeczesuje repozytorium równoległymi subagentami i składa wynik w research.md - kompletny obraz kodu pod plan.
skillkrok 02 · researchsubagenci
Detal
- Po co istnieje
- Plan pisany z pamięci (modelu albo własnej) dziedziczy jej luki; research zastępuje pamięć pomiarem.
- Wejście → wyjście
- Wejście: change.md lub pytanie badawcze. Wyjście: research.md obok change.md.
- Mechanizm
- Fan-out subagentów: każdy bada swój obszar (kod, testy, historia), a wyniki są scalane w jeden dokument z odnośnikami do plików.
SKILL
/10x-plan
plan.md
Tworzy szczegółowy plan implementacji przez gruntowny research i iterację z człowiekiem: fazy, warunki sukcesu, sekcja Progress.
skillkrok 03 · planfazy
Detal
- Po co istnieje
- Kluczowe decyzje deva mają zapaść, gdy są tanie - w tekście, nie w połowie diffa.
- Wejście → wyjście
- Wejście: change.md + research.md. Wyjście: plan.md z fazami i sekcją Progress.
- Mechanizm
- Iteracja: czytasz, kwestionujesz, poprawiasz; zatwierdzony plan staje się kontraktem dla /10x-implement.
SKILL
/10x-implement
commity per faza
Realizuje plan z context/changes/<change-id>/plan.md faza po fazie, z weryfikacją warunków sukcesu po każdej fazie.
skillkrok 04 · implementprogress
Detal
- Po co istnieje
- Realizacja planu ma być serią punktów powrotu, nie jednym wielkim diffem, którego nikt nie przeczyta.
- Wejście → wyjście
- Wejście: zatwierdzony plan.md. Wyjście: kod, commity per faza, odhaczona sekcja Progress.
- Mechanizm
- Faza po fazie: implementacja, weryfikacja warunków sukcesu, commit; Progress pilnuje, gdzie jesteś po przerwie.
SKILL
/10x-impl-review
raport review
Recenzuje implementację względem planu: dryf, niebezpieczne decyzje, zgodność ze wzorcami repo.
skillkrok 05 · reviewdryf
Detal
- Po co istnieje
- Im większy diff, tym łatwiej o dryf między tym, co plan obiecał, a tym, co kod robi.
- Wejście → wyjście
- Wejście: plan.md (opcjonalnie konkretna faza) i diff. Wyjście: raport review z listą rozbieżności.
- Mechanizm
- Subagenci porównują wymiary planu z kodem: zgodność zakresu, bezpieczeństwo decyzji, wzorce repo.
M1 // FUNDAMENT // MODUŁ 1
Pięć lekcji, które zamieniają mglisty pomysł w projekt gotowy do lotu: PRD, skille, bootstrap, onboarding agenta i pierwszy deploy. Rampa kończy się tam, gdzie startuje CSC.
m1fundamentmoduł 1landingrampa startowa
Detal
- Po co istnieje
- Mapa modułu 1: skąd biorą się jednostki pracy, zanim pierwsza zmiana wejdzie w new.
- Wejście → wyjście
- Wejście: pomysł (greenfield) lub istniejące repo (brownfield). Wyjście: prd.md, roadmap.md i środowisko - scaffold, AGENTS.md, działający deploy.
- Mechanizm
- Pięć lekcji = pięć pytań fundamentu; każda kończy się artefaktem na dysku.
LEKCJA
shape-notes.md → prd.md
Pytanie: co naprawdę budujemy? Gwarancja: ustalenia, których kolejne prompty nie podważą. Sesja sokratejska /10x-shape, potem /10x-prd.
lekcja 01prdshape/10x-shape/10x-prd
Detal
- Po co istnieje
- Bez testu pytań „mam pomysł na apkę" rozpada się przy trzecim promptcie.
- Wejście → wyjście
- Wejście: luźny pomysł lub istniejący projekt (auto-wykrycie greenfield/brownfield). Wyjście: shape-notes.md, a z niego prd.md.
- Mechanizm
- Pytania idą przed generowaniem - PRD spisuje ustalenia na dysku, więc kolejne prompty budują na decyzjach, zamiast po cichu je podważać.
LEKCJA
skille z kontraktami
Pytanie: czym gra agent? Gwarancja: powtarzalne narzędzia zamiast jednorazowych promptów. Skill to nie prompt - to odtwarzalna para kontraktów wejścia/wyjścia.
lekcja 02skillemetapromptingagent
Detal
- Po co istnieje
- Prompt żyje raz i umiera w historii czatu; powtarzalna praca ma być modułem, nie improwizacją w oknie czatu.
- Wejście → wyjście
- Wejście: powtarzający się problem, dziś załatwiany coraz dłuższym promptem. Wyjście: skill z kontraktem wejścia/wyjścia, zapisany obok kodu.
- Mechanizm
- Metaprompting - agent pomaga pisać własne narzędzia; każdy dopracowany skill podnosi jakość wszystkich kolejnych przebiegów.
LEKCJA
tech-stack.md + scaffold
Pytanie: na czym stawiamy? Gwarancja: starter z oficjalnego CLI, nie boilerplate z generatora. Greenfield: tech-stack-selector → bootstrapper; brownfield: stack-assess → health-check.
lekcja 03bootstrapstackgreenfieldbrownfield
Detal
- Po co istnieje
- Boilerplate generowany z pamięci modelu psuje się przy pierwszej aktualizacji frameworka - fundamenty kładzie oficjalne CLI.
- Wejście → wyjście
- Wejście: prd.md (greenfield) albo istniejące repo (brownfield). Wyjście: tech-stack.md i działający scaffold z oficjalnego CLI.
- Mechanizm
- Delegacja do oficjalnych CLI plus jasna polityka uprawnień: co agent uruchamia sam, a co wymaga człowieka.
Pytanie: co agent ma wiedzieć? Gwarancja: kontekst projektu bez szumu. Tylko to, czego model nie wywnioskuje z pretrainingu.
lekcja 04agents.mdonboardingai rules
Detal
- Po co istnieje
- Kontekst bez szumu decyduje, czy pracuje z tobą weteran, czy rekrut po złej odprawie.
- Wejście → wyjście
- Wejście: repo po bootstrapie. Wyjście: AGENTS.md z /10x-agents-md, oceniony przez /10x-rule-review.
- Mechanizm
- Feedback loop: każde potknięcie agenta to kandydat na regułę; przegląd reguł wycina szum, zanim zagłuszy sygnał.
LEKCJA
infrastructure.md + roadmap.md + deploy
Pytanie: gdzie i jak wypływamy? Gwarancja: działający deploy zamiast wiecznego localhosta. Kalkulacja przed skokiem: infra-research, roadmap, deployment.
lekcja 05deployprodukcjainfrastrukturaroadmap
Detal
- Po co istnieje
- Deploy to świadoma decyzja infrastrukturalna, nie odruch - dopiero produkcja weryfikuje decyzje.
- Wejście → wyjście
- Wejście: działający projekt na localhoście plus prd.md. Wyjście: infrastructure.md, roadmap.md i pierwszy działający deploy.
- Mechanizm
- Platforma wybrana z dowodów (/10x-infra-research), roadmapa wyznacza kolejność, /10x-deployment domyka bramkę gotowości preflightem.
SKILL
/10x-shape
shape-notes.md
Prowadzi ustrukturyzowaną rozmowę odkrywczą, która zamienia pomysł - greenfield lub brownfield, wykrywane z repo - w shape-notes.md, wejście do /10x-prd.
skilllekcja 01fundamentdiscovery
Detal
- Po co istnieje
- Pomysł bez spisanych ustaleń rozmywa się z każdym promptem; sesja sokratejska wyciąga decyzje, zanim powstanie kod.
- Wejście → wyjście
- Wejście: pomysł lub istniejący projekt. Wyjście: shape-notes.md.
- Mechanizm
- Rozmowa prowadzona pytaniami; kontekst (greenfield/brownfield) wykrywany automatycznie z katalogu roboczego.
SKILL
/10x-prd
prd.md
Generuje context/foundation/prd.md z shape-notes.md według zamkniętego schematu; sam trafia w szablon greenfield (10 sekcji) lub brownfield (11 sekcji).
skilllekcja 01prdfundament
Detal
- Po co istnieje
- PRD zgodny ze schematem to wspólny język dalszych skilli - roadmapa i wybór stacku czytają go bez zgadywania.
- Wejście → wyjście
- Wejście: shape-notes.md (lub surowe notatki). Wyjście: context/foundation/prd.md.
- Mechanizm
- Routing po context_type z shape-notes.md albo auto-detekcji; schemat PRD jest zamknięty, nie negocjowany per projekt.
SKILL
/10x-tech-stack-selector
tech-stack.md
Wybiera starter i stack dla projektu greenfield po PRD: czyta prd.md, przechodzi rejestr starterów przez cztery bramki jakości i zapisuje tech-stack.md.
skilllekcja 03stackgreenfield
Detal
- Po co istnieje
- Stack pod agenta musi przejść bramki: typowany, oparty na konwencjach, popularny, dobrze udokumentowany.
- Wejście → wyjście
- Wejście: context/foundation/prd.md. Wyjście: context/foundation/tech-stack.md.
- Mechanizm
- Rejestr starterów świadomy języka plus cztery bramki jakości; wynik to hand-off dla /10x-bootstrapper.
SKILL
/10x-bootstrapper
scaffold + log
Stawia scaffold w bieżącym katalogu po wyborze stacku: czyta tech-stack.md, uruchamia CLI oficjalnego startera i zapisuje log weryfikacji.
skilllekcja 03bootstrapcli
Detal
- Po co istnieje
- Fundamenty kładzie oficjalne CLI startera, nie generowany z pamięci boilerplate.
- Wejście → wyjście
- Wejście: context/foundation/tech-stack.md. Wyjście: działający scaffold plus log weryfikacji.
- Mechanizm
- Twarda polityka konfliktów: katalog context/ zawsze przeżywa uruchomienie startera.
SKILL
/10x-stack-assess
stack-assessment.md
Ocenia stack istniejącego projektu pod agenta według 4 bramek jakości; zapisuje stack-assessment.md z ocenami per komponent, lukami i gotowymi wpisami do CLAUDE.md/AGENTS.md.
skilllekcja 03brownfield
Detal
- Po co istnieje
- Brownfieldowy odpowiednik wyboru stacku: zanim agent zacznie pracę, trzeba wiedzieć, gdzie stack mu pomoże, a gdzie podłoży nogę.
- Wejście → wyjście
- Wejście: istniejące repo. Wyjście: context/foundation/stack-assessment.md.
- Mechanizm
- Cztery bramki jakości (typowany, oparty na konwencjach, popularny, udokumentowany) oceniane per komponent stacku.
SKILL
/10x-health-check
health-check.md
Audyt zdrowia istniejącego projektu: zależności, bezpieczeństwo, wykrycie test runnera, CI/CD i brakująca konfiguracja; kończy się werdyktem gotowości na agenta.
skilllekcja 03brownfieldaudyt
Detal
- Po co istnieje
- Agent w chorym repo mnoży problemy zamiast je rozwiązywać - najpierw diagnoza, potem praca.
- Wejście → wyjście
- Wejście: istniejące repo (po /10x-stack-assess). Wyjście: context/foundation/health-check.md z priorytetami napraw.
- Mechanizm
- Audyt zależności i bezpieczeństwa, detekcja test runnera, analiza CI/CD i brakującej konfiguracji - z priorytetyzacją.
SKILL
/10x-agents-md
AGENTS.md
Generuje AGENTS.md - zwięzły przewodnik po repo dla agentów AI: konwencje, komendy, pułapki; krytyczne reguły na górze.
skilllekcja 04onboardingagents.md
Detal
- Po co istnieje
- Agent bez kontekstu projektu wnioskuje z pretrainingu - a pretraining nie zna twoich konwencji ani pułapek.
- Wejście → wyjście
- Wejście: repo (manifest, README, skrypty, konfiguracja lintu/testów, układ, historia commitów). Wyjście: AGENTS.md.
- Mechanizm
- Dokument mały, precyzyjny, z odsyłaczami zamiast powtórzeń - agent czyta raz i nie blokuje się na oczywistościach.
SKILL
/10x-roadmap
roadmap.md
Generuje roadmap.md z PRD jako uporządkowany zestaw pionowych wycinków end-to-end - kolejne widoczne dla użytkownika kamienie milowe do oddania w /10x-plan.
skilllekcja 05roadmapfundament
Detal
- Po co istnieje
- Holistyczny PRD nie mówi, co budować najpierw - roadmapa tnie go na kolejność, którą da się odhaczać.
- Wejście → wyjście
- Wejście: context/foundation/prd.md (po wyborze stacku/bootstrapie, gdy dotyczy). Wyjście: context/foundation/roadmap.md.
- Mechanizm
- Pionowe wycinki end-to-end zamiast warstw technicznych; każdy wycinek jest kandydatem na jednostkę pracy dla łańcucha CSC.
SKILL
/10x-infra-research
infrastructure.md
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.
skilllekcja 05infrastrukturaplatforma
Detal
- Po co istnieje
- Wybór platformy „bo wszyscy tak robią" to decyzja bez dowodów - a infra jest droga do cofnięcia.
- Wejście → wyjście
- Wejście: prd.md lub tech-stack.md plus krótki wywiad. Wyjście: context/foundation/infrastructure.md.
- Mechanizm
- Równoległy research webowy z kontrolą biasu źródeł; wynik to punktowane porównanie plus rejestr ryzyk.
SKILL
/10x-deployment
raport gotowości + config
Bramka gotowości do deployu na PaaS (Cloudflare, Vercel, Netlify, Fly.io, Railway, Render): realny preflight, raport gotowości, natywna konfiguracja platformy, opcjonalny deploy z CLI.
skilllekcja 05deploypaas
Detal
- Po co istnieje
- „U mnie działa" nie jest bramką - deploy ma przejść preflight, zanim dotknie produkcji.
- Wejście → wyjście
- Wejście: projekt plus wybrana platforma PaaS. Wyjście: raport gotowości, konfiguracja platformy, opcjonalnie deploy przez CLI.
- Mechanizm
- Realny preflight zamiast checklisty z pamięci: build, konfiguracja, zmienne środowiskowe, dopiero potem zielone światło.
SKALOWANIE // SCALE TIER
Warstwa nad łańcuchem: quality gates → goal → loops. Skalowanie to więcej cykli równolegle z bramkami jakości i autonomią - sufit przepustowości wyznacza Twoja zdolność do review.
skalowaniescale tierquality gatesgoalloopslanding
Detal
- Po co istnieje
- Mapa warstwy „ponad łańcuchem": trzy węzły, które podnoszą rygor i autonomię, gdy rośnie ryzyko i/lub złożoność.
- Wejście → wyjście
- Wejście: działający łańcuch CSC na pojedynczych jednostkach pracy. Wyjście: więcej cykli równolegle, każdy domykany bramkami i review.
- Mechanizm
- Łańcuch się nie zmienia - dokładasz mu obstawę: bramki jakości per faza, autonomiczny przelot planu, równoległe cykle w rytmie.
WĘZEŁ
komplet zielonych bramek per faza
Pytanie: co pilnuje jakości, gdy Ciebie nie ma? Gwarancja: żadna faza nie przechodzi na czerwono. Lint i typecheck po każdej edycji, testy per faza, commit tylko na zielono.
węzeł 01quality gatesbramkigom dżabbardeliberate-break
Detal
- Po co istnieje
- Bez bramek autonomia oznacza kod, którego nikt nie sprawdził w chwili powstania - jedyną bramką jesteś Ty i musisz patrzeć na wszystko.
- Wejście → wyjście
- Wejście: plan z warunkami sukcesu. Wyjście: faza domknięta automatycznie - lint/typecheck per edycja, testy per faza, commit na zielono.
- Mechanizm
- Deliberate-break check: celowo psujesz implementację i potwierdzasz, że test pada - bramce można zaufać dopiero wtedy, gdy widziałeś, jak się zamyka.
WĘZEŁ
commity per faza + run report
Pytanie: jak plan wykonuje się bez Ciebie? Gwarancja: commit per faza na zielono albo uczciwy STOP. Autonomiczne przejście planu przez /10x-goal-implement pod /goal.
węzeł 02goalautonomiaseldonstop-blok/10x-goal-implement
Detal
- Po co istnieje
- Bez tego węzła siedzisz między fazami jako klikacz „dalej" i autonomia kończy się na pierwszym pytaniu.
- Wejście → wyjście
- Wejście: zatwierdzony plan.md. Wyjście: commit per faza na zielono albo uczciwy STOP - plus run report.
- Mechanizm
- Fazy wykonują się same, Progress pracuje jak maszyna stanów, a przy strukturalnym rozjeździe wykonanie zatrzymuje się STOP-blokiem zamiast improwizować.
WĘZEŁ
osobny cykl per tor
Pytanie: ile cykli naraz udźwigniesz? Gwarancja: więcej przepustowości bez nierecenzowanego kodu. Równoległe cykle plan → implement → review z izolacją kontekstu; rytm zamiast na żądanie.
węzeł 03loopsrównoległośćizolacja kontekstu/loop
Detal
- Po co istnieje
- Eskadra nie skaluje się przez wsadzenie dwunastu pilotów do jednego myśliwca - więcej cykli równolegle z izolacją kontekstu, nie więcej agentów na jednym wycinku.
- Wejście → wyjście
- Wejście: kilka niezależnych jednostek pracy. Wyjście: osobny cykl per tor - change-folder plus raport review, bez nierecenzowanego kodu.
- Mechanizm
- Cykle biegną w rytmie (/loop), każdy we własnym kontekście (worktree/sesje), a wszystkie zbiegają do jednej bramy - Twojego review; sufit wyznacza dowódca, nie liczba maszyn.
SKILL
/10x-goal-implement
commity + checklist
Autonomiczna realizacja planu pod /goal - bez człowieka między fazami; rodzeństwo /10x-implement do przebiegów nienadzorowanych i headless.
skillskalowaniewęzeł 02 · goalautonomia
Detal
- Po co istnieje
- Skalowanie łańcucha: gdy plan jest dobry, przejście faz nie wymaga człowieka - wymaga bramek.
- Wejście → wyjście
- Wejście: zatwierdzony plan.md. Wyjście: commity per faza (Conventional Commits) plus lista rzeczy do ręcznego sprawdzenia na koniec.
- Mechanizm
- Subagent na fazę plus automatyczny stos bramek jakości (warunki planu, kontrola celowo psutego testu, pełna suita); commit dopiero po zielonym.
M3 // JAKOŚĆ
Pięć lekcji o jakości: najpierw ryzyka, nie pliki - chroń najgroźniejsze scenariusze testem, którego asercja realnie pada. Jakość domyka blok 10xBuilder.
m3jakośćmoduł 3testylanding
Detal
- Po co istnieje
- Mapa modułu 3: jak chronić działający produkt testami według ryzyka, nie według listy plików - i jak nie ufać zieleni, która nie umie zrobić się czerwona.
- Wejście → wyjście
- Wejście: działający produkt z fundamentu i łańcucha. Wyjście: mapa ryzyk, testy, które realnie padają, warstwy hooków, przeloty E2E i diagnozy z dowodów.
- Mechanizm
- Pięć lekcji = pięć pytań jakości; zielony test, który nie pada po zepsuciu, niczego nie pilnuje (mutation check).
Pytanie: co zabija projekt najpierw? Gwarancja: najgroźniejsze scenariusze chronione najpierw. Mapa ryzyk wpływ × prawdopodobieństwo; ryzyko opisane jako awaria u usera.
lekcja q-01plan testówmapa ryzykfremeni/10x-test-plan
Detal
- Po co istnieje
- Zamiast pokrywać pliki po kolei, mapuje ryzyka na osi wpływ × prawdopodobieństwo - „koszyk gubi pozycje przy odświeżeniu", nie „brak testów w cart.ts".
- Wejście → wyjście
- Wejście: działający produkt i PRD. Wyjście: context/foundation/test-plan.md - mapa ryzyk pocięta na fazy rolloutu, od najgroźniejszych scenariuszy w dół.
- Mechanizm
- /10x-test-plan orkiestruje dowiezienie testów, nie pisze ich sam - każdą fazę prowadzi przez research → plan → implement, a ponowne uruchomienie wznawia od następnej fazy.
LEKCJA
test chroniący ryzyko + czerwień
Pytanie: skąd test wie, co jest poprawne? Gwarancja: asercja, która realnie pada na zepsutym kodzie. Wyrocznia z wymagań i researchu, nie z kodu; mutation check.
lekcja q-02wyroczniamutationanti-patterny/10x-tdd
Detal
- Po co istnieje
- Test odczytujący oczekiwaną wartość z implementacji tylko ją mirroruje - przyklepie każdy bug, który już tam mieszka; anti-patterny: asercje spisane z kodu, snapshoty bez zrozumienia, mocki testujące mocki.
- Wejście → wyjście
- Wejście: jedno ryzyko z test-plan.md. Wyjście: test, którego asercja realnie pada na zepsutym kodzie.
- Mechanizm
- Mutation check: zepsuj chronione zachowanie celowo i potwierdź czerwień; /10x-tdd wymusza kolejność - czerwony test przed kodem, zieleń jako dowód, refactor na osłoniętym gruncie.
LEKCJA
hooki per-edit / pre-commit / pre-push
Pytanie: co łapie błąd, zanim go zobaczysz? Gwarancja: dryf wykryty sekundy po powstaniu, nie na końcu fazy. Warstwowa obrona według kosztu: per-edit → pre-commit → pre-push.
lekcja q-03hookitarczelinttypecheck
Detal
- Po co istnieje
- Im dalej błąd doleci, tym drożej kosztuje jego zestrzelenie - obrona jest uporządkowana według kosztu, warstwa za warstwą, od najtańszej na zewnątrz.
- Wejście → wyjście
- Wejście: reguły jakości projektu - lint, typecheck, szybkie testy. Wyjście: hooki zapięte na zdarzenia - per-edit, pre-commit i pre-push, każdy z własnym budżetem czasu.
- Mechanizm
- Self-checking pipeline - dryf wykrywany sekundy po powstaniu, w tle, bez udziału człowieka; do końca fazy dolatuje tylko to, czego żadna warstwa nie mogła złapać wcześniej.
LEKCJA
testy Playwright + seed test
Pytanie: czy całość naprawdę leci? Gwarancja: przelot end-to-end tam, gdzie unit by skłamał. Najtańszy test dający sygnał - E2E tylko tam, gdzie mock by skłamał; coverage nie jest celem.
lekcja q-04e2eplaywrightrocinanteseed test/10x-e2e
Detal
- Po co istnieje
- Przelot przez wszystkie moduły naraz - UI, API, dane - dokładnie tam, gdzie mock by skłamał; jeśli unit wystarcza, E2E jest przepychem.
- Wejście → wyjście
- Wejście: działająca aplikacja i ryzyko z planu, którego nie pokryje nic tańszego. Wyjście: testy Playwright plus seed test przygotowujący dane pod przelot.
- Mechanizm
- /10x-e2e prowadzi ryzyko przez plan → generate → review → verify na uruchomionej aplikacji, multimodalnie - agent czyta DOM i patrzy na zrzuty ekranu jednocześnie.
LEKCJA
diagnoza + test przypinający naprawę
Pytanie: co mówią wszystkie przyrządy naraz? Gwarancja: diagnoza z dowodów, nie z przeczucia. Synteza dowodów z wielu źródeł: Sentry, wrangler logs, konsola i network z Playwrighta.
lekcja q-05debugowaniesentrypielgrzymiwranglermulti-source
Detal
- Po co istnieje
- Żadne pojedyncze źródło niczego nie wyjaśnia - wszystkie naraz wskazują to samo miejsce; liczy się synteza dowodów, nie mistrzostwo w jednym narzędziu.
- Wejście → wyjście
- Wejście: objaw - błąd u usera, czerwony test, alert. Wyjście: diagnoza poparta dowodami i naprawa przypięta testem, żeby regresja nie wróciła.
- Mechanizm
- Zbierz odczyty wszystkich przyrządów naraz i szukaj przecięcia opowieści; po drodze wytęp połykanie błędów - try/catch zwracający 200 to zamiatanie dowodów (OWASP A10:2025).
SKILL
/10x-test-plan
test-plan.md
Fazowy orkiestrator wdrażania testów w istniejącym produkcie: pisze test-plan.md i prowadzi każdą fazę rolloutu przez pełny łańcuch CSC.
skilllekcja q-01 · plan testówtestybrownfieldorkiestrator
Detal
- Po co istnieje
- Pokrycie testami istniejącego produktu to seria zmian, nie jeden zryw - potrzebuje stanu i kolejności.
- Wejście → wyjście
- Wejście: PRD i roadmapa istniejącego produktu. Wyjście: context/foundation/test-plan.md plus kolejne fazy rolloutu jako zmiany CSC.
- Mechanizm
- Każda faza przechodzi /10x-new → research → plan → implement; ponowne uruchomienie wznawia od następnej fazy zapisanej w test-plan.md.
SKILL
/10x-tdd
testy + kod
Prowadzi zatwierdzony plan faza po fazie test-first, przez red → green → refactor - tylko fazy, które da się TDD-ować; resztę kieruje do /10x-implement.
skilllekcja q-02 · wyroczniakrok 04 · implementtddtesty
Detal
- Po co istnieje
- Wariant implementacji dla logiki, którą opłaca się przybić testem, zanim powstanie.
- Wejście → wyjście
- Wejście: zatwierdzony plan.md. Wyjście: testy plus kod, wspólna sekcja Progress z /10x-implement.
- Mechanizm
- Red → green → refactor per faza; fazy, których nie da się prowadzić test-first, wracają do /10x-implement.
SKILL
/10x-e2e
testy E2E
Prowadzi przeglądarkowe (E2E) fazy planu na działającej aplikacji, ryzyko po ryzyku: plan → generacja → review → weryfikacja.
skilllekcja q-04 · e2ekrok 04 · implemente2eplaywright
Detal
- Po co istnieje
- Część ryzyk widać dopiero w przeglądarce - ale tylko tę część; reszta należy do /10x-tdd i /10x-implement.
- Wejście → wyjście
- Wejście: plan.md z fazami E2E plus zbudowany feature. Wyjście: testy E2E, wspólna sekcja Progress.
- Mechanizm
- Jedno ryzyko na raz; skill sam odsyła fazy, które nie potrzebują przeglądarki, do tańszych narzędzi.
M4 // LEGACY (10XARCHITECT)
Pięć lekcji o zastanym kodzie: decyzje architektoniczne z dowodów, nie z intuicji. Kręgosłup modułu: 5-elementowy raport architektoniczny - obronialny, nie przyjęty na wiarę.
m4legacy10xarchitectraport architektonicznylanding
Detal
- Po co istnieje
- Mapa modułu 4: jak wejść w cudzy, zastany kod z dowodami zamiast intuicji - obszar, którego niemal żaden kurs AI nie rusza.
- Wejście → wyjście
- Wejście: zastany system - cudzy kod, brak testów, archeologia decyzji. Wyjście: 5-elementowy raport architektoniczny: architektura kontekstu, mapa projektu, przegląd feature’a + hot spots, okazje refaktorowe, okazje DDD.
- Mechanizm
- Pięć lekcji = pięć pytań architekta; raport ma być Twój - obronialny, nie przyjęty na wiarę.
LEKCJA
lean AGENTS.md + context/
Pytanie: ile kontekstu naraz uniesie agent? Gwarancja: kontekst racjonowany, nie wylewany. Nie „co agent ma wiedzieć?", tylko „co agent ma wiedzieć TERAZ?".
lekcja a-01kontekstfiltrfrakagents.mdcontext/
Detal
- Po co istnieje
- Okno kontekstu jest zasobem jak woda na pustyni - wylany zapas nie wraca; kontekst trzeba racjonować, nie wylewać.
- Wejście → wyjście
- Wejście: repozytorium z kontekstem rozlanym po README, wiki i głowach ludzi. Wyjście: lean root AGENTS.md plus context/ jako system-of-record - fakty dociągane na żądanie, nie w jednym przeładowanym prompcie.
- Mechanizm
- Drabina dojrzałości - od zera do systemu, w którym każda dawka kontekstu ma swoje miejsce i swój moment podania.
LEKCJA
mapa projektu - pozycja ① raportu
Pytanie: jak wygląda teren, zanim wejdziesz? Gwarancja: mapa z dowodów, nie z folderów. Wide scan: historia gita, wyszukiwania strukturalne, grafy zależności.
lekcja a-02mapa projektusondywide scangit churn
Detal
- Po co istnieje
- Struktura folderów kłamie - mapa ma powstać z dowodów: które moduły są deep, a które shallow, co jest core, co peripheral, co load-bearing.
- Wejście → wyjście
- Wejście: nieznane repozytorium. Wyjście: mapa projektu (pozycja ① raportu) - deep vs shallow, core vs peripheral, load-bearing.
- Mechanizm
- Równoległe sondy - /10x-research wysyła subagentów, git log i churn pokazują, gdzie projekt naprawdę żyje, a graf zależności - co się zawali, gdy pociągniesz nitkę.
LEKCJA
przegląd feature’a + hot spots
Pytanie: gdzie kod pęka najczęściej? Gwarancja: ryzyko wskazane z dowodów, nie z vibes. Hot spot = złożoność × częstość zmian; semantykę domyka deterministyczne CLI.
lekcja a-03hot spotsceresast-grepchange couplingtornhill
Detal
- Po co istnieje
- Awarie nie rozkładają się równo po repozytorium - wracają w te same miejsca; tam, gdzie skomplikowane spotyka często dotykane, ryzyko rośnie najszybciej.
- Wejście → wyjście
- Wejście: mapa projektu i jeden feature. Wyjście: przegląd feature’a + hot spots (pozycje ② i ③ raportu) - przepływ danych end-to-end plus lista miejsc, które pękają najczęściej.
- Mechanizm
- Deterministyczne CLI domyka semantykę - ast-grep znajduje wzorce w składni, code-maat liczy change coupling, observability dokłada dowody z produkcji; agent interpretuje, pomiar jest maszynowy.
LEKCJA
okazje refaktorowe + ADR-y
Pytanie: jak przebudować bez zatrzymywania maszyny? Gwarancja: każdy krok odwracalny i osobno zielony. Strangler Fig, Branch by Abstraction, Mikado, ADR-y - zamiast big-bangu.
lekcja a-04refaktorstrangler figmikadoadrfowler
Detal
- Po co istnieje
- Wielki przepisujący skok kończy się katastrofą, bo nie ma z niego drogi powrotu - sekwencja małych, osobno zielonych kroków ma ją zawsze.
- Wejście → wyjście
- Wejście: hot spot z dowodami i test chroniący zachowanie - napisany, zanim ruszy refactor. Wyjście: okazje refaktorowe (pozycja ④ raportu) plus ADR-y dokumentujące decyzje.
- Mechanizm
- Wzorce odwracalności - Strangler Fig (nowe oplata stare, zanim je zastąpi), Branch by Abstraction, metoda Mikado - a /10x-plan tnie ścieżkę na fazy, z których każda kończy się zielenią albo cofnięciem kroku, nie planu.
LEKCJA
okazje DDD + glosariusz
Pytanie: czy model mówi językiem domeny? Gwarancja: granice i język, których zespół potrafi bronić. Event Storming, ubiquitous language, bounded contexts, inwarianty.
lekcja a-05dddevent stormingbounded contextubiquitous languageevans
Detal
- Po co istnieje
- Bounded contexts działają, gdy granice są ostre, a język jednoznaczny - „zamówienie" w magazynie i „zamówienie" w płatnościach to dwa różne pojęcia i mają prawo mieć dwa różne modele.
- Wejście → wyjście
- Wejście: chaos pojęć zastanej domeny. Wyjście: okazje DDD (pozycja ⑤ raportu) - kandydaci na bounded contexts, glosariusz ubiquitous language, inwarianty, entities vs value objects.
- Mechanizm
- AI jako coach DDD - agent prowadzi Event Storming, proponuje granice i nazwy, ale to człowiek broni każdej decyzji; model, którego zespół nie potrafi obronić, nie jest modelem, tylko notatką.
M5 // TEAMWORK (10XCHAMPION)
Pięć lekcji o pracy zespołowej z agentami: agent zarabia dla zespołu dopiero wtedy, gdy działa bez Ciebie. Artefakty AI to kod - jedno źródło prawdy, wersjonowanie, dystrybucja. Domyka kampanię.
m5teamwork10xchampiondrużynalanding
Detal
- Po co istnieje
- Mapa modułu 5: od osobistego workflow do zespołu - narzędzia wewnętrzne, agent poza IDE, review w CI, rejestr artefaktów, delegacja zdalna.
- Wejście → wyjście
- Wejście: workflow działający u Ciebie. Wyjście: agent pracujący dla zespołu - odznakę 10xChampion domyka jeden z dwóch projektów: pipeline CI/CD do review kodu albo rejestr artefaktów.
- Mechanizm
- Pięć lekcji = pięć pytań zespołowych; dowodem są działające instalacje - pipeline z komentarzem agenta na PR albo rejestr z wydanymi wersjami.
Pytanie: co zbudować, a co kupić? Gwarancja: najmniejsze narzędzie, które zamyka realną lukę. Zostań przy SaaS tam, gdzie niesie odpowiedzialność platformową; buduj wokół lokalnej luki zespołu.
lekcja t-01build vs buypasiarzehelper
Detal
- Po co istnieje
- Tam, gdzie SaaS niesie odpowiedzialność platformową - auth, billing, compliance - zostajesz przy SaaS; budujesz dopiero wokół luki, której żaden produkt z półki nie zna.
- Wejście → wyjście
- Wejście: realna luka w przepływie zespołu. Wyjście: najmniejsze narzędzie, które ją zamyka - i decyzja build vs buy podjęta świadomie, nie z rozpędu.
- Mechanizm
- Zanim powstanie pierwsza linijka, pada pytanie, kto poniesie odpowiedzialność, gdy narzędzie zawiedzie - jeśli platforma, kupujesz; jeśli luka jest wasza, budujesz najmniejszą rzecz, która działa.
LEKCJA
pierwszy agent zespołowy + metryki kosztów
Pytanie: z czego składa się agent, gdy zdejmiesz IDE? Gwarancja: agent złożony świadomie, z licznikiem kosztów. Zejście poziom niżej, do prymitywów SDK; koszty i metryki od pierwszego dnia.
lekcja t-02sdkdrużynakosztymetryki
Detal
- Po co istnieje
- Nowego członka zespołu składasz sam - model, narzędzia, pętla, kontekst - więc rozumiesz jego zachowanie, zamiast ufać czarnej skrzynce.
- Wejście → wyjście
- Wejście: prymitywy SDK agentowego. Wyjście: agent złożony świadomie, z licznikiem kosztów i metrykami od pierwszego dnia.
- Mechanizm
- Pierwszy fork projektu - ready-made SDK vs assemble-it-yourself - rozstrzyga, ile kontroli potrzebujesz; agent bez licznika to członek zespołu, którego pensji nikt nie zna.
LEKCJA
pipeline CI z komentarzem agenta na PR
Pytanie: kto pilnuje każdego PR, gdy śpisz? Gwarancja: review na każdym PR, nie tylko gdy masz czas. Agent jako krok pipeline’u, uruchamiany bez Ciebie; severity × impact i triage.
lekcja t-03obserwatorci/cdpipelinepr/10x-impl-review-ci
Detal
- Po co istnieje
- Przewagę ma stały obserwator: agent widzi każdą zmianę - także PR wysłany o trzeciej w nocy, także ten, którego nie miałbyś siły przeczytać.
- Wejście → wyjście
- Wejście: PR w repozytorium zespołu. Wyjście: pipeline CI, w którym agent zostawia komentarz na każdym PR - review przestaje zależeć od Twojego kalendarza.
- Mechanizm
- /10x-impl-review-ci na GitHub Actions ocenia zmiany po severity × impact, a triage odróżnia fix-worthy od szumu - recenzent zgłaszający wszystko jest tak samo bezużyteczny jak ten, który nie zgłasza niczego.
LEKCJA
rejestr paczek: definicja + wydane wersje
Pytanie: skąd zespół bierze wspólne skille? Gwarancja: jedna wersja prawdy zamiast dryfujących kopii. Artefakty AI to kod: source of truth, wersjonowanie, auth, dystrybucja.
lekcja t-04encyklopediarejestrwersjonowanie/10x-contract
Detal
- Po co istnieje
- Skille, komendy i reguły mają mieć source of truth, wersje i mechanizm dystrybucji - zamiast dryfujących kopii wklejanych między maszynami.
- Wejście → wyjście
- Wejście: skille i reguły rozproszone po komputerach zespołu. Wyjście: rejestr paczek - repo z definicją paczki, wydanymi wersjami i auth, z którego każdy instaluje tę samą prawdę.
- Mechanizm
- Install / update / uninstall jak w menedżerze pakietów, z multi-tool delivery - mechanizm dystrybucji dobierasz według audytorium, nie według efektowności demo.
LEKCJA
zadanie delegowane zdalnie + raport w review
Pytanie: jak delegować pracę na odległość? Gwarancja: granice ustawione, zanim agent ruszy, kontrola wraca w review. Delegacja z odroczoną kontrolą: sandbox, granice sieci i sekretów przed startem.
lekcja t-05flotaasyncsandboxremotemonitoring
Detal
- Po co istnieje
- Rozkazy idą przed bitwą - w trakcie nikt już nie negocjuje zasięgu dział; granice sieci i sekretów ustawia się, zanim agent wystartuje.
- Wejście → wyjście
- Wejście: zadanie, które nie wymaga Twojej obecności. Wyjście: agent pracujący zdalnie w sandboxie z jawnie zakreślonymi granicami - i raport, który wraca do review.
- Mechanizm
- Odpowiedzialność nie znika z delegacją, tylko zmienia moment - wraca w monitoringu i review; kontrolujesz wynik, nie każdy ruch.
SKILL
/10x-impl-review-ci
impl-review.md + komentarz na PR
Uruchamia review implementacji nieinterakcyjnie w CI na PR: znajduje plan, sprawdza dryf, bezpieczeństwo, wzorce i pokrycie testami, commituje raport na branch PR i zostawia komentarz z podsumowaniem.
skilllekcja t-03 · review w cici/cdgithub actionspr
Detal
- Po co istnieje
- Review na każdym PR bez człowieka w pętli - CI-owa wersja /10x-impl-review, stały obserwator zespołu.
- Wejście → wyjście
- Wejście: PR z planem w context/changes/<change-id>/. Wyjście: reviews/impl-review.md zacommitowany na branch PR plus komentarz z podsumowaniem.
- Mechanizm
- Nieinterakcyjny przebieg w GitHub Actions (Claude Code Action): odnajduje plan, porównuje dryf, bezpieczeństwo, wzorce i pokrycie testami.
SKILL
/10x-contract
contract-surfaces.md
Rejestruje nośne nazwy i schematy (kontrakty) w docs/reference/contract-surfaces.md - powierzchnie, których zmiana łamie konsumentów w dole strumienia.
skilllekcja t-04 · registrykontraktywersjonowanie
Detal
- Po co istnieje
- Wspólne artefakty żyją dłużej niż sesja - rename nośnej nazwy lub schematu łamie cudzy kod, więc kontrakt musi być zarejestrowany.
- Wejście → wyjście
- Wejście: świeżo utworzony lub rozpoznany wiążący kontrakt (nazwa, schemat). Wyjście: wpis w docs/reference/contract-surfaces.md.
- Mechanizm
- Rejestr powierzchni kontraktowych czytany przed refaktorami - zmiana przechodzi świadomie, z wersją, nie przypadkiem.