10X WORKFLOW // DOKUMENTACJA // QUICK SEARCH

DOKUMENTACJA // QUICK SEARCH

Cała mapa 10x Workflow w jednym indeksie

Cała kampania w jednym przeszukiwalnym indeksie: M1 Fundament, CSC (M2), skalowanie, M3 Jakość, M4 Legacy, M5 Teamwork - strony, kroki, węzły, lekcje i skille. Wpisz frazę albo naciśnij / - lista filtruje się natychmiast. Escape czyści wyszukiwanie.

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.

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ć.

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

Lekcja 03: AI-Powered Bootstrap - na czym stawiamy?

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

Lekcja 05: Z localhosta na produkcję - gdzie i jak wypływamy?

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Ł

Węzeł 01: quality gates - próba, której nie da się ominąć

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Ł

Węzeł 02: goal - plan wykonuje się bez autora

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Ł

Węzeł 03: loops - więcej cykli równolegle

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

Lekcja 02: Od planu do testów - skąd test wie, co jest poprawne?

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

Lekcja 03: Hooki i triggery - co łapie błąd, zanim go zobaczysz?

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

Lekcja 04: Testy E2E - czy całość naprawdę leci?

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

Lekcja 05: Debugowanie - co mówią wszystkie przyrządy naraz?

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ę.

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

Lekcja 02: Mapa projektu - jak wygląda teren, zanim wejdziesz?

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

Lekcja 03: Feature i hot spots - gdzie kod pęka najczęściej?

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.

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.

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.

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

Lekcja 03: Code review w erze AI - kto pilnuje każdego PR, gdy śpisz?

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

Lekcja 04: Shared AI Registry - skąd zespół bierze wspólne skille?

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

Lekcja 05: Async i remote agents - jak delegować pracę na odległość?

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.

BRAK WYNIKÓW // ZMIEŃ FRAZĘ ALBO FILTRY