Flow pracy z OpenSpec i OpenCode

 Ostatnio testuję narzędzia CLI, takie jak:

• Copilot CLI
• Gemini CLI
• OpenCode

oraz narzędzia do spec driven development:

• OpenSpec

Testy w trakcie, na ten moment wydaje mi się, że działają nawet lepiej niż Copilot. 

Próba dokończenia mojej aplikacji - szachy canvas

OpenCode /init - inicjalizuje, tworzy plik AGENTS.md

 

Dodaję OpenSpec 

openspec init - dodaje się i automatycznie wykrywa, że używam Opencode. Trzeba zrestartować konsolę z OpenCode i następnie widoczne są w niej polecenia Openspec.

 

 

Proponuję dodanie funkcjonalności, utworzy mi to listę todo w markdown.

 

OpenSpec tworzy plan działania, ale jeszcze nie jest on implementowany, aby zaimplementować wybieramy z konsoli OpenCode apply

Moja funkcjonalność zaczęła działać. Teraz warto oznaczyć zadanie jako wykonane.

Można podejrzeć sobie openspec view

 

 

Po archive

 

Kolejna funkcjonalność to zachowywanie tur ruchów - najpierw białe, potem czarne. 

 /opsx:propose - tutaj opisuję co ma być zrobione, tworzy się dokumentacja, lista todo

/opsx:apply - wykonuje tworzenie kodu

Tutaj moja uwaga - w pierwotnych czasach vibe-kodowania, tworzyło się kod po prostu prosząc o zrobienie całej gry. Jeśli coś poszło nie tak, trzeba było wielokrotnie prosić o poprawki w wielu warstwach gry. Teraz dzięki Spec Driven Development, można tworzyć kod w bardziej naturalny sposób, po trochę. Jeśli coś nie działa, można cofnąć tylko dany fragment kodu.

Minusem jest to, że tworzenie specyfikacji zarówno zajmuje czas, jak i zjada tokeny. 

Podczas developmentu pojawiło się kilka błędów, na przykład można było zaczynać grę jako czarne, albo OpenCode zostawił błąd składniowy i zapomniał o imporcie nowo utworzonych plików. Być może wychwyciłby to, gdyby dodać skrypt build. Jeszcze lepiej było by dodawać od razu testy.

W grze pojawiło się kilka bugów, naprawiłem je po prostu prosząc o to opencode. 

 

Pozdrawiam 🐍