sobota, 23 maja 2026

Testy Skilla do analizy część trzecia

Część trzecia.

Tym razem poszedłem w kolejny kontekst i na tym skończyłem. Rozpocząłem process level, Klaudiusz nie próżnował, zbadał heurystki, poprzez pytania naprowadzające oraz przykłady z kontekstu, na nieszczęście nie widzę tych rzeczy w wynikach po tym punkcie. Cóż nie wszystko da się przewidzieć.

Zostały wyznaczone rodzaje domen i zgadza się to,  częściowo z tym co z kolegami wyznaczyliśmy kiedyś, za każdym razem Klaudiusz pytał się czy wybór jest poprawny, i czy chce go skorygować jeszcze, zapewne jak bym powiedział, że core domain jest inna niż podpowiadał to bym musiał się tłumaczyć dlaczego, ciekawe czy by to zaakceptował? Można by taki test przeprowadzić.

Pokrótce domeny:

  • Rejestracja - supporting
  • Generacja grup strartowych - core
  • Biuro zawodów/weryfikacja - supporting
  • Start Zawodników - supporting
  • Pomiar czasu - generic
  • Zakończenie/wyniki - supporting
  • Knfiguracja/regulamin - generic
Co do nie których domen mam wątpliwości, ale to się jeszcze dopracuje w następnych wersjach.

Wyznaczył również Pivotal Events 

Nie które miał już zaznaczone na materiałach wsadowych, inne wyciągnął z pytań.
Są dwa które nie były wcześniej uwzględnione, lista wszystkich poniżej, wytłumaczone w pliku wynikowym, link na końcu:
  • Opłacono uczestnictwo,
  • Wygenerowano ostateczne grupy startowe,
  • Wydano pakiet startowy,
  • Zamknięto zapisy na dystans,
  • Wystartowano grupę,
  • Przekroczono metę / zakończono udział
W tej części zmieniły się dane dotyczące poprzedniego punktu czyli Big Picture, na samym końcu pliku analizy znajduje się to co zostało zmienione i dlaczego.

Co dalej?

Dalej Design Level przynajmniej jeden kontekst i przeskakuje do kolejnej wersji

Linki:

Skill analizy kolejna analiza

Po uruchomieniu wersji drugiej skilla i przejściu przez kontekst rejestracji jestem bardziej zadowolony niż na początku. Ale wynikł problem wybrałem tryb numer 1, dla przypomnienia, mam dostępne cztery:

## Tryb 1 — Agentowy (Claude orkiestruje)

Claude dzieli domenę na konteksty i przydziela je sub-agentom.

### Tryb 2 — Ekspercki (użytkownik jako ekspert domenowy) ← domyślny

Sub-agent zadaje pytania, użytkownik odpowiada.Claude śledzi spójność między odpowiedziami i sygnalizuje konflikty.

### Tryb 3 — Mixed (współpraca)

Część kontekstów trafia do sub-agentów, część użytkownik prowadzi sam.

### Tryb 4 — Użytkownik jako orkiestrator

Użytkownik decyduje co i kiedy badać, sub-agenci dostają konteksty od użytkownika.

Claude reaguje na pytania i pilnuje spójności na żądanie.

Agentowy z definicji miał działać sam, a ja miałem tylko dostać wynik, ale to claude zadawał pytania a ja odpowiadałem i tak dziesięć pytań pozwoliło pierwszy kontekst "rozpykać".

Dalsza część testów

Ściągnął sobie dane z cache i odkrył, że zrobiliśmy pierwszy etap, to idziemy dalej.

Odpowiedz prawidłowa, nie spodziewałem się.

Faza 1 — Big Picture: Generacja grup startowych
  
 Wznawiamy analizę. Kontekst z pamięci:
 - Tryb: Agentowy (Claude orkiestruje)
 - Zakres: Big Picture bazowy (bez read modeli)
 - Wejście z poprzedniej fazy: pivotal event "Opłacono uczestnictwo" + przypisany numer startowy + otwarty H1 (niedopłata)
