- Add /ralph:prd command for PRD generation with clarifying questions - Add /ralph:convert command to convert PRD to executable JSON - Include templates: ralph.sh, prompt.md, prd-template.json - Include example PRD (prd-hello-api.json) - Update marketplace.json with ralph plugin v1.0.0 - Update README with ralph documentation Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
195 lines
5.2 KiB
Markdown
195 lines
5.2 KiB
Markdown
---
|
|
description: Generează un Product Requirements Document (PRD) structurat pentru o funcționalitate nouă. Folosește acest skill când utilizatorul vrea să planifice și documenteze cerințele pentru un feature înainte de implementare.
|
|
---
|
|
|
|
# Skill: PRD Generator
|
|
|
|
Generează un Product Requirements Document (PRD) detaliat pentru funcționalități noi prin întrebări clarificatoare și documentație structurată.
|
|
|
|
## Când să folosești acest skill
|
|
|
|
- Utilizatorul vrea să adauge o funcționalitate nouă
|
|
- Vrea să planifice înainte de a implementa
|
|
- Menționează "PRD", "requirements", "cerințe", "planifică feature"
|
|
|
|
## Workflow
|
|
|
|
### Pas 1: Întrebări de clarificare
|
|
|
|
Înainte de a genera PRD-ul, pune 3-5 întrebări pentru a înțelege scopul:
|
|
|
|
```markdown
|
|
Pentru a genera un PRD bun, am câteva întrebări:
|
|
|
|
**A) Care este scopul principal?**
|
|
1. Funcționalitate nouă pentru utilizatori
|
|
2. Îmbunătățire performanță/scalabilitate
|
|
3. Refactoring/cleanup cod existent
|
|
4. Integrare cu sistem extern
|
|
|
|
**B) Cine sunt utilizatorii țintă?**
|
|
1. End users (clienți finali)
|
|
2. Admin/Staff intern
|
|
3. Developers (API/SDK)
|
|
4. Sistem automatizat
|
|
|
|
**C) Ce constrângeri tehnice există?**
|
|
1. Trebuie să folosească framework/librărie existentă
|
|
2. Fără dependențe externe noi
|
|
3. Compatibilitate backwards necesară
|
|
4. Flexibil
|
|
|
|
**D) Care e prioritatea?**
|
|
1. Urgent (blocant pentru release)
|
|
2. Important (următorul sprint)
|
|
3. Nice-to-have (când e timp)
|
|
|
|
**E) Ai specificații vizuale sau mockups?**
|
|
1. Da, am wireframes/mockups
|
|
2. Am idee generală în minte
|
|
3. Flexibil, propune tu
|
|
```
|
|
|
|
### Pas 2: Generează PRD-ul
|
|
|
|
După răspunsuri, creează documentul în `/tasks/prd-[feature-name].md`:
|
|
|
|
```markdown
|
|
# PRD: [Feature Name]
|
|
|
|
## 1. Introducere
|
|
[Context și motivație pentru feature - 2-3 propoziții]
|
|
|
|
## 2. Obiective
|
|
### Obiectiv Principal
|
|
- [Ce problem rezolvă]
|
|
|
|
### Obiective Secundare
|
|
- [Beneficii adiționale]
|
|
|
|
### Metrici de Succes
|
|
- [Cum măsurăm dacă e reușit]
|
|
|
|
## 3. User Stories
|
|
|
|
### US-001: [Titlu Descriptiv]
|
|
**Ca** [tip utilizator]
|
|
**Vreau** [funcționalitate]
|
|
**Pentru că** [beneficiu]
|
|
|
|
**Acceptance Criteria:**
|
|
- [ ] Criteriu 1 specific și testabil
|
|
- [ ] Criteriu 2 specific și testabil
|
|
- [ ] npm run typecheck passes
|
|
- [ ] [Pentru UI] Verify in browser that [comportament specific]
|
|
|
|
### US-002: [Titlu]
|
|
...
|
|
|
|
## 4. Cerințe Funcționale
|
|
1. [REQ-001] Sistemul trebuie să...
|
|
2. [REQ-002] Utilizatorul poate să...
|
|
3. [REQ-003] Când X se întâmplă, Y trebuie să...
|
|
|
|
## 5. Non-Goals (Ce NU facem)
|
|
- [Explicit ce nu e în scope pentru a evita scope creep]
|
|
- [Funcționalități similare care NU sunt incluse]
|
|
|
|
## 6. Considerații Tehnice
|
|
### Stack/Tehnologii
|
|
- [Ce framework/librării se folosesc]
|
|
|
|
### Patterns de Urmat
|
|
- [Patterns existente în codebase]
|
|
|
|
### Dependențe
|
|
- [De ce depinde acest feature]
|
|
|
|
### Riscuri Tehnice
|
|
- [Potențiale probleme]
|
|
|
|
## 7. Considerații UI/UX
|
|
[Dacă e relevant]
|
|
- Layout și flow
|
|
- Stări (loading, error, empty, success)
|
|
- Accesibilitate
|
|
|
|
## 8. Success Metrics
|
|
- [KPI 1]: [target]
|
|
- [KPI 2]: [target]
|
|
|
|
## 9. Open Questions
|
|
- [ ] [Întrebări nerezolvate care necesită clarificare]
|
|
```
|
|
|
|
### Pas 3: Validare cu utilizatorul
|
|
|
|
După generare, întreabă:
|
|
- "PRD-ul acoperă tot ce ai în minte?"
|
|
- "Vrei să adaugi sau să modifici ceva?"
|
|
- "Stories-urile sunt de mărime potrivită pentru implementare incrementală?"
|
|
|
|
### Pas 4: Salvare
|
|
|
|
```bash
|
|
# Crează directorul tasks dacă nu există
|
|
mkdir -p tasks
|
|
|
|
# Salvează PRD-ul
|
|
# Folosește kebab-case pentru nume
|
|
```
|
|
|
|
### Pas 5: Sugerează următorul pas
|
|
|
|
```markdown
|
|
PRD salvat în tasks/prd-[feature-name].md
|
|
|
|
**Următorii pași:**
|
|
1. Revizuiește PRD-ul și adaugă detalii dacă e nevoie
|
|
2. Când ești gata, folosește `/ralph:convert` pentru a converti în prd.json
|
|
3. Apoi rulează `./scripts/ralph/ralph.sh` pentru implementare autonomă
|
|
```
|
|
|
|
## Reguli pentru User Stories bune
|
|
|
|
### Mărime potrivită (1 context window):
|
|
- Adaugă un câmp în DB + migration
|
|
- Creează un component React simplu
|
|
- Implementează un endpoint API
|
|
- Scrie unit tests pentru o funcție
|
|
|
|
### Prea mare (trebuie spart):
|
|
- "Implementează autentificarea" → sparge în: login form, register form, JWT middleware, session management
|
|
- "Creează dashboard" → sparge în: layout, charts component, data fetching, filtering
|
|
|
|
### Ordine dependențe:
|
|
1. Database/Schema (nu depind de nimic)
|
|
2. Backend logic (depind de schema)
|
|
3. API endpoints (depind de backend)
|
|
4. UI components (depind de API)
|
|
5. Integration (depind de toate)
|
|
|
|
### Acceptance Criteria:
|
|
- Specifice: "Butonul Submit trimite form data la POST /api/users"
|
|
- NU vagi: "Funcționează corect"
|
|
|
|
- Verificabile: "După submit, redirect la /dashboard"
|
|
- NU subiective: "UX plăcut"
|
|
|
|
- Include ÎNTOTDEAUNA: "npm run typecheck passes"
|
|
- Pentru UI: "Verify in browser that [behavior]"
|
|
|
|
## Output așteptat
|
|
|
|
- Fișier `/tasks/prd-[feature-name].md` cu documentație completă
|
|
- User stories clare, atomice, cu acceptance criteria verificabile
|
|
- Non-goals explicit definite
|
|
|
|
## Important
|
|
|
|
1. **NU începe implementarea** - acest skill doar generează documentație
|
|
2. **Întreabă clarificări** înainte de a genera
|
|
3. **Stories atomice** - fiecare trebuie să fie independent completabil
|
|
4. **Acceptance criteria verificabile** - nu vagi
|
|
5. **Kebab-case** pentru nume fișiere
|