brd

BRD Skill — Business Requirements Document

Usage

/brd                              # interview-from-scratch
/brd --frd path/to/frd.md         # ground the BRD in a Functional Requirements Document
/brd --prd path/to/prd.md         # alias for --frd: a PRD is the grounding baseline
/brd --delta path/to/prd-sprintN.md    # ground sprint N's PRD against the prior sprint's requirement spine

Two modes:

• Document-grounded (recommended for greenfield): pass --frd <path> (or its alias --prd <path>) to a Functional/Product Requirements Document. --prd and --frd are treated identically — the document becomes the immutable grounding baseline, extracted into the same requirements spine (frd-requirements.json); only the input flag name differs. For the canonical PRD shape this skill grounds best against, see docs/prd-format.md. The document becomes the immutable grounding baseline — Claude interrogates it for gaps, then generates a BRD in which every requirement traces back to a source section or to a confirmed clarification. A deterministic gate (Step 4.4) hard-blocks anything invented or dropped relative to the source before you ever see it for approval.
• Interview-from-scratch: no argument — an interactive Socratic interview gathers requirements from nothing. Use only when there is no source document.

Overview

This is the first gate in the SDLC pipeline, and the origin of the whole grounding chain (BRD → /spec → /design → /test → /auto). Mistakes here cascade through every downstream phase, so the BRD must invent nothing the business did not state. With --frd, the FRD plus the human's confirmed interrogation answers are the only sanctioned sources of content; with no FRD, the confirmed interview answers are. Either way the planner interviews the human across five dimensions to surface the full problem space — Socratic: ask clarifying questions, probe assumptions, reflect answers back for confirmation before moving on.

Delta Mode (--delta)

Invoked by /sprint for sprint N (N >= 2). Grounds a new PRD against the prior sprint's approved requirement spine, not against nothing — this is what proves the new PRD's requirements are new/changed/carried, and flags anything it silently drops. See docs/superpowers/specs/2026-07-04-sprint-delta-lane-design.md.

Step Δ0 — Locate the prior spine and resolve N

List specs/brd/sprint-*/ directories; let prev be the highest number found. If none exist, the prior spine is the flat legacy specs/brd/brd-requirements.json (sprint 1 predates sprint-numbered directories) and N = 2. If sprint directories exist, N = prev + 1. If neither the flat file nor any sprint directory exists, halt — --delta requires a prior sprint; use --frd/--prd for the very first sprint.

Step Δ1 — Run Steps 0.0 through 4 unchanged, writing to specs/brd/sprint-N/

Run the FRD-grounded flow (Steps 0.0, 0, 0.5, 1, 2, 2.8, 3, 4) exactly as written above, with one change: every output path becomes specs/brd/sprint-N/ (e.g. specs/brd/sprint-N/brd.md, specs/brd/sprint-N/brd-requirements.json, specs/brd/sprint-N/clarification-log.json). When writing brd-requirements.json, any requirement that carries forward a prior-sprint requirement unchanged (or with only minor edits) must include that prior sprint's BR id in its traces array alongside this sprint's own FRD/clarification traces — this is what lets Step Δ2's classification tell "carried forward" apart from "silently dropped."

Step Δ2 — Requirements-delta classification [HARD BLOCK]

Step 4.4's grounding gate still runs unchanged (this sprint's BRD vs this sprint's own FRD/PRD spine). In addition, classify this sprint's spine against the prior sprint's spine — the same trace-check.js engine, reused with the prior spine as required, this sprint's spine also as a valid trace target (optional), and this sprint's spine as downstream:

node .claude/scripts/trace-check.js \
  --required specs/brd/sprint-{prev}/brd-requirements.json \
  --optional specs/brd/sprint-N/brd-requirements.json \
  --downstream specs/brd/sprint-N/brd-requirements.json \
  --layer requirements-delta \
  --out specs/brd/sprint-N/requirements-delta.json

(When prev refers to the flat legacy layout, use --required specs/brd/brd-requirements.json.)

Read the resulting requirements-delta.json:

• net_new entries are genuinely new requirements this sprint introduces — expected, not a failure.
• dropped entries are prior-sprint requirements this sprint's spine does not cover — each one needs an explicit human decision: still active (add a BR entry carrying it forward) or intentionally retired (record why in this sprint's BRD Open Questions). A dropped entry with no such resolution is a silent regression — halt and ask before proceeding to Step 4.5.

