---
model: opus
---

# /tas-brd $ARGUMENTS

Role: PE - Product Engineer
Create or update Business Requirements Document.

## Actions
1. Read root/tas.yaml for project context
2. Check if docs/brd.md already exists:

### CREATE mode (file doesn't exist):
3. Read .tas/templates/BRD.md
4. If $ARGUMENTS has content, use as initiative/problem description input
5. If no $ARGUMENTS, ask user:
   - What is the top strategic intent (this becomes `BO-NNN` — one line, no metrics)?
   - What measurable outcomes must this initiative achieve, and which BO does each serve (these become `BR-NNN`, each referencing exactly one BO)?
   - Who or what interacts directly with the product (these become `AT-NNN` Actors — mark each Human or External system)?
   - What core business objects (entities) and their lifecycle states does the business operate?
   - What business rules / policies must always hold (each with its scope + source), and what is the agreed business flow?
   - What is in scope vs out of scope?
   - Are there business, technical, NFR, security/compliance constraints or assumptions?
6. Create file docs/brd.md per template — fill every section in the governance order (BO → PS → SC → BR → BRU → Actor → BF → Entity → Entity State → CA):
   - **Business Objective** `BO-NNN` — strategic one-liners, no measurable numbers (those are BRs). 1 BO : N BR.
   - **Business Requirement** `BR-NNN` — each references exactly one `BO-NNN` (fill the BO Ref column).
   - **Business Rule** `BRU-NNN` — each with scope (entity/flow it governs) + source (regulatory/business policy).
   - **Actors** `AT-NNN` — Human vs External system. Human → downstream Persona (PRD); External → Integration Contract + System Context (SAD).
   - **Business Flow** — every step names its actor by `AT-NNN`, no free-text role names.
   - **Entities** `E-NNN` (business name + definition only), **Entity States** (conditional — `N/A` for reference/master data), and Glossary.
   - Stakeholders, Timeline, and Cost-Benefit are NOT in the BRD — they belong to the Project Charter.
6a. **Business Completeness pass** — before the coverage gate, apply `.tas/rules/common/business-completeness.md`: walk the lenses and present any gap as a candidate table for the PE to approve / reject / mark N/A. Fold approved candidates into the BRD (new `AT-NNN` / `BF` / `BRU` / `BR` / Assumption), then record every lens's disposition in the `## Completeness Disposition` table. This catches whole missing categories (e.g. "who administers users?", "who creates this entity?") that traceability alone cannot see.
6b. **Run the `coverage-auditor` agent on the BRD before handing off** (see `.tas/agents/coverage-auditor.md`) — it checks every BO has ≥1 BR, every BR references exactly one BO, every referenced Entity is defined, and every Actor appears in ≥1 Business Flow or is marked external. Surface its pass/fail report so the PE approves on evidence, not by feel. It also confirms every business-completeness lens is dispositioned (Covered or N/A) in `## Completeness Disposition` — a blank or missing lens blocks approval.
7. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add `artifacts.brd`

### UPDATE mode (file exists):
3. Read current docs/brd.md **in full first** — never regenerate blind. Preserve any human edits; merge changes into the existing content rather than overwriting whole sections.
4. $ARGUMENTS is change description. If not provided, ask user which section to update.
5. Update file, keep unchanged sections as-is
5b. Re-run the Business Completeness pass (step 6a) for any newly added Actor / Entity / Flow, and update the `## Completeness Disposition` table.
6. 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 (email/file the customer signed + signer + date).
7. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `artifacts.brd`

## Principles
- **BRD is business-level only** — no technical implementation detail, no architecture decisions
- **BO (BO-NNN) = one strategic statement of intent.** No measurable numbers here (those are BRs). Cardinality 1 BO : N BR.
- **BR (BR-NNN) = a measurable business outcome — the WHY the initiative exists, NOT a feature.** Each BR references **exactly one BO**. System behaviour ("user can checkout as guest") is an FR and belongs in the PRD, never here. If the initiative were cancelled, the BRs are exactly what would not be achieved.
- **Business Rules (BRU-NNN)** are stable cross-cutting policies, not features (e.g. "order confirmed only when payment succeeds"). Record **scope** (entity/flow) + **source** (regulatory/business policy) for each.
- **Actors (AT-NNN)** are whoever interacts directly with the product — Human or External system. Distinct from Stakeholders (Project Charter). Business Flow steps reference actors by `AT-NNN` only.
- **Entities (E-NNN)** record business name + definition only — no attributes, no technical relationships. Mode is **Inline** (no separate Entity-Doc). Entity States use business language only and are conditional (`N/A` for reference/master data).
- Constraints use the five CA groups: Business, Technical, NFR, Security & Compliance, Assumption — NFR constraints seed PRD.NFR
- Always include Out of Scope items — explicit exclusions prevent scope creep
- BRs must be measurable with targets (e.g. "reduce by 30%" not "improve"); BOs are strategic and carry no numbers
- Mermaid diagrams must use :::mermaid wrapper, NO () characters; for line breaks in a label use `<br />`, not `\n`

- **Completeness is checked, not assumed** — a BRD passes only when every lens in `.tas/rules/common/business-completeness.md` is dispositioned Covered or N/A. Silent omission of a category (admin, entity creation, access governance) is the main way a BRD looks complete but isn't.

## Relationship to PRD
- BRD answers: **Why?** (business need, goals, constraints)
- PRD answers: **What?** (product behavior, features, acceptance criteria)
- 1 BRD → 1 PRD in this kit (Option A cardinality)
- PRD command (`/tas-prd`) reads BRD for context and generates summary link-back

## Final Step — Token Log

Apply `.tas/rules/common/token-logging.md` to `docs/brd.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 BRD template already includes the skeleton — replace `~{N}k` with actual estimates.