Marcin porównuje możliwe trasy, a Przemek zamienia wybraną drogę w etapy i punkty weryfikacji — /10X-PLAN // SYMBOL: MAPA TRASY
Decyzje przed kodem: wybrana droga, zakres, etapy i sprawdzalne kryteria.

SKILL // KROK 03 ŁAŃCUCHA

/10x-plan - decyzje przed kodem

Pielgrzymka zna trasę, zanim ktokolwiek postawi krok - ten skill wyznacza trasę zmiany.Ten skill wyznacza trasę zmiany, zanim powstanie kod. /10x-plan prowadzi interaktywne, sceptyczne planowanie: skaluje liczbę pytań do złożoności i dostarczonych artefaktów, wymusza decyzje tam, gdzie są tanie, i zapisuje plan.md z etapami, kryteriami sukcesu i sekcją Progress - plus dwustronicowy plan-brief.md.

/10X-PLAN // TRASA USTALONA, ZANIM RUSZY IMPLEMENTACJA

PO COHyperion · Trasa pielgrzymki

Problem: decyzje zapadające mimochodem

„Na mapie poprawka kosztuje ołówek. W drodze - pielgrzyma."

- rachunek trasy przed wyjściem do Grobowców Czasu

Implementacja „na żywioł" podejmuje kluczowe decyzje w najgorszym możliwym miejscu: w środku pisania kodu, mimochodem, bez porównania opcji. /10x-plan wyciąga je przed kod - tam, gdzie zmiana zdania kosztuje edycję tekstu, nie refaktor.

Skill jest z założenia sceptyczny i interaktywny: kwestionuje mgliste wymagania, pyta „dlaczego" i „co z przypadkiem X", weryfikuje korekty użytkownika własnym researchem i nie pisze planu za jednym podejściem - zatwierdza złożoność, potem decyzje, potem szkielet etapów, dopiero na końcu szczegóły.

CEL:

najbardziej przydaje się, 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.

Marcin i Przemek obserwują kilka tras przez obcy kanion i wybierają jedną fioletową drogę z punktami kontroli — PO CO → WYBIERZ DROGĘ PRZED KODEM
Plan zamienia wiele możliwych dróg w jedną decyzję, którą człowiek może ocenić przed kosztowną implementacją.

WEJŚCIE → WYJŚCIE

Każdy artefakt na wejściu to mniej pytań

Wejściem jest opis zadania plus artefakty z wcześniejszych kroków. Każdy dostarczony artefakt to decyzje już podjęte - skill czyta je w całości i nie pyta o to, co użytkownik już zapisał. Frame zamyka pytania diagnostyczne (czym jest problem), research - pytania o stan kodu; z oboma naraz zostają wyłącznie decyzje projektowe.

Skala jest jawna: zadanie bez artefaktów przy złożoności MEDIUM to 7-10 pytań; z researchem 5-7; z frame 4-6; z oboma 3-5. Ponowne pytanie o rzecz rozstrzygniętą we wcześniejszych krokach to jawnie nazwany błąd skilla, nie nadgorliwość.

Wejście: opis zadania + opcjonalnie research.md i/lub frame.md z folderu zmiany
Wyjście: plan.md - etapy z kryteriami sukcesu + sekcja Progress (maszyna stanów)
Wyjście 2: plan-brief.md - dwustronicowy skrót z tabelą kluczowych decyzji i ich źródeł
Bonus: komenda /10x-implement <change-id> phase 1 skopiowana do schowka

Marcin i Przemek zamieniają dowody i ograniczenia w trasę implementacji z punktami kontrolnymi — WEJŚCIE → WYJŚCIE
Dowody oraz ograniczenia zmieniają się w trasę, którą człowiek może zatwierdzić przed zmianą kodu.

MECHANIZM

Od złożoności do zatwierdzonego szkieletu

01 · Kontekst: identyfikacja artefaktów z wcześniejszych kroków, lektura wszystkich wskazanych plików w całości, do tego równolegli subagenci na luki, których research nie pokrył.
02 · Złożoność: ocena LOW / MEDIUM / HIGH z uzasadnieniem, potwierdzana z użytkownikiem; wyznacza budżet pytań: LOW 4-6, MEDIUM 7-10, HIGH 11-15.
03 · Pytania: rundy po 1-4 pytania; każda opcja niesie rekomendację oraz jawną analizę: co daje, co kosztuje. Kategorie dobrane do domeny (software / treść / proces), pytania diagnostyczne pomijane przy obecnym frame.
04 · Research wykonawczy: wzorce, konwencje i punkty integracji skill ustala sam z kodu i wcześniejszych prac - o to nie pyta użytkownika.
05 · Szkielet: propozycja podziału na etapy zatwierdzana, zanim powstaną szczegóły; korekty (za drobno / za grubo) są tanie na tym etapie.
06 · Zapis: plan.md wg szablonu + plan-brief.md; status zmiany przechodzi na planned; potem iteracja z użytkownikiem do skutku.

