| name | business-requirements-capture |
| plugin | exploration-cycle-plugin |
| description | Captures and refines business requirements, including functional requirements, non-functional requirements, business rules, constraints, assumptions, and success measures. Produces structured BRD-style documents with [CONFIRMED] and [UNCONFIRMED] confidence markers. Trigger with "capture requirements", "generate a BRD", "document business rules", "list the constraints", or "create a requirements document".
|
| allowed-tools | Bash, Read, Write |
Business Requirements Capture
Generate structured Business Requirements Documents from exploration session captures.
Usage
python ./scripts/execute.py \
--input <file> [<file2>...] \
--mode <brd|rules|constraints> \
--output <output_file.md>
Modes:
brd (default): Full Business Requirements Document — functional/non-functional requirements, business rules, constraints, assumptions, success measures.rules: Business rules ledger only — decision logic, policy constraints, workflow conditions.constraints: Constraints and assumptions register only.
Flags:
--input PATH [PATH ...] : Session brief, problem framing, BRD draft, or prior captures--output PATH : Destination file (default: exploration/captures/brd-draft.md)--mode MODE : Output scope (default: brd)
Interactive Co-Authoring Workflow
When invoked interactively, follow this 3-stage pattern. Do not dump a full document at once.
Stage 1: Context Gathering
Ask all three questions in a single message before reading or generating anything:
- Input: Resolve input in this priority order — do not scan the filesystem before asking:
- If the user passed a problem statement or context inline — use that as primary input (mark as
[UNCONFIRMED] source)
- If input files were named — read them after this question; note any that are missing
- If neither exists — halt here and ask for input before proceeding
(Check
exploration/ only if no inline input and no files named.)
- Output scope: Which mode fits your need?
brd — full Business Requirements Document (functional + non-functional requirements, business rules, constraints, assumptions, success measures)rules — business rules ledger only (decision logic, policy constraints, workflow conditions)constraints — constraints and assumptions register only
- Emphasis: Any specific area, stakeholder concern, or hard constraint that must be front and centre?
After the user responds: read each input file they identify. Note any that are missing or incomplete.
Stage 2: Section-by-Section Refinement
Build iteratively — do not present a massive markdown dump.
[CONFIRMED] / [UNCONFIRMED] decision rule (apply throughout this stage):
- Mark
[CONFIRMED] only when: the user explicitly stated it, OR it appears clearly in an input file.
- Mark
[UNCONFIRMED] when: you inferred it, extrapolated it, or the source is ambiguous.
- When in doubt, use
[UNCONFIRMED] and surface it for human sign-off.
- Brainstorm & Curate: Based on the input files, present a numbered list of proposed requirements or rules (lightweight — title + one sentence each). Ask: "Which of these should we keep, cut, or merge? Anything missing?"
- Draft section by section: Present all approved items as drafts in a single message — one 2–4 sentence block per item, [CONFIRMED]/[UNCONFIRMED] marked. Ask: "Accurate? Flag any item to revise before we move on." Apply all edits in one pass, then proceed.
- Consolidate gaps: Collect all
[UNCONFIRMED] items and any [NEEDS HUMAN INPUT] markers into a single ## Consolidated Gaps section at the end.
Stage 3: Reader Testing (Validation)
Once all sections are drafted:
- Select the first reader using this heuristic — state your choice and one sentence of reasoning:
- Technical constraints, data flows, system behavior → engineer or tech lead
- Policy, compliance, approval gates → PM or auditor
- Cost, timeline, stakeholder sign-off → executive sponsor
- When multiple apply → pick the reader with the most to lose from an ambiguity in this specific document
- Predict exactly 3 questions that reader would ask after reading this document that it does not yet answer. Make questions specific to this document's content (not generic).
- Report: "If [reader type] reads this, they'll ask: [Q1], [Q2], [Q3]. Should we answer these inline or add them to
## Consolidated Gaps?"
- Apply whatever the user decides.
Anti-Hallucination Rules
- Do NOT invent requirements not present in the source captures.
- Apply [CONFIRMED]/[UNCONFIRMED] markers per the Stage 2 decision rule — do not skip marking.
- Do NOT make architectural decisions — capture only what was said or decided.
- Do NOT proceed without input — inline problem statements are valid input, but a BRD generated with neither files nor inline context is pure hallucination.
Context: User has completed problem framing and wants a formal BRD.
user: "Generate a BRD from our session captures."
assistant: "I'll run `business-requirements-capture` in `brd` mode to scaffold a formal document from your captures."
Context: User wants only the business rules extracted.
user: "Document the business rules we identified."
assistant: "I'll use `business-requirements-capture --mode rules` to extract a business rules ledger."
Context: Pre-handoff review.
user: "List all constraints and assumptions before we hand off to engineering."
assistant: "I'll run `business-requirements-capture --mode constraints` to produce a constraints and assumptions register."
