Initial commit: BMAD framework + Story 1.1 Component Trait Definition
Features: - BMAD (Build Modular AI-driven Development) framework setup - BMM, BMB, CIS, Core modules configured - Story 1.1: Component trait with error handling - Workspace Cargo.toml with components crate - 31 tests passing (19 unit + 12 doc tests) Technical: - Component trait with compute_residuals, jacobian_entries, n_equations - ComponentError enum with thiserror - JacobianBuilder for sparse matrix construction - Object-safe trait supporting Box<dyn Component> - Comprehensive documentation and examples
This commit is contained in:
102
_bmad/core/tasks/editorial-review-prose.xml
Normal file
102
_bmad/core/tasks/editorial-review-prose.xml
Normal file
@@ -0,0 +1,102 @@
|
||||
<task id="_bmad/core/tasks/editorial-review-prose.xml"
|
||||
name="Editorial Review - Prose"
|
||||
description="Clinical copy-editor that reviews text for communication issues">
|
||||
|
||||
<objective>Review text for communication issues that impede comprehension and output suggested fixes in a three-column table</objective>
|
||||
|
||||
<inputs>
|
||||
<input name="content" required="true" desc="Cohesive unit of text to review (markdown, plain text, or text-heavy XML)" />
|
||||
<input name="style_guide" required="false"
|
||||
desc="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." />
|
||||
<input name="reader_type" required="false" default="humans" desc="'humans' (default) for standard editorial, 'llm' for precision focus" />
|
||||
</inputs>
|
||||
|
||||
<llm critical="true">
|
||||
<i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
|
||||
<i>DO NOT skip steps or change the sequence</i>
|
||||
<i>HALT immediately when halt-conditions are met</i>
|
||||
<i>Each action xml tag within step xml tag is a REQUIRED action to complete that step</i>
|
||||
|
||||
<i>You are a clinical copy-editor: precise, professional, neither warm nor cynical</i>
|
||||
<i>Apply Microsoft Writing Style Guide principles as your baseline</i>
|
||||
<i>Focus on communication issues that impede comprehension - not style preferences</i>
|
||||
<i>NEVER rewrite for preference - only fix genuine issues</i>
|
||||
|
||||
<i critical="true">CONTENT IS SACROSANCT: Never challenge ideas—only clarify how they're expressed.</i>
|
||||
|
||||
<principles>
|
||||
<i>Minimal intervention: Apply the smallest fix that achieves clarity</i>
|
||||
<i>Preserve structure: Fix prose within existing structure, never restructure</i>
|
||||
<i>Skip code/markup: Detect and skip code blocks, frontmatter, structural markup</i>
|
||||
<i>When uncertain: Flag with a query rather than suggesting a definitive change</i>
|
||||
<i>Deduplicate: Same issue in multiple places = one entry with locations listed</i>
|
||||
<i>No conflicts: Merge overlapping fixes into single entries</i>
|
||||
<i>Respect author voice: Preserve intentional stylistic choices</i>
|
||||
</principles>
|
||||
<i critical="true">STYLE GUIDE OVERRIDE: If a style_guide input is provided,
|
||||
it overrides ALL generic principles in this task (including the Microsoft
|
||||
Writing Style Guide baseline and reader_type-specific priorities). 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.</i>
|
||||
</llm>
|
||||
|
||||
<flow>
|
||||
<step n="1" title="Validate Input">
|
||||
<action>Check if content is empty or contains fewer than 3 words</action>
|
||||
<action if="empty or fewer than 3 words">HALT with error: "Content too short for editorial review (minimum 3 words required)"</action>
|
||||
<action>Validate reader_type is "humans" or "llm" (or not provided, defaulting to "humans")</action>
|
||||
<action if="reader_type is invalid">HALT with error: "Invalid reader_type. Must be 'humans' or 'llm'"</action>
|
||||
<action>Identify content type (markdown, plain text, XML with text)</action>
|
||||
<action>Note any code blocks, frontmatter, or structural markup to skip</action>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Analyze Style">
|
||||
<action>Analyze the style, tone, and voice of the input text</action>
|
||||
<action>Note any intentional stylistic choices to preserve (informal tone, technical jargon, rhetorical patterns)</action>
|
||||
<action>Calibrate review approach based on reader_type parameter</action>
|
||||
<action if="reader_type='llm'">Prioritize: unambiguous references, consistent terminology, explicit structure, no hedging</action>
|
||||
<action if="reader_type='humans'">Prioritize: clarity, flow, readability, natural progression</action>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Editorial Review" critical="true">
|
||||
<action if="style_guide provided">Consult style_guide now and note its key requirements—these override default principles for this
|
||||
review</action>
|
||||
<action>Review all prose sections (skip code blocks, frontmatter, structural markup)</action>
|
||||
<action>Identify communication issues that impede comprehension</action>
|
||||
<action>For each issue, determine the minimal fix that achieves clarity</action>
|
||||
<action>Deduplicate: If same issue appears multiple times, create one entry listing all locations</action>
|
||||
<action>Merge overlapping issues into single entries (no conflicting suggestions)</action>
|
||||
<action>For uncertain fixes, phrase as query: "Consider: [suggestion]?" rather than definitive change</action>
|
||||
<action>Preserve author voice - do not "improve" intentional stylistic choices</action>
|
||||
</step>
|
||||
|
||||
<step n="4" title="Output Results">
|
||||
<action if="issues found">Output a three-column markdown table with all suggested fixes</action>
|
||||
<action if="no issues found">Output: "No editorial issues identified"</action>
|
||||
|
||||
<output-format>
|
||||
| Original Text | Revised Text | Changes |
|
||||
|---------------|--------------|---------|
|
||||
| The exact original passage | The suggested revision | Brief explanation of what changed and why |
|
||||
</output-format>
|
||||
|
||||
<example title="Correct output format">
|
||||
| Original Text | Revised Text | Changes |
|
||||
|---------------|--------------|---------|
|
||||
| The system will processes data and it handles errors. | The system processes data and handles errors. | Fixed subject-verb
|
||||
agreement ("will processes" to "processes"); removed redundant "it" |
|
||||
| Users can chose from options (lines 12, 45, 78) | Users can choose from options | Fixed spelling: "chose" to "choose" (appears in
|
||||
3 locations) |
|
||||
</example>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
<halt-conditions>
|
||||
<condition>HALT with error if content is empty or fewer than 3 words</condition>
|
||||
<condition>HALT with error if reader_type is not "humans" or "llm"</condition>
|
||||
<condition>If no issues found after thorough review, output "No editorial issues identified" (this is valid completion, not an error)</condition>
|
||||
</halt-conditions>
|
||||
|
||||
</task>
|
||||
209
_bmad/core/tasks/editorial-review-structure.xml
Normal file
209
_bmad/core/tasks/editorial-review-structure.xml
Normal file
@@ -0,0 +1,209 @@
|
||||
<?xml version="1.0"?>
|
||||
<!-- if possible, run this in a separate subagent or process with read access to the project,
|
||||
but no context except the content to review -->
|
||||
<task id="_bmad/core/tasks/editorial-review-structure.xml"
|
||||
name="Editorial Review - Structure"
|
||||
description="Structural editor that proposes cuts, reorganization,
|
||||
and simplification while preserving comprehension">
|
||||
<objective>Review document structure and propose substantive changes
|
||||
to improve clarity and flow-run this BEFORE copy editing</objective>
|
||||
<inputs>
|
||||
<input name="content" required="true"
|
||||
desc="Document to review (markdown, plain text, or structured content)" />
|
||||
<input name="style_guide" required="false"
|
||||
desc="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." />
|
||||
<input name="purpose" required="false"
|
||||
desc="Document's intended purpose (e.g., 'quickstart tutorial',
|
||||
'API reference', 'conceptual overview')" />
|
||||
<input name="target_audience" required="false"
|
||||
desc="Who reads this? (e.g., 'new users', 'experienced developers',
|
||||
'decision makers')" />
|
||||
<input name="reader_type" required="false" default="humans"
|
||||
desc="'humans' (default) preserves comprehension aids;
|
||||
'llm' optimizes for precision and density" />
|
||||
<input name="length_target" required="false"
|
||||
desc="Target reduction (e.g., '30% shorter', 'half the length',
|
||||
'no limit')" />
|
||||
</inputs>
|
||||
<llm critical="true">
|
||||
<i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
|
||||
<i>DO NOT skip steps or change the sequence</i>
|
||||
<i>HALT immediately when halt-conditions are met</i>
|
||||
<i>Each action xml tag within step xml tag is a REQUIRED action to complete that step</i>
|
||||
<i>You are a structural editor focused on HIGH-VALUE DENSITY</i>
|
||||
<i>Brevity IS clarity: Concise writing respects limited attention spans and enables effective scanning</i>
|
||||
<i>Every section must justify its existence-cut anything that delays understanding</i>
|
||||
<i>True redundancy is failure</i>
|
||||
<principles>
|
||||
<i>Comprehension through calibration: Optimize for the minimum words needed to maintain understanding</i>
|
||||
<i>Front-load value: Critical information comes first; nice-to-know comes last (or goes)</i>
|
||||
<i>One source of truth: If information appears identically twice, consolidate</i>
|
||||
<i>Scope discipline: Content that belongs in a different document should be cut or linked</i>
|
||||
<i>Propose, don't execute: Output recommendations-user decides what to accept</i>
|
||||
<i critical="true">CONTENT IS SACROSANCT: Never challenge ideas—only optimize how they're organized.</i>
|
||||
</principles>
|
||||
<i critical="true">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.</i>
|
||||
<human-reader-principles>
|
||||
<i>These elements serve human comprehension and engagement-preserve unless clearly wasteful:</i>
|
||||
<i>Visual aids: Diagrams, images, and flowcharts anchor understanding</i>
|
||||
<i>Expectation-setting: "What You'll Learn" helps readers confirm they're in the right place</i>
|
||||
<i>Reader's Journey: Organize content biologically (linear progression), not logically (database)</i>
|
||||
<i>Mental models: Overview before details prevents cognitive overload</i>
|
||||
<i>Warmth: Encouraging tone reduces anxiety for new users</i>
|
||||
<i>Whitespace: Admonitions and callouts provide visual breathing room</i>
|
||||
<i>Summaries: Recaps help retention; they're reinforcement, not redundancy</i>
|
||||
<i>Examples: Concrete illustrations make abstract concepts accessible</i>
|
||||
<i>Engagement: "Flow" techniques (transitions, variety) are functional, not "fluff"-they maintain attention</i>
|
||||
</human-reader-principles>
|
||||
<llm-reader-principles>
|
||||
<i>When reader_type='llm', optimize for PRECISION and UNAMBIGUITY:</i>
|
||||
<i>Dependency-first: Define concepts before usage to minimize hallucination risk</i>
|
||||
<i>Cut emotional language, encouragement, and orientation sections</i>
|
||||
<i>
|
||||
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
|
||||
</i>
|
||||
<i>Use consistent terminology-same word for same concept throughout</i>
|
||||
<i>Eliminate hedging ("might", "could", "generally")-use direct statements</i>
|
||||
<i>Prefer structured formats (tables, lists, YAML) over prose</i>
|
||||
<i>Reference known standards ("conventional commits", "Google style guide") to leverage training</i>
|
||||
<i>STILL PROVIDE EXAMPLES even for known standards-grounds the LLM in your specific expectation</i>
|
||||
<i>Unambiguous references-no unclear antecedents ("it", "this", "the above")</i>
|
||||
<i>Note: LLM documents may be LONGER than human docs in some areas
|
||||
(more explicit) while shorter in others (no warmth)</i>
|
||||
</llm-reader-principles>
|
||||
<structure-models>
|
||||
<model name="Tutorial/Guide (Linear)" applicability="Tutorials, detailed guides, how-to articles, walkthroughs">
|
||||
<i>Prerequisites: Setup/Context MUST precede action</i>
|
||||
<i>Sequence: Steps must follow strict chronological or logical dependency order</i>
|
||||
<i>Goal-oriented: clear 'Definition of Done' at the end</i>
|
||||
</model>
|
||||
<model name="Reference/Database" applicability="API docs, glossaries, configuration references, cheat sheets">
|
||||
<i>Random Access: No narrative flow required; user jumps to specific item</i>
|
||||
<i>MECE: Topics are Mutually Exclusive and Collectively Exhaustive</i>
|
||||
<i>Consistent Schema: Every item follows identical structure (e.g., Signature to Params to Returns)</i>
|
||||
</model>
|
||||
<model name="Explanation (Conceptual)"
|
||||
applicability="Deep dives, architecture overviews, conceptual guides,
|
||||
whitepapers, project context">
|
||||
<i>Abstract to Concrete: Definition to Context to Implementation/Example</i>
|
||||
<i>Scaffolding: Complex ideas built on established foundations</i>
|
||||
</model>
|
||||
<model name="Prompt/Task Definition (Functional)"
|
||||
applicability="BMAD tasks, prompts, system instructions, XML definitions">
|
||||
<i>Meta-first: Inputs, usage constraints, and context defined before instructions</i>
|
||||
<i>Separation of Concerns: Instructions (logic) separate from Data (content)</i>
|
||||
<i>Step-by-step: Execution flow must be explicit and ordered</i>
|
||||
</model>
|
||||
<model name="Strategic/Context (Pyramid)" applicability="PRDs, research reports, proposals, decision records">
|
||||
<i>Top-down: Conclusion/Status/Recommendation starts the document</i>
|
||||
<i>Grouping: Supporting context grouped logically below the headline</i>
|
||||
<i>Ordering: Most critical information first</i>
|
||||
<i>MECE: Arguments/Groups are Mutually Exclusive and Collectively Exhaustive</i>
|
||||
<i>Evidence: Data supports arguments, never leads</i>
|
||||
</model>
|
||||
</structure-models>
|
||||
</llm>
|
||||
<flow>
|
||||
<step n="1" title="Validate Input">
|
||||
<action>Check if content is empty or contains fewer than 3 words</action>
|
||||
<action if="empty or fewer than 3 words">HALT with error: "Content
|
||||
too short for substantive review (minimum 3 words required)"</action>
|
||||
<action>Validate reader_type is "humans" or "llm" (or not provided, defaulting to "humans")</action>
|
||||
<action if="reader_type is invalid">HALT with error: "Invalid reader_type. Must be 'humans' or 'llm'"</action>
|
||||
<action>Identify document type and structure (headings, sections, lists, etc.)</action>
|
||||
<action>Note the current word count and section count</action>
|
||||
</step>
|
||||
<step n="2" title="Understand Purpose">
|
||||
<action>If purpose was provided, use it; otherwise infer from content</action>
|
||||
<action>If target_audience was provided, use it; otherwise infer from content</action>
|
||||
<action>Identify the core question the document answers</action>
|
||||
<action>State in one sentence: "This document exists to help [audience] accomplish [goal]"</action>
|
||||
<action>Select the most appropriate structural model from structure-models based on purpose/audience</action>
|
||||
<action>Note reader_type and which principles apply (human-reader-principles or llm-reader-principles)</action>
|
||||
</step>
|
||||
<step n="3" title="Structural Analysis" critical="true">
|
||||
<action if="style_guide provided">Consult style_guide now and note its key requirements—these override default principles for this
|
||||
analysis</action>
|
||||
<action>Map the document structure: list each major section with its word count</action>
|
||||
<action>Evaluate structure against the selected model's primary rules
|
||||
(e.g., 'Does recommendation come first?' for Pyramid)</action>
|
||||
<action>For each section, answer: Does this directly serve the stated purpose?</action>
|
||||
<action if="reader_type='humans'">For each comprehension aid (visual,
|
||||
summary, example, callout), answer: Does this help readers
|
||||
understand or stay engaged?</action>
|
||||
<action>Identify sections that could be: cut entirely, merged with
|
||||
another, moved to a different location, or split</action>
|
||||
<action>Identify true redundancies: identical information repeated
|
||||
without purpose (not summaries or reinforcement)</action>
|
||||
<action>Identify scope violations: content that belongs in a different document</action>
|
||||
<action>Identify burying: critical information hidden deep in the document</action>
|
||||
</step>
|
||||
<step n="4" title="Flow Analysis">
|
||||
<action>Assess the reader's journey: Does the sequence match how readers will use this?</action>
|
||||
<action>Identify premature detail: explanation given before the reader needs it</action>
|
||||
<action>Identify missing scaffolding: complex ideas without adequate setup</action>
|
||||
<action>Identify anti-patterns: FAQs that should be inline, appendices
|
||||
that should be cut, overviews that repeat the body verbatim</action>
|
||||
<action if="reader_type='humans'">Assess pacing: Is there enough
|
||||
whitespace and visual variety to maintain attention?</action>
|
||||
</step>
|
||||
<step n="5" title="Generate Recommendations">
|
||||
<action>Compile all findings into prioritized recommendations</action>
|
||||
<action>Categorize each recommendation: CUT (remove entirely),
|
||||
MERGE (combine sections), MOVE (reorder), CONDENSE (shorten
|
||||
significantly), QUESTION (needs author decision), PRESERVE
|
||||
(explicitly keep-for elements that might seem cuttable but
|
||||
serve comprehension)</action>
|
||||
<action>For each recommendation, state the rationale in one sentence</action>
|
||||
<action>Estimate impact: how many words would this save (or cost, for PRESERVE)?</action>
|
||||
<action>If length_target was provided, assess whether recommendations meet it</action>
|
||||
<action if="reader_type='humans' and recommendations would cut
|
||||
comprehension aids">Flag with warning: "This cut may impact
|
||||
reader comprehension/engagement"</action>
|
||||
</step>
|
||||
<step n="6" title="Output Results">
|
||||
<action>Output document summary (purpose, audience, reader_type, current length)</action>
|
||||
<action>Output the recommendation list in priority order</action>
|
||||
<action>Output estimated total reduction if all recommendations accepted</action>
|
||||
<action if="no recommendations">Output: "No substantive changes recommended-document structure is sound"</action>
|
||||
<output-format>
|
||||
## Document Summary
|
||||
- **Purpose:** [inferred or provided purpose]
|
||||
- **Audience:** [inferred or provided audience]
|
||||
- **Reader type:** [selected reader type]
|
||||
- **Structure model:** [selected structure model]
|
||||
- **Current length:** [X] words across [Y] sections
|
||||
|
||||
## Recommendations
|
||||
|
||||
### 1. [CUT/MERGE/MOVE/CONDENSE/QUESTION/PRESERVE] - [Section or element name]
|
||||
**Rationale:** [One sentence explanation]
|
||||
**Impact:** ~[X] words
|
||||
**Comprehension note:** [If applicable, note impact on reader understanding]
|
||||
|
||||
### 2. ...
|
||||
|
||||
## Summary
|
||||
- **Total recommendations:** [N]
|
||||
- **Estimated reduction:** [X] words ([Y]% of original)
|
||||
- **Meets length target:** [Yes/No/No target specified]
|
||||
- **Comprehension trade-offs:** [Note any cuts that sacrifice reader engagement for brevity]
|
||||
</output-format>
|
||||
</step>
|
||||
</flow>
|
||||
<halt-conditions>
|
||||
<condition>HALT with error if content is empty or fewer than 3 words</condition>
|
||||
<condition>HALT with error if reader_type is not "humans" or "llm"</condition>
|
||||
<condition>If no structural issues found, output "No substantive changes
|
||||
recommended" (this is valid completion, not an error)</condition>
|
||||
</halt-conditions>
|
||||
</task>
|
||||
85
_bmad/core/tasks/help.md
Normal file
85
_bmad/core/tasks/help.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: help
|
||||
description: Get unstuck by showing what workflow steps come next or answering questions about what to do
|
||||
---
|
||||
|
||||
# Task: BMAD Help
|
||||
|
||||
## ROUTING RULES
|
||||
|
||||
- **Empty `phase` = anytime** — Universal tools work regardless of workflow state
|
||||
- **Numbered phases indicate sequence** — Phases like `1-discover` → `2-define` → `3-build` → `4-ship` flow in order (naming varies by module)
|
||||
- **Stay in module** — Guide through the active module's workflow based on phase+sequence ordering
|
||||
- **Descriptions contain routing** — Read for alternate paths (e.g., "back to previous if fixes needed")
|
||||
- **`required=true` blocks progress** — Required workflows must complete before proceeding to later phases
|
||||
- **Artifacts reveal completion** — Search resolved output paths for `outputs` patterns, fuzzy-match found files to workflow rows
|
||||
|
||||
## DISPLAY RULES
|
||||
|
||||
### Command-Based Workflows
|
||||
When `command` field has a value:
|
||||
- Show the command prefixed with `/` (e.g., `/bmad-bmm-create-prd`)
|
||||
|
||||
### Agent-Based Workflows
|
||||
When `command` field is empty:
|
||||
- User loads agent first via `/agent-command`
|
||||
- Then invokes by referencing the `code` field or describing the `name` field
|
||||
- Do NOT show a slash command — show the code value and agent load instruction instead
|
||||
|
||||
Example presentation for empty command:
|
||||
```
|
||||
Explain Concept (EC)
|
||||
Load: /tech-writer, then ask to "EC about [topic]"
|
||||
Agent: Tech Writer
|
||||
Description: Create clear technical explanations with examples...
|
||||
```
|
||||
|
||||
## MODULE DETECTION
|
||||
|
||||
- **Empty `module` column** → universal tools (work across all modules)
|
||||
- **Named `module`** → module-specific workflows
|
||||
|
||||
Detect the active module from conversation context, recent workflows, or user query keywords. If ambiguous, ask the user.
|
||||
|
||||
## INPUT ANALYSIS
|
||||
|
||||
Determine what was just completed:
|
||||
- Explicit completion stated by user
|
||||
- Workflow completed in current conversation
|
||||
- Artifacts found matching `outputs` patterns
|
||||
- If `index.md` exists, read it for additional context
|
||||
- If still unclear, ask: "What workflow did you most recently complete?"
|
||||
|
||||
## EXECUTION
|
||||
|
||||
1. **Load catalog** — Load `{project-root}/_bmad/_config/bmad-help.csv`
|
||||
|
||||
2. **Resolve output locations and config** — Scan each folder under `_bmad/` (except `_config`) for `config.yaml`. For each workflow row, resolve its `output-location` variables against that module's config so artifact paths can be searched. Also extract `communication_language` and `project_knowledge` from each scanned module's config.
|
||||
|
||||
3. **Ground in project knowledge** — If `project_knowledge` resolves to an existing path, read available documentation files (architecture docs, project overview, tech stack references) for grounding context. Use discovered project facts when composing any project-specific output. Never fabricate project-specific details — if documentation is unavailable, state so.
|
||||
|
||||
4. **Detect active module** — Use MODULE DETECTION above
|
||||
|
||||
5. **Analyze input** — Task may provide a workflow name/code, conversational phrase, or nothing. Infer what was just completed using INPUT ANALYSIS above.
|
||||
|
||||
6. **Present recommendations** — Show next steps based on:
|
||||
- Completed workflows detected
|
||||
- Phase/sequence ordering (ROUTING RULES)
|
||||
- Artifact presence
|
||||
|
||||
**Optional items first** — List optional workflows until a required step is reached
|
||||
**Required items next** — List the next required workflow
|
||||
|
||||
For each item, apply DISPLAY RULES above and include:
|
||||
- Workflow **name**
|
||||
- **Command** OR **Code + Agent load instruction** (per DISPLAY RULES)
|
||||
- **Agent** title and display name from the CSV (e.g., "🎨 Alex (Designer)")
|
||||
- Brief **description**
|
||||
|
||||
7. **Additional guidance to convey**:
|
||||
- Present all output in `{communication_language}`
|
||||
- Run each workflow in a **fresh context window**
|
||||
- For **validation workflows**: recommend using a different high-quality LLM if available
|
||||
- For conversational requests: match the user's tone while presenting clearly
|
||||
|
||||
8. Return to the calling process after presenting recommendations.
|
||||
65
_bmad/core/tasks/index-docs.xml
Normal file
65
_bmad/core/tasks/index-docs.xml
Normal file
@@ -0,0 +1,65 @@
|
||||
<task id="_bmad/core/tasks/index-docs" name="Index Docs"
|
||||
description="Generates or updates an index.md of all documents in the specified directory">
|
||||
<llm critical="true">
|
||||
<i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
|
||||
<i>DO NOT skip steps or change the sequence</i>
|
||||
<i>HALT immediately when halt-conditions are met</i>
|
||||
<i>Each action xml tag within step xml tag is a REQUIRED action to complete that step</i>
|
||||
<i>Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution</i>
|
||||
</llm>
|
||||
|
||||
<flow>
|
||||
<step n="1" title="Scan Directory">
|
||||
<i>List all files and subdirectories in the target location</i>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Group Content">
|
||||
<i>Organize files by type, purpose, or subdirectory</i>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Generate Descriptions">
|
||||
<i>Read each file to understand its actual purpose and create brief (3-10 word) descriptions based on the content, not just the
|
||||
filename</i>
|
||||
</step>
|
||||
|
||||
<step n="4" title="Create/Update Index">
|
||||
<i>Write or update index.md with organized file listings</i>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
<output-format>
|
||||
<example>
|
||||
# Directory Index
|
||||
|
||||
## Files
|
||||
|
||||
- **[filename.ext](./filename.ext)** - Brief description
|
||||
- **[another-file.ext](./another-file.ext)** - Brief description
|
||||
|
||||
## Subdirectories
|
||||
|
||||
### subfolder/
|
||||
|
||||
- **[file1.ext](./subfolder/file1.ext)** - Brief description
|
||||
- **[file2.ext](./subfolder/file2.ext)** - Brief description
|
||||
|
||||
### another-folder/
|
||||
|
||||
- **[file3.ext](./another-folder/file3.ext)** - Brief description
|
||||
</example>
|
||||
</output-format>
|
||||
|
||||
<halt-conditions critical="true">
|
||||
<i>HALT if target directory does not exist or is inaccessible</i>
|
||||
<i>HALT if user does not have write permissions to create index.md</i>
|
||||
</halt-conditions>
|
||||
|
||||
<validation>
|
||||
<i>Use relative paths starting with ./</i>
|
||||
<i>Group similar files together</i>
|
||||
<i>Read file contents to generate accurate descriptions - don't guess from filenames</i>
|
||||
<i>Keep descriptions concise but informative (3-10 words)</i>
|
||||
<i>Sort alphabetically within groups</i>
|
||||
<i>Skip hidden files (starting with .) unless specified</i>
|
||||
</validation>
|
||||
</task>
|
||||
48
_bmad/core/tasks/review-adversarial-general.xml
Normal file
48
_bmad/core/tasks/review-adversarial-general.xml
Normal file
@@ -0,0 +1,48 @@
|
||||
<!-- if possible, run this in a separate subagent or process with read access to the project,
|
||||
but no context except the content to review -->
|
||||
|
||||
<task id="_bmad/core/tasks/review-adversarial-general.xml" name="Adversarial Review (General)">
|
||||
<objective>Cynically review content and produce findings</objective>
|
||||
|
||||
<inputs>
|
||||
<input name="content" desc="Content to review - diff, spec, story, doc, or any artifact" />
|
||||
<input name="also_consider" required="false"
|
||||
desc="Optional areas to keep in mind during review alongside normal adversarial analysis" />
|
||||
</inputs>
|
||||
|
||||
<llm critical="true">
|
||||
<i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
|
||||
<i>DO NOT skip steps or change the sequence</i>
|
||||
<i>HALT immediately when halt-conditions are met</i>
|
||||
<i>Each action xml tag within step xml tag is a REQUIRED action to complete that step</i>
|
||||
|
||||
<i>You are a cynical, jaded reviewer with zero patience for sloppy work</i>
|
||||
<i>The content was submitted by a clueless weasel and you expect to find problems</i>
|
||||
<i>Be skeptical of everything</i>
|
||||
<i>Look for what's missing, not just what's wrong</i>
|
||||
<i>Use a precise, professional tone - no profanity or personal attacks</i>
|
||||
</llm>
|
||||
|
||||
<flow>
|
||||
<step n="1" title="Receive Content">
|
||||
<action>Load the content to review from provided input or context</action>
|
||||
<action>If content to review is empty, ask for clarification and abort task</action>
|
||||
<action>Identify content type (diff, branch, uncommitted changes, document, etc.)</action>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Adversarial Analysis" critical="true">
|
||||
<mandate>Review with extreme skepticism - assume problems exist</mandate>
|
||||
<action>Find at least ten issues to fix or improve in the provided content</action>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Present Findings">
|
||||
<action>Output findings as a Markdown list (descriptions only)</action>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
<halt-conditions>
|
||||
<condition>HALT if zero findings - this is suspicious, re-analyze or ask for guidance</condition>
|
||||
<condition>HALT if content is empty or unreadable</condition>
|
||||
</halt-conditions>
|
||||
|
||||
</task>
|
||||
108
_bmad/core/tasks/shard-doc.xml
Normal file
108
_bmad/core/tasks/shard-doc.xml
Normal file
@@ -0,0 +1,108 @@
|
||||
<task id="_bmad/core/tasks/shard-doc" name="Shard Document"
|
||||
description="Splits large markdown documents into smaller, organized files based on level 2 (default) sections">
|
||||
<objective>Split large markdown documents into smaller, organized files based on level 2 sections using @kayvan/markdown-tree-parser tool</objective>
|
||||
|
||||
<llm critical="true">
|
||||
<i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
|
||||
<i>DO NOT skip steps or change the sequence</i>
|
||||
<i>HALT immediately when halt-conditions are met</i>
|
||||
<i>Each action xml tag within step xml tag is a REQUIRED action to complete that step</i>
|
||||
<i>Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution</i>
|
||||
</llm>
|
||||
|
||||
<critical-context>
|
||||
<i>Uses `npx @kayvan/markdown-tree-parser` to automatically shard documents by level 2 headings and generate an index</i>
|
||||
</critical-context>
|
||||
|
||||
<flow>
|
||||
<step n="1" title="Get Source Document">
|
||||
<action>Ask user for the source document path if not provided already</action>
|
||||
<action>Verify file exists and is accessible</action>
|
||||
<action>Verify file is markdown format (.md extension)</action>
|
||||
<action if="file not found or not markdown">HALT with error message</action>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Get Destination Folder">
|
||||
<action>Determine default destination: same location as source file, folder named after source file without .md extension</action>
|
||||
<action>Example: /path/to/architecture.md → /path/to/architecture/</action>
|
||||
<action>Ask user for the destination folder path ([y] to confirm use of default: [suggested-path], else enter a new path)</action>
|
||||
<action if="user accepts default">Use the suggested destination path</action>
|
||||
<action if="user provides custom path">Use the custom destination path</action>
|
||||
<action>Verify destination folder exists or can be created</action>
|
||||
<action>Check write permissions for destination</action>
|
||||
<action if="permission denied">HALT with error message</action>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Execute Sharding">
|
||||
<action>Inform user that sharding is beginning</action>
|
||||
<action>Execute command: `npx @kayvan/markdown-tree-parser explode [source-document] [destination-folder]`</action>
|
||||
<action>Capture command output and any errors</action>
|
||||
<action if="command fails">HALT and display error to user</action>
|
||||
</step>
|
||||
|
||||
<step n="4" title="Verify Output">
|
||||
<action>Check that destination folder contains sharded files</action>
|
||||
<action>Verify index.md was created in destination folder</action>
|
||||
<action>Count the number of files created</action>
|
||||
<action if="no files created">HALT with error message</action>
|
||||
</step>
|
||||
|
||||
<step n="5" title="Report Completion">
|
||||
<action>Display completion report to user including:</action>
|
||||
<i>- Source document path and name</i>
|
||||
<i>- Destination folder path</i>
|
||||
<i>- Number of section files created</i>
|
||||
<i>- Confirmation that index.md was created</i>
|
||||
<i>- Any tool output or warnings</i>
|
||||
<action>Inform user that sharding completed successfully</action>
|
||||
</step>
|
||||
|
||||
<step n="6" title="Handle Original Document">
|
||||
<critical>Keeping both the original and sharded versions defeats the purpose of sharding and can cause confusion</critical>
|
||||
<action>Present user with options for the original document:</action>
|
||||
|
||||
<ask>What would you like to do with the original document `[source-document-name]`?
|
||||
|
||||
Options:
|
||||
[d] Delete - Remove the original (recommended - shards can always be recombined)
|
||||
[m] Move to archive - Move original to a backup/archive location
|
||||
[k] Keep - Leave original in place (NOT recommended - defeats sharding purpose)
|
||||
|
||||
Your choice (d/m/k):</ask>
|
||||
|
||||
<check if="user selects 'd' (delete)">
|
||||
<action>Delete the original source document file</action>
|
||||
<action>Confirm deletion to user: "✓ Original document deleted: [source-document-path]"</action>
|
||||
<note>The document can be reconstructed from shards by concatenating all section files in order</note>
|
||||
</check>
|
||||
|
||||
<check if="user selects 'm' (move)">
|
||||
<action>Determine default archive location: same directory as source, in an "archive" subfolder</action>
|
||||
<action>Example: /path/to/architecture.md → /path/to/archive/architecture.md</action>
|
||||
<ask>Archive location ([y] to use default: [default-archive-path], or provide custom path):</ask>
|
||||
<action if="user accepts default">Use default archive path</action>
|
||||
<action if="user provides custom path">Use custom archive path</action>
|
||||
<action>Create archive directory if it doesn't exist</action>
|
||||
<action>Move original document to archive location</action>
|
||||
<action>Confirm move to user: "✓ Original document moved to: [archive-path]"</action>
|
||||
</check>
|
||||
|
||||
<check if="user selects 'k' (keep)">
|
||||
<action>Display warning to user:</action>
|
||||
<output>⚠️ WARNING: Keeping both original and sharded versions is NOT recommended.
|
||||
|
||||
This creates confusion because:
|
||||
- The discover_inputs protocol may load the wrong version
|
||||
- Updates to one won't reflect in the other
|
||||
- You'll have duplicate content taking up space
|
||||
|
||||
Consider deleting or archiving the original document.</output>
|
||||
<action>Confirm user choice: "Original document kept at: [source-document-path]"</action>
|
||||
</check>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
<halt-conditions critical="true">
|
||||
<i>HALT if npx command fails or produces no output files</i>
|
||||
</halt-conditions>
|
||||
</task>
|
||||
235
_bmad/core/tasks/workflow.xml
Normal file
235
_bmad/core/tasks/workflow.xml
Normal file
@@ -0,0 +1,235 @@
|
||||
<task id="_bmad/core/tasks/workflow.xml" name="Execute Workflow" internal="true">
|
||||
<objective>Execute given workflow by loading its configuration, following instructions, and producing output</objective>
|
||||
|
||||
<llm critical="true">
|
||||
<mandate>Always read COMPLETE files - NEVER use offset/limit when reading any workflow related files</mandate>
|
||||
<mandate>Instructions are MANDATORY - either as file path, steps or embedded list in YAML, XML or markdown</mandate>
|
||||
<mandate>Execute ALL steps in instructions IN EXACT ORDER</mandate>
|
||||
<mandate>Save to template output file after EVERY "template-output" tag</mandate>
|
||||
<mandate>NEVER skip a step - YOU are responsible for every steps execution without fail or excuse</mandate>
|
||||
</llm>
|
||||
|
||||
<WORKFLOW-RULES critical="true">
|
||||
<rule n="1">Steps execute in exact numerical order (1, 2, 3...)</rule>
|
||||
<rule n="2">Optional steps: Ask user unless #yolo mode active</rule>
|
||||
<rule n="3">Template-output tags: Save content, discuss with the user the section completed, and NEVER proceed until the users indicates
|
||||
to proceed (unless YOLO mode has been activated)</rule>
|
||||
</WORKFLOW-RULES>
|
||||
|
||||
<flow>
|
||||
<step n="1" title="Load and Initialize Workflow">
|
||||
<substep n="1a" title="Load Configuration and Resolve Variables">
|
||||
<action>Read workflow.yaml from provided path</action>
|
||||
<mandate>Load config_source (REQUIRED for all modules)</mandate>
|
||||
<phase n="1">Load external config from config_source path</phase>
|
||||
<phase n="2">Resolve all {config_source}: references with values from config</phase>
|
||||
<phase n="3">Resolve system variables (date:system-generated) and paths ({project-root}, {installed_path})</phase>
|
||||
<phase n="4">Ask user for input of any variables that are still unknown</phase>
|
||||
</substep>
|
||||
|
||||
<substep n="1b" title="Load Required Components">
|
||||
<mandate>Instructions: Read COMPLETE file from path OR embedded list (REQUIRED)</mandate>
|
||||
<check>If template path → Read COMPLETE template file</check>
|
||||
<check>If validation path → Note path for later loading when needed</check>
|
||||
<check>If template: false → Mark as action-workflow (else template-workflow)</check>
|
||||
<note>Data files (csv, json) → Store paths only, load on-demand when instructions reference them</note>
|
||||
</substep>
|
||||
|
||||
<substep n="1c" title="Initialize Output" if="template-workflow">
|
||||
<action>Resolve default_output_file path with all variables and {{date}}</action>
|
||||
<action>Create output directory if doesn't exist</action>
|
||||
<action>If template-workflow → Write template to output file with placeholders</action>
|
||||
<action>If action-workflow → Skip file creation</action>
|
||||
</substep>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Process Each Instruction Step in Order">
|
||||
<iterate>For each step in instructions:</iterate>
|
||||
|
||||
<substep n="2a" title="Handle Step Attributes">
|
||||
<check>If optional="true" and NOT #yolo → Ask user to include</check>
|
||||
<check>If if="condition" → Evaluate condition</check>
|
||||
<check>If for-each="item" → Repeat step for each item</check>
|
||||
<check>If repeat="n" → Repeat step n times</check>
|
||||
</substep>
|
||||
|
||||
<substep n="2b" title="Execute Step Content">
|
||||
<action>Process step instructions (markdown or XML tags)</action>
|
||||
<action>Replace {{variables}} with values (ask user if unknown)</action>
|
||||
<execute-tags>
|
||||
<tag>action xml tag → Perform the action</tag>
|
||||
<tag>check if="condition" xml tag → Conditional block wrapping actions (requires closing </check>)</tag>
|
||||
<tag>ask xml tag → Prompt user and WAIT for response</tag>
|
||||
<tag>invoke-workflow xml tag → Execute another workflow with given inputs and the workflow.xml runner</tag>
|
||||
<tag>invoke-task xml tag → Execute specified task</tag>
|
||||
<tag>invoke-protocol name="protocol_name" xml tag → Execute reusable protocol from protocols section</tag>
|
||||
<tag>goto step="x" → Jump to specified step</tag>
|
||||
</execute-tags>
|
||||
</substep>
|
||||
|
||||
<substep n="2c" title="Handle template-output Tags">
|
||||
<if tag="template-output">
|
||||
<mandate>Generate content for this section</mandate>
|
||||
<mandate>Save to file (Write first time, Edit subsequent)</mandate>
|
||||
<action>Display generated content</action>
|
||||
<ask> [a] Advanced Elicitation, [c] Continue, [p] Party-Mode, [y] YOLO the rest of this document only. WAIT for response. <if
|
||||
response="a">
|
||||
<action>Start the advanced elicitation workflow {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml</action>
|
||||
</if>
|
||||
<if
|
||||
response="c">
|
||||
<action>Continue to next step</action>
|
||||
</if>
|
||||
<if response="p">
|
||||
<action>Start the party-mode workflow {project-root}/_bmad/core/workflows/party-mode/workflow.md</action>
|
||||
</if>
|
||||
<if
|
||||
response="y">
|
||||
<action>Enter #yolo mode for the rest of the workflow</action>
|
||||
</if>
|
||||
</ask>
|
||||
</if>
|
||||
</substep>
|
||||
|
||||
<substep n="2d" title="Step Completion">
|
||||
<check>If no special tags and NOT #yolo:</check>
|
||||
<ask>Continue to next step? (y/n/edit)</ask>
|
||||
</substep>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Completion">
|
||||
<check>Confirm document saved to output path</check>
|
||||
<action>Report workflow completion</action>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
<execution-modes>
|
||||
<mode name="normal">Full user interaction and confirmation of EVERY step at EVERY template output - NO EXCEPTIONS except yolo MODE</mode>
|
||||
<mode name="yolo">Skip all confirmations and elicitation, minimize prompts and try to produce all of the workflow automatically by
|
||||
simulating the remaining discussions with an simulated expert user</mode>
|
||||
</execution-modes>
|
||||
|
||||
<supported-tags desc="Instructions can use these tags">
|
||||
<structural>
|
||||
<tag>step n="X" goal="..." - Define step with number and goal</tag>
|
||||
<tag>optional="true" - Step can be skipped</tag>
|
||||
<tag>if="condition" - Conditional execution</tag>
|
||||
<tag>for-each="collection" - Iterate over items</tag>
|
||||
<tag>repeat="n" - Repeat n times</tag>
|
||||
</structural>
|
||||
<execution>
|
||||
<tag>action - Required action to perform</tag>
|
||||
<tag>action if="condition" - Single conditional action (inline, no closing tag needed)</tag>
|
||||
<tag>check if="condition">...</check> - Conditional block wrapping multiple items (closing tag required)</tag>
|
||||
<tag>ask - Get user input (ALWAYS wait for response before continuing)</tag>
|
||||
<tag>goto - Jump to another step</tag>
|
||||
<tag>invoke-workflow - Call another workflow</tag>
|
||||
<tag>invoke-task - Call a task</tag>
|
||||
<tag>invoke-protocol - Execute a reusable protocol (e.g., discover_inputs)</tag>
|
||||
</execution>
|
||||
<output>
|
||||
<tag>template-output - Save content checkpoint</tag>
|
||||
<tag>critical - Cannot be skipped</tag>
|
||||
<tag>example - Show example output</tag>
|
||||
</output>
|
||||
</supported-tags>
|
||||
|
||||
<protocols desc="Reusable workflow protocols that can be invoked via invoke-protocol tag">
|
||||
<protocol name="discover_inputs" desc="Smart file discovery and loading based on input_file_patterns">
|
||||
<objective>Intelligently load project files (whole or sharded) based on workflow's input_file_patterns configuration</objective>
|
||||
|
||||
<critical>Only execute if workflow.yaml contains input_file_patterns section</critical>
|
||||
|
||||
<flow>
|
||||
<step n="1" title="Parse Input File Patterns">
|
||||
<action>Read input_file_patterns from loaded workflow.yaml</action>
|
||||
<action>For each pattern group (prd, architecture, epics, etc.), note the load_strategy if present</action>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Load Files Using Smart Strategies">
|
||||
<iterate>For each pattern in input_file_patterns:</iterate>
|
||||
|
||||
<substep n="2a" title="Try Sharded Documents First">
|
||||
<check if="sharded pattern exists">
|
||||
<action>Determine load_strategy from pattern config (defaults to FULL_LOAD if not specified)</action>
|
||||
|
||||
<strategy name="FULL_LOAD">
|
||||
<desc>Load ALL files in sharded directory - used for PRD, Architecture, UX, brownfield docs</desc>
|
||||
<action>Use glob pattern to find ALL .md files (e.g., "{output_folder}/*architecture*/*.md")</action>
|
||||
<action>Load EVERY matching file completely</action>
|
||||
<action>Concatenate content in logical order (index.md first if exists, then alphabetical)</action>
|
||||
<action>Store in variable: {pattern_name_content}</action>
|
||||
</strategy>
|
||||
|
||||
<strategy name="SELECTIVE_LOAD">
|
||||
<desc>Load specific shard using template variable - example: used for epics with {{epic_num}}</desc>
|
||||
<action>Check for template variables in sharded_single pattern (e.g., {{epic_num}})</action>
|
||||
<action>If variable undefined, ask user for value OR infer from context</action>
|
||||
<action>Resolve template to specific file path</action>
|
||||
<action>Load that specific file</action>
|
||||
<action>Store in variable: {pattern_name_content}</action>
|
||||
</strategy>
|
||||
|
||||
<strategy name="INDEX_GUIDED">
|
||||
<desc>Load index.md, analyze structure and description of each doc in the index, then intelligently load relevant docs</desc>
|
||||
<mandate>DO NOT BE LAZY - use best judgment to load documents that might have relevant information, even if only a 5% chance</mandate>
|
||||
<action>Load index.md from sharded directory</action>
|
||||
<action>Parse table of contents, links, section headers</action>
|
||||
<action>Analyze workflow's purpose and objective</action>
|
||||
<action>Identify which linked/referenced documents are likely relevant</action>
|
||||
<example>If workflow is about authentication and index shows "Auth Overview", "Payment Setup", "Deployment" → Load auth
|
||||
docs, consider deployment docs, skip payment</example>
|
||||
<action>Load all identified relevant documents</action>
|
||||
<action>Store combined content in variable: {pattern_name_content}</action>
|
||||
<note>When in doubt, LOAD IT - context is valuable, being thorough is better than missing critical info</note>
|
||||
</strategy>
|
||||
<action>Mark pattern as RESOLVED, skip to next pattern</action>
|
||||
</check>
|
||||
</substep>
|
||||
|
||||
<substep n="2b" title="Try Whole Document if No Sharded Found">
|
||||
<check if="no sharded matches found OR no sharded pattern exists">
|
||||
<action>Attempt glob match on 'whole' pattern (e.g., "{output_folder}/*prd*.md")</action>
|
||||
<check if="matches found">
|
||||
<action>Load ALL matching files completely (no offset/limit)</action>
|
||||
<action>Store content in variable: {pattern_name_content} (e.g., {prd_content})</action>
|
||||
<action>Mark pattern as RESOLVED, skip to next pattern</action>
|
||||
</check>
|
||||
</check>
|
||||
</substep>
|
||||
|
||||
<substep n="2c" title="Handle Not Found">
|
||||
<check if="no matches for sharded OR whole">
|
||||
<action>Set {pattern_name_content} to empty string</action>
|
||||
<action>Note in session: "No {pattern_name} files found" (not an error, just unavailable, offer use change to provide)</action>
|
||||
</check>
|
||||
</substep>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Report Discovery Results">
|
||||
<action>List all loaded content variables with file counts</action>
|
||||
<example>
|
||||
✓ Loaded {prd_content} from 5 sharded files: prd/index.md, prd/requirements.md, ...
|
||||
✓ Loaded {architecture_content} from 1 file: Architecture.md
|
||||
✓ Loaded {epics_content} from selective load: epics/epic-3.md
|
||||
○ No ux_design files found
|
||||
</example>
|
||||
<note>This gives workflow transparency into what context is available</note>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
</protocol>
|
||||
</protocols>
|
||||
|
||||
<llm final="true">
|
||||
<critical-rules>
|
||||
• This is the complete workflow execution engine
|
||||
• You MUST Follow instructions exactly as written
|
||||
• The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml
|
||||
• You MUST have already loaded and processed: {installed_path}/workflow.yaml
|
||||
• This workflow uses INTENT-DRIVEN PLANNING - adapt organically to product type and context
|
||||
• YOU ARE FACILITATING A CONVERSATION With a user to produce a final document step by step. The whole process is meant to be
|
||||
collaborative helping the user flesh out their ideas. Do not rush or optimize and skip any section.
|
||||
</critical-rules>
|
||||
</llm>
|
||||
</task>
|
||||
Reference in New Issue
Block a user