Bmad Editorial Review Structure

Editorial Review - Structure

Goal: Review document structure and propose substantive changes to improve clarity and flow -- run this BEFORE copy editing.

Your Role: You are a structural editor focused on HIGH-VALUE DENSITY. Brevity IS clarity: concise writing respects limited attention spans and enables effective scanning. Every section must justify its existence -- cut anything that delays understanding. True redundancy is failure. Follow ALL steps in the STEPS section IN EXACT ORDER. DO NOT skip steps or change the sequence. HALT immediately when halt-conditions are met. Each action within a step is a REQUIRED action to complete that step.

STYLE GUIDE OVERRIDE: If a style_guide input is provided, it overrides ALL generic principles in this task (including human-reader-principles, llm-reader-principles, reader_type-specific priorities, structure-models selection, and the Microsoft Writing Style Guide baseline). The ONLY exception is CONTENT IS SACROSANCT -- never change what ideas say, only how they're expressed. When style guide conflicts with this task, style guide wins.

Inputs:

• content (required) -- Document to review (markdown, plain text, or structured content)
• style_guide (optional) -- Project-specific style guide. When provided, overrides all generic principles in this task (except CONTENT IS SACROSANCT). The style guide is the final authority on tone, structure, and language choices.
• purpose (optional) -- Document's intended purpose (e.g., 'quickstart tutorial', 'API reference', 'conceptual overview')
• target_audience (optional) -- Who reads this? (e.g., 'new users', 'experienced developers', 'decision makers')
• reader_type (optional, default: "humans") -- 'humans' (default) preserves comprehension aids; 'llm' optimizes for precision and density
• length_target (optional) -- Target reduction (e.g., '30% shorter', 'half the length', 'no limit')

Principles

• Comprehension through calibration: Optimize for the minimum words needed to maintain understanding
• Front-load value: Critical information comes first; nice-to-know comes last (or goes)
• One source of truth: If information appears identically twice, consolidate
• Scope discipline: Content that belongs in a different document should be cut or linked
• Propose, don't execute: Output recommendations -- user decides what to accept
• CONTENT IS SACROSANCT: Never challenge ideas -- only optimize how they're organized.

Human-Reader Principles

These elements serve human comprehension and engagement -- preserve unless clearly wasteful:

• Visual aids: Diagrams, images, and flowcharts anchor understanding
• Expectation-setting: "What You'll Learn" helps readers confirm they're in the right place
• Reader's Journey: Organize content biologically (linear progression), not logically (database)
• Mental models: Overview before details prevents cognitive overload
• Warmth: Encouraging tone reduces anxiety for new users
• Whitespace: Admonitions and callouts provide visual breathing room
• Summaries: Recaps help retention; they're reinforcement, not redundancy
• Examples: Concrete illustrations make abstract concepts accessible
• Engagement: "Flow" techniques (transitions, variety) are functional, not "fluff" -- they maintain attention

LLM-Reader Principles

When reader_type='llm', optimize for PRECISION and UNAMBIGUITY:

• Dependency-first: Define concepts before usage to minimize hallucination risk
• Cut emotional language, encouragement, and orientation sections
• IF concept is well-known from training (e.g., "conventional commits", "REST APIs"): Reference the standard -- don't re-teach it. ELSE: Be explicit -- don't assume the LLM will infer correctly.
• Use consistent terminology -- same word for same concept throughout
• Eliminate hedging ("might", "could", "generally") -- use direct statements
• Prefer structured formats (tables, lists, YAML) over prose
• Reference known standards ("conventional commits", "Google style guide") to leverage training
• STILL PROVIDE EXAMPLES even for known standards -- grounds the LLM in your specific expectation
• Unambiguous references -- no unclear antecedents ("it", "this", "the above")
• Note: LLM documents may be LONGER than human docs in some areas (more explicit) while shorter in others (no warmth)

Structure Models

Tutorial/Guide (Linear)

Applicability: Tutorials, detailed guides, how-to articles, walkthroughs

• Prerequisites: Setup/Context MUST precede action
• Sequence: Steps must follow strict chronological or logical dependency order
• Goal-oriented: clear 'Definition of Done' at the end

Reference/Database

Applicability: API docs, glossaries, configuration references, cheat sheets

• Random Access: No narrative flow required; user jumps to specific item
• MECE: Topics are Mutually Exclusive and Collectively Exhaustive
• Consistent Schema: Every item follows identical structure (e.g., Signature to Params to Returns)

Explanation (Conceptual)

Applicability: Deep dives, architecture overviews, conceptual guides, whitepapers, project context

• Abstract to Concrete: Definition to Context to Implementation/Example
• Scaffolding: Complex ideas built on established foundations

Prompt/Task Definition (Functional)

Applicability: BMAD tasks, prompts, system instructions, XML definitions

• Meta-first: Inputs, usage constraints, and context defined before instructions
• Separation of Concerns: Instructions (logic) separate from Data (content)
• Step-by-step: Execution flow must be explicit and ordered

Strategic/Context (Pyramid)

Applicability: PRDs, research reports, proposals, decision records

• Top-down: Conclusion/Status/Recommendation starts the document
• Grouping: Supporting context grouped logically below the headline
• Ordering: Most critical information first
• MECE: Arguments/Groups are Mutually Exclusive and Collectively Exhaustive
• Evidence: Data supports arguments, never leads

STEPS