---
roadcrew_template_name: "create-brd.md"
roadcrew_template_type: "command"
execution_mode: "auto-execute"
roadcrew_template_version: "v1.0"
roadcrew_last_updated: "2025-10-25"
roadcrew_min_version: "1.5.0"
roadcrew_license: "See LICENSE file in .roadcrew folder"
roadcrew_copyright: "Copyright (c) 2025 North Star Holdings, LLC"
spdx_license_identifier: "LicenseRef-RoadcrewLicense-1.0"
---

# create-brd

<!-- Usage: /create-brd [path/to/source-document.md] [--output path/to/output-brd.md] -->

You are transforming a source document (strategy doc, monetization plan, business plan, narrative BRD, PRD, or spec) into a ruthlessly concise, AI-parseable Business Requirements Document following `templates/brd.template.md`.

**Input Documents:** Strategy docs, business plans, monetization plans, narrative BRDs, PRDs (extract business context), specs (extract business context)
**Output:** Structured BRD optimized for reference by PRD and Spec (no duplication)
**Template:** `templates/brd.template.md`

**Core Principles:**
1. **Business context only** - Market, segments, pricing, revenue, goals
2. **Reference not duplicate** - PRDs/Specs reference BRD sections, never copy
3. **Strict length limits** - Every field has max words/bullets
4. **Table/bullet driven** - Pricing, GTM, metrics, risks all in tables
5. **Atomic bullets** - No narrative except Executive Summary (≤40 words)

---

## WORKFLOW

### 0. PRE-FLIGHT CHECKS

**Read required context:**
- Source document (provided by user)
- `templates/brd.template.md` (the output format)
- `templates/prd.template.md` (downstream requirements)
- `templates/spec.template.md` (downstream requirements)
- `templates/release.template.md` (downstream requirements)

**Validate source document:**
- Contains business strategy, market info, pricing, or revenue model
- Has enough business context to extract
- If pure technical document: WARN and extract what's available
- If business/strategy doc: Perfect - extract business requirements
- If PRD/Spec with business context: Good - extract business sections only

### 1. CHECK EXISTING OUTPUT FORMAT (NEW STEP)

**Predict output path:**
```
If user provides --output flag: Use that path
If not: Predict path as context/brds/[feature-id]-brd.md
```

**If output file already exists:**
```bash
# Check if file exists
if [ -f "$OUTPUT_PATH" ]; then
  echo "Checking existing BRD format..."
  
  # Read type from frontmatter
  TYPE=$(head -20 "$OUTPUT_PATH" | grep "^type:" | sed 's/.*: //')
  VERSION=$(head -20 "$OUTPUT_PATH" | grep "^version:" | sed 's/.*: //')
  
  if [ "$TYPE" = "brd" ]; then
    echo "✓ Output file is already a properly formatted BRD (v$VERSION)"
    echo ""
    echo "Options:"
    echo "1. Keep existing BRD (skip transformation)"
    echo "2. Overwrite with new BRD (from source document)"
    echo "3. Cancel"
    echo ""
    read -p "Choose [1/2/3]: " choice
    
    if [ "$choice" = "1" ]; then
      echo "Skipping transformation. BRD already up-to-date."
      exit 0
    elif [ "$choice" = "3" ]; then
      echo "Cancelled."
      exit 0
    fi
    # choice 2 continues to transformation
  else
    echo "⚠️  Output file exists but is NOT a BRD (type: $TYPE)"
    echo "This will be overwritten. Proceed? (yes/no)"
    read -p "> " confirm
    if [ "$confirm" != "yes" ]; then
      exit 0
    fi
  fi
fi
```

**If output doesn't exist:**
```
Continue to transformation (new BRD will be created)
```

### 2. EXTRACT METADATA

**From source document, extract:**
- Business strategy name (feature name, product name, or initiative)
- Feature ID (kebab-case: `strategy-name`)
- Status (Draft by default)
- Version (1.0 by default)
- Business owner (if mentioned, or leave as placeholder)
- Related vision path (default: `../vision.md`)
- Related PRD path (if mentioned, or predict: `../prds/[feature-id]-prd.md`)
- Creation date (today if new, original date if reformatting)

