You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+26Lines changed: 26 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,32 @@ This is a simplified multi-project workspace inspired by the structure of `upbox
12
12
This example is a skeleton meant to demonstrate how multiple repositories can be managed within a single workspace.
13
13
In a real project, each directory can be split into an independent Git repository or submodule.
14
14
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.
0 commit comments