Pierwszy projekt w Monolynx: od konta do /monolynx:setup

Co trzeba zrobić, zanim agent weźmie pierwszy ticket?

Pierwsza konfiguracja zajmuje jedno posiedzenie i robisz ją raz na projekt. Poniżej cała droga w jednym miejscu, a dalej każdy krok osobno.

1. Zaloguj się do panelu

   Konto dostajesz z zaproszenia albo logujesz się kontem Google, jeśli Twoja instancja to dopuszcza.

2. Utwórz projekt

   W panelu wybierz tworzenie projektu i podaj nazwę, kod i slug.

3. Podłącz agenta

   Raz, globalnie, przez MCP. Opisuje to wpis Jak połączyć agenta AI z Monolynx.

4. Powiąż repozytorium z projektem

   Wpisz slug projektu do .claude/settings.json w repozytorium.

5. Uruchom /monolynx:setup

   Komenda pokaże, czego jeszcze brakuje, i zaproponuje naprawę.

flowchart TD
  A["Konto w panelu"] --> B["Nowy projekt: nazwa, kod, slug"]
  B --> C["Agent podłączony przez MCP"]
  C --> D["Plugin Monolynx w Claude Code"]
  D --> E["Slug projektu w repozytorium"]
  E --> F["/monolynx:setup"]
  F --> G["project-toolchain: lint i testy"]
  F --> H["wiki-init: metoda LLM Wiki"]
  G --> I["Pierwszy ticket"]
  H --> I

Krok 1 i 2: konto i projekt

Po zalogowaniu panel pokazuje listę Twoich projektów. Nowy projekt tworzysz z tej listy. Formularz sprawdza na bieżąco, czy kod i slug są wolne, i podpowiada wolną wersję, gdy są zajęte.

Kto utworzył projekt, zostaje jego właścicielem. Kolejne osoby dodajesz w ustawieniach projektu, w sekcji członków, wybierając dla każdej rolę.

Kto co może: role w projekcie

Rola decyduje o tym, co wolno człowiekowi w panelu i agentowi, który działa na jego koncie. Projekt ma trzy role domyślne, a w ustawieniach możesz zdefiniować własne.

Krok 3: połączenie i plugin

Połączenie z platformą ustawiasz raz dla siebie, nie dla projektu. Plugin instalujesz w sesji Claude Code dwiema komendami, a po instalacji kończysz logowanie w /mcp.

/plugin marketplace add https://gitlab.com/piotrkrych/monolynx.git
/plugin install monolynx@monolynx

Plugin przynosi komendy /monolynx:*, definicje agentów i połączenie z serwerem MCP. Programiści zwykle dokładają do tego klienta monolynx, opisanego we wpisie CLI monolynx dla deweloperów i agentów.

Krok 4: jak powiązać repozytorium z projektem?

Serwer zna wszystkie Twoje projekty, więc komendy pluginu muszą wiedzieć, na którym pracują. Mówi im o tym zmienna MONOLYNX_PROJECT_SLUG w śledzonym pliku .claude/settings.json.

{
  "env": {
    "MONOLYNX_PROJECT_SLUG": "sklep"
  }
}

Plik .claude/settings.json commitujesz do repozytorium. Dzięki temu cały zespół i każda sesja w tle pracują na tym samym projekcie.

Krok 5: /monolynx:setup

Komenda /monolynx:setup nie przyjmuje argumentów. Działa jak audytor: sprawdza siedem punktów, wypisuje tabelę stanu i pyta, które braki naprawić. Sama niczego nie zmienia.

> /monolynx:setup

| Punkt                         | Stan                          | Skill naprawczy                     |
| 1. Slug projektu              | OK (sklep, źródło: settings)  | -                                   |
| 2. Strona wiki toolchain      | BRAK                          | /monolynx:project-toolchain         |
| 3. LLM Wiki                   | BRAK                          | /monolynx:wiki-init                 |
| 4. Graf zależności w CI       | BRAK                          | /monolynx:create-graph-ci-script    |
| 5. Testy mutacyjne w CI       | BRAK                          | /monolynx:create-mutation-ci-script |
| 6. Flagi MONOLYNX_*           | INFO (1 jawnie ustawiona)     | -                                   |
| 7. CLI monolynx               | OK (0.4.0, zalogowane)        | -                                   |

Strona toolchain: jedyny punkt, bez którego agent nie ruszy

Agent kończy ticket dopiero po zielonym lincie i testach, więc musi wiedzieć, jak je uruchomić w Twoim projekcie. Komenda /monolynx:project-toolchain wykrywa stos technologiczny, proponuje komendy, czeka na Twoje potwierdzenie i zapisuje je jako stronę wiki o tytule Toolchain. Każde pole tej strony opisuje wpis Strona toolchain i /monolynx:setup.

# Toolchain projektu

Stack: Python 3.12, FastAPI
Uruchamianie: docker

## Lint

komenda: docker compose exec app ruff check .
kto odpala: agent

## Test

komenda: docker compose exec app python -m pytest
kto odpala: agent
testy istnieja: tak
framework: pytest

## Worktree

lint: jak wyzej
test: jak wyzej
izolacja testów: brak

Co dalej?

Projekt jest gotowy, gdy setup pokazuje OK przy slugu i stronie toolchain. Pierwszy ticket najprościej poprowadzić ręcznie, żeby zobaczyć cały obieg na własne oczy.

> /monolynx:ticket-create Dodaj eksport zamówień do CSV
> /monolynx:ticket-review SKL-1
> /monolynx:work SKL-1

Każdą z tych komend opisuje osobny wpis: ticket-create, ticket-review i work. Gdy pojedyncze tickety idą gładko, pora na sprint prowadzony pętlami. Konfigurację i pierwszy ticket na jednym przykładzie pokazuje wpis Od pustego repozytorium do zmergowanego ticketu.

Najczęstsze pytania

Słownik i następny krok

Slug projektu

krótki identyfikator projektu z małych liter, cyfr i myślników, używany w adresach i konfiguracji

Kod projektu

przedrostek kluczy ticketów, na przykład SKL w kluczu SKL-12

Rola

zestaw uprawnień członka projektu: odczyt, zapis i usuwanie osobno dla każdego modułu

Toolchain

strona wiki z komendami lintu i testów, którą czytają agenci przed zamknięciem ticketu

Skill

komenda pluginu zaczynająca się od /monolynx:, czyli zapisana procedura pracy agenta

Skill naprawczy

komenda, którą setup proponuje dla punktu ze stanem BRAK