**Populate YAML frontmatter:**
```yaml
---
type: brd
title: [Business Strategy Name]
feature_id: [strategy-name]
status: Draft
version: 1.0
owner: [business-owner]
created: 2025-10-24
updated: 2025-10-24
related_vision: ../vision.md
related_prd: ../prds/[feature-id]-prd.md
---
```

### 3. EXECUTIVE SUMMARY (≤40 words)

**Synthesize from source into single paragraph:**
- Market opportunity
- Target audience
- Why this matters for the business
- One-liner pitch

**Structure:** "[Product/Strategy] enables [audience] to [value prop] by [approach]. This addresses [market need] and positions us to [business outcome]."

**If not explicit in source:** Synthesize from business goals and market context

### 4. BUSINESS CONTEXT

#### 4.1 Market & Target Segments (max 4 bullets)
**Extract from source:**
- Look for: target customers, market segments, personas, audience
- Each bullet: ≤15 words
- Focus on WHO we're selling to

**Example:**
```markdown
- Semi-technical founders building SaaS products (500-5000 users)
- Product teams at growth-stage startups (10-50 employees)
- Enterprise engineering orgs with multi-repo architectures
- Open source maintainers managing complex release cycles
```

#### 4.2 Revenue Streams (max 3 bullets)
**Extract from source:**
- Look for: pricing models, revenue sources, monetization strategy
- Each bullet: ≤15 words
- Focus on HOW we make money

**Example:**
```markdown
- Freemium SaaS: Token-based AI usage, premium automation features
- Professional Services: Consulting, implementation, custom template development
- Enterprise licenses: Multi-repo orchestration, self-hosted deployments
```

#### 4.3 Differentiators (max 3 bullets)
**Extract from source:**
- Look for: competitive advantages, unique value props, "only" statements
- Each bullet: ≤15 words
- Focus on WHAT makes us different

**Example:**
```markdown
- Only AI-native spec-driven development platform with agent orchestration
- Built-in token tracking and cost attribution for transparent AI expenses
- Submodule architecture prevents namespace conflicts in existing projects
```

### 5. BUSINESS GOALS (≤5, each ≤15 words)

**Extract from source:**
- Look for: revenue targets, market share, growth objectives, strategic outcomes
- Must be measurable business outcomes
- Each: ≤15 words

**Example:**
```markdown
- Achieve $1.5M ARR by end of Year 1
- Convert 5% of free users to paid tier within 90 days
- Sign 5 enterprise customers at $999+/month each
- Reduce customer acquisition cost below $500 per paid customer
- Maintain >75% gross margin across all revenue streams
```

### 6. NON-GOALS / CONSTRAINTS (≤3, each ≤12 words)

**Extract from source:**
- Look for: market segments we're NOT targeting, features we're NOT building
- Helps set boundaries and manage expectations
- Each: ≤12 words

**Example:**
```markdown
- No visual UI dashboard (command-line only in v1.0)
- No support for non-SaaS projects (focus on SaaS only)
- Free tier remains manual (no AI agent automation)
```

### 7. PRICING MODEL (table, ≤3 tiers)

**Extract from source or synthesize:**
- Create structured pricing table
- Max 3 tiers (Free/Starter/Enterprise or similar)
- Key Features column: ≤6 words per tier
- Audience column: ≤5 words per tier

**Format:**
```markdown
| Tier        | Price        | Key Features                | Audience              |
|-------------|--------------|-----------------------------|-----------------------|
| Free        | $0           | Manual commands, 1 repo     | Solo, early adopters  |
| Starter     | $49/mo       | AI agent, 100k tokens       | Fast-moving founders  |
| Enterprise  | $999+/mo     | Multi-repo, unlimited AI    | Large companies       |
```

**If source has more than 3 tiers:** Consolidate or pick the 3 most important
**If source has no pricing:** Create reasonable tiers based on features mentioned

### 8. GTM ROADMAP (max 3 phases, ≤20 words per goal)

**Extract from source or synthesize:**
- Go-to-market phases
- Each phase: one bullet, ≤20 words
- Focus on market milestones, not technical milestones