Skończył w odpowiednim miejscu, wchodzimy w nowy kontekst zaczynający się od pivotal 

Będę wrzucał odpowiedzi Klaudiusza, co jakiś czas. Całość i tak pójdzie na repo.

 Dodatkowe pliki (linki na końcu) procesu Klaudiusza:

 - project_marathon_analiza.md — stan analizy: co ukończono, wnioski z Rejestracji, następny krok, otwarty hotspot H1
 - reference_skill_deepanalysis.md — gdzie jest skill i jak go ładować przy wznowieniu

Klaudiusz mówi:

 "Indeks tych plików jest w MEMORY.md w tym samym katalogu — to jest ładowane automatycznie przy każdym starcie sesji, dzięki czemu wiedziałem od razu gdzie
  skończyliśmy."

Spryciarz.

Katalog memory wrzucę w repo.

To jedziemy z kolejnym kontekstem.

Tym razem pytań było 11, ale dodał kilka zdarzeń których nie było i są sensowne.

Czy będę poprawiał wersje 2? nie, ta wersja jest tylko testowa nie do rozbudowy działam z tym co mam i sprawdzam kolejne kroki. 

A wcześniej jeszcze słów kilka o procesie tworzenia, tak właściwie to Klaudiusz na podstawie moich wytycznych tworzy tego skilla, teraz mam wersje trzecią ale ona wejdzie na testy gdy wyczerpie się wersja 2. Klaudiusz podpowiedział, że plik ze skillem nie może być większy niż 500 linii, jako że wersja 2 już dobija do tego. Wersja 3 będzie mocno zredukowana, tam pomysł mam zupełnie inny ale na razie testy wersji drugiej.

Zastanawiam się co wyjdzie z tego, pomysły ładuje już w rozwiązanie trzecie, ono jeszcze nie przetestowane, a już puchnie. Będzie do tego inne repo, osobne, dane wejściowe będą te same, chce to potem porównać. Ostatecznie trzeba będzie z tego kod wygenerować, ale do tego jeszcze dłuuuga droga. Jestem teraz na ponownym przejściu przez Big Picture i uzupełnieniu go, na trzecim kontekście, przed ostatnim z tego co pamiętam, już mniejszym od pozostałych.

Linki do tej wersji:




środa, 20 maja 2026

Maraton powrót

 W 2019 roku zakończyłem przygodę z maratonem rowerowym na wersji najbardziej zaawansowanej pod kątem ilości funkcji. W 2021 zrodził się pomysł stworzenia Event Stromingu w kontekście maratonu i taki powstał. Teraz w roku 2026 mam kolejną wizję, mam ES, mam jeszcze wiedzę na temat domeny, mam Klaudiusza, może czas zrobić nowy maraton? przy okazji poćwiczyć z LLM-em?

Nie lubię działać bez planu. Jaki jest plan?

  • Przygotować dane do wytworzenia systemu, który ma na celu obsługę maratonu rowerowego,
  • Przygotować skile które pozwolą w odpowiedni sposób przejść przez analizę,
  • Przygotować skille z odpowiednią architekturą i implementacją rozwiązania,
  • Pociąć ES na odpowiednie kawałki zdatne do przetrawienia przez Klaudiusza,
  • Implementować po kawałku, rozwiązania
Celem jest poprawienie mojego warsztatu w kierunku lepszego posługiwania się LLMem, odświeżenie informacji o Event Stormingu i o całym procesie wytwarzania w dobie generatywnej sztucznej inteligencji. Tak więc praca ze wsparciem.

Na początek 

Analiza z razem z kolegą, podrzucę Kladiuszowi kontekst w postaci event stormingu i opis "słowno-muzyczny", zobaczę co wygeneruje i jakie rozwiązania zaproponuje.

Będzie to też rozwinięcie poprzedniego posta, który wyznaczał bounded contexty i pivotal eventy.
No to lecimy od lewej do prawej.
  • Rejestracja,
  • Tworzenie grup,
  • Pomiar czasu,
  • Zakończenie maratonu
