Jedna jednostka pracy, sześć skokówsześć kroków

Zakłada folder zmiany w context/changes/<change-id>/. „Zmiana” to jedna jednostka pracy od początku do końca: research, plan, implementacja i review żyją w jednym folderze spiętym identyfikatorem zmiany.

Wejście: change-id w kebab-case plus opcjonalny zamiar w wolnej formie - pierwszy człon staje się identyfikatorem, reszta zasila tytuł i notatki. Wyjście: change.md - mały plik tożsamości z frontmatterem (change_id, title, status: new, daty) i sekcją Notes na luźny kontekst.

Trzy bramki, zanim cokolwiek powstanie: kebab-case sprawdzany regexem, unikalność identyfikatora w changes/ i archive/, istniejący katalog context/changes/. Brak katalogu to odmowa, nie auto-tworzenie - to sygnał, że repo nie jest przygotowane pod tę strukturę.

Po utworzeniu skill podpowiada domyślnie /10x-plan. Sytuacyjnie: /10x-research, gdy zamiar sugeruje eksplorację kodu przed planem, albo /10x-frame, gdy framing jest podejrzany - zgłoszenie typu „fix / bug / broken” z gotową diagnozą w treści. Sugerowana komenda ląduje w schowku.

Nie pisze research.md, plan.md ani frame.md - to praca kolejnych skilli. Nie prowadzi żadnego pliku stanu: jedynym źródłem prawdy o wykonaniu jest sekcja Progress w plan.md.

Research kodu przed planowaniem: odpowiedzieć na pytanie badawcze dowodami z repozytorium i zapisać je na dysku - jako trwały artefakt, nie ulotną pamięć rozmowy.

Wejście: pytanie badawcze plus wskazane pliki - czytane w całości, zanim ruszy cokolwiek innego. Wyjście: context/changes/<change-id>/research.md z frontmatterem (data, commit, branch, temat) i sekcjami: podsumowanie, szczegółowe ustalenia, referencje do kodu z plik:linia, wnioski architektoniczne, kontekst historyczny i pytania otwarte.

Pytanie jest dekomponowane na obszary, zakres doprecyzowany z użytkownikiem (szerokość, głębokość, fokus), a potem 2-4 subagentów rusza równolegle - każdy przeczesuje swój wymiar: pliki i wzorce, wcześniejsze decyzje w context/changes/ i context/archive/, działanie systemu. Synteza zaczyna się dopiero, gdy wrócą wszyscy.

Dokument jest samowystarczalny: ścieżki, numery linii, wzorce międzykomponentowe, permalinki do GitHuba, gdy commit jest wypchnięty. Pytania uzupełniające trafiają do tego samego pliku z adnotacją we frontmatterze - jeden artefakt researchu na zmianę.

Subagenci dostają zadania tylko do odczytu i mają zwracać konkretne referencje plik:linia, nie ogólniki. Świeży research zawsze przed zaufaniem historii: wcześniejsze zmiany i archiwum to kontekst uzupełniający, nie zamiennik czytania kodu.

Podjąć kluczowe decyzje, dopóki są tanie - w tekście, nie w kodzie. Plan powstaje interaktywnie i sceptycznie - skill kwestionuje mgliste wymagania, pyta „dlaczego” i „co z przypadkiem X”, zamiast spisywać życzenia.

Wejście: opis zadania plus artefakty z wcześniejszych kroków - research.md i/lub frame.md. Każdy dostarczony artefakt zmniejsza liczbę pytań: nie pyta się o to, co użytkownik już zapisał. Wyjście: plan.md (etapy z kryteriami sukcesu i sekcją Progress) plus plan-brief.md - dwustronicowy skrót z tabelą kluczowych decyzji.

Najpierw ocena złożoności potwierdzana z użytkownikiem (LOW: 4-6 pytań, MEDIUM: 7-10, HIGH: 11-15), potem pytania w rundach - każda opcja z rekomendacją oraz analizą zalet i kosztów. Szkielet etapów jest zatwierdzany, zanim powstaną szczegóły.

Overview, stan bieżący, stan docelowy, „czego NIE robimy” (tama na pełzanie zakresu), etapy z kryteriami podzielonymi na weryfikację automatyczną (komendy) i ręczną (człowiek). Na dole sekcja Progress - jedyne miejsce checkboxów i maszyna stanów dla /10x-implement.

