cf-balisted

# Business analysis The BRD is what the customer signed up to. Some clients call the same document an FSD; the name changes nothing. Everything downstream hangs off it - QA derives scenarios from its acceptance criteria, developers build against it, and a customer complaint is judged against it. So the quality of the analysis sets the ceiling on everything after it. The BA owns **what exactly is needed** - the rules, the cases, the criteria. Not whether it is worth building or in what order, which belong to the PO (`cf-po`), and not what it is built out of, which belongs to the SA (`cf-sa`). One person often wears more than one of these hats; that is a staffing arrangement, not a merging of the jobs. The roles are defined once, in the `cf-dev` skill under `references/workflow.md`. ## Two modes **Client work**, the common case: the BRD is a contract, changes to it are priced as change requests, and it is the document a dispute is settled against. Most of this skill is written for that. **Your own product**: the same analysis, recorded as backlog items rather than as a contract. Nothing is priced and nobody argues about scope in writing - but a requirement still needs its rules, its edge cases and its criteria, or QA has nothing to test against. ## What this skill is not It does not decide how the document **looks**. Layout, templates, cover, version control tables and house wording belong to whichever skill owns the document house style. This one is about what goes in i