Wersja 3.1 wnioski

Testy

Zacznę od testów, zdałem sobie sprawę, że nie jestem w stanie ocenić rezultatów w sposób odpowiedni. Do tej pory to było powiązane z moim doświadczeniem w tym kontekście, ale to za mało. Każda sesja generuje sporą ilość materiałów, potrzeba mi narzędzia do porównywania wyników testu.

Aktualnie testuje tryb agentowy, automatyczny z każdym razem wygląda on coraz lepiej, nie ma pomijania faz, mieszania, LLM sam podpowiada opcje do wyboru i są one właściwe - powiązane z kontekstem. Nie trzeba pisać, ale czasami trzeba doprecyzować bo nie trafia z podpowiedzą. Na razie testy opierają się na big picture i process level i na pełnych materiałach, które mam.

Takie testy chce jeszcze kilka razy przeprowadzić, żebym mieć więcej materiałów porównawczych, potem chce  przejść pełny proces z design level w trybie automatycznym - agentowym. By następnie się wrócić do dwóch pierwszych ale z ograniczonymi materiałami.

Wnioski

Tak jak wspominałem będę budował razem z Klaudiuszem instrukcje testowania wyników, ale już teraz widzę że jednym z problemów jest to że LLM potrzebuje bardzo dokładnych instrukcji co ma zrobić, jeżeli nie będą dokładne to ogólny zarys zadania będzie dobrze zrobiony ale reszta, która nie jest dobrze wytłumaczona, czyli tło będzie wymyślane na bieżąco. W moim przypadku widać do w rozrastarającyh się plikach skilla, zadaje coś Klaudiuszowi on robi to dobrze, weryfikuje to co piszę ale za każdym razem dodaje dodatkową "panierkę".

Plik z instrukcjami porównywania V3.1/deep-analysis-test-comparator.md

Zapomniałem o ważnej rzeczy Klaudiusz ma jeszcze pamięć swoją schowaną w katalogu .claude/projects/, pamięć poprzednich sesji, powinienem ją usuwać za każdym razem albo wrzucić w skilla info że by sam kasował.

Wersja 3.1

 Wersja 3.1

Zmiany względem poprzedniej wersji:

• dodanie kolejnego pliku, który przejmie od orkiestratora obsługę badania pokrycia materiałami poszczególnych faz ES,
• dane wsadowe mają teraz swój katalog wpisany w orkiestratora,
• nastąpiła zmiana i wymuszenie wyboru trybu pracy, a nie zawsze wybieranie domyślnego
• został dodany log - orkiestrator ma zapisywać każdy krok który wykonuje w formacie data, godzina, krótki opis, dwa trzy słowa,

Testy

Testy będą takie jak poprzednio ale tym razem postaram się uruchomić test w trybie automatycznym, jeżeli się to uda kolejne testy będą prowadzone w tym trybie. Później przejdę do kolejnego trybu, tu jest trochę trudniej z ustaleniem prawidłowego wyniku, muszę stworzyć taki wzór danych wejściowych, tekstowych, które mogły być uzupełnieniem materiałów z event stromingu.

Nim jednak przejdę do trybu drugiego czyli Eksperckiego to chce sprawdzić jak się zachowa ten skill gdy dane będą mniejsze.

Sama sekwencja testów czyli takie przypadki testowe, będą tworzone na bieżąco, tu również mam kilka pomysłów które można by realizować.

Wyniki

Rezultaty jak i sam przebieg testu nie będę już wrzucał w formie posta, a w repozytorium z wynikami każda wersja będzie miała swój katalog z testami, wnioskami czy też uwagami. W poście będą kolejne zmiany jakie będą w następnych wersjach, ogólne uwagi i być może jakieś wnioski. Tym razem nie będę się rozpisywał co i jak zostało podane i wrzucone jako wsad, chce żeby to było przy wynikach testowania danej wersji. Również będę dążył do tego żeby materiały wsadowe były takie same między różnymi wersjami i przypadkami testowymi.

Wnioski

W porównaniu z pierwszą czy drugą wersja trzecia jest znacznie bardziej rozbudowa, w głowie zaczyna mi się powoli rysować obraz tego jak to testować i poprawiać, ale nim wizja się wyklaruje minie jeszcze trochę czasu. Sądzę że wersja 3.1 będzie bardziej testowana niż poprzednia i dłużej będę zwlekał z przejściem do wersji kolejnej, chce w końcu zdobyć pewną ścieżkę do testowania i weryfikacji wyników, wielokrotnie uruchomić te skille i sprawdzić na dłuższej "ścieżce" jak się to zachowa.

