MODUŁ 2 // CORE SKILL CHAIN
Rdzeń 10x Workflow: pięć skoków jednej jednostki pracy - od wyznaczenia zakresu po weryfikację. new → research → plan → implement → review, a każdy krok zostawia artefakt na dysku.
ŁAŃCUCH CSC // KLIKNIJ KROK, BY DOLECIEĆ DO SEKCJI
Skrót łańcucha · pięć skoków w 30 sekund
Jedna jednostka pracy z jasnym, odwracalnym zakresem.
KROK 02Dowody do planu: fakty z repozytorium zamiast założeń.
KROK 03Kluczowe decyzje deva przed kodem: etapy + warunki sukcesu.
KROK 04Etap po etapie: commitowane, weryfikowalne kroki.
KROK 05Czy implementacja realizuje plan? Subagenci: plan vs kod.
„Zacznij od 10xDevs Workflow™ Core Skill Chain (CSC). Dodatki dokładaj, gdy rośnie ryzyko i/lub złożoność."
- fundament 10x Workflow„Brama wroga jest na dole."
- Ender Wiggin, orientacja przed każdą bitwą w Sali BitewnejEnder przed każdą bitwą najpierw ustawiał sobie pole: gdzie jest brama, co jest celem, czym gra. Ten krok robi to samo z robotą. Bez niego zadanie „popraw onboarding" rozlewa się na całe repo i nigdy nie wiadomo, co znaczy „zrobione". 10x-new tnie zamiar na jedną jednostkę pracy - na tyle małą, że jej zakres da się ogarnąć i cofnąć.
Wejście: luźny pomysł lub zgłoszenie. Wyjście: folder context/changes/<change-id> z plikiem change.md - tożsamością zmiany zapisaną na dysku. Artefakt zatrzymuje maszynę: to człowiek patrzy na zakres i decyduje, czy to jest ta bitwa, zanim cokolwiek poleci dalej.
kluczowy, gdy zadanie jest mgliste albo zbyt duże - zanim ruszy jakakolwiek praca, musi istnieć jednostka o zakresie, który da się wycofać jednym ruchem.
„Wszechświat będzie dla was migotał."
- sygnatura sofonów: pomiary, którym nie można już ufaćSofony zakłócały ludzkości pomiary, żeby decyzje zapadały na zatrutych danych. W kodzie sabotażystą jest własna pamięć: „wiem, jak to działa" bywa wiedzą sprzed trzech refaktorów. 10x-research istnieje po to, żeby plan powstał na dowodach z repozytorium, nie na założeniach.
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, a wynik ląduje na dysku - kolejne kroki czytają fakty z pliku zamiast polegać na pamięci rozmowy.
kluczowy w cudzym, starym lub dużym kodzie - wszędzie tam, gdzie fałszywe „wiem" kosztuje najwięcej.
„Trasa jest znana, zanim ktokolwiek postawi pierwszy krok."
- zasada pielgrzymki do Grobowców CzasuPielgrzymi w „Hyperionie" znają trasę i zasady, zanim wyruszą - improwizuje się w drodze, nie na mapie. Ten krok usuwa ból implementacji „na żywioł", w której kluczowe decyzje deva zapadają mimochodem, w środku pisania kodu. 10x-plan wyciąga je przed kod, gdzie są tanie do zmiany.
Wejście: research.md. Wyjście: plan.md - fazy z warunkami sukcesu (automatyczne i ręczne) plus sekcja Progress. Mechanizm: plan iteruje z człowiekiem - czyta się go i kwestionuje, dopóki jest tekstem; zatwierdzony staje się kontraktem, a Progress maszyną stanów dla następnego kroku.
kluczowy, gdy zmiana dotyka wielu plików albo niesie decyzje trudne do cofnięcia (schemat danych, publiczne API) - decyzje mają zapaść przed kodem, nie w jego trakcie.
„Drzwi i rogi, mały. Tam cię dopadają."
- Miller do Holdena, o sprawdzaniu pomieszczeń krok po krokuRocinante nie leci do celu jednym odpaleniem silnika: pół drogi ciągu, obrót, pół drogi hamowania - i korekty kursu po drodze. Ten krok usuwa ból jednej wielkiej zmiany bez punktów kontrolnych, której nie da się ani przerwać, ani cofnąć. 10x-implement realizuje plan etap po etapie.
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 jej warunki sukcesu są zielone i zmiana jest zacommitowana; przerwana sesja wraca od ostatniego zielonego etapu, nie od zera.
kluczowy przy długiej lub przerywanej pracy - każda faza to punkt powrotu: commit plus zielone warunki sukcesu zamiast jednego wielkiego diffa na koniec.
„Błogosławiony umysł zbyt mały, by wątpić."
- katechizm Adeptus Mechanicus; review istnieje po to, by wątpićTech-kapłani Mechanicus odprawiają rytuały nad maszynami, których nikt już nie rozumie. Odpowiednikiem w kodzie jest „działa, mergujemy" - akceptacja bez sprawdzenia, czy kod dotrzymał obietnic planu. 10x-impl-review zadaje jedno pytanie wprost: czy implementacja realizuje plan?
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, a człowiek dostaje listę konkretnych rozbieżności zamiast rytualnego „wygląda dobrze".
kluczowy przed merge - im większy diff, tym łatwiej o dryf między tym, co plan obiecał, a tym, co kod robi.
CSC pracuje na jednostkach pracy - fundament ustala, skąd one pochodzą. Trzy skille budują kontekst produktu, zanim pierwsza zmiana wejdzie w new.
Łańcuch się nie zmienia - dokładasz mu obstawę. Trzy dokładki podnoszą rygor i autonomię, kiedy stawka rośnie.