---
title: "Jak działa /monolynx:mr-queue: kolejka merge, która sama pilnuje CI"
description: "Jak skill mr-queue prowadzi merge requesty po kolei: konflikt, CI, approve, merge. I dlaczego zalecamy uruchamianie go w pętli /loop 10m."
url: "https://monolynx.com/blog/jak-dziala-monolynx-mr-queue"
lang: "pl"
author: "Zespół Monolynx"
published: "2026-10-08T07:33:01.594442+00:00"
modified: "2026-10-09T18:11:36.123818+00:00"
last_verified: "2026-10-08"
tags: ["plugin", "claude-code", "agenci-ai", "scrum", "merge-request"]
translations: []
reading_time_minutes: 10
word_count: 1892
---

> [!TLDR]
> - `/monolynx:mr-queue` to strażnik kolejki merge: jedno uruchomienie bierze pierwszy niezmergowany MR albo PR i robi dokładnie jedno działanie.
> - Kolejność sprawdzeń jest stała: konflikt, CI, approve, merge. Stan liczy skrypt z danych `glab` albo `gh`, nie model z opisu MR.
> - Skill sam rozwiązuje konflikt i poprawia czerwone CI, ale nigdy nie zatwierdza MR i nie robi na branchu MR force pusha ani rebase'u.
> - Zalecamy wywołanie w pętli: `/loop 10m /monolynx:mr-queue`. Tick jest idempotentny, więc powtarzanie niczego nie dubluje.

## Po co kolejka merge, skoro MR można kliknąć ręcznie?

Ręczne mergowanie działa przy jednym MR dziennie. Gdy agenci oddają kilka zmian naraz, zaczyna się pilnowanie: ten ma konflikt po poprzednim merge, tamten czerwone CI, trzeci czeka na approve, a po każdym merge trzeba sprawdzić, czy branch docelowy nadal jest zielony. To praca, w której człowiek głównie czeka i odświeża stronę.

Skill mr-queue przejmuje czekanie. Trzyma listę MR i PR w ustalonej kolejności i przy każdym uruchomieniu przesuwa pierwszy z nich o jeden krok w stronę merge. Działa z GitLabem przez `glab` i z GitHubem przez `gh`.


**Wywołanie mr-queue**

```console
# zalecane: pętla co 10 minut, kolejka układa się sama
/loop 10m /monolynx:mr-queue

# jeden tick ręcznie
/monolynx:mr-queue

# własna kolejność merge
/monolynx:mr-queue !142 !139 !145
```



**Statystyki**

- **1** - działanie na jeden tick: push, merge albo pytanie
- **4** - sprawdzenia w stałej kolejności: konflikt, CI, approve, merge
- **2** - rundy automatycznych poprawek, potem decyduje człowiek
- **0** - użyć force, rebase i reset na branchu MR


## Dlaczego zalecamy pętlę co 10 minut?

Jedno uruchomienie skilla to jeden tick, a pełne przejście MR przez kolejkę wymaga kilku ticków: merge brancha docelowego, czekanie na nowe CI, merge, czekanie na CI brancha docelowego. Pętla jest celowo poza skillem. Skill robi krok i kończy turę, a o rytmie decyduje `/loop`.

```text title="Zalecane wywołanie"
/loop 10m /monolynx:mr-queue
```

Dziesięć minut to rytm dobrany do tego, na co kolejka czeka najczęściej, czyli do rundy CI. U nas pełna runda lintu i testów trwa kilkanaście do dwudziestu minut, więc tick co 10 minut zauważa wynik niedługo po jego pojawieniu się, a nie odpytuje serwera co chwilę bez powodu. Większość ticków kończy się werdyktem `wait` i niczego nie zmienia.

> [!TIP]
> Powtarzanie jest bezpieczne, bo tick jest idempotentny. Stan kolejki leży w pliku, stan MR w GitLabie albo GitHubie. Dwa ticki pod rząd nie zdublują pusha, merge ani pytania.