Główne repo projektu będą tam wrzucane kolejne wersje skilla a rezultaty usuwane i przenoszone do repozytorium wynikowego, tu powstanie struktura do przechowywania wyników i plików z danej wersji, mam nadzieję że zachowam porządek.

Skill do analizy wersja trzecia

wersja druga dobijała do limitu 500 linii na plik, postanowiłem ją podzielić. Dodatkowo rozdzielić zadania, tak powstał orkiestrator i kolejne skille odpowiedzialne za różne zadania. Czyli wersja numer 3.

Skill się rozrósł, jest trochę większy:

• deep-analysis-orchestrator,
• deep-analysis-data-prep
• deep-analysis-big-picture
• deep-analysis-process-level
• deep-analysis-design-level
• deep-analysis-specialist
• deep-analysis-mermaid-generator
• deep-analysis-llm-blueprint
• phase-1-template
• phase-2-template
• phase-3-template

W czasie testów wersji drugiej, miałem kolejne pomysły i tak się to rozrastało, w końcu razem z Klaudiuszem wysmarowaliśmy jedenaście plików, z czego faktycznie gotowe do testów są cztery pierwsze. W tej fazie, wersji zależy mi na przetestowaniu orkiestratora i sprawdzeniu czy działa zgodnie z założeniami.

Założenia

Zastanawiałem się nad tym jaki powinien być ten skill kilka rzeczy mi się nasuneło, będzie ewoluowało w trakcie testów wersji trzeciej mogę już napisać kilka podstawowych celów.

• Skill musi być deterministyczny - powtarzalny nie zależnie od domeny, 
• Musi wykonywać kroki w zależności od dostępnych materiałów
• Musi współpracować z użytkownikiem i niczego nie narzucać, być współpracownikiem, a nie zarządcą.
• Człowiek ma moc decyzyjną ale LLM na podstawie reguł ze skilla może sugerować rozwiązania oraz ostrzegać przed konsekwencjami,
• Wyniki muszą być czytelne dla LLM ale też dla człowieka, na różnych stanowiskach,
• Nie może być tak że sam skill będzie pożerał tokeny
• Skill musi być odporny na awarie, czynniki zewnętrzne, które mogą przerwać proces

Na razie tyle, albo aż tyle, spełnienie wszystkich może być trudne ale jest do czego dążyć.

Szczegóły

Orkiestartor nie bierze udziału w analizie jest "nadzorcą" modułów, które mają wykonywać poszczególne kroki analizy.

W aktualnej wersji orkiestrator rozpoczyna proces od zbadania czy jest to kontynuacja czy nowa sesja

w katalogu state jest zapisywany stan sessji.

Nadzorca zbiera podstawowe dane:

• Cel sesji,
• stan materiałów wsadowych - na których ma się oprzeć analiza,
• krótki opis kontekstu,
• poziom szczegółowości event stromingu

Tu jest istotna uwaga, system (nazwę to w ten sposób żeby było łatwiej mi opisywać jego zachowanie, będzie to tylko określenie w kontekście tego posta) będzie sugerował różne tryby i rozwiązania ale i tak człowiek, operator, może zadecydować inaczej i pominąć pewne kroki.

Np. Jeżeli nie mamy materiałów wsadowych system zasugeruje rozpocząć od big picture ale operator może zadecydować inaczej ale w tym momencie LLM powinien ostrzec przed konsekwencjami jeżeli nie znamy procesu rezultat może być nie odpowiedni.

Jeżeli mamy materiały zostaną one zapisane w katalogu state/inputs będą one przetworzone i ich format zostanie zamieniony w taki sposób żeby nie trzeba było za każdym razem marnować tokenów na wczytywanie kontekstu.

Po załadowaniu materiałów następuje faza ich badania w celu wykrycia z na które fazy event stromingu są zrealizowane lub też ile materiału przypada na poszczególne części. Kryteria:

