prdlisted

# PRD — Product Requirements (WHAT) **Template:** `references/default-template.md` — local reference, kept up to date with the standard structure. ## Default guardrails (before any final content) 1. Apply **`output-handshake`**: confirm **where** the final PRD will be stored (path, Doc page, task, paste-only, etc.) and that a **human** will review. Engagements may store PRDs in different places; do not assume. 2. Then follow the steps below. ## When to use - A feature or product increment needs a **shared agreement** on scope, users, and acceptance. - The team must **trace** work from PRD → implementation → tests. - An engagement uses an **Operations**-style doc hub with linked requirements documents. ## Instructions 1. **Open the PRD template** (`references/default-template.md`) and keep section headings **aligned** with it: Objective, User flow / Personas, Entities & use cases, Acceptance criteria, Edge cases, Integrations, Timeline, Approvals. 2. For **discovery** in an existing repository, delegate repository inspection to **`assistant`**; cite `AGENTS.md` and test/lint commands from the project. 3. **Acceptance criteria** must be testable and in **English** for work items/PRs (match `workflow-generic-project`). 4. Link **stakeholder approval** to your engagement process (task lists, doc pages, or client sign-off). Do not invent sign-off if not agreed. 5. For **ticket updates**, use the appropriate tool (`clickup-cli`, `jira-*`, etc.) to post a short plan comment o