**Example:**
```markdown
- **Phase 1:** Open source launch (100 GitHub stars, 20 active users, community feedback)
- **Phase 2:** Freemium launch (10 paid customers, 500 free tier users, $500 MRR)
- **Phase 3:** Enterprise push (5 enterprise customers, $5k+ MRR, partner integrations)
```

**If source has detailed GTM plan:** Condense to 3 key phases
**If source has no GTM plan:** Infer logical phases from business goals

### 9. METRICS (≤6 total, split across 3 categories)

**Extract from source:**
- Split into Product/Customer, Financial, Usage/Technical
- Max 2 metrics per category
- Each metric: ≤15 words

**Format:**
```markdown
### 7.1 Product/Customer Metrics
- MAU: 2,000 by end of Year 1
- Paid conversion rate: 5% (free tier to paid tier)

### 7.2 Financial Metrics
- ARR: $1.5M by end of Year 1
- Gross margin: >75% across all tiers

### 7.3 Usage/Technical Metrics
- AI token usage: track and limit by tier (100k/month Starter)
- Agent automation rate: 65%+ of commands in Enterprise tier
```

**If source has more metrics:** Pick the 6 most important (2 per category)
**If source has fewer metrics:** Infer reasonable targets from goals

### 10. KEY RISKS & MITIGATIONS (table, ≤4 risks)

**Extract from source or synthesize:**
- Business risks only (not technical risks - those go in spec)
- Each risk and mitigation: ≤15 words
- Focus on market, competition, pricing, churn

**Format:**
```markdown
| Risk                  | Mitigation              |
|-----------------------|------------------------|
| AI cost spikes        | Pass-through pricing, token caps per tier  |
| High churn rate       | Aggressive onboarding, usage analytics     |
| Competitors copy      | Community moat, patent agent orchestration |
| Consulting doesn't scale | Standardize playbooks, train partners   |
```

**If source has technical risks:** Convert to business risks or omit (they belong in spec)

### 11. REFERENCES & DOWNSTREAM

**Always include:**
```markdown
- **Product Vision:** [../vision.md](../vision.md)
- **PRD:** [../prds/{{FEATURE_ID}}-prd.md](../prds/{{FEATURE_ID}}-prd.md)
- **Spec:** [../specs/{{FEATURE_ID}}-spec.md](../specs/{{FEATURE_ID}}-spec.md)
```

**Purpose:** Enables PRDs/Specs to reference BRD sections rather than duplicating business context

### 12. EDITOR INSTRUCTIONS

**Always include at bottom:**
```markdown
## Editor Instructions:
- Update only as market conditions, pricing, or segment focus change—not for every feature.
- Downstream docs (PRD, Spec) must reference section numbers directly.
- Any redundant narrative, or exceeding bullet/word counts, invalidates the doc for automation or AI parsing.
```

### 13. VALIDATION & OUTPUT

**Before outputting, validate:**
- [ ] All length limits respected (no field exceeds max)
- [ ] Pricing table has ≤3 tiers with all 4 columns
- [ ] GTM roadmap has ≤3 phases
- [ ] Metrics split across 3 categories (2 per category)
- [ ] Risks table has ≤4 risks with mitigations
- [ ] Executive Summary ≤40 words
- [ ] No technical implementation details (those belong in spec)

**Output format:**
- If `--output` flag provided: Write to that path
- If no flag: Write to `context/brds/[feature-id]-brd.md`
- Display summary: "Created BRD with N segments, M tiers, [feature-id]-brd.md"

---

## EXAMPLE TRANSFORMATIONS

### Input: Strategy Doc (Monetization Strategy)
**Approach:**
- Extract: Business model (freemium + consulting)
- Extract: Target segments (solo founders, teams, enterprises)
- Extract: Pricing tiers (Free, Starter, Enterprise)
- Synthesize: GTM roadmap from timeline sections
- Extract: Revenue targets and success metrics
- Create: Risk/mitigation table from concerns mentioned

### Input: Narrative PRD (Submodule Isolation)
**Approach:**
- Extract business context: Problem statement → Executive summary
- Identify target audience: Who has namespace conflicts → Market segments
- Synthesize pricing: Premium features → Pricing tiers
- Extract goals: Reduce churn, improve adoption → Business goals
- Create metrics: Success criteria → Product/customer metrics
- Infer risks: Adoption challenges → Risks & mitigations