Pętla ma jeszcze jedną zaletę: kolejka sama rośnie. Przy każdym ticku skill dopisuje na koniec otwarte MR, których jeszcze w niej nie ma. Nowa zmiana oddana przez agenta w trakcie dnia trafia do kolejki bez żadnej komendy. Dotyczy to każdego otwartego merge requesta, także merge requesta całego sprintu do gałęzi głównej. Trzymaj go jako draft, dopóki tickety nie są zmergowane: drafty kolejka pomija.


**Porównanie**

| Cecha | Ręczne ticki | Pętla co 10 minut |
| --- | --- | --- |
| Kto pamięta o kolejnym kroku | człowiek | pętla |
| Reakcja na zielone CI | gdy ktoś zajrzy | w ciągu jednego interwału |
| Nowe MR w ciągu dnia | po ręcznym uruchomieniu | dopisywane same |
| Kiedy przerywa człowiekowi | przy każdym ticku | tylko przy decyzji: approve albo raport "Potrzebne" |


## Co dzieje się w jednym ticku?


**Kroki**

1. **Kontrola wstępna** Skill sprawdza repozytorium, logowanie `glab` albo `gh` i spójność konfiguracji brancha docelowego.
2. **Kolejka** Bez argumentów układa ją sam z otwartych MR; z argumentami przyjmuje podaną kolejność.
3. **Pierwszy niezmergowany element** Reszta kolejki czeka, bo kolejność jest święta.
4. **Werdykt** Skrypt `mr_queue_state.py` liczy go z JSON-a dostawcy.
5. **Jedno działanie** Rozwiązanie konfliktu, poprawka CI, pytanie o approve albo merge.
6. **Raport i linia statusu** Ostatnia linia odpowiedzi ma zamrożony format, który czytają pętla i inne narzędzia.



**Decyzja ticka dla pierwszego MR w kolejce**

Tick sprawdza kolejno konflikt, CI i approve. Konflikt prowadzi do merge brancha docelowego w tymczasowym worktree, czerwone CI do poprawki, brak approve do pytania do człowieka, a komplet warunków do merge. Po każdym działaniu tick się kończy, a następny liczy stan od nowa.

```mermaid
flowchart TD
  A[Pierwszy MR w kolejce] --> B{Konflikt?}
  B -->|tak| C[Anuluj pipeline MR i zmerguj branch docelowy]
  B -->|nie| D{CI}
  D -->|w toku| E[wait: koniec ticka]
  D -->|czerwone| F[Poprawka w tymczasowym worktree]
  D -->|zielone| G{Approve?}
  G -->|brak| H[Pytanie do człowieka]
  G -->|jest| I[Merge z blokadą na SHA]
  C --> J[Koniec ticka]
  F --> J
  H --> J
  I --> J
```


### Jak skill układa kolejkę?

Bez argumentów skill pobiera listę otwartych MR i układa je od najstarszego. MR oparty o branch innego otwartego MR idzie zaraz po nim. Drafty i zmiany oparte o draft są pomijane, z powodem w raporcie. Kolejkę przyjmuje bez pytania, a inną kolejność można podać w każdej chwili jako argumenty: `!iid` dla GitLaba, `#numer` dla GitHuba albo pełny adres.

Plik kolejki leży we wspólnym katalogu gita, więc jest jeden dla głównego checkoutu i wszystkich worktree repozytorium.

## Jakie werdykty może dać tick?


**Porównanie**

| Werdykt | Co oznacza | Co robi tick |
| --- | --- | --- |
| `wait` | CI w toku albo dostawca liczy mergeowalność | nic, koniec ticka |
| `conflict` | branch MR koliduje z branchem docelowym | anuluje pipeline MR i merguje branch docelowy |
| `ci_failed` | czerwone CI na branchu MR | poprawka w tymczasowym worktree |
| `needs_approval` | brak zatwierdzenia | pyta człowieka |
| `ready` | zielone CI, approve, brak konfliktu | merge |
| `needs_human` | stan, którego automat nie powinien ruszać | raport "Potrzebne", kolejka stoi |
| `merged` / `closed` | zmergowany albo zamknięty poza kolejką | domyka pozycję i idzie dalej |


