Skip to content

Commit bebc5c6

Browse files
committed
docs: describe PRD-driven feature workflow
1 parent 0a60399 commit bebc5c6

1 file changed

Lines changed: 26 additions & 0 deletions

File tree

README.md

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,32 @@ This is a simplified multi-project workspace inspired by the structure of `upbox
1212
This example is a skeleton meant to demonstrate how multiple repositories can be managed within a single workspace.
1313
In a real project, each directory can be split into an independent Git repository or submodule.
1414

15+
## Objective
16+
17+
The main objective of this workspace is docs-first product development.
18+
19+
The idea is simple:
20+
21+
- write a Product Requirements Document in `docs/prd/`
22+
- use that PRD as the source of truth for the feature
23+
- generate or implement the related changes in `backend`, `frontend`, and `e2e-test`
24+
25+
This means the starting point for a new feature is not code. The starting point is a clear product document that explains what should happen, what is out of scope, and how the result should be validated.
26+
27+
If you are acting as the product side of the workflow, your job is to write the PRD. You do not begin by editing application code. You describe the feature well enough that the implementation and tests can be created from the document.
28+
29+
## How To Make A Feature
30+
31+
1. Create a new PRD file under `docs/prd/`, for example `docs/prd/user-profile.md`.
32+
2. Describe the feature in product terms first: background, user problem, goals, and non-goals.
33+
3. Define the expected backend behavior: endpoints, request and response shape, validation rules, and database impact if needed.
34+
4. Define the expected frontend behavior: screens, states, empty/error/loading cases, and the API data it needs.
35+
5. Define the expected `e2e-test` coverage: the main user flow, important API checks, and acceptance criteria.
36+
6. Mark anything intentionally out of scope so the implementation stays focused.
37+
7. Use the PRD as the handoff document for building the feature across `backend`, `frontend`, and `e2e-test`.
38+
39+
In short: this workspace exists so that one good PRD in `docs/` can drive one complete feature across multiple projects.
40+
1541
## Quick Start
1642

1743
```bash

0 commit comments

Comments
 (0)