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.
- Autor
- waynesutton ↗
- Repozytorium
- builder-skills ↗
- Licencja
- Apache-2.0
- Ostatnia zmiana repozytorium
- 09.11.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 5
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 0
Brak sygnałów. Repozytorium zmienione 09.11.2026, bez odwołań do wycofanych modeli i API.
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
- When to write one
- When to skip it
- Location and naming
- Template
- Filling it in
- After writing it
- Never
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
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · waynesutton/builder-skills | 100 | Apache-2.0 |
| drvoss/everything-copilot-cli | 100 | MIT |
| globalmindsolution/gms-marketplace | 100 | MIT |
| borghei/Claude-Skills | 100 | MIT |
| FradSer/dotclaude | 100 | MIT |
| tarunccet/pm-skills | 100 | MIT |
| platformplatform/platformplatform | 100 | MIT |
| ar4mirez/samuel | 100 | MIT |
| j4flmao/agent-skills | 95 | MIT |
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.