> [!NOTE]
> Nieznany stan z GitLaba albo GitHuba mapuje się na `wait`, nigdy na `ready`. Czekanie da się odwrócić następnym tickiem, a merge nie.

### Dlaczego konflikt wygrywa z CI?

CI na branchu, który koliduje z branchem docelowym, nie da mergowalnego wyniku, a runda trwa i zajmuje runner innym zmianom. Dlatego przy konflikcie tick anuluje trwający pipeline MR i od razu merguje branch docelowy w tymczasowym, odłączonym worktree. Konflikty w plikach rozstrzyga subagent na modelu `opus`, bo musi pogodzić dwie intencje, a nie tylko poprawić składnię. Gdy intencje są sprzeczne, subagent przerywa, a pozycja czeka na człowieka.

### Jak wygląda poprawka czerwonego CI?

Tick czyta ogon logu czerwonych jobów, tworzy odłączony worktree na aktualnym HEAD brancha MR i zleca poprawkę subagentowi na modelu `sonnet`. Commit i push robi główna sesja, zwykłym pushem na branch MR. Potem worktree znika, a nowy pipeline oceni następny tick.


**Granice automatycznych poprawek**

| Sytuacja | Zachowanie |
| --- | --- |
| Dwie rundy poprawek bez zielonego CI | pozycja zatrzymana, raport z oboma podejściami |
| Branch innego autora | push tylko po zgodzie człowieka |
| Kod wyjścia 137 bez czerwonego testu | ponowienie joba, bez liczenia rundy poprawek |
| Pipeline anulowany przez człowieka | werdykt `needs_human`, tick go nie ponawia |
| Push odrzucony, bo branch poszedł do przodu | worktree usunięty, następny tick liczy stan od nowa |


## Co wolno automatowi, a co zostaje dla człowieka?

Skill pyta tylko o decyzje, które należą do człowieka: approve, merge bez włączonej zmiennej `MONOLYNX_AUTOMERGE` i push do cudzego brancha. Approve dany w rozmowie wiąże się z konkretnym SHA. Każdy nowy commit na branchu, także poprawka zrobiona przez sam skill, wymaga nowego zatwierdzenia.

> Nigdy nie zatwierdzasz MR/PR i nigdy nie mergujesz bez werdyktu ready policzonego w tym samym ticku, z blokadą na ten SHA.
> -- skill mr-queue, ważne zasady

> [!WARNING]
> Merge idzie z wyłączonym auto-merge i z blokadą na SHA, który tick właśnie ocenił. Jeśli w międzyczasie ktoś dopchnął commit, merge zostaje odrzucony, a następny tick liczy werdykt od nowa.

Gdy tick trafia na stan wymagający człowieka, nie pyta "co dalej?". Kończy się raportem z linią `Potrzebne:`, która mówi, co dokładnie zrobić i jaką komendą wrócić do kolejki. Po działaniu człowieka kolejka rusza sama przy następnym ticku.

> [!IMPORTANT]
> Checkout użytkownika zostaje nietknięty. Poprawki powstają wyłącznie w tymczasowych worktree. Jedyny wyjątek to fast-forward lokalnego brancha docelowego po domknięciu pozycji, i tylko wtedy, gdy da się go wykonać bez resetu, rebase'u i stasha.

## Co się dzieje po merge?

Tor po merge zależy od brancha docelowego i wybiera go skrypt, nie model.


**Porównanie**