Żadnych otwartych pytań w finalnym planie - wszystko rozstrzygnięte przed zapisem. Plan opisuje intencję i kontrakt zmiany, nie gotowy kod: snippet pojawia się tylko przy zmianie nieoczywistej. I zero ponownego pytania o rzeczy rozstrzygnięte we frame lub researchu.

Zrealizować zatwierdzony plan etap po etapie z weryfikacją, zamiast jednym wielkim diffem. Filozofia: podążaj za intencją planu, adaptując się do zastanego kodu - a przy rozjeździe zatrzymaj się i przedstaw problem, zamiast improwizować po cichu.

Wejście: context/changes/<change-id>/plan.md, opcjonalnie numer etapu. Wyjście: commit per etap w konwencji Conventional Commits plus odhaczona sekcja Progress, w której każdy wiersz etapu dostaje dopisany skrócony SHA zamykającego commita.

Sekcja Progress w plan.md to jedyne źródło prawdy - żadnych plików stanu obok. Pierwszy niezaznaczony wiersz wyznacza miejsce startu - po przerwie nie zgadujesz, co już zrobione. Skill modyfikuje wyłącznie Progress; bloki etapów są tylko do odczytu.

Automatyczne kryteria przechodzą → brama ręcznej weryfikacji (człowiek potwierdza testy) → staging jawnie po ścieżkach z zestawu plików dotkniętych w etapie (nigdy git add -A) → zatwierdzenie komunikatu commita → SHA wpisany z powrotem do Progress.

Nie odhacza ręcznych testów bez potwierdzenia użytkownika. Rozjazd z planem eskaluje pytaniem z trzema wyjściami - adaptuj i kontynuuj, pomiń, wróć do planowania - zamiast decydować za człowieka.

Porównać rzeczywistą implementację z planem, zanim dryf, niebezpieczne decyzje i łamanie konwencji zdążą się skumulować. Dwa zakresy: szybki review pojedynczego etapu albo pełny przegląd całego planu przed merge.

Wejście: plan.md plus faktyczny stan repo - diff wyznaczany od daty planu. Wyjście: raport w context/changes/<change-id>/reviews/ z werdyktem APPROVED / NEEDS ATTENTION / REJECTED i listą znalezisk gotowych do triage'u.

Dwóch równoległych subagentów: pierwszy wykrywa dryf - dla każdej planowanej zmiany werdykt MATCH / DRIFT / MISSING / EXTRA; drugi sprawdza bezpieczeństwo, wydajność, niezawodność i zgodność ze wzorcami repo. Do tego skill uruchamia komendy z automatycznych kryteriów sukcesu i porównuje wynik z deklaracjami w Progress.

ID, severity (CRITICAL / WARNING / OBSERVATION), impact (ile namysłu wymaga decyzja - wymiar ortogonalny do severity), lokalizacja plik:linia, dowód w formule „plan mówił X, kod robi Y” i propozycja naprawy z analizą kompromisów.

Interaktywna pętla po znaleziskach: napraw teraz, napraw inaczej, pomiń albo zapisz jako lekcję do context/foundation/lessons.md. Każda decyzja wraca do zapisanego raportu, więc triage można przerwać i wznowić później od pozycji PENDING.

Domknąć skończoną jednostkę pracy: potwierdzić, że jest kompletna, przenieść wiedzę do trwałego kontekstu projektu i zwolnić changes/. „Skończone” ma znaczyć skończone - z zapisem, nie z pamięci.

Wejście: folder zmiany context/changes/<change-id>/ po review. Wyjście: dopisane lekcje w context/foundation/lessons.md i folder przeniesiony do context/archive/ - z zachowaniem pełnej historii (change, research, plan, reviews).

Przed archiwizacją skill sprawdza spójność stanu: każdy etap w Progress powinien mieć commit (skrócony SHA). Etap czysto ręczny nie tworzy commita i zostaje bez SHA - to ostrzeżenie informacyjne, nie błąd, ale jawnie odnotowane, żeby „domknięte” nie znaczyło „po cichu pominięte”.

To, czego nauczyła Cię ta zmiana - powtarzalne pułapki, decyzje warte zapamiętania - ląduje w context/foundation/lessons.md, wspólnym dla całego projektu. Następne zmiany startują z tej wiedzy, zamiast wynajdywać ją od nowa.

Nie zmienia kodu ani planu - operuje na już zamkniętej pracy. Archiwum to zapis historyczny: nic nie czyta z niego rutynowo, ale wszystko tam jest, gdyby trzeba było wrócić do kontekstu starej zmiany.