• Big Picture   [X%] — kryteria: aktorzy, zdarzenia domenowe, granice systemu,  liczba zdarzeń względem złożoności
• Process Level [X%] — kryteria: przepływy, reguły biznesowe, wyjątki, hot spoty
• Design Level  [X%] — kryteria: agregaty, encje, kontrakty, bounded contexts

Wynik zapisany w state/inputs/processed/

Przed każdym krokiem analizy orkiestrator przygotowuje dane dla agenta w odpowiednim formacie.

Tryby pracy, zgodne z poprzednią wersją:

### 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.

Obowiązuje coś takiego jak pętla zwrotna jeżeli analiza danej fazy będzie miała wpływ na poprzednie fazy będzie to uwzględnione w rezultacie fazy poprzedniej.

Testy

Zastanawiałem się nad tymi testami, środowiskiem testowym. Na początek będzie osobne repo na wersję trzecią, zostaną stworzone logi które ręcznie będę ściągał, posłużą do śledzenia tego co robi model.

Ciekawi mnie to czy dane wynikowe nie będą wykorzystywane przez Klaudiusza do poprawienia wyników więc trzeba będzie wyniki trzymać na osobnym repo. 

Co będę sprawdzał w tej wersji? Skupie się bardziej na orkiestratorze i jego pracy.

Trzeba będzie wrócić do tego co robiłem dziesięć czy więcej lat temu czyli do pisania scenariuszy testowych, historia zatacza koło, znowu jestem testerem ;-).

Ale takie use casy nieuniknione są, tylko nie mogę być pewny w tym wypadku czy dostanę za każdym razem to samo ale do tego będę dążył bo to jedno z założeń. I tak nie ma co ukrywać Klaudiusz będzie mi pomagać testować, zresztą sam podsuwa mi pomysły co robić.

Sądze że trzeba będzie przejść przez proces BIG Picrure i Procces Level uzyskując najlepszy wynik zbliżony do oczekiwanego, stworzyć go jako wzorcowy i porównywać wyniki kolejnych prób do niego, jeżeli próby będą takie same albo lepsze wtedy taka próba staje się wzorcem.

Docelowo repo z wynikami oraz plikami wynikowymi z każdej sesji będzie osobne żeby zabezpieczyć się przed fałszowaniem danych przez samego LLM.

Ale na razie testy orkiestratora i pracy z poszczególnymi częściami.

Wyniki

W między czasie przeprowadziłem pierwszy test tu jest repo wyniki oraz repo ze skillem w wersji 3. Mam już poprawki i powoli przygotowuje wersje 3.1. Będzie dodatkowy plik który będzie służył tylko do oceny jakości materiałów, dzięki temu sam orkiestrator będzie nie co lżejszy. Muszę też poprawić obsługę trybów oraz ustalić komendy które będą trigerować rozpoczęcie kolejnego etapu. Co do danych testowych to mam event strorming na różnym etapie od Big Picture do Desing level więc mogę się bawić różnymi materiałami wsadowymi.

Testy będą długie już mogę stwierdzić że, core domain został wybrany inaczej niż w wersji drugiej ale nie jestem pewny czy to nie przez moje odpowiedzi. Dlatego też zależy mi na poprawnym uruchomieniu trybu automatycznego dzięki któ©emu będzie można lepiej sprawdzić wyniki.

......

skill do analizy ver 3 - test1

Uruchomienie Claude Code

Instrukcja na start:

w katalodu skill w tym projekcie jest plik  deep-analysis-orchestrator załaduj ten plik jako skill

Odpowiedz LLM:

Pytania startowe — Deep Analysis Orchestrator
  
 1. Co jest przedmiotem analizy?
 System, proces, decyzja architektoniczna — co analizujemy?

 2. Jaki jest cel?
 Zrozumienie domeny, planowanie implementacji, decyzja techniczna, coś innego?

 3. Opisz system w 2–3 zdaniach
 Co robi i z czym się łączy?

 4. Czy masz materiały wejściowe?
 Event Storming, diagramy, notatki, screenshoty — cokolwiek co już istnieje?

 5. Poziom szczegółowości
 - Tylko Big Picture
 - Big Picture + Process Level
 - Pełna analiza (Big Picture → Process Level → Design Level)

Ponowne uruchomienie, przez przerwanie sesji, a nie przez komunikacje z LLM.

komenda na start:

w katalogu skill jest plik deep-analysis-orchestrator załaduj go i postępuj według instrukcji w nim zawartych

