Co właściwie instaluje plugin?
Plugin jest paczką dla Claude Code i Codex, która zamienia połączenie z platformą w gotowe procedury pracy. Samo połączenie MCP daje agentowi narzędzia. Plugin mówi mu, w jakiej kolejności i z jakimi zabezpieczeniami ich używać.
| Składnik | Ile | Co robi |
|---|---|---|
| Skille | 24 | komendy /monolynx:*, czyli zapisane procedury: od założenia ticketu po zamknięcie sprintu |
| Agenci | 7 | role wykonawcze, którym koordynator zleca pracę nad ticketem |
| Hooki | 2 | strażnicy uruchamiani przed komendą agenta i przed Twoim pierwszym poleceniem w sesji |
| Połączenie MCP | 1 | dostęp do serwera Monolynx z logowaniem OAuth |
Praca zaczyna się od grupy Setup, która przygotowuje projekt. Planowanie tworzy i sprawdza tickety. Praca wykonuje pojedynczy ticket. Integracja doprowadza zmianę do merge. Sprint prowadzi wiele ticketów naraz i zamyka sprint. Wiki zbiera wiedzę z wykonanej pracy i oddaje ją przy następnym planowaniu.
flowchart LR
A["Setup"] --> B["Planowanie"]
B --> C["Praca"]
C --> D["Integracja"]
D --> E["Sprint"]
E --> F["Wiki"]
F --> BKtóra komenda do czego?
Poniższe tabele wymieniają wszystkie komendy, grupa po grupie. Nawias kwadratowy oznacza argument opcjonalny.
Setup: raz na projekt
| Komenda | Co robi |
|---|---|
/monolynx:setup |
checklista konfiguracji projektu: stan każdego punktu i propozycja naprawy |
/monolynx:project-toolchain |
wykrywa komendy lintu i testów i zapisuje je na stronie wiki toolchain |
/monolynx:wiki-init |
włącza metodę LLM Wiki i tworzy jej strony systemowe |
/monolynx:graph-sync |
synchronizuje graf zależności kodu lokalnie, bez CI |
/monolynx:create-graph-ci-script [adres] |
dodaje do CI krok, który odświeża graf kodu |
/monolynx:create-mutation-ci-script |
dodaje do CI nieblokujący krok z testami mutacyjnymi |
Pierwszą konfigurację krok po kroku opisuje wpis Pierwszy projekt w Monolynx. Pełny format strony toolchain i listę kontrolną opisuje wpis Strona toolchain i /monolynx:setup. Całą drogę na jednym przykładzie pokazuje wpis Od pustego repozytorium do zmergowanego ticketu.
Planowanie: zanim powstanie kod
| Komenda | Co robi |
|---|---|
/monolynx:ticket-create [opis] |
tworzy ticket z kontekstem z wiki, kodu i grafu oraz z kryteriami akceptacji |
/monolynx:ticket-review [klucz albo sprint] |
sprawdza ticket przed startem; wariant sprint wykrywa tickety, które weszłyby sobie w drogę |
/monolynx:brief [opis zadania] |
spisuje kontrakt pracy dla zadania bez ticketu |
Szczegóły: Jak działa /monolynx:ticket-create i Jak działa /monolynx:ticket-review.
Praca: jeden ticket
| Komenda | Co robi |
|---|---|
/monolynx:next |
czyta stan repozytorium, ticketu, sprintu i sesji, a potem poleca od jednej do trzech komend; niczego nie zmienia |
/monolynx:work [klucz] |
prowadzi ticket powyżej 3 story points: rozpoznanie, zespół agentów, krytyk, lint i testy |
/monolynx:work-simple [klucz] |
prowadzi mały ticket, do 3 story points: jeden programista i krytyk |
/monolynx:resume [klucz] |
odtwarza stan pracy po przerwie; tylko odczyt |
/monolynx:mutation-check [moduł] |
uruchamia testy mutacyjne i zamienia przeżywające mutanty w kryteria albo tickety |
/monolynx:help |
pokazuje mapę komend |
Szczegóły: Jak działa /monolynx:work. Jeden ticket krok po kroku: Pierwszy ticket ręcznie: od brancha do merge.
Integracja: od merge requesta do wiki
| Komenda | Co robi |
|---|---|
/monolynx:mr-queue [merge requesty] |
prowadzi merge requesty do merge, jeden po drugim: konflikt, CI, zatwierdzenie, merge |
/monolynx:wiki-sync-merge [klucze ticketów] |
po merge przenosi wiedzę ze wskazanych ticketów do wiki |
Szczegóły: Jak działa /monolynx:mr-queue. Rolę człowieka opisuje wpis Zatwierdzanie i merge: co zawsze robi człowiek.
Sprint: wiele ticketów naraz
| Komenda | Co robi |
|---|---|
/monolynx:sprint-run [sloty] |
dyspozytor: startuje sesje ticketów w tle i zbiera zakończone |
/monolynx:sprint-end [nazwa sprintu] |
zamyka sprint: wiedza do wiki, audyt wiki, zamknięcie w panelu |
/monolynx:retro [nazwa sprintu] |
zamienia powtarzające się korekty ze sprintu w reguły projektu |
Szczegóły: Jak działa /monolynx:sprint-run i Jak działa /monolynx:sprint-end.
Wiki: pamięć projektu
| Komenda | Co robi |
|---|---|
/monolynx:search |
wyszukiwanie semantyczne w wiki; zwykle włącza się samo przy pytaniu o dokumentację |
/monolynx:wiki-ingest [źródło] |
włącza nowe źródło do wiki: plik, adres albo temat |
/monolynx:wiki-lint |
audyt wiki: sieroty, martwe linki, sprzeczności, luki |
/monolynx:blog-post [temat] |
prowadzi wpis na blog od konspektu po podgląd; publikuje dopiero po Twojej zgodzie |
Szczegóły: Jak działają skille LLM Wiki.
Dwie ścieżki pracy
Komendy z powyższych tabel składają się w dwa obiegi. Wybór zależy od tego, ile ticketów masz i ile chcesz pilnować sam.
| Cecha | Ręczna | Autopilot |
|---|---|---|
| Jednostka | jeden ticket | cały sprint |
Kto uruchamia work |
Ty, w swojej sesji | dyspozytor, w tle |
| Kto merguje | Ty | kolejka mr-queue, po Twoim zatwierdzeniu |
| Wiedza do wiki | wiki-sync-merge po merge |
sprint-end na koniec sprintu |
| Kiedy wybrać | pierwszy ticket, hotfix, praca wymagająca Twoich decyzji | wiele dobrze opisanych ticketów |
> /monolynx:ticket-create Dodaj eksport zamówień do CSV
> /monolynx:ticket-review SKL-12
> /monolynx:work SKL-12
# po merge
> /monolynx:wiki-sync-merge SKL-12> /loop 15m /monolynx:sprint-run
> /loop 10m /monolynx:mr-queue
# po merge brancha sprintu
> /monolynx:sprint-endAutopilot od początku do końca opisuje przewodnik Sprint z Monolynx krok po kroku.
Agenci i hooki
Koordynator ticketu nie pisze całego kodu sam. Dzieli pracę między agentów z rolami, a każdy agent ma własny zakres i własny model.
| Agent | Zakres |
|---|---|
backend-developer |
endpointy, modele, logika usług, migracje |
frontend-developer |
szablony, style, interakcje w przeglądarce |
database-specialist |
migracje, zapytania, indeksy |
devops-infra |
Docker, CI, infrastruktura |
qa-tester |
testy jednostkowe i integracyjne, regresja |
code-reviewer |
recenzja jakości, bezpieczeństwa i zgodności z konwencjami |
technical-writer |
dokumentacja i strony wiki |
Dwa hooki i to, czego pilnują
| Hook | Kiedy działa | Co robi |
|---|---|---|
| Strażnik komend | przed każdą komendą powłoki agenta | subagentom odmawia zapisu w git, testów i otwierania merge requestów; sesję główną pyta, chyba że dałeś zgodę flagą; zatwierdzenie merge requesta zawsze zostawia człowiekowi |
| Strażnik polecenia | przy pierwszym poleceniu w sesji | gołe polecenie bez kontraktu, na przykład "napraw build", zamienia w propozycję kontraktu pracy |
Hook nie działa tylko dlatego, że plugin jest zainstalowany. Klient musi go załadować, a Ty musisz nadać pluginowi zaufanie w swoim kliencie. Komendy work i mr-queue same sprawdzają, czy strażnik działa, i mówią wprost, gdy ochrony nie udało się potwierdzić.
Wspólny słownik pojęć
Wpisy na tym blogu używają tych samych słów w tym samym znaczeniu. Poniżej wszystkie w jednym miejscu, pogrupowane.
Plugin i połączenie
- Plugin
- paczka dla Claude Code i Codex: komendy, agenci, hooki i połączenie z serwerem Monolynx
- Skill
- komenda
/monolynx:*, czyli zapisana procedura, według której pracuje agent - Agent
- model AI wykonujący pracę; także rola wykonawcza, której koordynator zleca część ticketu
- Subagent
- agent powołany przez sesję do jednego zadania, z własnym kontekstem
- MCP
- Model Context Protocol, protokół, przez który agent wywołuje narzędzia platformy
- CLI
- klient wiersza poleceń
monolynx, drugi kanał do tej samej platformy - Transport
- kanał, którym komenda wykonuje operację: CLI albo MCP
- Hook
- skrypt uruchamiany przed działaniem agenta, który może je przepuścić, zablokować albo zamienić w pytanie
Ticket i jego obieg
- Kontrakt ticketu
- opis celu, zakresu, plików do zmiany, plików nie do ruszenia i kryteriów akceptacji
- Kontrakt autonomii
- lista decyzji, przed którymi agent ma się zatrzymać i zapytać
- Koordynator
- sesja prowadząca ticket: planuje, zleca pracę agentom i pilnuje bramek; w starszych wpisach nazywana Team Managerem
- Researcher
- agent rozpoznający kod i wiki przed planem pracy; nie pisze kodu
- Krytyk
- agent oceniający wynik pracy według rubryki punktowej
- Bramka jakości
- warunek przejścia dalej: zielony lint, zielone testy, ocena krytyka powyżej progu
- Bloker
- ticket, który musi być zakończony, zanim ruszy ticket zależny
- Story points
- umowna miara wielkości ticketu
Sprint i pętle
- Dyspozytor
- skill
sprint-run, który startuje i zbiera sesje ticketów, ale sam nad nimi nie pracuje - Kolejka
- skill
mr-queue, który prowadzi merge requesty do merge jeden po drugim - Tick
- jedno wykonanie pętli: odczyt stanu, jeden krok, linia statusu
- Idempotentny
- bezpieczny do powtórzenia; drugi tick nie dubluje pracy pierwszego
- Werdykt
- stan ticketu albo merge requesta policzony przez skrypt, na przykład
runningalboneeds_approval - Slot
- miejsce na jedną pracującą sesję ticketu
- Sesja w tle
- sesja uruchomiona bez okna terminala, do której można wejść później
- Kontrola wstępna
- sprawdzenie środowiska na początku ticku; w komunikatach nazywana preflight
- Linia STOP
- jedna linia z powodem, którą sesja kończy turę, gdy potrzebuje decyzji człowieka
Git i środowisko
- Worktree
- osobny katalog roboczy tego samego repozytorium, w którym sesja ticketu pracuje bez kolizji z innymi
- Branch sprintu
- branch, z którego startują tickety sprintu i do którego wracają ich merge requesty; nazywany też integracyjnym, a w opisach zmiennych bazowym, źródłowym albo docelowym
- Merge request
- prośba o włączenie zmiany do brancha; na GitHubie pull request
- Toolchain
- strona wiki z komendami lintu i testów projektu
- Flagi autonomii
- zmienne
MONOLYNX_AUTO*, którymi dajesz zgodę na testy, commit, push i merge request bez pytania
Wiki i wiedza
- LLM Wiki
- metoda, w której wiki jest rosnącym, pielęgnowanym przez agentów zbiorem wiedzy projektu
- INGEST
- włączenie nowego źródła do wiki
- LINT
- audyt wiki: sieroty, martwe linki, sprzeczności, luki
- Graf kodu
- mapa zależności między plikami, klasami i funkcjami projektu
- Pipeline
- zapis przebiegu pracy agentów nad ticketem albo zamknięciem sprintu, widoczny w panelu
- Testy mutacyjne
- sprawdzenie jakości testów przez wprowadzanie drobnych błędów do kodu
Najczęstsze pytania
Czy muszę znać wszystkie 24 komendy?
Nie. Na co dzień wystarcza kilka: next, ticket-create, ticket-review, work, a w sprincie sprint-run, mr-queue i sprint-end. Resztę podpowie next albo setup, gdy będzie potrzebna.
Czym różni się work od work-simple?
Wielkością ticketu. work-simple prowadzi mały ticket jednym programistą i krytykiem. work powołuje zespół i fazę rozpoznania. Gdy mały ticket okazuje się większy, work-simple sam przekazuje go do work.
Czy komendy działają w ChatGPT albo w aplikacji Claude?
Nie. Rozmowa w tych aplikacjach dostaje narzędzia MCP, ale nie komendy pluginu. Komendy są dostępne w Claude Code i w Codex.
Kiedy brief, a kiedy ticket-create?
brief służy zadaniu, które robisz od ręki i nie chcesz zakładać dla niego ticketu. ticket-create zostawia ślad w projekcie: ticket z kryteriami, który może wejść do sprintu.
Skąd wziąć pełną dokumentację zmiennych i ustawień?
Z pliku README pluginu w repozytorium Monolynx. Zawiera tabelę wszystkich zmiennych MONOLYNX_*, modele przypisane do ról i opis hooków.
Następny krok
Masz mapę, więc pora wybrać drogę. Bez konfiguracji zacznij od wpisu Pierwszy projekt w Monolynx. Bez połączenia zacznij od wpisu Jak połączyć agenta AI z Monolynx. Nazwy statusów z panelu i z komend zestawia wpis Statusy ticketu w Monolynx.
Nowa osoba może czytać wpisy w tej kolejności:
- Połączenie
- Projekt
- Jeden ticket
- Sprint
- Kłopoty i ustawienia
Poza tą ścieżką zostają dwa wpisy tematyczne: Graf kodu i testy mutacyjne oraz CLI monolynx dla deweloperów i agentów.
Chcesz zobaczyć, jak praca agentów wygląda po stronie platformy?
Zobacz moduł Pipelines w Monolynx