Writing PRD flows Dezycro can check¶
Dezycro reads your PRD, draws the Flow Map from it, and turns each flow into a journey the verifier can run against the product. You write the PRD in plain language. The developer, or their coding agent, publishes the API description. Dezycro matches your flows to that API and builds the checks.
You never need to know how the API works to write a checkable flow. This page is what does matter.
1. Write what a person does and what happens¶
Describe each flow as actions and results, in everyday words. Keep the "The user … / the system …" rhythm: it's how Dezycro recognises a section as behaviour rather than background.
The admin pauses the schedule. The system skips the next scheduled job and shows the schedule as paused.
2. End every flow on a named result¶
The last line of a flow names the thing and its new state. That is what the verifier will look for.
| Ends well | Ends badly |
|---|---|
| "…the job is skipped" | "…and it works" |
| "…the card is approved" | "…done" |
| "…the export is ready to download" | "…the user is happy" |
| "…the invite is rejected and the user sees why" | "…an error happens" |
A flow that ends on a vague word gives Dezycro nothing to check.
3. Say who may act, and who may not¶
Put permissions inside the flow or next to it: "Only admins can pause a schedule. A viewer who tries is refused." Each "may not" becomes a check of its own.
4. Keep flows under flow or feature headings¶
Dezycro looks for behaviour under headings such as User flows, Flows, or the feature's own name. It skips sections headed API, Dependencies, Assumptions, Out of scope, Roles and responsibilities and similar, so a flow written there is not picked up.
5. Don't write endpoints, methods, status codes or field names¶
Leave GET /jobs/{id}, 200, status: SKIPPED and the like out of the PRD. They are not read, and they clutter the document for everyone else. The developer's published API description supplies all of that, and Dezycro matches your plain outcome to it.
One flow, one result
If a flow has two outcomes (the happy path and a refusal), write it as two flows. Each ends on its own named result.
What you see afterwards¶
- The Flow Map with one journey per outcome. If a journey is missing or invented, the PRD wording is usually the cause; the Flow Map page has a review checklist.
- On the feature's Verify tab, each journey with its run result once the developer has published the API description and run the verifier.
If a journey can't be verified, the fix is almost always on the API side; the developer's guide is Making your API verifiable. You are only asked to change the PRD when a flow's result is unclear.