---
title: "Mapa pluginu Monolynx: wszystkie komendy i wspólny słownik"
description: "Wszystkie 24 komendy pluginu Monolynx w sześciu grupach, dwie ścieżki pracy, siedmiu agentów, dwa hooki i wspólny słownik pojęć używanych na blogu."
url: "https://monolynx.com/blog/mapa-pluginu-monolynx"
lang: "pl"
author: "Zespół Monolynx"
published: "2026-10-08T08:42:22.973879+00:00"
modified: "2026-10-09T18:11:39.904460+00:00"
last_verified: "2026-10-08"
tags: ["plugin", "claude-code", "agenci-ai", "sprint", "slownik"]
translations: []
reading_time_minutes: 11
word_count: 2178
---

> [!TLDR]
> - Plugin Monolynx to 24 komendy `/monolynx:*`, siedmiu agentów z rolami i dwa hooki pilnujące granic.
> - Komendy dzielą się na sześć grup: Setup, Planowanie, Praca, Integracja, Sprint i Wiki.
> - Dwie komendy warto zapamiętać od razu: `/monolynx:next` mówi, co zrobić teraz, a `/monolynx:help` pokazuje mapę.
> - Są dwie ścieżki pracy: ręczna, ticket po tickecie, i autopilot, czyli sprint prowadzony dwiema pętlami.
> - Ten wpis jest też wspólnym słownikiem: skill, agent, tick, werdykt, worktree i reszta pojęć w jednym miejscu.

## 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ć.


**Porównanie**

| 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 |



**Statystyki**

- **24** - komendy pluginu
- **6** - grup komend
- **7** - ról agentów
- **2** - ścieżki pracy: ręczna i autopilot



**Sześć grup komend w kolejności użycia**

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.

```mermaid
flowchart LR
  A["Setup"] --> B["Planowanie"]
  B --> C["Praca"]
  C --> D["Integracja"]
  D --> E["Sprint"]
  E --> F["Wiki"]
  F --> B
```


## Która komenda do czego?

Poniższe tabele wymieniają wszystkie komendy, grupa po grupie. Nawias kwadratowy oznacza argument opcjonalny.

### Setup: raz na projekt


**Porównanie**

| 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](https://monolynx.com/blog/pierwszy-projekt-w-monolynx). Pełny format strony `toolchain` i listę kontrolną opisuje wpis [Strona toolchain i /monolynx:setup](https://monolynx.com/blog/strona-toolchain-i-monolynx-setup). Całą drogę na jednym przykładzie pokazuje wpis [Od pustego repozytorium do zmergowanego ticketu](https://monolynx.com/blog/od-repozytorium-do-zmergowanego-ticketu).

### Planowanie: zanim powstanie kod


**Porównanie**

| 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](https://monolynx.com/blog/jak-dziala-monolynx-ticket-create) i [Jak działa /monolynx:ticket-review](https://monolynx.com/blog/jak-dziala-monolynx-ticket-review).

### Praca: jeden ticket


**Porównanie**

| 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](https://monolynx.com/blog/jak-dziala-monolynx-work). Jeden ticket krok po kroku: [Pierwszy ticket ręcznie: od brancha do merge](https://monolynx.com/blog/pierwszy-ticket-recznie-monolynx).

### Integracja: od merge requesta do wiki


**Porównanie**

| 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](https://monolynx.com/blog/jak-dziala-monolynx-mr-queue). Rolę człowieka opisuje wpis [Zatwierdzanie i merge: co zawsze robi człowiek](https://monolynx.com/blog/zatwierdzanie-i-merge-w-monolynx).

### Sprint: wiele ticketów naraz


**Porównanie**

| 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](https://monolynx.com/blog/jak-dziala-monolynx-sprint-run) i [Jak działa /monolynx:sprint-end](https://monolynx.com/blog/jak-dziala-monolynx-sprint-end).

### Wiki: pamięć projektu


**Porównanie**

| 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](https://monolynx.com/blog/jak-dzialaja-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.


**Porównanie**

| 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 |



**Ścieżka ręczna: jeden ticket**

```console
> /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
```



**Ścieżka autopilot: cały sprint**

```console
> /loop 15m /monolynx:sprint-run
> /loop 10m /monolynx:mr-queue
# po merge brancha sprintu
> /monolynx:sprint-end
```


Autopilot od początku do końca opisuje przewodnik [Sprint z Monolynx krok po kroku](https://monolynx.com/blog/sprint-z-monolynx-krok-po-kroku).

> [!TIP]
> Nie wiesz, na którym etapie jesteś? Wpisz `/monolynx:next`. Komenda kończy się linią `NEXT: <komenda>` z jedną najlepszą propozycją i niczego nie uruchamia sama.

## 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.


**Porównanie**

| 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 |


> [!NOTE]
> Agenci z tej listy są dostarczani z pluginem dla Claude Code. Zespół możesz też zdefiniować sam, w katalogu `.claude/agents/` swojego projektu, jeśli Twój stos technologiczny wymaga innych ról.


**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


**Słownik**

- **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


**Słownik**

- **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


**Słownik**

- **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 `running` albo `needs_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


**Słownik**

- **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


**Słownik**

- **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


**FAQ**

### 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](https://monolynx.com/blog/pierwszy-projekt-w-monolynx). Bez połączenia zacznij od wpisu [Jak połączyć agenta AI z Monolynx](https://monolynx.com/blog/polaczenie-z-monolynx-mcp-claude-code-chatgpt). Nazwy statusów z panelu i z komend zestawia wpis [Statusy ticketu w Monolynx](https://monolynx.com/blog/statusy-ticketu-w-monolynx).

Nowa osoba może czytać wpisy w tej kolejności:


**Kroki**

1. **Połączenie** [Jak połączyć agenta AI z Monolynx](https://monolynx.com/blog/polaczenie-z-monolynx-mcp-claude-code-chatgpt).
2. **Projekt** [Pierwszy projekt w Monolynx](https://monolynx.com/blog/pierwszy-projekt-w-monolynx), a potem [Strona toolchain i /monolynx:setup](https://monolynx.com/blog/strona-toolchain-i-monolynx-setup).
3. **Jeden ticket** [Od pustego repozytorium do zmergowanego ticketu](https://monolynx.com/blog/od-repozytorium-do-zmergowanego-ticketu).
4. **Sprint** [Sprint w panelu Monolynx](https://monolynx.com/blog/sprint-w-panelu-monolynx), [Sprint z Monolynx krok po kroku](https://monolynx.com/blog/sprint-z-monolynx-krok-po-kroku) i [Sesje w tle: jak obserwować pętle sprintu](https://monolynx.com/blog/sesje-w-tle-monolynx).
5. **Kłopoty i ustawienia** [Gdy coś nie działa w Monolynx](https://monolynx.com/blog/gdy-cos-nie-dziala-w-monolynx) oraz [Konfiguracja: która zmienna w którym pliku](https://monolynx.com/blog/konfiguracja-monolynx-zmienne).


Poza tą ścieżką zostają dwa wpisy tematyczne: [Graf kodu i testy mutacyjne](https://monolynx.com/blog/graf-kodu-i-testy-mutacyjne) oraz [CLI monolynx dla deweloperów i agentów](https://monolynx.com/blog/monolynx-cli-dla-deweloperow-i-agentow).


**Wezwanie do działania**

Chcesz zobaczyć, jak praca agentów wygląda po stronie platformy?

[Zobacz moduł Pipelines w Monolynx](https://monolynx.com/features/pipelines)