--- title: "Pierwszy projekt w Monolynx: od konta do /monolynx:setup" description: "Od zera do pierwszego ticketu: konto, projekt w panelu, role, połączenie agenta, slug w repozytorium i checklista /monolynx:setup ze stroną toolchain." url: "https://monolynx.com/blog/pierwszy-projekt-w-monolynx" lang: "pl" author: "Zespół Monolynx" published: "2026-10-08T08:35:49.585264+00:00" modified: "2026-10-09T18:11:32.713262+00:00" last_verified: "2026-10-08" tags: ["konfiguracja", "plugin", "claude-code", "agenci-ai", "scrum"] translations: [] reading_time_minutes: 10 word_count: 1849 --- > [!TLDR] > - Start to pięć kroków: konto, projekt w panelu, połączenie agenta, slug w repozytorium i komenda `/monolynx:setup`. > - Projekt ma trzy pola: nazwę, kod i slug. Kod staje się przedrostkiem kluczy ticketów, slug łączy repozytorium z projektem. > - Agent pracuje na Twoim koncie, więc o tym, co może, decyduje Twoja rola w projekcie. > - `/monolynx:setup` sprawdza siedem punktów konfiguracji, pokazuje stan każdego i niczego nie zmienia bez Twojej zgody. > - Przed pierwszym ticketem wymagane są dwa punkty: slug projektu i strona wiki `toolchain` z komendami lintu i testów. ## 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. **Kroki** 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](https://monolynx.com/blog/polaczenie-z-monolynx-mcp-claude-code-chatgpt). 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ę. **Od konta do pierwszego ticketu** Użytkownik loguje się do panelu i tworzy projekt, potem raz podłącza agenta przez MCP i instaluje plugin. W repozytorium zapisuje slug projektu, a komenda setup sprawdza konfigurację i kieruje do skilli naprawczych: project-toolchain dla komend lintu i testów oraz wiki-init dla metody LLM Wiki. Po tym projekt jest gotowy na pierwszy ticket. ```mermaid 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 ``` **Statystyki** - **3** - pola formularza nowego projektu - **7** - punktów checklisty `/monolynx:setup` - **2** - punkty wymagane przed pierwszym ticketem: slug projektu i strona `toolchain` ## 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. **Porównanie** | Pole | Do czego służy | Przykład | | --- | --- | --- | | Nazwa projektu | nazwa widoczna w panelu | Sklep internetowy | | Kod projektu | przedrostek kluczy ticketów | `SKL`, czyli tickety `SKL-1`, `SKL-2` | | Slug | identyfikator w adresach, komendach i konfiguracji | `sklep` | > [!NOTE] > Slug składa się z małych liter, cyfr i myślników. Zapamiętaj go: to jedyna wartość, którą przenosisz z panelu do repozytorium. 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. **Porównanie** | Moduł | Owner | Admin | Member | | --- | --- | --- | --- | | Scrum: tickety i sprinty | odczyt, zapis, usuwanie | odczyt, zapis, usuwanie | odczyt, zapis | | Wiki | odczyt, zapis, usuwanie | odczyt, zapis, usuwanie | odczyt, zapis | | Błędy 500, monitoring, heartbeat | pełny dostęp | pełny dostęp | odczyt | | Graf kodu | pełny dostęp | pełny dostęp | odczyt | | Ustawienia i członkowie | pełny dostęp | odczyt, zapis | odczyt | > [!IMPORTANT] > Rola `member` wystarcza do zwykłej pracy nad ticketami, ale nie do wszystkiego, co robią komendy pluginu. Włączenie metody LLM Wiki wymaga prawa zapisu ustawień, a zamknięcie sprintu przez `sprint-end` usuwa strony logów, czyli wymaga prawa usuwania w wiki. Konto, na którym pracują agenci, powinno mieć rolę `admin` albo własną rolę z tymi uprawnieniami. > [!NOTE] > Komendę `/monolynx:wiki-init` i inne zapisy do wiki uruchamiaj z brancha głównego albo z brancha sprintu. Na branchu roboczym komenda zapyta o zgodę, bo wiki ma opisywać kod po merge. **Publikowanie na blogu to osobne uprawnienie** Publikacja wpisu na publicznym blogu nie wynika z żadnej roli w projekcie, nawet z roli właściciela. Jest uprawnieniem konta, które nadaje administrator całej instancji. Bez niego agent może pisać szkice jako prywatne strony wiki, ale ich nie opublikuje. ## 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`. ```text title="Sesja Claude Code" /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](https://monolynx.com/blog/monolynx-cli-dla-deweloperow-i-agentow). ## 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`. ```json title=".claude/settings.json" { "env": { "MONOLYNX_PROJECT_SLUG": "sklep" } } ``` **Porównanie** | Kolejność | Źródło sluga | Kiedy używane | | --- | --- | --- | | 1 | slug podany wprost w poleceniu | zawsze wygrywa | | 2 | `MONOLYNX_PROJECT_SLUG` w środowisku klienta | zwykła praca w repozytorium | | 3 | pytanie do użytkownika | gdy nie ma żadnego z powyższych | > [!WARNING] > Sam plik `.env` nie przekazuje zmiennych do Claude Code. Slug wpisany tylko tam nie zadziała. Komendy pluginu nie zgadują projektu: gdy nie znają sluga, pytają. 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. **Wynik /monolynx:setup w nowym projekcie** ```console > /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) | - | ``` **Porównanie** | Punkt | Co sprawdza | Czy wymagany | | --- | --- | --- | | Slug projektu | czy komendy wiedzą, na którym projekcie pracują | tak | | Strona `toolchain` | czy projekt ma zapisane komendy lintu i testów | tak, przed pierwszym ticketem | | LLM Wiki | czy wiki rośnie razem z projektem | zalecany | | Graf zależności w CI | czy graf kodu odświeża się po zmianach | opcjonalny | | Testy mutacyjne w CI | czy jakość testów jest mierzona | opcjonalny | | Flagi `MONOLYNX_*` | które zgody na autonomię są ustawione i gdzie | informacja | | CLI `monolynx` | czy jest zainstalowane, zalogowane i aktualne | opcjonalny | > [!NOTE] > Flagi autonomii, takie jak zgoda na commit albo push bez pytania, `setup` tylko raportuje. Nigdy ich nie włącza i nie proponuje włączenia, bo to decyzja człowieka. ### 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](https://monolynx.com/blog/strona-toolchain-i-monolynx-setup). ```markdown title="Strona wiki Toolchain (fragment)" # 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 oznaczają sekcje strony toolchain** | Sekcja | Zawartość | | --- | --- | | Lint | komenda lintu i informacja, kto ją uruchamia: agent czy człowiek | | Test | komenda testów, framework, informacja, czy testy istnieją, oraz czy pełny przebieg idzie lokalnie, czy w CI | | Worktree | wariant komend dla sesji pracującej w osobnej kopii repozytorium oraz informacja, czy równoległe przebiegi testów są od siebie odizolowane | | TDD | czy agenci mają pisać test przed kodem | | Mutacje | narzędzie do testów mutacyjnych i jego komendy, albo wpis, że go nie ma | | Uwagi | reguły repozytorium zapisane zwykłym tekstem, na przykład "tylko przez Docker" | Sekcja Worktree ma znaczenie dopiero w sprincie z sesjami w tle, gdzie każdy ticket pracuje w osobnym katalogu. Przy pracy nad jednym ticketem wystarczą sekcje Lint i Test. > [!TIP] > Projekt bez testów też przejdzie ten krok. Strona zapisze wtedy, że testów nie ma, a agent nie będzie udawał, że je uruchomił. ## 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. **Pierwszy ticket** ```console > /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](https://monolynx.com/blog/jak-dziala-monolynx-ticket-create), [ticket-review](https://monolynx.com/blog/jak-dziala-monolynx-ticket-review) i [work](https://monolynx.com/blog/jak-dziala-monolynx-work). Gdy pojedyncze tickety idą gładko, pora na [sprint prowadzony pętlami](https://monolynx.com/blog/sprint-z-monolynx-krok-po-kroku). Konfigurację i pierwszy ticket na jednym przykładzie pokazuje wpis [Od pustego repozytorium do zmergowanego ticketu](https://monolynx.com/blog/od-repozytorium-do-zmergowanego-ticketu). ## Najczęstsze pytania **FAQ** ### Czy mogę zmienić slug projektu po utworzeniu? Traktuj slug jako stały. Jest wpisany w adresy panelu, w konfigurację repozytorium i w nazwy sesji w tle, więc jego zmiana oznacza poprawki w każdym z tych miejsc. ### Czy jedno repozytorium może pracować z kilkoma projektami? Zmienna w `.claude/settings.json` wskazuje jeden projekt domyślny. Inny projekt wskażesz, podając jego slug wprost w poleceniu, bo slug z polecenia ma pierwszeństwo. ### Czy setup trzeba uruchamiać przed każdym sprintem? Nie. Uruchom go przy pierwszym starcie i wtedy, gdy podejrzewasz brak w konfiguracji, na przykład po zmianie stosu technologicznego albo gdy sesja w tle odmawia startu. ### Co, jeśli projekt nie używa Dockera? Strona `toolchain` zapisuje dowolne komendy. Projekt uruchamiany lokalnie dostaje komendy lokalne, a sekcja Worktree odsyła wtedy do sekcji Lint i Test. ### Czy agent może dodać członków do projektu? Tylko wtedy, gdy Twoja rola na to pozwala. Agent działa z Twoimi uprawnieniami, a zaproszenie nowej osoby wymaga prawa zapisu w module członków. ## Słownik i następny krok **Słownik** - **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 **Wezwanie do działania** Projekt skonfigurowany? Zobacz, jak wygląda w nim tablica i sprint. [Zobacz moduł Scrum w Monolynx](https://monolynx.com/features/scrum)