# Szablon PRD w Markdown do programowania z AI Canonical: https://specscore.md/pl/articles/feature-spec-template/ Ostatnia aktualizacja: 5 listopada 2026 Dokument wymagań produktu (PRD, product requirements document) to proza, która określa problem i zakres, zanim praca zostanie podzielona na zadania. [Specyfikacja funkcji](https://specscore.md/feature-specification) to plik SpecScore dla jednej możliwości produktu: co robi, dlaczego istnieje i jak się zachowuje. Markdown to format tekstu prostego tego pliku. [Rozwój sterowany specyfikacją](https://specscore.md/pl/spec-driven-development/) (SDD, spec-driven development) to praktyka pisania specyfikacji przed kodem i traktowania specyfikacji jako źródła prawdy. W [SpecScore](https://specscore.md/) wymaganie (REQ) to nazwana reguła wewnątrz funkcji. [Kryterium akceptacji](https://specscore.md/acceptance-criteria-specification) (AC, acceptance criterion) to opcjonalny abstrakcyjny warunek, który wskazuje jedną lub więcej z tych reguł. Scenariusz to konkretny przykład zapisany jako kroki Given, When i Then. [Plan](https://specscore.md/plan-specification) to dokument, który dzieli funkcję na zadania. [Zadanie](https://specscore.md/task-specification) to jedna jednostka pracy, którą może ukończyć osoba albo agent. [Ciągła integracja](https://specscore.md/pl/validators/) (CI, continuous integration) to automatyczne sprawdzenie przy każdej proponowanej zmianie. Sprawdzenie jest poleceniem [interfejsu wiersza poleceń](https://specscore.md/pl/cli/) (CLI, command-line interface), `specscore spec lint`, z CLI w [specscore/specscore-cli](https://github.com/specscore/specscore-cli). [Easy Approach to Requirements Syntax](https://specscore.md/pl/articles/ears-requirements/) (EARS) to wzorzec zdania, którego może użyć wymaganie. Claude Code to agent kodujący z AI, dla którego napisano wtyczkę [CLI Skills](https://specscore.md/pl/ai/cli-skills/) na tej stronie. Ten szablon specyfikacji funkcji to ten plik funkcji plus plan i zadanie, które wskazują z powrotem na niego. ## Czym jest ten szablon specyfikacji funkcji PRD to często jeden plik prozy, który czyta człowiek. SpecScore trzyma to samo zlecenie w plikach, które może sprawdzić linter. [Specyfikacja funkcji](https://specscore.md/feature-specification) nazywa funkcję atomową jednostką specyfikacji produktu: katalogiem pod `spec/features/`, którego `README.md` jest jedynym źródłem prawdy o tym, co robi funkcja. [Specyfikacja planu](https://specscore.md/plan-specification) nazywa plan dokumentem, który rozkłada tę funkcję na zadania. Scenariusz, w [specyfikacji scenariusza](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md), to konkretny plik Given/When/Then w katalogu `_tests/` funkcji. [Specyfikacja kryteriów akceptacji](https://specscore.md/acceptance-criteria-specification) utrzymuje kryterium abstrakcyjnym: mówi, co musi być prawdziwe, a scenariusz mówi, jak to udowodnić. Plik checkout poniżej to wypełniony szablon. Wraz z indeksem funkcji, README specyfikacji i `specscore.yaml` polecenie `specscore spec lint` zaakceptowało go z 0 naruszeniami. To sprawdzenie uruchomiono 2 listopada 2026 ze specscore 0.55.1 i z 0.39.1, tagiem, który instaluje [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). Linia paska SpecScore Studio w pliku funkcji to linia, którą niosą README funkcji w [specscore/specscore](https://github.com/specscore/specscore). Tabela sekcji obowiązkowych w specyfikacji funkcji jej nie wymienia. ## README funkcji Tabela sekcji obowiązkowych w specyfikacji funkcji mówi, że każdy README funkcji ma tytuł `# Feature: {Title}`, linię `**Status:**` bezpośrednio po tytule, Summary, Problem, sekcję Behavior, sekcję Acceptance Criteria, sekcję Open Questions i stopkę zgodności. Wartość statusu to jedno z `Draft`, `In Review`, `Approved`, `Implementing`, `Stable`, `Amending`, `Rejected` albo `Deprecated`. Sekcja Contents jest wymagana tylko wtedy, gdy funkcja ma katalogi potomne. `**Source Ideas:**` jest opcjonalne. Sprawdzony plik ustawia je na `—`. Open Questions nigdy się nie pomija. Gdy nie ma żadnych, sekcja mówi `None at this time.` Acceptance Criteria też nigdy się nie pomija. Gdy nie zdefiniowano kryteriów, ta sekcja mówi `Not defined yet.` a Open Questions musi wtedy zawierać `Acceptance criteria not yet defined for this feature.` Stopka jest ostatnią linią, a jej URL to `https://specscore.md/feature-specification`. [Konwencja frontmatter artefaktów](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md) mówi, że każdy artefakt niesie klucz `format:` we frontmatter YAML, a artefakt ze statusem niesie też `status:`, odbicie tokenu `**Status:**` w treści. Ta sama funkcja mówi, że wymuszające reguły lint wchodzą po okresie karencji. Sprawdzony plik zawiera oba klucze. Ta strona nie twierdzi, że pin v0.39.1 odrzuca plik, który je pomija. ### README funkcji, który specscore spec lint zaakceptował (2 listopada 2026) ```markdown --- format: https://specscore.md/feature-specification status: Draft --- # Feature: Checkout validation > [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) | **Status:** Draft **Source Ideas:** — ## Summary The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. ## Problem A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them. ## Behavior ### Field validation The checkout system checks the form when the shopper submits it. #### REQ: show-field-error When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field. #### REQ: reject-invalid-email If the submitted email is not a valid address, then the checkout system MUST reject the form. ## Acceptance Criteria ### AC: invalid-submission **Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected. ## Open Questions None at this time. --- *This document follows the https://specscore.md/feature-specification* ``` ### Indeks funkcji z tego samego przebiegu lint ```markdown --- format: https://specscore.md/features-index-specification --- # Features | Feature | Status | Description | |---|---|---| | [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. | ## Open Questions None at this time. --- *This document follows the https://specscore.md/features-index-specification* ``` ### README specyfikacji z tego samego przebiegu lint ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml z tego samego przebiegu lint ```yaml # SpecScore Repo Config Schema: https://specscore.md/repo-config project: title: Checkout sample host: github.com org: example repo: checkout ``` Identyfikator funkcji to ścieżka katalogu względem `spec/features/`. Link indeksu `checkout/README.md` znaczy, że plik leży w `spec/features/checkout/README.md`, więc id funkcji, którego używają wymagania i kryteria, to `checkout`. Indeks wymienia każdą funkcję pierwszego poziomu. Katalog potomny, którego nie ma na liście, jest naruszeniem `index-entries`, które opisuje [lintowanie specyfikacji w CI](https://specscore.md/pl/articles/lint-specs-in-ci/). README specyfikacji w tym drzewie ma jedną sekcję, Open Questions, i mówi `None at this time.` Plik konfiguracji jest tym, czego CLI szuka w górę. Bez `specscore.yaml` polecenie kończy się kodem 3 i wymienia `specscore init`. ## Identyfikatory REQ, kryteria akceptacji i scenariusze [Specyfikacja wymagania](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) umieszcza każdą regułę pod nagłówkiem tematu wewnątrz `## Behavior`. Nagłówek to `#### REQ: {slug}`, z jedną spacją po dwukropku. Slug używa małych liter, cyfr i myślników. Id kanoniczny to `{feature-path}#req:{slug}`. W pliku checkout to `checkout#req:show-field-error` i `checkout#req:reject-invalid-email`. Wymaganie stwierdza jeden obowiązek. Specyfikacja mówi, że wymagania SHOULD używać słów kluczowych RFC 2119 MUST, MUST NOT, SHOULD, SHOULD NOT i MAY. Nagłówek `REQ:` nie jest ważny poza `## Behavior`. Zdanie EARS może być tą prozą. Linter nie ocenia angielskiego. Wzorce są w [składni wymagań EARS](https://specscore.md/pl/articles/ears-requirements/). ### Kryterium akceptacji [Specyfikacja kryteriów akceptacji](https://specscore.md/acceptance-criteria-specification) mówi, że każde kryterium to nagłówek `### AC: {slug}` wewnątrz `## Acceptance Criteria`, potem linia `**Requirements:**` wymieniająca wartości `{feature-id}#req:{slug}`, a potem abstrakcyjne stwierdzenie tego, co musi być prawdziwe. Kryteria są opcjonalne. Specyfikacja mówi, żeby dodać kryterium, gdy połączenie dwóch lub więcej powiązanych wymagań dodaje jasności. Plik checkout łączy obie reguły w `checkout#ac:invalid-submission`. Stwierdzenie nie zawiera Given, When ani Then. [Jak pisać kryteria akceptacji](https://specscore.md/pl/articles/acceptance-criteria/) to przewodnik pisania. Reguła `ac-heading-format` ([ac_heading.go](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go) przy tagu CLI v0.55.1) sprawdza, że nagłówek to `### AC: ` z id w kebab-case. [Artykuł o lintowaniu](https://specscore.md/pl/articles/lint-specs-in-ci/) zapisuje, że ta reguła nie wymaga linii `**Requirements:**` i nie punktuje słów. Specyfikacja kryteriów akceptacji nadal wymaga tej linii. ### Scenariusz [Specyfikacja scenariusza](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) umieszcza scenariusz w `_tests/`, który nie jest podfunkcją i jest wyłączony z indeksu funkcji. Plik zaczyna się od `# Scenario: {Title}`, linii `**Validates:**` wskazującej wymaganie albo kryterium oraz sekcji `## Steps`, której słowa kluczowe są wielkimi literami: GIVEN, WHEN, THEN i AND. Każdy katalog `_tests/` musi zawierać README z indeksem scenariuszy. Próbka poniżej ma ten kształt pliku. Nie wchodziła w skład przebiegu lint z 2 listopada. `specscore spec lint` nie sprawdza słów kluczowych kroków scenariusza. `specscore rehearse` uruchamia pliki scenariuszy. [Rehearse](https://specscore.md/rehearse) to ten program uruchamiający. Workflow dogfood uruchamia linter i nie wywołuje rehearse. ### Kształt pliku scenariusza według specyfikacji scenariusza ```markdown # Scenario: Reject an invalid email **Validates:** [checkout#ac:invalid-email-rejected](../README.md#ac-invalid-email-rejected) ## Steps GIVEN the shopper is on the checkout form WHEN the shopper submits the email "not-an-email" THEN the page shows "Enter a valid email address" beside the email field AND the order is not placed ``` Czytaj trzy warstwy po kolei. Wymaganie mówi regułę. Kryterium akceptacji mówi, co musi być prawdziwe dla reguł, które nazywa. Scenariusz daje jeden konkretny przepływ. Agent, który widzi tylko prozę PRD, musi wymyślić ten podział. Szablon już go ma. ## Plany i zadania README planu leży w `spec/plans/{plan-slug}/README.md`. [Specyfikacja planu](https://specscore.md/plan-specification) wymaga tytułu `# Plan: {Title}` oraz pól nagłówka Status, dokładnie jednej linii źródła, Date, Owner i Supersedes. Plan o źródle w funkcji używa `**Source Feature:**` plus slug funkcji, tutaj `checkout`. Inne dozwolone linie źródła to `**Source:** idea:{slug}` i `**Source:** none`. Sekcje obowiązkowe to Summary, Approach, Tasks i Open Questions. Wewnątrz planu każde zadanie to nagłówek `### Task N:` z linią `**Verifies:**` w postaci `feature-slug#ac:ac-slug`. Reguła `P-001` w [plan_rules.go](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/plan_rules.go) zgłasza nagłówek kryterium akceptacji, którego nie pokrywa żadne zadanie i którego nie ma pod `## Deferred AC Coverage`. Reguła `P-002` zgłasza wartość `**Verifies:**`, która nie rozwiązuje się do jednego z tych nagłówków. Plany o źródle w pomyśle i plany z `**Source:** none` są zwolnione z `P-001`. Plan poniżej trzyma ten opublikowany kształt dla funkcji checkout, łącznie z frontmatter `format:` i `status:`. Nie było go w przebiegu lint z 2 listopada. Funkcja, której dotyka plan, musi zawierać tabelę `## Plans` z kolumnami Plan, Status, Author i Approved. Sprawdzony plik funkcji nie ma sekcji Plans, bo to drzewo nie ma planu. [Specyfikacja zadania](https://specscore.md/task-specification) definiuje też zadanie jako własny katalog i `README.md` pod planem. Tytuł to `# Task: {Title}`. Pola obowiązkowe to `**Status:**`, `**Depends on:**` (literał `none`, gdy nie ma zależności) i `**Model:**` (`small`, `medium`, `large` albo `inherit`). Katalog, który zawiera katalogi zadań potomnych, jest planem, a nie zadaniem. Plik zadania poniżej używa tych pól dla pierwszego zadania checkout. Nie było go w przebiegu lint z 2 listopada. URL stopki dokumentu zadania to `https://specscore.md/task-specification`. ### Kształt planu ze specyfikacji planu, wypełniony dla checkout ```markdown --- format: https://specscore.md/plan-specification status: Draft --- # Plan: Show checkout validation errors **Status:** Draft **Source Feature:** checkout **Date:** 2026-11-05 **Owner:** @example **Supersedes:** — ## Summary This plan decomposes the checkout feature into the work that shows a field error and rejects an email that is not a valid address. ## Approach Both tasks verify the same acceptance criterion, which bundles the two requirements. Nothing is deferred, so this plan has no Deferred AC Coverage section. ## Tasks ### Task 1: Show a validation error beside the invalid field **Verifies:** checkout#ac:invalid-submission When the shopper submits the checkout form with invalid data, show a validation error next to the invalid field. ### Task 2: Reject an email that is not a valid address **Verifies:** checkout#ac:invalid-submission If the submitted email is not a valid address, reject the form. ## Open Questions None at this time. --- *This document follows the https://specscore.md/plan-specification* ``` ### Kształt dokumentu zadania ze specyfikacji zadania ```markdown --- format: https://specscore.md/task-specification status: queued --- # Task: Show a validation error beside the invalid field **Status:** queued **Depends on:** none **Model:** medium ## Acceptance Criteria - Submitting the checkout form with invalid data shows a validation error next to the invalid field. ## Open Questions None at this time. --- *This document follows the https://specscore.md/task-specification* ``` Plik funkcji odpowiada, co musi robić formularz checkout. Plan odpowiada, jak ta praca jest podzielona, a każde zadanie w treści nazywa kryterium, które weryfikuje. Dokument zadania jest liściem, po który sięga osoba albo agent. Utrzymuj stabilne id kryterium. `checkout#ac:invalid-submission` to ciąg, którego używają i funkcja, i plan. ## Lintowanie szablonu w CI `specscore spec lint` waliduje drzewo specyfikacji pod kątem naruszeń konwencji strukturalnej. Czysty przebieg wypisuje `0 violations found` i kończy się kodem 0. Przebieg, który znajduje naruszenia, wypisuje jedną linię na znalezisko i kończy się kodem 1. Ten kod wyjścia powoduje niepowodzenie joba CI. Nieprawidłowe argumenty kończą się kodem 2. Brak `specscore.yaml` kończy się kodem 3. [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) instaluje CLI z `SPECSCORE_VERSION` ustawionym na `v0.39.1`, a potem uruchamia `specscore spec lint` przy pull requestach i przy pushach do main. Fragment workflow, raport niepowodzenia i katalog reguł są w [lintowaniu specyfikacji w CI](https://specscore.md/pl/articles/lint-specs-in-ci/). Licencja formatu to [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) w [specscore/specscore](https://github.com/specscore/specscore). Licencja CLI to [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) w [specscore/specscore-cli](https://github.com/specscore/specscore-cli). Inne narzędzia rozwoju sterowanego specyfikacją publikują inne sprawdzenia. Zdania poniżej używają tylko tego, co mówią własne strony tych projektów. [Przegląd narzędzi](https://specscore.md/pl/spec-driven-development/tools/) zapisuje te same strony jako czytane 30 października 2026, poza stroną główną dokumentacji Spec Kit, która drukuje 28 września 2026. [OpenSpec](https://github.com/Fission-AI/OpenSpec) dokumentuje `openspec validate` w swojej [referencji CLI](https://openspec.dev/docs/cli). To polecenie sprawdza strukturę zmian i specyfikacji OpenSpec i kończy się kodem niezerowym, gdy walidacja się nie powiedzie. Nie sprawdza nagłówka SpecScore `### AC:` ani indeksu SpecScore. README [Task Master](https://github.com/eyaltoledano/claude-task-master) opisuje rozbicie PRD na zadania poleceniem `task-master parse-prd`. Nie opisuje lintera dla tego PRD. PRD nadal może być tekstem wejściowym, który przepisuje się do pliku funkcji na tej stronie. `specscore spec lint` jest tym, co potem sprawdza plik funkcji. [GitHub Spec Kit](https://github.github.io/spec-kit/) opisuje workflow agenta, którego fazy piszą artefakty Markdown. Ta strona główna dokumentacji nie opisuje polecenia, które lintuje README funkcji SpecScore w CI. Porównanie tych narzędzi to [przegląd narzędzi](https://specscore.md/pl/spec-driven-development/tools/). ## Szablon specyfikacji, który Claude Code może czytać Pliki są w Markdown, więc agent, który może czytać repozytorium, może czytać szablon. Claude Code to agent, do którego kieruje się strona [CLI Skills](https://specscore.md/pl/ai/cli-skills/). Ta strona dokumentuje `ai-plugin-specscore`, cienką wtyczkę Claude Code, która owija CLI. Repozytorium wtyczki to [specscore/ai-plugin-specscore](https://github.com/specscore/ai-plugin-specscore). Strona mówi, że wtyczka udostępnia `specscore spec lint`, `specscore feature`, `specscore task` i `specscore feature change-status` jako polecenia wtyczki. Linie instalacji na tej stronie to `/plugin marketplace add specscore/ai-marketplace` i `/plugin install cli-skills@specscore`. Ta sama strona dokumentuje `specscore agent setup ` dla `claude`, `copilot`, `cursor`, `codex`, `antigravity.google`, `pi.dev` albo `opencode`, uruchamiane wewnątrz projektu zarządzanego przez SpecScore. [SpecStudio Skills](https://specscore.md/pl/ai/specstudio-skills/) to prowadzony przepływ pracy (`/ideate`, `/specify`, `/plan`, `/implement`) i też jest wtyczką Claude Code. Szablon na tej stronie jest plikiem, który te polecenia lintują. Wtyczka nie zastępuje README funkcji. ## Najczęstsze pytania ### Czym jest szablon PRD w Markdown? To dokument wymagań produktu zapisany jako pliki Markdown o stałym kształcie. W SpecScore ten kształt to README funkcji: tytuł, status, podsumowanie, problem, zachowanie z regułami `#### REQ:`, kryteria akceptacji i pytania otwarte. Plik checkout na tej stronie jest jednym z tych, które `specscore spec lint` zaakceptował. ### Gdzie w szablonie specyfikacji funkcji trafiają identyfikatory REQ? Pod nagłówkiem tematu wewnątrz `## Behavior`, jako `#### REQ: {slug}`. Id to `{feature-path}#req:{slug}`. Kryteria akceptacji wymieniają te id w `**Requirements:**`. Zadanie planu wymienia id kryterium w `**Verifies:**`. ### Czym różni się kryterium akceptacji od scenariusza? Kryterium akceptacji to abstrakcyjny warunek. Scenariusz to konkretny przepływ Given/When/Then w `_tests/`. [Specyfikacja kryteriów akceptacji](https://specscore.md/acceptance-criteria-specification) mówi, że kryterium nie może przepisywać kroków. Plik scenariusza to robi. ### Czy linter ocenia prozę PRD? Nie. `specscore spec lint` sprawdza strukturę: nagłówki, sekcje obowiązkowe, wiersze indeksu i odwołania takie jak `P-001` i `P-002`. Nie rozstrzyga, czy produkt jest dobrym pomysłem. [Lintowanie specyfikacji w CI](https://specscore.md/pl/articles/lint-specs-in-ci/) to dłuższe omówienie tego polecenia. ### Czy Claude Code może użyć tego szablonu specyfikacji? Tak. Szablon to Markdown w repozytorium. Wtyczka [CLI Skills](https://specscore.md/pl/ai/cli-skills/) udostępnia `specscore spec lint` oraz polecenia funkcji i zadania wewnątrz Claude Code. `specscore agent setup claude` zapisuje plik instrukcji dla tego agenta. Wtyczka nie wymyśla innego szablonu. ### Czy plan zastępuje specyfikację funkcji? Nie. README funkcji jest źródłem wymagań i kryteriów akceptacji. Plan rozkłada tę funkcję na zadania, a każde zadanie wskazuje z powrotem przez `**Verifies:**`. [Specyfikacja planu](https://specscore.md/plan-specification) i [specyfikacja zadania](https://specscore.md/task-specification) to dwa dokumenty tego podziału. ## Źródła Funkcja checkout, indeks funkcji, README specyfikacji i specscore.yaml zostały zaakceptowane przez specscore spec lint 2 listopada 2026 ze specscore 0.55.1 i z 0.39.1. Próbki planu i zadania są zgodne z opublikowanymi specyfikacjami i nie wchodziły w skład tego przebiegu. Strony konkurentów to te powiązane poniżej; przegląd narzędzi zapisuje je jako czytane 30 października 2026, poza stroną główną dokumentacji Spec Kit, która drukuje 28 września 2026. - [Specyfikacja funkcji](https://specscore.md/feature-specification) - [specscore/specscore — specyfikacja funkcji](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — specyfikacja wymagania](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [Specyfikacja kryteriów akceptacji](https://specscore.md/acceptance-criteria-specification) - [specscore/specscore — specyfikacja kryteriów akceptacji](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — specyfikacja scenariusza](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [Specyfikacja planu](https://specscore.md/plan-specification) - [specscore/specscore — specyfikacja planu](https://github.com/specscore/specscore/blob/main/spec/features/plan/README.md) - [Specyfikacja zadania](https://specscore.md/task-specification) - [specscore/specscore — specyfikacja zadania](https://github.com/specscore/specscore/blob/main/spec/features/task/README.md) - [specscore/specscore — konwencja frontmatter artefaktów](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md) - [specscore/specscore](https://github.com/specscore/specscore) - [specscore/specscore — licencja CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore-cli — licencja Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) - [specscore/specscore — dogfood.yml (CLI v0.39.1)](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specscore-cli v0.55.1 — ac-heading-format](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go) - [specscore-cli v0.55.1 — reguły planu P-001 i P-002](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/plan_rules.go) - [Lintowanie specyfikacji w CI linterem specyfikacji](https://specscore.md/pl/articles/lint-specs-in-ci/) - [Jak pisać kryteria akceptacji, które agent AI może zweryfikować](https://specscore.md/pl/articles/acceptance-criteria/) - [Składnia wymagań EARS wyjaśniona, z przykładami](https://specscore.md/pl/articles/ears-requirements/) - [CLI Skills — SpecScore CLI wewnątrz Claude Code](https://specscore.md/pl/ai/cli-skills/) - [SpecStudio Skills](https://specscore.md/pl/ai/specstudio-skills/) - [specscore/ai-plugin-specscore](https://github.com/specscore/ai-plugin-specscore) - [Co waliduje SpecScore](https://specscore.md/pl/validators/) - [Rehearse](https://specscore.md/rehearse) - [Referencja CLI OpenSpec — openspec validate](https://openspec.dev/docs/cli) - [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) - [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) - [Dokumentacja GitHub Spec Kit (data strony 28 września 2026)](https://github.github.io/spec-kit/) - [Narzędzia rozwoju sterowanego specyfikacją](https://specscore.md/pl/spec-driven-development/tools/) ## Powiązane - [Rozwój sterowany specyfikacją z Claude Code i Cursor](https://specscore.md/pl/articles/claude-code-specs/) - [Specyfikacja funkcji](https://specscore.md/feature-specification) - [Specyfikacja kryteriów akceptacji](https://specscore.md/acceptance-criteria-specification) - [Specyfikacja planu](https://specscore.md/plan-specification) - [Specyfikacja zadania](https://specscore.md/task-specification) - [Jak pisać kryteria akceptacji, które agent AI może zweryfikować](https://specscore.md/pl/articles/acceptance-criteria/) - [Składnia wymagań EARS wyjaśniona, z przykładami](https://specscore.md/pl/articles/ears-requirements/) - [Lintowanie specyfikacji w CI linterem specyfikacji](https://specscore.md/pl/articles/lint-specs-in-ci/) - [Rozwój sterowany specyfikacją](https://specscore.md/pl/spec-driven-development/) - [Narzędzia rozwoju sterowanego specyfikacją](https://specscore.md/pl/spec-driven-development/tools/) - [CLI Skills dla Claude Code](https://specscore.md/pl/ai/cli-skills/) - [CLI](https://specscore.md/pl/cli/)