ZASADA:

plan opisuje intencję i kontrakt zmiany, nie gotowy kod - każda pozycja rozdziela Intent (co i po co) od Contract (interfejs, sygnatura, schemat, niezmiennik); fragment kodu pojawia się tylko przy zmianie nieoczywistej.

Marcin i Przemek uzgadniają trzy odwracalne etapy planu z automatycznymi i manualnymi punktami kontroli — MECHANIZM → ETAPY I KRYTERIA
Każdy etap ma wynik i kryteria domknięcia; zadania poza zakresem pozostają poza trasą.

ANATOMIA

plan.md i plan-brief.md - kontrakt oraz skrót

Sekcja „What We're NOT Doing" to tama na pełzanie zakresu, a Critical Implementation Details jest jawnie opcjonalna: pojawia się tylko, gdy istnieje realny haczyk (kolejność, wyścig, budżet wydajności). Plan bez niej nie jest niekompletny; plan wypchany szablonowymi punktami jest rozdęty.

Na dole mieszka Progress - jedyne miejsce checkboxów i maszyna stanów dla /10x-implement: po jednym wpisie na każde kryterium sukcesu, w podziale Automated / Manual, z indeksami N.M, które nigdy nie są przenumerowywane. Bloki etapów wyżej niosą zwykłe punktory, bez checkboxów.

Overview + stany: co budujemy i po co; stan bieżący z kluczowymi odkryciami (plik:linia); stan docelowy z metodą weryfikacji
What We're NOT Doing: jawna lista rzeczy poza zakresem zmiany
Etapy: Changes Required per plik z parą Intent / Contract; kryteria sukcesu podzielone na automatyczne (komendy) i ręczne (człowiek)
Progress: jedyne checkboxy planu; wpisy N.M per kryterium, Automated / Manual, czytane i odhaczane przez /10x-implement
plan-brief.md: What & Why, punkt startu, stan końcowy, tabela kluczowych decyzji ze źródłem (frame / research / plan), etapy w pigułce, ryzyka

BRIEF:

czyta się w mniej niż 2 minuty i jest pisany dla kogoś, kto nie brał udziału w planowaniu - tabela decyzji pokazuje rodowód: co rozstrzygnięto we wcześniejszych krokach, a co w tej sesji.

Dłonie Marcina i Przemka układają fioletową trasę z modułowych etapów i osobnych punktów kontroli — ANATOMIA → ODWRACALNE ETAPY
Etapy, kryteria i rzeczy poza zakresem tworzą czytelny kontrakt prowadzący implementację oraz późniejsze review.

ANTYWZORCE

Czego dobry plan nie zawiera

Otwarte pytania: żadnych w finalnym planie - napotkane w trakcie zatrzymują pracę do rozstrzygnięcia; plan ma być kompletny i wykonywalny.
Gotowy kod: plan mówi wykonawcy, co zmienić i dlaczego, nie jak pisać; rutynowa edycja = Intent w 1-2 zdaniach, Contract w jednym, koniec.
Powtórzone pytania: zero ponownego pytania o rzeczy rozstrzygnięte we frame lub researchu - to podważa zaufanie do wcześniejszych artefaktów.
Szablonowe wypełniacze: Critical Implementation Details domyślnie pomijane; generyczne rady („użyj memoizacji") nie są treścią planu.
Checkboxy w etapach: bloki etapów niosą zwykłe punktory; stan wykonania żyje wyłącznie w sekcji Progress.

NA STRONIE ŁAŃCUCHA:

wróć do kroku 03 (plan) na stronie Core Skills Chain - kontekst całego łańcucha i sąsiednie kroki.

Marcin i Przemek pozostają na bezpiecznej fioletowej trasie, a kuszące boczne drogi znikają w burzy za barierami — ANTYWZORCE → NIE IDŹ ZA KAŻDĄ ISKRĄ
Jawne non-goals chronią plan przed rozrostem, przypadkowym refaktorem i pomysłami odkrywanymi dopiero w trakcie kodowania.