Odpowiedz modelu:

Brak sesji — startujemy od zera. Zanim uruchomię pierwszy sub-skill, potrzebuję odpowiedzi na pytania orientacyjne (pomijam te, które da się wywnioskować
 z kontekstu):

 ---
 1. Co jest przedmiotem analizy?
 System, proces, decyzja architektoniczna?

 2. Jaki jest cel analizy?
 Zrozumienie domeny, planowanie implementacji, decyzja architektoniczna, coś innego?

 3. Opisz system w 2–3 zdaniach — co robi i z czym się łączy?
 (Na tej podstawie ocenię złożoność i zaproponuję odpowiedni tryb pracy.)

 4. Czy masz już jakieś materiały wejściowe?
 Event Storming, diagramy, dokumentacja, screenshoty — cokolwiek co opisuje domenę.

 5. Jaki poziom szczegółowości Cię interesuje?
 - Tylko Big Picture (aktorzy, zdarzenia, granice)
 - Do Process Level (przepływy, reguły biznesowe, bounded contexts)
 - Pełna analiza (+ Design Level: agregaty, kontrakty, wzorce)

Zostało wykonane to co jest wpisane w skill orkiestratora. Nasuwa mi się już pierwszy wniosek, materiały wejściowe powinny być wpisane w odpowiedni katalog wpisany w strukturę pliku z orkiestratorem.

Kolejna instrukcja:

Przedmiotem analizy jest system obsługujący maraton rowerowy, celem jest przegląd procesu oraz uzupełnienie brakujących części, materiały wejściowe są w   
 katalogu Dane_wejsciowe, chce przejść do process level

Tym razem wyniki w formie streszczenia

Przeanalizował materiały wejściowe, muszę uważać co piszę, chciałem żeby LLM przeszedł do Proccess level ale przez big piscture, muszę być bardziej precyzyjny. 

Tu jest kolejny pomysł na poprawkę, trzeba lepiej zorganizować początkowe zbieranie informacji, być może podzielić to na lepsze sekcje.  

Co nie zostało zrobione to, nie było pytania o tryb działania.

Ale zostały stworzone materiały dodatkowe, według procesu który jest wpisany w skilla.

• session 
• wynik z big picture, który został automatycznie wykonany
• przetworzone materiały
  
• input index - lista plików graficznych załadowana oraz rozdzielona na konteksty w których ma zastosowanie,
• źródło do części process level

Przegląd materiałów wyjściowych z wstępnego przetworzenia napawa optymizmem, jest lista wczytanych plików, rozłożenie ich na fazy i procent pokrycia. Są wyciągniete eventy, hotspoty, są wstępnie wyznaczone bounded contexty na podstawie dołączonych materiałów, są też przedstawione reguły zawarte w rozpisanej subdomenie.

Czas na sprawdzenie czy LLM wystartuje z poprzedniego miejsca, wczoraj przerwałem na ładowaniu i ocenianiu wsadu.

Muszę sprecyzować jak ma Klaudiuszowi kazać wznowić poprzednią sesje. Samo wskazanie pliku orkiestratora to za mało, trzeba mu powiedzieć kontynuuj wtedy już zadziała mechanizm zapisany w głównym pliku.

Wznawiamy od miejsca gdzie skończyliśmy — Faza 2: Process Level, Tryb 2 (Ekspercki).
  
 Zacznę od pytań blokujących, bo bez nich nie można poprawnie zdefiniować Bounded Contexts ani przepływów. Idę pytanie po pytaniu:

Powyżej odpowiedz LLM-a, więc można uznać że zgodnie z oczekiwaniami.

Pytania blokery z wyniku fazy pierwszej , wyniki fazy drugiej, jest tylko jeden plik, coś nie zostało uruchomione. Trzeba przejrzeć orkiestratora i uzupełnić go o wnioski z testów. Przygotować go do kolejnych testów.

Przy okazji warto wspomnieć że core domain zostało ustalone inne niż w wersji drugiej.

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:

• Wynik analizy proccess level
  

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:

• Wynik kolejnego kontekstu
  
•  Pamieć modelu

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:

• skill wersja 1
• skill wersja 2
• porównanie skilli
• dane wejściowe
• wynik skill wersja 1
• wynik skill wersja 2 tryb , jeden kontekst, big picture
• historia wersji
• skill grill-me