Wydzieliłbym te cztery główne konteksty

Rejestracja

Drogi (coraz droższy) Klaudiuszu działaj.

No to może by tak zainstalować na Kubuntu? Klaudiusz pomóż,

curl -fsSL https://claude.ai/install.sh | bash

To wystarczy bez roota

To teraz zaczynamy.

Napoczątek napisałem sobie skilla do analizy inspirowanego event stormingiem i skillem grille-me.


Spróbuje pogłębionej analizy tym skilem zobaczę co wyjdzie. Skill jest tak napisany żeby szedł od ogółu do szczegółu i posiłkował się dokumentacja czy też istniejącym event stromingiem, dopytywał się o szczegóły sądzę, że będzie trzeba go doszlifować ale na początek test numer 1.

Plan jednak się nie powiódł, dlaczego? Z powodu niedostatecznie dobrze zrobionego skilla do analizy i tym o to sposobem post o wytworzeniu aplikacji za pomocą LLM-a zmienił się na post o tematyce wytwarzania skilla do analizy.

Skill oprócz event stormingu, implementacji pewnych reguł z nie go, zawiera jeszcze inne opcje, które nie będą na razie rozwijane. Liczę na podejście ewolucyjne, plan jest taki że na bazie wsadu w postaci pocięte ES-a będę testował kolejne wersje skilla aż dostane satysfakcjonujące rozwiązanie.

Skill deep-analisis wersja 1

Krótki opis, bo sam skill znajduje się w repo, ale nim do tego dojdę to słowo wstępu moje testy poszczególnych wersji skilli będą odbywać się na danych wejściowych w postaci pociętego event stromingu process level i trochę design level. Chce dostać na wyjściu pliki z satysfakcjonującą mnie analizą która będzie podstawą dalszych kroków.

Opis Skilla - bardzo ogólny

Skill jest prosty w swej formie i wynik jak się okazało też nie był najlepszy, żadnych pytań, w pięć minut odpowiedz.


Test Skilla

Wykonał dwa kroki ES BP i PL na bazie tego co było w wsadzie,  ale wynik był mało satysfakcjonujący

Sam skill dane wejściowe oraz wynik będzie na repo w githubie.

Skill deep-analisis wersja 2


Przerobiłem trochę skilla, dodałem tam więcej rzeczy w pierwszym i drugim etapie czyli w big picrure i process level, reszta na razie nie jest istotna będzie dobry wynik na tych dwóch przejdę dalej.

Porównanie skilli jest tutaj -> porównanie 

Opis Skilla - ogólny

Tu jest bardziej rozbudowana ścieżka, w tym skillu Claude doprecyzowuje poprzez pytania, zbiera informacje. Są wbudowane tryby działania:
  • Tryb 1 — Agentowy (Claude orkiestruje)
  • Tryb 2 — Ekspercki (użytkownik jako ekspert domenowy)
  • Tryb 3 — Mixed (współpraca)
  • Tryb 4 — Użytkownik jako orkiestrator
Jest większa interakcja pomiędzy fazami

Test Skilla

Było więcej wstępnych pytań, wybrałem fazę 1 i musiałem odpowiedzieć na 10 pytań tylko z jednego kontekstu rejestracji co trwało dosyć długo, musiałem się zastanawiać na odpowiedziami LLM wykrył brakujące zdarzenia i wnioski które nie zostały nigdy opisane a mogły bo są istotne.

Wynik też jest obiecujący i ma znacznie większa wartość niż ten ze skilla wersji 1. Ale że jest już późno to na dziś koniec, jutro dalszy test, a na horyzoncie majaczy kolejna wersja Skilla jeszcze bardziej złożona. Cóż musi poczekać

Linki:












Wersja 3.4

 Nowa wersja, mnóstwo zmian. Na horyzoncie pojawił się Fable (na chwilę) ale w ramach testów dałem mu do przejrzenia orkiestratora i pliki z...