--- model: opus --- # /tas-prd $ARGUMENTS Role: PE - Product Engineer Create or update Product Requirements Document. ## Actions 1. Read root/tas.yaml for project context 2. Check if docs/brd.md exists — store result as HAS_BRD (yes/no) 3. Check if docs/prd.md already exists: ### CREATE mode (file doesn't exist): 4. Read .tas/templates/PRD.md 5. **BRD is the upstream source of truth.** If HAS_BRD = yes: read docs/brd.md (objectives, problem, BRs, entities, business flow, scope) — the PRD references it and never restates business analysis. If HAS_BRD = no: tell the user that business context, BRs, and entities belong in a BRD and recommend running `/tas-brd` first so FRs stay traceable; proceed only if the user insists, defining minimal BR-NNN inline. 6. If $ARGUMENTS has content, use as product description input 7. If no $ARGUMENTS, ask user: - What product or feature does this PRD cover? - Who are the primary users / personas? - What are the core features (P0 must-haves) and which BR does each serve? - Any integration constraints? (NFR seeds from BRD.Constraint & Assumption) 8. Create file docs/prd.md per template — set the header BRD link, then fill: - **Product Goal** `PG-NNN` (product-oriented, from BRD.BO + BRD.PS) — each PG references the `BR-NNN` it serves without copying the BR's numbers. This feeds both UI/UX design intent and Master Plan feature ordering. - **User Personas** — one per **human** `AT-NNN` from BRD.Actor (reference the AT); external-system actors get no persona. Role/goals/device/pain — no use-case stubs; journeys go in User Flows. - **User Flows** (derived from BRD.Business Flow), **Modules** (MOD-NN), **Product Data Model** (carry `E-NNN` codes from BRD.Entities — relationships only) - **Functional Requirements** — every FR carries a BR reference inline, e.g. `FR-001 (BR-001)` - **Non-Functional Requirements** (seed from BRD.Constraint & Assumption NFR group) - **Feature Map & Dependency** (group features by Module, flag cross-module deps as integration points) - **Out of Scope** (from BRD.Project Scope) 8b. **Product Completeness pass** — before the coverage gate, apply `.tas/rules/common/business-completeness.md` at the product tier: walk the lenses and present gaps as a candidate table for the PE to approve / reject / mark N/A. Fold approved candidates in as new `FR-NNN` / Persona / `MOD-NN` / NFR. Cross-check each new category upstream in the BRD — if the category is missing there too (e.g. a missing Actor), flag `⚠ BRD gap → run /tas-brd UPDATE` instead of inventing business analysis in the PRD. Record every lens's disposition in the `## Completeness Disposition` table. 9. **Coverage gate (run the `coverage-auditor` agent on the PRD):** the PRD gate checks both directions — - *Anti-missing:* every BR has ≥1 FR; every BRU maps to ≥1 FR that will enforce it; **every FR is grouped under ≥1 Module and every Module holds ≥1 FR** (FR↔Module coverage lives here, not in the SAD); every human Actor leads to ≥1 Persona; every PG references ≥1 BR. - *Anti-excess:* every FR references a valid BR (an FR with no BR is gold-plating → flag for PE); every Persona traces to one Actor. - *Completeness:* every business-completeness lens is dispositioned in `## Completeness Disposition` (Covered with a valid Persona/FR/Module/NFR ref, or `N/A — reason`); no blank or missing lens. - Fail-mode: PRD `artifact-status: draft` → ⚠ warn and continue; `approved` → **hard-block** until fixed. 10. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add `artifacts.prd` ### UPDATE mode (file exists): 4. Read current docs/prd.md **in full first** — never regenerate blind; preserve human edits and merge changes into existing content. 5. If HAS_BRD = yes: read docs/brd.md to stay aligned (especially BO/BR IDs, `AT-NNN` actors, and `E-NNN` entity codes) 6. $ARGUMENTS is change description. If not provided, ask user which section to update. 7. Update file, keep unchanged sections as-is 7b. Re-run the Product Completeness pass (step 8b) for any newly added FR / Persona / Module and update the `## Completeness Disposition` table. 8. Re-run the coverage gate (step 9) for any changed/added FR/Module/PG 9. Add line to Changelog section at end: date, change description. If this update sets the version to Approved, fill the **Customer Sign-off Reference** column. 10. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `artifacts.prd` ## Principles - **Structure (flat top-level sections, in this order):** Product Goal → User Personas → User Flows → Product Data Model → Functional Requirements → Non-Functional Requirements → Out of Scope → Modules → Feature Map & Dependency. No wrapper sections — each sub-artifact is its own `##` heading. (Modules and Feature Map & Dependency are decomposition/planning outputs, placed after scope is fixed.) The header carries a one-line BRD link only. **No Product Specification wrapper, no Business Context, no Executive Summary, no Go-to-Market, no Timeline** (those live in the BRD), **no Use Cases** (covered by User Flows + Feature Spec.User Flow), **no product Risk table** (risks belong to the Risk Record / SAD §14). - **PRD never restates business analysis** — the BRD is the single source of truth; the PRD references it and adds only the product layer - **Product Goal (PG-NNN)** is product-oriented and references the BR(s) it serves — it does not copy BR numbers. It is the design-intent source for UI/UX and the priority axis for the Master Plan. - **Personas derive from BRD.Actor** — one per human `AT-NNN` (referenced), external-system actors excluded. - **FR = system behaviour (the WHAT); it must trace to a BR (the WHY).** Never restate a BR as an FR, and never put a system behaviour in the BRD as a BR. - **FR ↔ Module is a grouping relation, checked here (not in the SAD).** A Module groups FRs by business area + core entity; an FR may be grouped under one or more Modules and a Module holds many FRs. The SAD inherits Modules 1-to-1 and does its coverage at the Component level. - **No Technical Specifications section** — architecture belongs in the SAD, not the PRD - **User Flows** are high-level journeys (no per-screen detail); **Modules** group features and map 1-to-1 to a SAD Module (a logical component grouping inside a SAD Container, not a Container itself); **Product Data Model** shows entity relationships only, using `E-NNN` codes — no attributes/cardinality - Write Acceptance Criteria in Given/When/Then format — each AC generates test ID + automated test; an EARS phrasing of the core trigger is encouraged - Write at sufficient detail for SE to understand and design architecture - **Do not group FRs by MoSCoW** — list FRs flat; priority is captured upstream in BRD.Business Requirement and in the Feature Map & Dependency table - Each requirement has unique ID: FR-001, NFR-001; each FR shows its BR ref inline as `FR-001 (BR-001)` - Always fill the Out of Scope section to limit scope (sourced from BRD.Project Scope) - Mermaid diagrams must use :::mermaid wrapper, NO () characters; for line breaks in a label use `
`, not `\n` - **Completeness is checked at the product tier** — the PRD passes only when every lens in `.tas/rules/common/business-completeness.md` is dispositioned. A product-tier gap that is really a business gap (missing actor/objective) routes back to the BRD, never invented here. ## Flow Context - Upstream: **BRD → PRD** → Feature → Feature-Technical (BRD is the expected upstream; business context, BRs and entities live there) - `/tas-brd` creates `docs/brd.md` (business level: objectives (BO), measurable requirements (BR), rules (BRU), actors, entities, constraints) - `/tas-prd` creates `docs/prd.md` (product level: features, AC, UX, NFR) - `/tas-feature` uses PRD as input to create Feature files ## Final Step — Token Log Apply `.tas/rules/common/token-logging.md` to `docs/prd.md` NOW (do not defer, do not leave placeholder text). Estimate input/output tokens from this session per the rule, then fill the `## AI Usage Log` table row and Total. The PRD template already includes the skeleton — replace `~{N}k` with actual estimates.