docs(bmad): enforce prose formatting as one-sentence-per-line with leading bullet; exclude code/diagrams

This commit is contained in:
Kota Shirakura 2025-08-24 21:38:19 +09:00
parent 323382b996
commit c44d2ba34c
3 changed files with 13 additions and 10 deletions

View File

@ -23,7 +23,7 @@
- 変数: `screen_id`, `wireframe_screenshot_relpath`(例: `../assets/{{screen_id}}-wireframe.png`
5. 生成された仕様書に「Wireframe Screenshots」セクションが含まれることを確認
6. (任意)プローズモードでの出力
- `export BMAD_STYLE=prose` を設定してからレンダリングを行うと、箇条書き中心の短文ではなく、段落ベースの詳細な説明が優先される
- `export BMAD_STYLE=prose` を設定してからレンダリングを行うと、本リポジトリのポリシーに従い「1文1行各行先頭に`* `」で整形されたプローズが生成されるコードブロック・Mermaid・画像・表は除外
## Execution Notes
- 撮影後に画像パスを相対に変換し、仕様書から参照可能にします。

View File

@ -19,6 +19,8 @@ sections:
Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.
Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
Formatting Policy (when BMAD_STYLE=prose): Output narrative as one sentence per line and prefix each sentence with `* `. Do not change formatting of code blocks, Mermaid diagrams, tables, or images.
content: |
This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
sections:
@ -66,7 +68,7 @@ sections:
- id: information-architecture
title: Information Architecture (IA)
instruction: |
Collaborate with the user to create a comprehensive information architecture. When BMAD_STYLE=prose, describe structures and rationale in paragraphs first, then add diagrams for support (not as the sole content):
Collaborate with the user to create a comprehensive information architecture. When BMAD_STYLE=prose, still format each sentence as its own bullet line with `* ` for diffability. Provide the narrative before diagrams:
1. Build a Site Map or Screen Inventory showing all major areas
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
@ -105,7 +107,7 @@ sections:
- id: screen-transitions
title: Screen Transitions
instruction: |
Document how users move between screens at an application level. In prose mode, explain the entry points, decision points, and outcomes in full sentences before the diagram. Avoid terse bullet-only descriptions.
Document how users move between screens at an application level. In prose mode, explain the entry points, decision points, and outcomes in full sentences, formatted as one sentence per line with leading `* `, before the diagram. Avoid mixing multiple sentences on a single line.
- Use Mermaid flow diagrams to visualize transitions
- Include decision points (permissions, confirmations) as diamond nodes
@ -174,7 +176,7 @@ sections:
- id: wireframes-mockups
title: Wireframes & Mockups
instruction: |
Clarify where detailed visual designs will be created (Figma, Sketch, etc.) and how to reference them. If low-fidelity wireframes are needed, offer to help conceptualize layouts for key screens. In prose mode, describe each screenshots purpose, key elements, and intended interactions in sentences, not only bullets.
Clarify where detailed visual designs will be created (Figma, Sketch, etc.) and how to reference them. If low-fidelity wireframes are needed, offer to help conceptualize layouts for key screens. In prose mode, describe each screenshots purpose, key elements, and intended interactions as one sentence per line with leading `* `. Do not alter code/diagrams.
elicit: true
sections:
- id: wireframe-screenshots

View File

@ -39,13 +39,14 @@ If a YAML Template has not been provided, list all templates from .bmad-core/tem
## Global Prose Mode (BMAD_STYLE=prose)
When the environment variable `BMAD_STYLE=prose` is set:
When the environment variable `BMAD_STYLE=prose` is set, apply this repository's formatting policy:
1. Write sections in full sentences and paragraphs. Avoid shorthand.
2. Do not use terse bullet-only outputs unless identifiers are mandatory (e.g., FR/NFR numbers). When lists are necessary, convert each item into 1-2 descriptive sentences.
3. Always cover, in order where applicable: Purpose → Structure → Behavior → Conditions → Results → Errors/Edge Cases → Accessibility/Non-Functional → Acceptance.
4. Replace ambiguous shorthand with explicit phrasing. Example: “1行省略” → “1行表示領域を超えたテキストは末尾に省略記号を付けて切り詰める”。
5. Prefer paragraph explanations before any diagrams or tables to clarify context and rationale.
1. Write in full sentences, but format output as one sentence per line, and prefix each sentence with `* ` (asterisk + space).
2. Do not wrap multiple sentences into a single paragraph. Each sentence must be its own bullet line for readability and diffability.
3. Exceptions: Do NOT alter formatting for code blocks, diagrams (e.g., Mermaid), tables, or images; keep their native formats.
4. Always cover, in order where applicable: Purpose → Structure → Behavior → Conditions → Results → Errors/Edge Cases → Accessibility/Non-Functional → Acceptance.
5. Replace ambiguous shorthand with explicit phrasing. Example: “1行省略” → “1行表示領域を超えたテキストは末尾に省略記号を付けて切り詰める”。
6. Before any lists or diagrams, you may include context sentences; still apply one-sentence-per-line with leading `* ` to those sentences (diagrams/tables themselves are excluded).
## Processing Flow