10X WORKFLOW // SKILL // /10X-RESEARCH
Marcin steruje sondami skanującymi repo, a Przemek przypina dowody do symbolu soczewki i oddziela je od założeń
/10X-RESEARCH // SYMBOL: SOCZEWKA

Równoległe rozpoznanie tylko do odczytu. Fakty z kodu trafiają do wspólnego raportu.

SKILL // KROK 02 ŁAŃCUCHA

/10x-research - dowody z repozytorium

Gdy pomiarom nie można ufać, buduje się własne przyrządy - ten skill jest przyrządem do mierzenia kodu.Ten skill jest przyrządem do mierzenia kodu, zanim zapadną decyzje. /10x-research odpowiada na pytanie badawcze równoległymi subagentami i zapisuje ustalenia z referencjami plik:linia do research.md - kolejne kroki czytają fakty z dysku, nie z pamięci rozmowy.

WEJŚCIEPYTANIESUBAGENT: KOD I WZORCESUBAGENT: HISTORIA DECYZJISUBAGENT: DZIAŁANIE SYSTEMU2-4 RÓWNOLEGLE // TYLKO ODCZYTSYNTEZARESEARCH.MDPLIK:LINIAZAŁOŻENIA: 0

/10X-RESEARCH // RÓWNOLEGŁY POMIAR ZBIEGA W JEDEN ARTEFAKT

PO COProblem trzech ciał · Własne przyrządy

Problem: decyzje na zatrutych danych

„Nie ufaj pomiarowi, którego nie wykonałeś własnym przyrządem."

- odruch naukowców po tym, jak wszechświat zaczął migotać

Największym sabotażystą planu jest fałszywe „wiem, jak to działa" - wiedza sprzed trzech refaktorów, cudzy kod, duże repozytorium. /10x-research zastępuje założenia dowodami z repozytorium: przeczesuje kod, historię decyzji i realne zachowanie systemu, a wynik zapisuje na dysku.

Artefakt jest sednem: research w pamięci rozmowy znika z kontekstem, research w pliku przeżywa sesję i staje się wejściem dla /10x-plan - plan powstaje na faktach, które można zacytować z numerem linii.

CEL:

najbardziej przydaje się w cudzym, starym lub dużym kodzie - wszędzie tam, gdzie fałszywe „wiem" kosztuje najwięcej i gdzie plan bez ugruntowania byłby zgadywaniem.

Marcin i Przemek w orbitalnym obserwatorium wysyłają sondy do rozpoznania konstelacji modułów repozytorium
PO CO → NAJPIERW ZOBACZ REPO

Agent najpierw poznaje fakty z kodu, zależności i istniejące wzorce, zanim zaproponuje rozwiązanie.

WEJŚCIE → WYJŚCIE

Z pytania badawczego do dokumentu z dowodami

Wejściem jest pytanie badawcze plus pliki wskazane przez użytkownika - te skill czyta w całości zanim ruszy cokolwiek innego, w głównym kontekście, nie w subagentach. Jeśli istnieje context/foundation/lessons.md, jego reguły są przyjmowane z góry: co zespół już zaakceptował, tego nie trzeba badać od nowa.

Wyjściem jest research.md w folderze zmiany - jeden artefakt researchu na zmianę. Pytania follow-up nie tworzą nowych plików: dopisują się do tego samego dokumentu jako osobna sekcja z adnotacją w frontmatterze.

Wejście
pytanie badawcze + wskazane pliki (czytane w całości) + opcjonalnie change-id
Wyjście
research.md w context/changes/<change-id>/ z metadanymi (data, commit, branch, temat)
Status
change.md przechodzi z new na preparing; brak folderu = tworzony jak w /10x-new
Marcin i Przemek prowadzą trzy równoległe skany repozytorium zbiegające się w raport oparty na dowodach
WEJŚCIE → WYJŚCIE

Jedno pytanie uruchamia równoległe, bezpieczne skany, które kończą się wspólnym zestawem dowodów.

MECHANIZM

Dekompozycja, równoległy pomiar, synteza