| Cecha | Domyślny branch repozytorium | Branch integracyjny, np. sprint/* |
| --- | --- | --- |
| Następny MR wchodzi | po zielonym CI brancha docelowego | od razu po merge |
| Ticket dostaje status done | po zielonym CI commita merge | od razu, na podstawie zielonego CI samego MR |
| Pipeline brancha po merge | jest warunkiem dalszej pracy | tick go anuluje, bo blokowałby kolejny MR |
| Czerwone CI brancha | kolejka staje, raport "Potrzebne" | całość weryfikuje MR brancha integracyjnego do domyślnego |


Na koniec każdego ticka skill wypisuje linię statusu:

```text title="Ostatnia linia ticka"
MR-QUEUE: remaining=3 current=!142 verdict=ready done=2
```


**Przykładowy dzień kolejki: werdykty ticków (liczby ilustracyjne)**

| Werdykt | Liczba ticków |
| --- | --- |
| wait | 21 |
| ready | 5 |
| conflict | 3 |
| ci_failed | 2 |
| needs_approval | 5 |


## Najczęstsze pytania


**FAQ**

### Czy mr-queue zatwierdza MR za mnie?
Nie. Approve zawsze daje człowiek. Skill może zapisać zgodę wyrażoną w rozmowie, ale tylko dla konkretnego SHA, i nigdy nie wywołuje zatwierdzenia w GitLabie ani GitHubie.

### Czy pętla może zmergować coś bez mojej wiedzy?
Bez zmiennej `MONOLYNX_AUTOMERGE` ustawionej na `true` każda komenda merge pyta o zgodę. Z nią skill merguje sam, ale wyłącznie MR z werdyktem `ready`: zielone CI, approve i brak konfliktu, policzone w tym samym ticku.

### Co jeśli tick trafi na coś, czego nie umie naprawić?
Kolejka staje na tej pozycji, a raport zawiera linię `Potrzebne:` z konkretnym działaniem i komendą powrotu. Kolejne ticki pętli niczego nie psują: liczą stan od nowa i ruszają dopiero po zmianie.

### Czy mogę zmienić kolejność w trakcie?
Tak. Wywołaj skill z refami w nowej kolejności. Argumenty zawsze nadpisują kolejkę ułożoną automatycznie.

### Dlaczego nie krótszy interwał niż 10 minut?
Kolejka czeka głównie na CI, a runda CI trwa dłużej niż kilka minut. Częstsze ticki dałyby więcej werdyktów `wait` i tyle samo merge. Jeśli Twoje CI kończy się w dwie minuty, krótszy interwał ma sens.


## Słownik i następny krok


**Słownik**

- **Tick** - jedno uruchomienie skilla: odczyt stanu, jedno działanie, raport
- **Werdykt** - stan MR policzony przez skrypt z danych GitLaba albo GitHuba
- **Branch integracyjny** - branch docelowy inny niż domyślny branch repozytorium, na przykład branch sprintu
- **Blokada na SHA** - merge przechodzi tylko wtedy, gdy HEAD brancha jest tym commitem, który tick ocenił
- **Raport "Potrzebne"** - zakończenie ticka z konkretnym działaniem dla człowieka zamiast pytania
- **Idempotentny** - powtórzony daje ten sam stan, bez zdublowanych skutków


Kolejka merge domyka obieg, który zaczyna [skill work, prowadzący ticket od planu do merge requesta](https://monolynx.com/blog/jak-dziala-monolynx-work), a kończy [skill sprint-end, zamykający sprint i aktualizujący wiki](https://monolynx.com/blog/jak-dziala-monolynx-sprint-end).

Granicę między kolejką a człowiekiem, czyli zgodę związaną z commitem i merge, opisuje wpis [Zatwierdzanie i merge: co zawsze robi człowiek](https://monolynx.com/blog/zatwierdzanie-i-merge-w-monolynx). Kiedy ticket po merge dostaje status Gotowe, wyjaśnia wpis [Statusy ticketu w Monolynx](https://monolynx.com/blog/statusy-ticketu-w-monolynx).


**Wezwanie do działania**

Chcesz, żeby merge requesty agentów trafiały do głównej gałęzi po kolei, z zielonym CI i bez ręcznego pilnowania?

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