Empty-spine guard: a required_total: 0 here means the prior sprint's spine is empty — a pre-spine legacy project. Skip this step in that case and note it in the BRD summary (Step 4.4's own grounding gate still runs normally against this sprint's spine).

Step Δ3 — Present for Human Approval (delta mode)

Same as Step 5, plus display the requirements-delta classification (new / changed / carried / dropped, with the human's resolution for each dropped item) before asking for approval.

Steps

Step 0.0 — Ingest the FRD (only when --frd <path> was given)

If an FRD path was provided:

1. Copy it verbatim to specs/brd/source-frd.md — this is the immutable grounding baseline. Never edit it.
2. Extract its requirements into specs/brd/frd-requirements.json — one entry per discrete functional requirement, with a stable id, the requirement text, and the source section:

   [
     { "id": "FRD-1", "text": "Users can reset their password via an emailed link", "section": "3.2 Authentication" },
     { "id": "FRD-2", "text": "Users can view their order history", "section": "4.1 Orders" }
   ]
   

   Be exhaustive and faithful — every "the system must / shall / should" statement, every user-facing behavior, every business rule becomes one FRD-n. Do not paraphrase away constraints. This list is what the BRD will be checked against, so a requirement you fail to extract here is a requirement that can be silently dropped.

If no --frd was given, skip this step; the BRD's grounding baseline is then the confirmed INT-n interview requirements captured in Step 2 (specs/brd/interview-requirements.json), plus the Step 0.5 clarification log.

Step 0 — Brainstorm with Superpowers

Before beginning the interview, invoke superpowers:brainstorming to explore the user's intent, requirements, and design space. This surfaces hidden assumptions and alternative framings before the structured Socratic interview locks in a direction. In FRD-grounded mode, brainstorm gaps and ambiguities in the FRD specifically — what it leaves unspecified. The brainstorming output feeds into the interview — it does not replace it.

Step 0.5 — Apply the Clarification Budget (and log every answer)

Before asking interview questions, invoke .claude/skills/clarify/SKILL.md. Use it to cap the total clarification burden:

• Ask only load-bearing questions that affect requirements, scope, data, security, architecture, or story readiness.
• Default to 10 total questions across the BRD interview.
• Continue to 15 only if the user explicitly asks to keep going.
• Capture low-risk assumptions in the BRD instead of asking about them.

Persist every confirmed answer to specs/brd/clarification-log.json with a stable id:

[
  { "id": "C1", "question": "What is the password-reset token TTL?", "answer": "1 hour" },
  { "id": "C2", "question": "Should order history paginate?", "answer": "Yes, 20 per page" }
]

The clarification log is the only sanctioned channel for content not already in the FRD. A BRD requirement may legitimately introduce something new only if it traces to an FRD section, an INT-n interview requirement, or a C-n clarification here — so anything the human confirms that expands scope must be captured as a C-n entry, not absorbed silently into the BRD prose.

Step 1 — Analyze Existing Codebase (if any)

Before beginning the interview, scan the working directory for existing code. Note:

• Current tech stack, frameworks, languages
• Existing data models or schemas
• Existing API surface
• Any patterns or conventions already in use

If this is an existing non-trivial codebase and specs/brownfield/codebase-map.md does not exist, recommend running /brownfield first. For small or urgent work, continue only after documenting the risk and the limited scope.

This prevents proposing solutions that conflict with what is already built.

Step 2 — Conduct the Five-Dimension Interview

Work through each dimension in order. Do not skip dimensions. Ask only the highest-value questions within the clarification budget, then summarize what you heard and ask the human to confirm before proceeding. If a dimension is already answered by local context, document the assumption and move on.

As each dimension is confirmed, append the confirmed requirement statements to specs/brd/interview-requirements.json — one entry per discrete requirement the human signed off:

[{ "id": "INT-1", "text": "Admins invite users by email", "section": "users-and-permissions" }]

Write entries at confirmation time, not after synthesis — this file is the grounding baseline the BRD is mechanically checked against (Step 4.4), so it must capture what the human confirmed before BRD prose can drift. Q&A detail that is context rather than a requirement stays in clarification-log.json (C-n); a statement the human confirmed as something the system must do is an INT-n.

Dimension 1 — Why (Problem & Goals)

• What problem does this solve, and for whom?
• Who ar

Content truncated.