From aidoc-flow
Creates a Business Requirements Document (BRD) — Layer 1 of the SDD workflow — defining business needs, objectives, scope, and success criteria for a new project or feature.
How this skill is triggered — by the user, by Claude, or both
Slash command
/aidoc-flow:doc-brdThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create a **Business Requirements Document (BRD)** — Layer 1 of the SDD flow.
Create a Business Requirements Document (BRD) — Layer 1 of the SDD flow. A BRD captures business objectives, stakeholder needs, scope, and success criteria in business language, before any product or technical detail.
Layer: 1 — entry point, no upstream artifacts. Downstream: PRD → EARS → BDD → ADR → SPEC → TDD → IPLAN → Code.
Each BRD represents one MVP iteration (5–15 focused requirements). New
features get a new BRD rather than expanding an existing one; link cycles with
@depends: BRD-NN.
Use doc-brd when:
For end-to-end generation from reference docs, a prompt, or an IPLAN, use
../doc-brd-autopilot/SKILL.md. For a new project skeleton, run
../project-init/SKILL.md first.
BRD is the entry point, so there are no upstream artifacts to verify. Before writing, read:
framework/layers/01_BRD/BRD-TEMPLATE.yamlframework/layers/01_BRD/README.mdframework/governance/ID_NAMING_STANDARDS.mdConfirm no ID collision: ls docs/01_BRD/ 2>/dev/null. Never invent
placeholders like BRD-XXX or reference documents that do not yet exist.
| Signal | Type |
|---|---|
| Defines infrastructure, technology stack, or cross-cutting concerns | Platform |
| Other BRDs will depend on its architectural choices | Platform |
| Describes one user-facing workflow / feature | Feature |
| Builds on capabilities an existing Platform BRD established | Feature |
N/A — See Platform BRD-NN §3.6/§3.7 and
references the specific items.## Document Control comes first, before all numbered sections (project
name, version, date YYYY-MM-DD, owner, prepared-by, status, revision-history
table). Then:
See BRD-TEMPLATE.yaml for per-section content and cross_section_rules.
Identify architectural topics needing decisions, with cost-focused, alternatives-based analysis, across the 7 categories. Do not reference ADR numbers — ADRs do not exist yet.
| # | Category | When N/A |
|---|---|---|
| 1 | Infrastructure | Pure data/analytics project |
| 2 | Data Architecture | No persistent data |
| 3 | Integration | Standalone system |
| 4 | Security | Internal tool, no sensitive data |
| 5 | Observability | MVP/prototype only |
| 6 | AI/ML | No AI/ML components |
| 7 | Technology Selection | Using an existing stack |
Each Selected topic carries a BRD.NN.07.xxxx element ID and includes a
status, business driver, business constraints, an Alternatives Overview
table (with cost estimates), a Cloud Provider Comparison (GCP/Azure/AWS), a
recommended selection, and the PRD requirements it implies. Layer separation:
BRD §7.2 = what & why & how much; PRD = how to evaluate; ADR = the decision.
BRD.{doc_id}.{section_id}.{hash} (e.g.
BRD.01.07.a7f3; hash = first 4 hex of SHA256 of
"{doc_id}:{section_id}:{title}:{description}", extend to 8 on collision).@ upstream tags. Downstream artifacts
tag it: @brd: BRD.01.06.a7f3.AC-XXX, FR-XXX, BO-XXX, BC-XXX,
and the legacy 3-segment BRD.NN.xxxx.Most BRDs are authored from stakeholder input — keep the default
upstream_mode: "none". Only when content derives from docs/00_REF/ docs set
upstream_mode: "ref" and list upstream_ref_path (relative to the BRD file).
BRD-NN (two digits, no leading zero beyond two:
BRD-01, BRD-99, BRD-102).docs/01_BRD/BRD-NN_{slug}/
regardless of size. Monolithic: BRD-NN_{slug}.md inside it; section-based
(>25 KB): BRD-NN.S_{section}.md + index from
framework/layers/01_BRD/BRD-00_index.TEMPLATE.md.none default; ref if from docs/00_REF/).docs/01_BRD/BRD-00_index.md in the same change.The framework ships no runtime code — this skill is the validator. Apply the
checklist against framework/layers/01_BRD/README.md and
framework/governance/ID_NAMING_STANDARDS.md.
BRD.NN.SS.xxxx; no removed patterns.@diagram: c4-l1 and @diagram: dfd-l1 present (use
../charts-flow/SKILL.md); add a sequence tag if a sequence diagram
exists.| Code | Meaning | Severity |
|---|---|---|
| XDOC-006 | Tag format invalid | error |
| XDOC-008 | Broken internal link | error |
| XDOC-009 | Missing traceability section | error |
Quality gate (blocking): PRD-Ready score ≥ 90/100 before moving on. If issues are found, fix and re-check; if unfixable, log for manual review.
BRD-REF documents (
BRD-REF-NNN_{slug}.md, via../doc-ref/SKILL.md) are free-format reference targets — exempt from ready-scores, cumulative tags, and quality gates.
../doc-prd/SKILL.md — the PRD references this BRD (@brd: BRD.NN.SS.xxxx),
defines product features and KPIs, and inherits the §7.2 architecture topics.
Before applying defaults, read the project adaptation profile
(.aidoc/profile.yaml). Honor only this skill's declared knobs:
section_toggles (include or omit template-declared optional sections)
and glossary (substitute preferred terms in generated prose). Ignore any
unknown or out-of-surface key; absent a profile, use framework defaults.
Authority: framework/governance/ADAPTATION.md.
framework/layers/01_BRD/BRD-TEMPLATE.yamlframework/layers/01_BRD/README.mdframework/layers/01_BRD/BRD-00_index.TEMPLATE.mdframework/governance/ID_NAMING_STANDARDS.md../doc-brd-audit/SKILL.md · Fixes: ../doc-brd-fixer/SKILL.md../doc-brd-autopilot/SKILL.md| Purpose | Define business needs and objectives |
| Layer | 1 (entry point) |
| Upstream tags | None |
| Key decision | Platform vs Feature |
| Must include | Document Control (first), §7.2 (7 categories), 18 sections |
| Next | doc-prd |
npx claudepluginhub vladm3105/aidoc-flow-framework --plugin aidoc-flowDrafts or refines Business Requirements Documents (BRDs) covering problem, goals, value, constraints, metrics, risks, and investment rationale. Useful for business justification before product specs.
Creates a Product Requirements Document (PRD) from an upstream BRD, defining product features, personas, success metrics, and acceptance criteria at the C4 Container level. Use after BRD exists and before EARS.
Generates formal product requirements from ideas and goals: BRD, user stories, acceptance criteria, prioritization via CEO interview, domain research, and structured protocols.