Marcin uruchamia symbol sześciokątnego beaconu, a Przemek zamyka mały zakres zmiany w osobnej kapsule zadania — /10X-NEW // SYMBOL: BEACON
Najpierw jedna mała, odwracalna jednostka pracy — z jawnym celem i granicami.

SKILL // KROK 01 ŁAŃCUCHA

/10x-new - jedna jednostka pracy

Przed bitwą Ender ustawia pole gry - ten skill ustawia pole zmiany.Ten skill ustawia pole zmiany, zanim ruszy jakakolwiek praca. /10x-new zakłada folder context/changes/<change-id>/ z małym plikiem tożsamości change.md i wskazuje następny skill. Jedna zmiana = jedna jednostka pracy od researchu po review, spięta jednym identyfikatorem.

/10X-NEW // Z ROZMYTEGO ZAMIARU DO JEDNOSTKI PRACY NA DYSKU

PO COGra Endera · Wybór bitwy

Problem: praca bez tożsamości

„Zanim ruszysz do Sali Bitewnej, nazwij bitwę, którą grasz."

- zasada odprawy przed każdą symulacją

Research, plan, implementacja i review potrzebują jednego wspólnego miejsca na dysku - inaczej artefakty rozłażą się po repozytorium i po pamięci rozmowy. /10x-new daje zmianie tożsamość: folder o nazwie change-id i mały plik change.md, w którym wszystko kolejne będzie żyć. „Zmiana" to jedna jednostka pracy od początku do końca.

To celowo najkrótszy skill łańcucha: robi jedną rzecz (zakłada folder), po czym natychmiast oddaje pałeczkę dalej, podpowiadając następny krok z gotową komendą w schowku.

CEL:

otwierany na samym początku każdej zmiany - zanim powstanie jakikolwiek research, frame czy plan, musi istnieć folder, do którego trafią.

Marcin i Przemek wybierają jeden zielony sygnał misji spośród wielu rozproszonych zadań nad powierzchnią planety — PO CO → JEDEN SYGNAŁ
Zamiast uruchamiać agenta na całym backlogu, wybierasz jedną małą zmianę, którą da się bezpiecznie sprawdzić i cofnąć.

WEJŚCIE → WYJŚCIE

Z luźnego zamiaru do pliku tożsamości

Wejście to change-id w kebab-case plus opcjonalny zamiar w wolnej formie: pierwszy token argumentu staje się identyfikatorem, cała reszta zasila tytuł i sekcję Notes. Akceptowane są też referencje ścieżkowe (@context/changes/oauth-login/) - wtedy identyfikatorem jest ostatni segment ścieżki.

Zamiar jest wskazówką, nie literałem: skill pisze z niego zwięzły tytuł (do 80 znaków), a pełną treść zamiaru wrzuca dosłownie do Notes jako ziarno kontekstu. Bez zamiaru tytuł powstaje z samego identyfikatora, rozpisanego na słowa, a Notes dostaje komentarz-podpowiedź.

Wejście: change-id (kebab-case) + opcjonalny zamiar w wolnej formie lub ścieżka
Wyjście: change.md w context/changes/<change-id>/ ze statusem new
Bonus: sugerowana komenda następnego kroku skopiowana do schowka

Marcin i Przemek zamieniają rozproszone zadania w jedną jasno ograniczoną zmianę — WEJŚCIE → WYJŚCIE
Z rozlanego zadania powstaje jedna odwracalna jednostka pracy, gotowa do sprawdzenia w repozytorium.

MECHANIZM

Cztery ruchy, zero magii

01 · Parsowanie: argument dzieli się na pierwszym odstępie: pierwszy token → change-id (po zdjęciu „@" i końcowego „/"), reszta → zamiar. Brak argumentu = instrukcja i stop.
02 · Walidacja: trzy bramki, zanim cokolwiek powstanie: kebab-case sprawdzany regexem, unikalność identyfikatora w changes/ i archive/, istniejący katalog context/changes/. Każda odmowa to jasny komunikat błędu i stop.
03 · Utworzenie: folder context/changes/<change-id>/ + change.md: frontmatter (change_id, title, status: new, daty, archived_at: null) i sekcja Notes z zamiarem albo podpowiedzią.
04 · Następny krok: domyślnie /10x-plan; sytuacyjnie /10x-research (zamiar sugeruje eksplorację kodu) albo /10x-frame (zgłoszenie typu „fix / bug / broken" z gotową diagnozą). Komenda ląduje w schowku.

ZASADA:

brak katalogu context/changes/ to odmowa, nie auto-tworzenie - to sygnał, że repo nie jest jeszcze przygotowane pod strukturę kontekstu (od tego jest /10x-init).

Marcin i Przemek zamykają wybraną zmianę w kapsule, pozostawiając inne zadania poza jej granicą — MECHANIZM → GRANICE ZMIANY
Jawne granice zatrzymują dryf: agent wie, co ma dowieźć i czego świadomie nie rusza.

ANATOMIA

change.md - plik tożsamości zmiany

Plik jest celowo mały: frontmatter plus jedna sekcja notatek. To rekord, nie maszyna stanów - statusy są zapisem cyklu życia, nic ich nie wymusza, a pominięcie kroku jest dozwolone (luki wyłapie /10x-status po brakujących artefaktach).

Cykl życia statusów: new → preparing (research lub frame) → planned → plan_reviewed → implementing → implemented → impl_reviewed → archived; z każdego miejsca ręcznie do blocked i z powrotem. Każdy skill łańcucha podbija pole updated przy swoim przejściu.

change_id: kebab-case, musi odpowiadać nazwie folderu
title: tytuł czytelny dla człowieka (z zamiaru albo rozpisany z identyfikatora)
status: new → ... → archived; zapis cyklu życia, niczego nie wymusza
created / updated: daty założenia i ostatniej zmiany w cyklu życia
Notes: luźny kontekst: linki, decyzje ad hoc, których nie mieści research/frame/plan

CZEGO TU NIE MA:

żadnego bloku artifacts.* (wynika z zawartości folderu) ani liczników etapów - postęp wykonania mieszka wyłącznie w sekcji Progress w plan.md.

GRANICE

Czego /10x-new nie robi

Nie pisze artefaktów: frame.md, research.md i plan.md powstają w swoich skillach - tu rodzi się tylko tożsamość zmiany.
Nie prowadzi stanu: zero plików stanu obok - jedynym źródłem prawdy o wykonaniu jest sekcja Progress w plan.md.
Nie wymusza przejść: change.md jest record-only; statusy opisują, co się stało, a nie pilnują kolejności.
Nie tworzy struktury: brak context/changes/ = odmowa; przygotowanie repo to osobna decyzja, nie efekt uboczny.

NA STRONIE ŁAŃCUCHA:

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

Marcin i Przemek chronią jedną zieloną kapsułę zmiany w śluzie, podczas gdy poboczne zadania pozostają za polem granicznym — GRANICE → RESZTA ZOSTAJE NA ZEWNĄTRZ
To, czego zmiana nie obejmuje, jest równie jawne jak jej cel — dzięki temu scope nie rośnie podczas implementacji.