BRD Reviewer
Overview
Review a BRD paragraph by paragraph, capture clarification questions for ambiguous or incomplete requirements, and generate a single .docx with Word comments plus tracked revisions.
Prefer the bundled pipeline so the final deliverable is a Word-native review artifact instead of chat-only notes.
Workflow
- Confirm the source BRD
.docx path.
- Initialize the paragraph review JSON:
python scripts/brd_review_pipeline.py init-review \
--input <brd.docx> \
--output <brd.review.json>
- Read the BRD and fill the review JSON.
- For every
paragraphs[] item, keep paragraph_index, style_id, heading_path, and source_text unchanged.
- Set
needs_comment to true when the paragraph is unclear, incomplete, internally inconsistent, or missing acceptance criteria, data definitions, ownership, dependencies, assumptions, or edge cases.
- Write
comment_question as a concise reviewer question suitable for a Word comment.
- Set
needs_revision to true when the paragraph should be rewritten for precision, completeness, grammar, or testability.
- Write
proposed_replacement as full replacement language, not fragments.
- Use
issue_tags to make the reason explicit. Prefer tags such as ambiguity, scope, actor, data, workflow, exception, dependency, acceptance-criteria, nonfunctional, term-definition, or conflict.
- Materialize the final reviewed DOCX in the same folder as the source BRD:
python scripts/brd_review_pipeline.py materialize \
--input <brd.docx> \
--review-json <brd.review.json> \
--output <brd.reviewed.docx> \
--author "Codex BRD Reviewer"
- Verify output quality.
- Confirm the reviewed file exists beside the source BRD.
- Confirm Word comments appear on paragraphs with
needs_comment=true.
- Confirm tracked changes are visible for paragraphs with
needs_revision=true.
- If the BRD relies heavily on tables or special layout, use the
$doc skill workflow to render and visually inspect the result before delivery.
Review standard
- Question every paragraph that leaves implementation choices unresolved.
- Favor reviewer comments for missing information and tracked changes for proposed wording.
- Rewrite requirements into concrete, testable statements.
- Flag undefined actors, systems, interfaces, calculations, timing, permissions, and exception handling.
- Do not silently invent business rules. If the BRD lacks a critical detail, ask for it in the comment instead of guessing.
- Keep comments short and specific enough to be actionable in a comment balloon.
- Keep proposed replacements professional and directly usable in the document.
Output contract
- Always produce:
<name>.review.json
<name>.reviewed.docx
- Place both outputs in the same folder as the source BRD unless the user explicitly requests another path.
- Treat chat analysis as supplemental only. The
.docx is the primary deliverable.
Resources
- Paragraph review schema:
references/review-json-schema.md
- Main tool:
scripts/brd_review_pipeline.py
Dependencies
Install once if missing:
python -m pip install python-docx lxml
1---2name: brd-reviewer3description: Review Business Requirements Documents in `.docx` format by reading the existing BRD, extracting paragraph-level context, drafting clarification questions for unclear statements, and producing a final Word document that combines comments and tracked changes. Use when the user wants a BRD reviewed, challenged for ambiguity, or redlined with proposed wording improvements while preserving Word-native review features.4---56# BRD Reviewer78## Overview9Review a BRD paragraph by paragraph, capture clarification questions for ambiguous or incomplete requirements, and generate a single `.docx` with Word comments plus tracked revisions.1011Prefer the bundled pipeline so the final deliverable is a Word-native review artifact instead of chat-only notes.1213## Workflow141. Confirm the source BRD `.docx` path.152. Initialize the paragraph review JSON:16 ```bash17 python scripts/brd_review_pipeline.py init-review \18 --input <brd.docx> \19 --output <brd.review.json>20 ```213. Read the BRD and fill the review JSON.22 - For every `paragraphs[]` item, keep `paragraph_index`, `style_id`, `heading_path`, and `source_text` unchanged.23 - Set `needs_comment` to `true` when the paragraph is unclear, incomplete, internally inconsistent, or missing acceptance criteria, data definitions, ownership, dependencies, assumptions, or edge cases.24 - Write `comment_question` as a concise reviewer question suitable for a Word comment.25 - Set `needs_revision` to `true` when the paragraph should be rewritten for precision, completeness, grammar, or testability.26 - Write `proposed_replacement` as full replacement language, not fragments.27 - Use `issue_tags` to make the reason explicit. Prefer tags such as `ambiguity`, `scope`, `actor`, `data`, `workflow`, `exception`, `dependency`, `acceptance-criteria`, `nonfunctional`, `term-definition`, or `conflict`.284. Materialize the final reviewed DOCX in the same folder as the source BRD:29 ```bash30 python scripts/brd_review_pipeline.py materialize \31 --input <brd.docx> \32 --review-json <brd.review.json> \33 --output <brd.reviewed.docx> \34 --author "Codex BRD Reviewer"35 ```365. Verify output quality.37 - Confirm the reviewed file exists beside the source BRD.38 - Confirm Word comments appear on paragraphs with `needs_comment=true`.39 - Confirm tracked changes are visible for paragraphs with `needs_revision=true`.40 - If the BRD relies heavily on tables or special layout, use the `$doc` skill workflow to render and visually inspect the result before delivery.4142## Review standard43- Question every paragraph that leaves implementation choices unresolved.44- Favor reviewer comments for missing information and tracked changes for proposed wording.45- Rewrite requirements into concrete, testable statements.46- Flag undefined actors, systems, interfaces, calculations, timing, permissions, and exception handling.47- Do not silently invent business rules. If the BRD lacks a critical detail, ask for it in the comment instead of guessing.48- Keep comments short and specific enough to be actionable in a comment balloon.49- Keep proposed replacements professional and directly usable in the document.5051## Output contract52- Always produce:53 - `<name>.review.json`54 - `<name>.reviewed.docx`55- Place both outputs in the same folder as the source BRD unless the user explicitly requests another path.56- Treat chat analysis as supplemental only. The `.docx` is the primary deliverable.5758## Resources59- Paragraph review schema: `references/review-json-schema.md`60- Main tool: `scripts/brd_review_pipeline.py`6162## Dependencies63Install once if missing:64```bash65python -m pip install python-docx lxml66```