### Input: Technical Spec (extract business context only)
**Approach:**
- Reverse engineer: Technical solution → what business problem solved?
- Extract: Non-functional requirements → Business constraints
- Synthesize: Implementation phases → GTM roadmap phases
- Create: Business goals from motivation/context sections
- Infer: Target audience from use cases mentioned
- Estimate: Pricing based on feature complexity

---

## SEPARATION OF CONCERNS

**BRD vs PRD vs Spec - Crystal Clear Boundaries:**

**BRD Contains (BUSINESS CONTEXT):**
- Market segments and target audience
- Revenue streams and pricing model
- Business goals and success metrics
- GTM roadmap and phases
- Competitive differentiators
- Business risks and mitigations

**PRD Contains (WHAT/WHY):**
- Product requirements and features
- User goals and user stories
- Functional acceptance criteria
- Product success metrics
- User journeys
- References BRD for business context

**Spec Contains (HOW):**
- Technical architecture
- Implementation details
- API design, data models
- Technical acceptance criteria
- Testing strategy
- References BRD for constraints, PRD for requirements

**BRD MUST NOT Include:**
- Specific product features or requirements (those go in PRD)
- User stories or user journeys (those go in PRD)
- Technical implementation details (those go in Spec)
- Detailed acceptance criteria (those go in PRD/Spec)

**If source contains product features:** Move to PRD, not BRD
**If source contains technical details:** Move to Spec, not BRD

---

## DOWNSTREAM TEMPLATE MAPPING

**BRD → PRD:**
- Business Goals (3) → PRD Business Objectives (1.1)
- Metrics (7) → PRD Success Metrics (3)
- Target Segments (2.1) → PRD User Goals context
- Differentiators (2.3) → PRD Problem Statement context

**BRD → Spec:**
- Pricing Model (5) → Spec NFRs (pricing/licensing constraints)
- Metrics (7) → Spec Acceptance Criteria (performance targets)
- GTM Roadmap (6) → Spec Implementation Plan (phasing)

**BRD → Release:**
- Business Goals (3) → Release overview (business impact)
- GTM Roadmap phases → Release sequencing
- Metrics (7) → Release criteria

**Example reference pattern:**
```markdown
# In PRD
## 1. Business & User Goals
**Business Context:** See [BRD § 3 Business Goals](../brds/monetization-brd.md#3-business-goals)

# In Spec
## 2.2 Non-Functional Requirements
**Pricing Constraints:** See [BRD § 5 Pricing Model](../brds/monetization-brd.md#5-pricing-model)
```

---

## COST OPTIMIZATION

**Concise output patterns:**
- Tables over paragraphs (pricing, risks, metrics)
- Bullets over prose (goals, segments, revenue streams)
- Single executive summary paragraph (≤40 words)
- "See BRD §" references prevent duplication in downstream docs

**Expected savings:** 40-50% fewer tokens vs narrative business docs

---

## GUARDRAILS

1. **Length Enforcement:**
   - If field exceeds limit: Truncate intelligently and warn
   - Executive summary is ONLY paragraph (≤40 words)
   - Better concise than verbose

2. **Business Focus Only:**
   - If source has product features: Note "Belongs in PRD"
   - If source has technical details: Note "Belongs in Spec"
   - Strip all non-business content

3. **Pricing Table Validation:**
   - Max 3 tiers (if source has more, consolidate)
   - All 4 columns required: Tier, Price, Features, Audience
   - Features column: ≤6 words per tier

4. **Metric Distribution:**
   - MUST split across 3 categories
   - Max 2 per category (6 total)
   - Each metric: ≤15 words

5. **GTM Roadmap Phases:**
   - Max 3 phases
   - Each phase: ≤20 words
   - Focus on market milestones (not technical)

---

**Behavior:**
- If invoked with file path (e.g., `/create-brd context/brds/monetization-strategy.md`), read that file and proceed
- If no path provided, ask user for source document path
- If `--output` flag provided, write to that path
- Always validate output against template structure before presenting
- If source is pure technical doc with no business context, extract what's available and WARN user
- If source mixes business and product content, extract business only and note what was omitted