01 · Lektura
pliki wymienione przez użytkownika czytane w całości w głównym kontekście - żadnych limitów, żadnego delegowania tej lektury.
02 · Dekompozycja
pytanie rozbijane na obszary badawcze, które potem złożą się w odpowiedź; każdy obszar dostaje widoczne dla użytkownika zadanie na liście postępu.
03 · Zakres
doprecyzowanie z użytkownikiem: szerokość, głębokość, punkt ciężkości (2-4 konkretne opcje na pytanie). Pomijane, gdy zapytanie jest jednoznaczne i wąsko zakrojone.
04 · Subagenci
2-4 równolegle, każdy w swoim wymiarze: szybkie wyszukiwanie plików i wzorców, wcześniejsze decyzje w context/changes/ i context/archive/, głęboka analiza działania systemu.
05 · Synteza
start dopiero, gdy wrócą wszyscy; ustalenia z żywego kodu mają pierwszeństwo, historia jest kontekstem uzupełniającym; wszystko spina się referencjami plik:linia.
06 · Zapis
metadane (commit, branch, data) zbierane przed pisaniem - dokument nigdy nie powstaje z placeholderami; przy wypchniętym commicie referencje dostają permalinki do GitHuba.
ZASADA:

subagenci dostają zadania tylko do odczytu i mają zwracać konkretne referencje plik:linia oraz wzorce użycia - nie ogólniki i nie same definicje.

Marcin i Przemek rozdzielają niebieskie fakty znalezione w kodzie od pomarańczowych założeń
MECHANIZM → FAKTY I ZAŁOŻENIA

Fakty z kodu i założenia mają osobne tory, więc plan nie opiera się na pewnie brzmiącym zgadywaniu.

ANATOMIA

research.md - dokument samowystarczalny

Dokument otwiera frontmatter z pełnym kontekstem czasowym: data z timezone, badacz, commit, branch, repozytorium, temat, tagi. Dzięki temu czytelnik za trzy miesiące wie, względem jakiego stanu kodu te ustalenia były prawdziwe.

Sekcje prowadzą od skrótu do szczegółu: najpierw odpowiedź na pytanie, potem dowody per komponent, na końcu wnioski architektoniczne i to, czego nie udało się rozstrzygnąć. Pytania follow-up trafiają na dół z własnym znacznikiem czasu.

Summary
wysokopoziomowa odpowiedź na pytanie badawcze
Detailed Findings
ustalenia per komponent/obszar z referencjami i powiązaniami między komponentami
Code References
lista ścieżka:linia z opisem, co tam jest - grunt pod plan
Architecture Insights
wzorce, konwencje i decyzje projektowe odkryte po drodze
Historical Context
wnioski z context/changes/ i context/archive/ z referencjami do tamtych dokumentów
Open Questions
obszary wymagające dalszego zbadania - jawnie, zamiast udawać kompletność
Dłonie Marcina i Przemka łączą niebieskie dowody z repo, oddzielając je od pomarańczowych założeń
ANATOMIA → STÓŁ DOWODÓW

Każdy istotny wniosek ma ślad prowadzący do kodu; założenia są oznaczone i nie udają faktów.

GRANICE

Czego /10x-research nie robi

Nie zmienia kodu
badanie jest w całości odczytowe - jedyny zapis to research.md i podbicie statusu w change.md.
Nie ufa historii w ciemno
świeży research żywego kodu zawsze przed archiwum - wcześniejsze zmiany to kontekst uzupełniający, nie zamiennik czytania.
Nie planuje
research ustala fakty; decyzje projektowe i etapy to praca /10x-plan.
Nie mnoży artefaktów
jeden research.md na zmianę; pytania follow-up dopisują się do istniejącego pliku. Zmiana zarchiwizowana = odmowa i wskazanie /10x-new.
NA STRONIE ŁAŃCUCHA:

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

Marcin i Przemek nadzorują sondy skanujące stację repozytorium, podczas gdy narzędzia zapisu pozostają za czerwoną blokadą
GRANICE → TYLKO ODCZYT

Research może działać równolegle, ale nie zmienia repo — dzięki temu rozpoznanie pozostaje bezpieczne i odwracalne.