docs(bmad): enforce prose formatting as one-sentence-per-line with leading bullet; exclude code/diagrams
This commit is contained in:
parent
323382b996
commit
c44d2ba34c
|
|
@ -23,7 +23,7 @@
|
||||||
- 変数: `screen_id`, `wireframe_screenshot_relpath`(例: `../assets/{{screen_id}}-wireframe.png`)
|
- 変数: `screen_id`, `wireframe_screenshot_relpath`(例: `../assets/{{screen_id}}-wireframe.png`)
|
||||||
5. 生成された仕様書に「Wireframe Screenshots」セクションが含まれることを確認
|
5. 生成された仕様書に「Wireframe Screenshots」セクションが含まれることを確認
|
||||||
6. (任意)プローズモードでの出力
|
6. (任意)プローズモードでの出力
|
||||||
- `export BMAD_STYLE=prose` を設定してからレンダリングを行うと、箇条書き中心の短文ではなく、段落ベースの詳細な説明が優先される。
|
- `export BMAD_STYLE=prose` を設定してからレンダリングを行うと、本リポジトリのポリシーに従い「1文1行+各行先頭に`* `」で整形されたプローズが生成される(コードブロック・Mermaid・画像・表は除外)。
|
||||||
|
|
||||||
## Execution Notes
|
## Execution Notes
|
||||||
- 撮影後に画像パスを相対に変換し、仕様書から参照可能にします。
|
- 撮影後に画像パスを相対に変換し、仕様書から参照可能にします。
|
||||||
|
|
|
||||||
|
|
@ -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.
|
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.
|
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: |
|
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.
|
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:
|
sections:
|
||||||
|
|
@ -66,7 +68,7 @@ sections:
|
||||||
- id: information-architecture
|
- id: information-architecture
|
||||||
title: Information Architecture (IA)
|
title: Information Architecture (IA)
|
||||||
instruction: |
|
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
|
1. Build a Site Map or Screen Inventory showing all major areas
|
||||||
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
|
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
|
||||||
|
|
@ -105,7 +107,7 @@ sections:
|
||||||
- id: screen-transitions
|
- id: screen-transitions
|
||||||
title: Screen Transitions
|
title: Screen Transitions
|
||||||
instruction: |
|
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
|
- Use Mermaid flow diagrams to visualize transitions
|
||||||
- Include decision points (permissions, confirmations) as diamond nodes
|
- Include decision points (permissions, confirmations) as diamond nodes
|
||||||
|
|
@ -174,7 +176,7 @@ sections:
|
||||||
- id: wireframes-mockups
|
- id: wireframes-mockups
|
||||||
title: Wireframes & Mockups
|
title: Wireframes & Mockups
|
||||||
instruction: |
|
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 screenshot’s 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 screenshot’s purpose, key elements, and intended interactions as one sentence per line with leading `* `. Do not alter code/diagrams.
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
- id: wireframe-screenshots
|
- id: wireframe-screenshots
|
||||||
|
|
|
||||||
|
|
@ -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)
|
## 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.
|
1. Write in full sentences, but format output as one sentence per line, and prefix each sentence with `* ` (asterisk + space).
|
||||||
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.
|
2. Do not wrap multiple sentences into a single paragraph. Each sentence must be its own bullet line for readability and diffability.
|
||||||
3. Always cover, in order where applicable: Purpose → Structure → Behavior → Conditions → Results → Errors/Edge Cases → Accessibility/Non-Functional → Acceptance.
|
3. Exceptions: Do NOT alter formatting for code blocks, diagrams (e.g., Mermaid), tables, or images; keep their native formats.
|
||||||
4. Replace ambiguous shorthand with explicit phrasing. Example: “1行省略” → “1行表示領域を超えたテキストは末尾に省略記号(…)を付けて切り詰める”。
|
4. Always cover, in order where applicable: Purpose → Structure → Behavior → Conditions → Results → Errors/Edge Cases → Accessibility/Non-Functional → Acceptance.
|
||||||
5. Prefer paragraph explanations before any diagrams or tables to clarify context and rationale.
|
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
|
## Processing Flow
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue