Jak działa /monolynx:sprint-end: zamknięcie sprintu, po którym wiedza zostaje w wiki

Co się dzieje, gdy sprint się kończy?

Sprint prowadzony przez agentów AI zostawia po sobie dużo materiału: raporty Researchera, logi developerów, oceny krytyka. Na każdy ticket przypada kilka stron logów w wiki. Bez porządków ta wiedza albo ginie, albo zaśmieca wyszukiwanie.

Skill sprint-end z pluginu Monolynx dla Claude Code robi z zamknięcia sprintu powtarzalną procedurę. Argumentem jest nazwa sprintu. Bez argumentu skill bierze sprint aktywny, a gdy aktywnych jest kilka, pyta, który zamknąć.

$ claude
> /monolynx:sprint-end

Cały przebieg jest widoczny w module Pipelines jako pipeline typu sprint_close, z osobnym wpisem dla każdego zadania.

Dwa etapy, osiem zadań

Przebieg ma stałą kolejność, a zadania idą po sobie, nigdy równolegle. Kolejność nie jest przypadkowa: każde zadanie stoi przed tym, które mogłoby mu odebrać dane.

1. wiki-ingest

   Wiedza z logów pracy agentów trafia na strony wiki: encje, pojęcia, linki między stronami, katalog i dziennik.

2. wiki-lint

   Audyt wiki szuka stron osieroconych, martwych linków i sprzeczności.

3. wiki-clean

   Strony logów sprintu są usuwane, bo ich treść jest już w wiki.

4. mutation-run

   Opcjonalny przebieg testów mutacyjnych na modułach rdzenia.

5. retro

   Opcjonalne retro: powtarzające się uwagi krytyka stają się regułami.

6. version-bump

   Warunkowe nadanie numeru wydania pluginu.

7. close-sprint

   Faktyczne zamknięcie sprintu, po potwierdzeniu.

8. summary

   Podsumowanie całego przebiegu.

Dwa etapy odpowiadają dwóm kolumnom pipeline'u w panelu. Etap pierwszy, aktualizacja wiki, to zadania 1-3. Etap drugi, domknięcie, to zadania 4-8.

flowchart TD
  A[Sprint do zamknięcia] --> B[wiki-ingest]
  B --> C[wiki-lint]
  C --> D{Ingest udany?}
  D -->|tak| E[wiki-clean]
  D -->|nie| F[Logi zostają]
  E --> G[mutation-run]
  F --> G
  G --> H[retro]
  H --> I[version-bump]
  I --> J{Potwierdzenie}
  J -->|tak| K[close-sprint]
  J -->|nie| L[Sprint zostaje otwarty]
  K --> M[summary]

Dlaczego kolejność w wiki ma znaczenie?

Etap wiki ma jedną twardą regułę: logów nie wolno skasować, dopóki ich treść nie trafiła do wiki. Strony logów są jedynym zapisem tego, co agenci ustalili podczas pracy nad ticketami.

Audyt wiki stoi pośrodku z prostego powodu. Świeżo dopisane strony mogą przeczyć starszym, a rozstrzygnięcie sprzeczności bywa decyzją człowieka. Skill czeka wtedy na odpowiedź, zamiast wybierać wersję samodzielnie.

Testy mutacyjne jako trend, nie bramka

Przebieg mutacyjny odpowiada na pytanie, czy testy faktycznie wykrywają błędy w najważniejszych modułach. Skill go proponuje, ale nigdy nie odpala sam. Konfigurację czyta ze strony wiki toolchain, a gdy jej nie ma, pomija zadanie jedną linią w podsumowaniu.

Wynik każdego modułu i wiersz zbiorczy trafiają na stronę wiki "Trend mutacji". Tabela tylko rośnie: skill dopisuje wiersze na końcu i nie poprawia historii.

Baseline działa jak zapadka. Lepszy wynik podnosi punkt odniesienia, gorszy go nie rusza. W przykładzie widać to w trzecim sprincie: wynik spadł, a baseline został na poprzednim poziomie.

Punkt odniesienia jest jedną linią na stronie toolchain:

baseline: 71.4% (2026-10-08)

Retro i numer wydania przed zamknięciem

Dwa kolejne zadania stoją przed zamknięciem sprintu z konkretnych powodów.

Retro

Skill pyta, czy uruchomić retro korekt. Retro zbiera uwagi krytyka, zatrzymania i eskalacje z komentarzy ticketów, grupuje te, które się powtarzają, i proponuje dla nich trwałe reguły.

Musi iść przed zamknięciem, bo zamknięcie wypisuje niedokończone tickety ze sprintu do backlogu. A właśnie te tickety niosą najwięcej materiału: eskalacje i oceny poniżej progu. Po zamknięciu lista ticketów sprintu już by ich nie zwróciła.

Numer wydania

Zadanie version-bump dotyczy repozytoriów, które wydają plugin. Tickety sprintu dopisują swoje zmiany do changelogu pod nagłówkiem "Unreleased" i nie ruszają numeru wersji. Numer nadaje dopiero zamknięcie sprintu.

Skill przygotowuje wydanie w osobnym katalogu roboczym, na osobnym branchu, i sprawdza je walidatorem. Twój checkout zostaje nietknięty. Commit, push i merge request powstają tylko przy włączonych flagach, tak jak w skillu opisanym we wpisie jak działa /monolynx:work.

Zamknięcie, którego nie da się cofnąć

Zamknięcie sprintu jest jedynym krokiem w tym etapie, którego nie odwróci żadna komenda. Niedokończone tickety wracają do backlogu i tracą przypisanie do sprintu.

Zamykam sprint "Blog". Niedokończone tickety wrócą do backlogu. Kontynuować?
  1. Tak, zamknij sprint
  2. Nie, przerwij

Odpowiedź "nie" kończy przebieg bez zamykania sprintu. Praca wykonana wcześniej zostaje: wiki jest zaktualizowana, trend dopisany.

Podsumowanie na końcu zbiera wszystko w jednym miejscu: wynik przeniesienia wiedzy i audytu, liczbę usuniętych stron logów, wynik testów mutacyjnych, zapisane reguły z retro i numer wydania.

Najczęstsze pytania

Pytania poniżej dotyczą sytuacji, które zdarzają się przy pierwszym zamknięciu sprintu skillem.

Słownik i następny krok

Pojęcia z tego wpisu, w jednym miejscu:

Ingest

przeniesienie wiedzy ze źródła do stron wiki, z linkami i wpisem w dzienniku

Lint wiki

audyt spójności wiki: strony osierocone, martwe linki, sprzeczności

Test mutacyjny

sprawdzenie, czy testy wykryją celowo wprowadzoną zmianę w kodzie

Baseline

punkt odniesienia dla wyniku mutacji, który może tylko rosnąć

Moduły rdzenia

uzgodniona lista najważniejszych modułów mierzonych w trendzie

Retro

przegląd powtarzających się korekt ze sprintu, zakończony regułami

Sprint, który zamykasz, wcześniej przerabiają tickety pisane skillem z wpisu jak działa /monolynx:ticket-create.