Od suchych bulletów do publikowalnych release notes. Po polsku.
Jan to repo-native MCP agent dla polskich zespołów technicznych. Bierze typowe GitHubowe notki, diffy i surowe bullet points, a oddaje gotowe changelogi, release notesy i opisy PR, które da się wkleić bez dalszego wygładzania.
- Zamienia bezosobowe, angielskie notki z GitHuba w naturalny polski komunikat dla zespołu.
- Trzyma się faktów i szablonów artefaktu zamiast pisać "od zera" jak ogólny chat.
- Działa w MCP i można go prototypować za darmo na
NVIDIA_API_KEY.
Szybkie przejścia: Quickstart · Before / After · Core workflows · Benchmarki
Jan jest ustawiony pod jeden konkretny workflow: komunikację zmian w software delivery po polsku.
Najlepiej sprawdza się przy:
- release notesach i changelogach z GitHubowych bulletów
- opisach PR dla reviewerów
- porządkowaniu ticketów i issue do formy gotowej dla zespołu
- notatkach rolloutowych opartych o realny kontekst z repo
Nie jest pozycjonowany jako "najmądrzejszy model ogólny". Ma być lepszym narzędziem do codziennego publikowania zmian po polsku.
Wejście z typowych, bezosobowych notek GitHuba:
- Added retry handling for checkout webhook delivery.
- Improved cache invalidation for product detail pages.
- Fixed duplicate analytics events on checkout success.
| Typowy ogólny model | Jan MCP |
|---|---|
| Dodano obsługę ponownych prób dostarczenia webhooków checkoutu. Ulepszono unieważnianie pamięci podręcznej dla stron szczegółów produktu. Naprawiono zduplikowane zdarzenia analityczne po pomyślnym zakończeniu checkoutu. | Poprawiliśmy niezawodność checkoutu i uporządkowaliśmy kilka elementów wokół zakupu. System lepiej ponawia dostarczanie webhooków, strony produktów szybciej pokazują aktualne dane, a analityka po zakończonym checkoutcie nie dubluje już zdarzeń. |
Różnica nie polega na "magii modelu". Jan jest po prostu ustawiony produktowo pod polskie release notesy i changelogi dla współpracowników, a nie pod ogólną konwersację.
git clone https://github.com/pdurlej/jan-subagent.git
cd jan-subagent
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
.venv/bin/pip install -e .
export NVIDIA_API_KEY="twoj-klucz"
.venv/bin/python -m jan.jan_subagent_opencodeGotowy sample config dla klienta MCP jest w mcp_config.json.
Jeśli chcesz szybko sprawdzić runtime lokalnie:
python3 -m pytest -q
.venv/bin/python -m compileall -q jan
.venv/bin/python -m jan.jan_subagent_opencodeJan działa na Bieliku przez hosted endpointy NVIDIA NIM. Do prototypowania wystarczy darmowy dostęp z NVIDIA Developer Program.
- Wejdź na build.nvidia.com.
- Otwórz dowolny model lub endpoint i kliknij
Get API Key. - Zaloguj się albo załóż konto w NVIDIA Developer Program.
- Skopiuj klucz i ustaw lokalnie jako
NVIDIA_API_KEY.
Oficjalne źródła:
Przykładowy plik środowiskowy jest w .env.example.
Jan ma dziś najwięcej sensu jako zestaw nazwanych workflowów, a nie zbiór ogólnych promptów.
compose_release_notes(
raw_notes="""
- Added retry handling for checkout webhook delivery.
- Improved cache invalidation for product detail pages.
- Fixed duplicate analytics events on checkout success.
""",
audience="customer",
)write_pr_description(
raw_notes="""
checkout webhook retries
product page cache invalidation
analytics dedupe on success
""",
audience="reviewer",
)rewrite_issue(
raw_notes="""
klient zgłasza, że po checkoutcie czasem są zdublowane eventy,
trudno to odtworzyć, wygląda na problem po stronie success callback
""",
audience="internal",
response_mode="review",
)write_rollout_note(
raw_notes="Rollout checkout webhook retry logic behind a feature flag.",
audience="internal",
response_mode="review",
)response_mode="final" zwraca gotowy tekst do wklejenia. response_mode="review" zwraca JSON z final_text, source_trace i validator_report.
Jan najlepiej pasuje do:
- polskich zespołów produktowo-inżynieryjnych
- leadów i senior engineerów piszących opisy PR
- release managerów składających changelog lub release notes
- zespołów, które chcą spójnej terminologii i szablonów bez ręcznego promptowania
Mniej sensu ma wtedy, gdy potrzebujesz ogólnego asystenta do wszystkiego albo miękkiej, relacyjnej komunikacji typu support reply czy statusowy mail.
| Sytuacja | Lepszy wybór | Dlaczego |
|---|---|---|
| Release notes z suchych bulletów i commitów | Jan | Ma workflow, audience packs, policy pack i output gotowy do wklejenia. |
| Opis PR zgodny z template'em zespołu | Jan | Lepiej trzyma sekcje, fakty i terminologię z repo. |
| Porządkowanie issue pod zespół techniczny | Jan | Pracuje na named workflow, nie na improwizowanym promptcie. |
| Otwarta burza mózgów albo swobodny writing assistant | Ogólny model | Tu specjalizacja Jana daje mniej przewagi niż szeroka inteligencja ogólna. |
Obecny pilot po refactorze paste-ready:
GPT-5.4:96.5%Jan:94.0%raw Bielik:93.1%
Najważniejszy sygnał: Jan nie wygrywa "większą inteligencją ogólną". Wygrywa tym, że daje lepszy workflow i bardziej publikowalny polski output niż surowy model.
Dalsze szczegóły:
Jan potrafi pracować na więcej niż samym raw_notes.
jan.ymltrzyma glossary,do_not_translate, audience packs i validation policy.- Workflow może korzystać z local git, GitHuba i Jiry, jeśli są dostępne kredensiale.
reviewmode dodaje traceability i raport walidacyjny zamiast zgadywania.
Najważniejsze envy:
NVIDIA_API_KEYGITHUB_TOKENGITHUB_REPOSITORYJIRA_BASE_URLJIRA_EMAILJIRA_API_TOKENJAN_POLICY_FILE
Zobacz:
Jeśli chcesz pracować nad repo, benchmarkami albo planowaniem kolejnych pivotów: