pstanek Pisanie specyfikacji
Kontrakt produktu, prefiks plików i katalog speców biorą się z AGENTS.md projektu. Ten skill opisuje proces, nie numerację jednego produktu.
Czytaj razem z $repository-writing i $testing.
Kiedy używać
- Nowy moduł, istotny flow, model danych albo zmiana architektury.
- Użytkownik prosi o analizę/spec i nie chce jeszcze kodu.
- Zakres jest niejasny albo koliduje z istniejącym kontraktem produktu.
Nie pisz speca przy małym bugfixie, zmianie copy, refaktorze bez zmiany kontraktu albo dopasowaniu instrukcji.
Źródła
- Kontrakt produktu w tym repo (często
SPEC.md/AGENTS.md). - Istniejący kod i już zatwierdzone specy tego projektu.
- Notatki i backlog nie zmieniają zakresu, dopóki użytkownik ich nie zatwierdzi.
Nie implementuj funkcji ze speców innego produktu ani nie przejmuj ich statusów. Gdy użytkownik prosi tylko o analizę/spec, nie zmieniaj kodu.
Nowy plik nazwij i złóż tam, gdzie każe AGENTS.md projektu. Numeruj w serii tego repo, bez kolizji z importowanymi referencjami.
Struktura
Dostosuj długość do zadania. Pełna spec obejmuje:
Status: Draft / Approved / In progress (data) / Implemented (data) / Superseded by …; przy fazach dodaj ich stan.- Cel, problem i zakres, w tym co pozostaje poza zmianą.
- Flow użytkownika i kryteria odbioru.
- Architektura: UI → transport → serwisy → repozytoria; granica server/client.
- Dane: schema, relacje, DTO, ograniczenia, migracja i błędy.
- Integracje i uprawnienia, jeśli dotyczą zadania.
- Fazy z weryfikowalnymi wynikami.
- Testy, ryzyka, nieustalone kwestie i historia istotnych zmian.
Krótka spec: status, problem, rozwiązanie, kroki, kryteria odbioru. Nie dodawaj wycen ani terminów bez prośby.
Decyzje i realizacja
Najpierw ustalenia użytkownika i repo. Pytaj tylko o decyzje, które zmieniają zakres, odpowiedzialność albo kontrakt. Rutynowe wybory implementacyjne opisz jako założenia.
Samo planowanie → spec bez kodu, implementacja po zgodzie. Już zlecona implementacja w ustalonym zakresie → spec jest planem, nie dodatkową bramką. Nie oznaczaj Approved bez rzeczywistej autoryzacji.
Status według wykonania, nie zamiaru. Implemented wymaga kodu i opisanej weryfikacji; brakującą integrację albo produkcję podaj osobno. Nie poszerzaj V1 o funkcje z innego projektu tylko dlatego, że tam były.
Po specu
- Warstwy danych →
$repository-writing - Testy →
$testing - UI →
$tailwind-ui