Przejdź do treści
Biblioteka skilli
Zarządzanie i produkt · Planowanie

create-prd

/create-prd

Pisze krótki dokument PRD w katalogu prds przed nietrywialną pracą: problem, przyczynę błędu, proponowane rozwiązanie, pliki, przypadki brzegowe i kryteria sprawdzenia.

Repozytorium
builder-skills ↗
Licencja
Apache-2.0
Ostatnia zmiana repozytorium
09.11.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
5
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 09.11.2026, bez odwołań do wycofanych modeli i API.

Licencja

Apache-2.0, otwarta: można używać i zmieniać, z zachowaniem licencji i informacji o zmianach.

Co robi i kiedy

Pisze krótki dokument PRD w katalogu prds przed nietrywialną pracą: problem, przyczynę błędu, proponowane rozwiązanie, pliki, przypadki brzegowe i kryteria sprawdzenia.

Oryginalny opis (EN)

Writes a short PRD in prds/<slug>.md before non trivial work: problem, root cause for bugs, proposed solution, files to change, edge cases, verification steps, and a completion log, with UTC metadata. Then queues the work in task.md. Use before any multi file feature, schema change, architectural decision, or bug that took real investigation, or when the user says write a PRD, @create-prd, or plan this.

Jak działa

  1. When to write one
  2. When to skip it
  3. Location and naming
  4. Template
  5. Filling it in
  6. After writing it
  7. Never
Sekcje z nagłówków SKILL.md, w oryginale · 73 linii, 439 słów
Podgląd SKILL.md
---
name: create-prd
description: "Writes a short PRD in prds/<slug>.md before non trivial work: problem, root cause for bugs, proposed solution, files to change, edge cases, verification steps, and a completion log, with UTC metadata. Then queues the work in task.md. Use before any multi file feature, schema change, architectural decision, or bug that took real investigation, or when the user says write a PRD, @create-prd, or plan this."
---

# Create a PRD

A PRD is the scope contract for one change. Write it before the code, keep it under two screens, and update it when the plan changes.

Activate with `@create-prd`, `/create-prd`, or "write a PRD".

## When to write one

- Three or more files will change
- The schema changes
- An architectural choice is being made (auth, hosting, data model)
- A bug took real investigation to diagnose
- The work will be referenced later as a migration guide or how-to

## When to skip it

- A single file fix that is obvious from logs or types
- A typo, a CSS tweak, or a label change
- A copy change to markdown content

## Location and naming

- Every PRD lives in `prds/`.
- File name: `prds/<feature-or-problem-slug>.md`, kebab case. Example: `prds/adding-email-auth.md`.
- Always `.md`, never `.prd`.
- Finished or sensitive PRDs move to `prds/archive/`.

## Template

Copy the full template from [references/prd-template.md](references/prd-template.md). The required parts:

```markdown
# <Feature or problem, sentence case>

Created: YYYY-MM-DD HH:mm UTC
Last Updated: YYYY-MM-DD HH:mm UTC
Status: Draft | In Progress | Done

## Problem
## Root cause            (bugs only)
## Proposed solution
## Files to change
## Edge cases
## Verification steps
## Out of scope
## Task completion log
```

Get the time from the system (`date -u +"%Y-%m-%d %H:%M UTC"`). Never invent it.

## Filling it in

- Problem before solution. If the problem section is thin, the solution is a guess.
- For bugs, name the root cause: the line, query, or design choice. If it is unknown, say so and list the two likeliest candidates.
- Files to change is the scope. If a file not on the list needs to change, update the PRD first.
- Edge cases save the next session. Write down anything non obvious you found.
- Each verification step has an expected result, so someone else could run it.
- Out of scope is where extra ideas wait. Link an issue or a new PRD if they should happen later.
- The completion log is append only.

## After writing it

1. Add the tasks to `task.md` under `## To Do` as checkable items, with the PRD path.
2. Share the PRD with the user if it has a real choice in it. Wait for an answer on that choice.
3. Start building only once the plan is clear. Update `Last Updated` and `Status` as it moves.

## Never

- Write a PRD for a one line change.
- Pad it. Two screens is plenty for most work.
- Mark it Done before its verification steps ran.
Pliki w paczce (5)
  • SKILL.md 3 KB
  • agents/openai.yaml 1 KB
  • assets/large-logo.png 3 KB
  • assets/small-logo.svg 1 KB
  • references/prd-template.md 2 KB

Wersje

RepozytoriumWynikLicencja
Ta strona · waynesutton/builder-skills100Apache-2.0
drvoss/everything-copilot-cli100MIT
globalmindsolution/gms-marketplace100MIT
borghei/Claude-Skills100MIT
FradSer/dotclaude100MIT
tarunccet/pm-skills100MIT
platformplatform/platformplatform100MIT
ar4mirez/samuel100MIT
j4flmao/agent-skills95MIT

Migawka bazy z 13.11.2026 · wersja paczki f87ef964da76 (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100writing-feature-prds
    Pisze PRD i specyfikację wymagań przed implementacją nowej funkcji, gdy użytkownik mówi o nowej funkcji albo prosi o PRD.
  • 100prd-feature-specification
    Pisze wykonalne dokumenty wymagań produktowych i specyfikacje funkcji: problem, persony, metryki OKR i KPI, wymagania funkcjonalne i niefunkcjonalne, przypadki brzegowe, granice zakresu i kryteria wydania.
  • 100authoring-prds
    Prowadzi wywiad i pisze PRD produktu lub funkcji z kontraktami i testami, z folderem dla agentów.
  • 100product-requirements
    Zamienia niejasny pomysł w testowalne PRD: problem, użytkowników, ścieżki, zakres, przypadki brzegowe i kryteria akceptacji.
  • 95prd-development
    Buduje uporządkowany PRD łączący problem, użytkowników, rozwiązanie i kryteria sukcesu, gdy notatki z discovery trzeba zamienić w dokument gotowy dla inżynierów.
  • 95prd-development
    Buduje uporządkowany PRD łączący problem, użytkowników, rozwiązanie i kryteria sukcesu, gdy notatki z discovery trzeba zamienić w dokument gotowy dla inżynierów.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.