| name | prd |
| description | Generuje 1-2 stronicowy, agent-ready PRD dla MVP budowanego w 7 dni (Faza 1 playbooka PLSoft 7-Day MVP / AI Startup Builders Week 3). Bierze insighty z Week 1 (Problem-Solution Fit) i Week 2 (GTM/ICP/Value Proposition + LP) — dostarczone w dowolnym układzie plików (jeden dokument, osobne icp/positioning/ gtm-plan/landing-brief, folder, notatki) plus brand — i sprowadza je do jednego dokumentu prd.md, który agent (Claude Code lub Lovable/v0) rozumie i pod który generuje kod. Triggeruj na komendę /prd ORAZ gdy founder-uczestnik programu chce zrobić PRD pod MVP, spisać scope na 7 dni, przerobić output W1/W2 na dokument dla agenta, albo pyta "jak napisać PRD dla mojego MVP", "spnij to w PRD", "scope na MVP". Triggeruj też gdy ktoś chce ograniczyć/przyciąć zakres (scope) MVP do jednego core flow i spisać to w dokument pod agenta, oraz gdy osoba nietechniczna buduje aplikację w Lovable/v0 i potrzebuje PRD/spisanego zakresu pod swoje MVP. Nie triggeruj na pełne PRD dla zewnętrznego klienta z fixed-price (to software-delivery-playbook, 9-day), ani na czysty UI/design brief (to vibe-coding). |
| license | Apache-2.0 |
/prd — Agent-ready PRD dla 7-dniowego MVP
Sprowadza insighty Week 1 / Week 2 do jednego dokumentu prd.md, pod który
agent generuje kod bez chaosu. To Faza 1 [[mvp-7-day-playbook]]. Output zostaje
skonsumowany przez Fazę 3 (dekompozycja na /goal-e) i ostatecznie przez build
w Track Tech (Claude Code + /prepare-goal → /goal) lub Track Builder (Lovable/v0).
Invocation
/prd <opcjonalnie nazwa projektu>
/prd → poproś o nazwę i wskazanie prd-input.md
Jedyna zasada, która decyduje o sukcesie: tnij do JEDNEGO Core Flow
7 dni starczy na jedną ścieżkę użytkownika zrobioną dobrze ALBO trzy zrobione źle.
To nie jest pełny PRD dla klienta — to ostry brief pod jeden tydzień buildu. Jeśli
czujesz, że potrzebujesz 2 user stories w Core Flow, wybierz ważniejszą; druga idzie
do §6 Out of scope. Większość Twojej pracy w tym skillu to odmawianie, nie dodawanie.
Dlaczego: agent dostając PRD na 8 stron z trzema flow dryfuje w niuansach i po D7
masz trzy half-baked ścieżki zamiast jednego działającego MVP na Demo Day.
Input contract — liczy się informacja, nie pliki
PRD powstaje z insightów Week 1 (Problem-Solution Fit) i Week 2 (GTM / ICP / Value
Proposition / LP). Nie ma znaczenia, w ilu plikach ani pod jakimi nazwami founder
je dostarczy — jeden skonsolidowany dokument, cztery osobne pliki z W2
(icp.md, positioning.md, gtm-plan.md, landing-brief.md), cały folder repo,
czy wklejone notatki. Founder wskazuje materiały; Ty czytasz to, co wskazał, i sprawdzasz,
czy treść pokrywa poniższą checklistę — nie czy istnieje plik o konkretnej nazwie.
Czego PRD potrzebuje (input checklist):
| Informacja | Zasila sekcję | Zwykle pochodzi z |
|---|
| Problem-Solution Fit + kto jest zdesperowany | §1, §2 | W1 Discovery |
| ICP + 1 persona (+ wnioski z social listeningu) | §2 | W2 ICP |
| Value Proposition / positioning / JTBD / key messaging | §1, §3 | W2 positioning |
| Model monetyzacji + zarys unit economics | §1 | W2 Lean Canvas / GTM |
| Brief LP + link do opublikowanego LP (headline, sekcje, CTA) | §1 | W2 landing brief |
| Brand: konkretne HEX-y, fonty, voice & tone | §5 | LP Week 2 |
Jedna pozycja rozbita na trzy pliki — w porządku. Jeden plik pokrywający kilka pozycji —
też. Przeczytaj wszystko, co founder wskazał, zanim ocenisz kompletność — brak pliku
o danej nazwie to nie to samo co brak informacji (może siedzieć w innym pliku).
Jeśli materiały nie pokrywają checklisty (nie ma ich w ogóle, są szczątkowe, albo
brakuje krytycznej pozycji — mierzalny problem, 1 persona, value proposition, model
przychodu) → nie zgaduj i nie generuj od razu. Najpierw krótko podsumuj, czego brakuje
(1-3 zdania, wskaż której pozycji checklisty), a potem przedstaw userowi dwie ścieżki
do wyboru:
Ścieżka 1 — dostarczasz materiały: wskazujesz dodatkowe pliki/notatki z W1/W2
(w dowolnym układzie). Generuję PRD z nich; jeśli czegoś nadal zabraknie, dopytam tylko o luki.
Ścieżka 2 — seria pytań: przeprowadzam Cię przez brakujące elementy pytaniami.
Zasady Ścieżki 2 (wywiad):
- Jedno pytanie naraz — nigdy ściana tekstu z 6 pytaniami.
- Do każdego pytania dodaj rekomendację ("na podstawie tego co napisałeś,
sugerowałbym X, bo...") — founder może ją przyjąć jednym słowem.
- Każde pytanie można pominąć — ale przy pominięciu powiedz wprost, czym to grozi:
PRD w tym miejscu będzie zgadywany i może być nietrafiony. Founder pomija świadomie,
nie przez przeoczenie.
- Kolejność pytań: problem & kto jest zdesperowany → ICP/persona → value proposition →
monetization → core action → track. (Od "dlaczego" do "czym".)
Dlaczego ten protokół: bez niego model uprzejmie zmyśli ICP, metryki i persony z jednego
zdania pomysłu — PRD wygląda kompletnie, ale jest generic i nie pasuje do żadnego
zwalidowanego LP. Founder może świadomie zaakceptować luki; nie może ich dostać w pakiecie
bez ostrzeżenia.
Jeśli brakuje tylko pojedynczych pozycji checklisty (np. jest problem, nie ma
monetization), pomiń wybór ścieżek — od razu zadaj 1-2 precyzyjne pytania (z rekomendacją,
jedno naraz).
Jak prowadzisz rozmowę
- Przeczytaj wszystkie wskazane materiały (jeden plik, wiele plików, folder, wklejone
notatki). Wyciągnij surowiec do każdej z 8 sekcji, mapując treść na input checklist.
- Jeśli któraś krytyczna pozycja checklisty nie jest pokryta (mierzalny problem, 1 persona,
model przychodu, pomysł na core action) → dopytaj, jedno pytanie naraz.
- Aktywnie proponuj cięcia: jak widzisz 3 features, powiedz wprost które 2 idą
do Out of scope i dlaczego. Founder = klient, ale Twoja rola to dyscyplina scope'u.
- Wygeneruj
prd.md w strukturze poniżej. Zapisz do repo uczestnika jako prd.md
(1 plik, bez date-prefixa — to live dokument przez cały tydzień).
- Po wygenerowaniu: pokaż §6 Out of scope i §7 Open Questions wprost — to są dwie
sekcje, które najczęściej ratują deadline. Zaproponuj przejście do Fazy 3 (dekompozycja).
Struktura prd.md — 8 sekcji (9 dla Track Builder), ≤ 2 strony
Każda sekcja maksymalnie pół strony. Jeśli sekcja nie ma treści, napisz "n/d" —
nie watuj. To jest świadomie odchudzony PRD (pełny 8-sekcyjny PRD dla klienta żyje w
[[software-delivery-playbook]] §3; tutaj insighty W1/W2 dostarczają większość treści).
§1-§8 są zawsze. §9 Component Inventory generujesz wyłącznie dla Track Builder —
patrz warunek pod §8. Track Tech zostaje przy 8 sekcjach.
Header block (zawsze, przed §1)
Dokument otwiera blok nagłówkowy — wszystkie bazowe informacje zwięźle w jednym miejscu,
żeby każdy (founder, Paweł, agent) wiedział od pierwszej linii co to jest i do czego służy:
# PRD — <NAZWA> (MVP 7 dni)
> **Cel dokumentu:** Spiąć input z Week 1 / Week 2 w wykonalny PRD pod 7-dniowe MVP.
> **Track / Stack:** <Track Tech: Claude Code + Next.js 15 + Supabase + Vercel | Track Builder: Lovable/v0 + Supabase + Vercel>
> **Data:** <YYYY-MM-DD> · **Status:** live dokument (aktualizowany przez W3)
§1 — Problem-Solution Fit + Value Proposition
Jeden akapit. Przepisz 1:1 z LP Week 2 / W1, nie reformułuj — copy z LP jest już
zwalidowany, Twoja parafraza tylko wprowadzi drift. Dodaj na końcu AI Build Summary:
jedno zdanie w trybie rozkazującym, machine-readable, dla agenta.
AI Build Summary (przykład): "Zbuduj aplikację web Next.js 15 + Supabase, w której
junior dev loguje się Google, przegląda mentorów, rezerwuje 30-min slot i dostaje
link do Zoom. Bez płatności realnych w V1 (fake checkout). Musi działać pod publicznym URL."
To zdanie to pierwsza rzecz, którą agent czyta — odpowiada "co budować i jaki jest
najtwardszy constraint", zanim dotknie ekranów.
§2 — ICP + 1 persona
Z W2 (i Discovery W1 jeśli było). Jedna persona, nie pięć. Kto i dlaczego jest
zdesperowany — desperacja klienta to paliwo MVP. Max 4-5 zdań.
§3 — Core Flow (TO jest cały scope V1)
Serce dokumentu. Dokładnie jedna user story end-to-end z acceptance criteria.
Job to Be Done (rama, która chroni przed technically-correct-but-wrong):
"Gdy [sytuacja], chcę [motywacja], żeby [oczekiwany rezultat]."
User story:
"Jako [rola] chcę [akcja], żeby [korzyść]."
Flow tekstowo (na poziomie ekranów — nie potrzebujesz Figmy):
Ekran A (login) → Sign in z Google → Ekran B (lista X) → klik item → Ekran C (detail + akcja Y) → potwierdzenie
Acceptance criteria (binarne, pass/fail — tak żeby agent/QA zweryfikował bez
dwuznaczności; "działa poprawnie" to NIE kryterium):
§4 — Data model (3-5 encji MAX)
Kształt danych, które Core Flow tworzy/czyta/zmienia. Tyle precyzji, żeby agent
wygenerował schema bez zgadywania. Track Tech → interfejsy TypeScript z komentarzami
przy nieoczywistych polach; Track Builder → tabele Supabase opisane słownie (nazwa,
pola, typy, relacje FK). Jeśli encji > 5 → prawie na pewno scope za szeroki, wróć do §3.
§5 — Tech stack lock (Track + wersje)
Decyzja zalockowana — zmiana w środku tygodnia = restart. Wybierz JEDEN track:
| Track Tech | Track Builder |
|---|
| Stack | Claude Code + Next.js + Supabase + Vercel + shadcn/ui | Lovable/v0 + Supabase + Vercel |
| Dla kogo | Founder-tech, długi runway kodu | Founder-biznes, MVP-do-walidacji |
Wymień konkretne wersje (Next.js 15, nie "latest" — "latest" sprawia, że agent
łapie breaking changes). Track determinuje §4 i całą Fazę 4.
Brand reference (podsekcja §5, zawsze): wklej do PRD esencję informacji brandowych —
konkretne HEX-y, font names, 1-2 zdania voice & tone i dla kogo ten styl jest
(dopasowanie do ICP z §2) — niezależnie skąd przyszły (osobny plik brandowy, sekcja
w briefie LP, fragment notatek). PRD ma być samowystarczalny dla agenta: w Fazie 4
agent dostaje często sam prd.md + prompt, a bez brandu w dokumencie generuje generic
UI, który nie pasuje do LP. Nie kopiuj całej specyfikacji brandu — esencja, 5-8 linii.
Jeśli brandu nie ma w żadnym materiale → to pozycja do dopytania (Open Question / pytanie
do foundera), nie do zmyślenia.
§6 — Out of scope (min. 5 rzeczy, które kuszą ale NIE wchodzą)
Najważniejsza sekcja po §3. Wymień konkretnie co NIE wchodzi do V1: auth wieloma
metodami, role/permissions, admin panel, realne płatności, powiadomienia email,
wyszukiwarka, itd. — chyba że jedno z nich JEST Core Flow. Bez tej sekcji masz scope
creep w D4 i zagrożony deadline.
§7 — Open Questions (decyzje wymagające inputu — agent ma PYTAĆ, nie zgadywać)
Lista decyzji, których agent nie podejmuje sam: wybór konkretnego providera/SaaS
oznaczonego TBD, treści marketingowe, cokolwiek poza stack lockiem §5. Każda pozycja
z ownerem (Ty / Paweł). W Fazie 4 agent przerywa właśnie na tych punktach.
§8 — Definition of Done MVP V1 (boolean checklist)
Sprawdzalne haczyki, nie "MVP gotowe":
§9 — Component Inventory (TYLKO Track Builder)
Generuj tę sekcję wyłącznie gdy §5 lock = Track Builder. Pomiń ją całkowicie dla
Track Tech — tam shadcn/ui komponuje komponenty sam z user flow §3, osobna lista to
narzut bez zwrotu.
Dlaczego dla Buildera tak: Lovable/v0 generują UI na poziomie pojedynczego komponentu,
więc płaska, wyliczalna lista to dla nich gotowy build-brief. Bez niej generujesz
ekran-po-ekranie i gubisz empty/error states.
Wymień każdy znaczący element UI Core Flow §3: formularze, karty, modale, przyciski,
nawigację, empty states, error states. Mapuj do user story:
| Komponent | Typ | Opis | Story |
|---|
| [nazwa] | Form / Layout / Action / Display / Navigation / Modal | co robi | US1 |
Obowiązkowo: instrukcja użycia dla foundera. Pamiętaj, że czyta to osoba
nietechniczna — sekcja §9 w wygenerowanym PRD musi zaczynać się od 2-3 zdań prostym
językiem JAK z niej korzystać i PO CO, np.:
Jak używać tej listy: buduj w Lovable po jednym komponencie naraz, w kolejności
z tabeli — opisz narzędziu pojedynczy wiersz (nazwa + opis + brand), obejrzyj wynik,
dopiero potem bierz następny. Dlaczego: prosząc o cały ekran naraz tracisz kontrolę
i Lovable pomija stany puste/błędów. Kolumna "Story" mówi, którą część Core Flow
z §3 dany komponent realizuje — jak komponent nie mapuje się na story, to znak,
że nie jest potrzebny w V1.
Żargon bez wyjaśnienia ("każdy wiersz = jeden prompt", "mapuje do US1") zostawia
foundera z pytaniem "co mam z tym zrobić?" — i sekcja idzie do kosza.
Handoff do Fazy 3
Po akceptacji prd.md następny krok to dekompozycja Core Flow §3 na 3-5 sekwencyjnych
goals (goals.md): G1 foundation → G2 data → G3 core flow UI → G4 integration/edge
→ G5 deploy + analytics. Każdy goal potem leci przez /prepare-goal → /goal (Track Tech)
lub jako milestone w narzędziu (Track Builder). Zaproponuj to przejście usera, ale samej
dekompozycji nie rób w tym skillu — to osobny krok playbooka §5.
Anti-wzorce (czego NIE robić)
- ❌ PRD na 8 stron jak dla zewnętrznego klienta → agent dryfuje, 7 dni nie wystarczy
- ❌ Core Flow = 3 user stories "bo wszystkie ważne" → 1 dobrze > 3 źle
- ❌ Brak §6 Out of scope → scope creep w D4
- ❌ Reformułowanie value proposition z LP zamiast 1:1 → drift od zwalidowanego copy
- ❌ Stack "latest" zamiast wersji → breaking changes w trakcie buildu
- ❌ Generowanie PRD z pustych/szczątkowych materiałów (zgadywanie W1/W2) → generic MVP nie pasujący do LP
- ❌ Upieranie się przy pliku o konkretnej nazwie zamiast czytania treści, którą founder dostarczył (1 plik czy 10 — bez znaczenia)
- ❌ Data model na 10 encji → znak że scope §3 za szeroki, wróć i tnij
Format odpowiedzi
- (Jeśli brak inputu) 1-2 pytania o ścieżkę pliku albo brakujące elementy W1/W2
- (Jeśli widzisz za szeroki scope) jawna propozycja cięć: co → Out of scope i dlaczego
- Wygenerowany
prd.md zapisany do repo + krótkie podsumowanie cięć scope'u
- Wskazanie §6 i §7 + propozycja przejścia do Fazy 3 (dekompozycja na goals)
Bez długich wstępów. Bez powtarzania całego inputu W1/W2.
