Update project structure and configurations
This commit is contained in:
@@ -3,4 +3,102 @@ name: bmad-create-prd
|
||||
description: 'Create a PRD from scratch. Use when the user says "lets create a product requirements document" or "I want to create a new PRD"'
|
||||
---
|
||||
|
||||
Follow the instructions in ./workflow.md.
|
||||
# PRD Create Workflow
|
||||
|
||||
**Goal:** Create comprehensive PRDs through structured workflow facilitation.
|
||||
|
||||
**Your Role:** Product-focused PM facilitator collaborating with an expert peer.
|
||||
|
||||
You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `steps-c/step-01-init.md`) resolve from the skill root.
|
||||
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
||||
- `{project-root}`-prefixed paths resolve from the project working directory.
|
||||
- `{skill-name}` resolves to the skill directory's basename.
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **step-file architecture** for disciplined execution:
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step is a self-contained instruction file that is a part of an overall workflow that must be followed exactly
|
||||
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
||||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
||||
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
||||
6. **LOAD NEXT**: When directed, read fully and follow the next step file
|
||||
|
||||
### Critical Rules (NO EXCEPTIONS)
|
||||
|
||||
- 🛑 **NEVER** load multiple step files simultaneously
|
||||
- 📖 **ALWAYS** read entire step file before execution
|
||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
||||
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
||||
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||
- 📋 **NEVER** create mental todo lists from future steps
|
||||
|
||||
## On Activation
|
||||
|
||||
### Step 1: Resolve the Workflow Block
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
||||
|
||||
**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
|
||||
|
||||
1. `{skill-root}/customize.toml` — defaults
|
||||
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
|
||||
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
|
||||
|
||||
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
|
||||
|
||||
### Step 2: Execute Prepend Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
||||
|
||||
### Step 3: Load Persistent Facts
|
||||
|
||||
Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
|
||||
|
||||
### Step 4: Load Config
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
- Use `{user_name}` for greeting
|
||||
- Use `{communication_language}` for all communications
|
||||
- Use `{document_output_language}` for output documents
|
||||
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||
- Use `{project_knowledge}` for additional context scanning
|
||||
|
||||
### Step 5: Greet the User
|
||||
|
||||
Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
### Step 6: Execute Append Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
Activation is complete. Begin the workflow below.
|
||||
|
||||
## Paths
|
||||
|
||||
- `outputFile` = `{planning_artifacts}/prd.md`
|
||||
|
||||
## Execution
|
||||
|
||||
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
||||
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
||||
|
||||
**Create Mode: Creating a new PRD from scratch.**
|
||||
|
||||
Read fully and follow: `./steps-c/step-01-init.md`
|
||||
|
||||
41
.agent/skills/bmad-create-prd/customize.toml
Normal file
41
.agent/skills/bmad-create-prd/customize.toml
Normal file
@@ -0,0 +1,41 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-create-prd. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "All PRDs must include a regulatory-risk section."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches Step 12 (Workflow Completion),
|
||||
# after the PRD is finalized and workflow status is updated. Override wins.
|
||||
# Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -1,4 +1,4 @@
|
||||
# Step 8: Scoping Exercise - MVP & Future Features
|
||||
# Step 8: Scoping Exercise - Scope Definition (Phased or Single-Release)
|
||||
|
||||
**Progress: Step 8 of 11** - Next: Functional Requirements
|
||||
|
||||
@@ -12,6 +12,8 @@
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on strategic scope decisions that keep projects viable
|
||||
- 🎯 EMPHASIZE lean MVP thinking while preserving long-term vision
|
||||
- ⚠️ NEVER de-scope, defer, or phase out requirements that the user explicitly included in their input documents without asking first
|
||||
- ⚠️ NEVER invent phasing (MVP/Growth/Vision) unless the user requests phased delivery — if input documents define all components as core requirements, they are ALL in scope
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
@@ -34,7 +36,7 @@
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct comprehensive scoping exercise to define MVP boundaries and prioritize features across development phases.
|
||||
Conduct comprehensive scoping exercise to define release boundaries and prioritize features based on the user's chosen delivery mode (phased or single-release).
|
||||
|
||||
## SCOPING SEQUENCE:
|
||||
|
||||
@@ -75,30 +77,41 @@ Use structured decision-making for scope:
|
||||
- Advanced functionality that builds on MVP
|
||||
- Ask what features could be added in versions 2, 3, etc.
|
||||
|
||||
**⚠️ SCOPE CHANGE CONFIRMATION GATE:**
|
||||
- If you believe any user-specified requirement should be deferred or de-scoped, you MUST present this to the user and get explicit confirmation BEFORE removing it from scope
|
||||
- Frame it as a recommendation, not a decision: "I'd recommend deferring X because [reason]. Do you agree, or should it stay in scope?"
|
||||
- NEVER silently move user requirements to a later phase or exclude them from MVP
|
||||
- Before creating any consequential phase-based artifacts (e.g., phase tags, labels, or follow-on prompts), present artifact creation as a recommendation and proceed only after explicit user approval
|
||||
|
||||
### 4. Progressive Feature Roadmap
|
||||
|
||||
Create phased development approach:
|
||||
- Guide mapping of features across development phases
|
||||
- Structure as Phase 1 (MVP), Phase 2 (Growth), Phase 3 (Vision)
|
||||
- Ensure clear progression and dependencies
|
||||
**CRITICAL: Phasing is NOT automatic. Check the user's input first.**
|
||||
|
||||
- Core user value delivery
|
||||
- Essential user journeys
|
||||
- Basic functionality that works reliably
|
||||
Before proposing any phased approach, review the user's input documents:
|
||||
|
||||
**Phase 2: Growth**
|
||||
- **If the input documents define all components as core requirements with no mention of phases:** Present all requirements as a single release scope. Do NOT invent phases or move requirements to fabricated future phases.
|
||||
- **If the input documents explicitly request phased delivery:** Guide mapping of features across the phases the user defined.
|
||||
- **If scope is unclear:** ASK the user whether they want phased delivery or a single release before proceeding.
|
||||
|
||||
- Additional user types
|
||||
- Enhanced features
|
||||
- Scale improvements
|
||||
**When the user requests phased delivery**, guide mapping of features across the phases the user defines:
|
||||
|
||||
**Phase 3: Expansion**
|
||||
- Use user-provided phase labels and count; if none are provided, propose a default (e.g., MVP/Growth/Vision) and ask for confirmation
|
||||
- Ensure clear progression and dependencies between phases
|
||||
|
||||
- Advanced capabilities
|
||||
- Platform features
|
||||
- New markets or use cases
|
||||
**Each phase should address:**
|
||||
|
||||
**Where does your current vision fit in this development sequence?**"
|
||||
- Core user value delivery and essential journeys for that phase
|
||||
- Clear boundaries on what ships in each phase
|
||||
- Dependencies on prior phases
|
||||
|
||||
**When the user chooses a single release**, define the complete scope:
|
||||
|
||||
- All user-specified requirements are in scope
|
||||
- Focus must-have vs nice-to-have analysis on what ships in this release
|
||||
- Do NOT create phases — use must-have/nice-to-have priority within the single release
|
||||
|
||||
**If phased delivery:** "Where does your current vision fit in this development sequence?"
|
||||
**If single release:** "How does your current vision map to this upcoming release?"
|
||||
|
||||
### 5. Risk-Based Scoping
|
||||
|
||||
@@ -129,6 +142,8 @@ Prepare comprehensive scoping section:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
**If user chose phased delivery:**
|
||||
|
||||
```markdown
|
||||
## Project Scoping & Phased Development
|
||||
|
||||
@@ -160,11 +175,39 @@ Prepare comprehensive scoping section:
|
||||
**Resource Risks:** {{contingency_approach}}
|
||||
```
|
||||
|
||||
**If user chose single release (no phasing):**
|
||||
|
||||
```markdown
|
||||
## Project Scoping
|
||||
|
||||
### Strategy & Philosophy
|
||||
|
||||
**Approach:** {{chosen_approach}}
|
||||
**Resource Requirements:** {{team_size_and_skills}}
|
||||
|
||||
### Complete Feature Set
|
||||
|
||||
**Core User Journeys Supported:**
|
||||
{{all_journeys}}
|
||||
|
||||
**Must-Have Capabilities:**
|
||||
{{list_of_must_have_features}}
|
||||
|
||||
**Nice-to-Have Capabilities:**
|
||||
{{list_of_nice_to_have_features}}
|
||||
|
||||
### Risk Mitigation Strategy
|
||||
|
||||
**Technical Risks:** {{mitigation_approach}}
|
||||
**Market Risks:** {{validation_approach}}
|
||||
**Resource Risks:** {{contingency_approach}}
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Present the scoping decisions for review, then display menu:
|
||||
- Show strategic scoping plan (using structure from step 6)
|
||||
- Highlight MVP boundaries and phased roadmap
|
||||
- Highlight release boundaries and prioritization (phased roadmap only if phased delivery was selected)
|
||||
- Ask if they'd like to refine further, get other perspectives, or proceed
|
||||
- Present menu options naturally as part of conversation
|
||||
|
||||
@@ -173,7 +216,7 @@ Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Fu
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current scoping analysis, process the enhanced insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF P: Invoke the `bmad-party-mode` skill with the scoping context, process the collaborative insights on MVP and roadmap decisions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-09-functional.md
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array (also add `releaseMode: phased` or `releaseMode: single-release` to frontmatter based on user's choice), then read fully and follow: ./step-09-functional.md
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
@@ -189,8 +232,9 @@ When user selects 'C', append the content directly to the document using the str
|
||||
|
||||
✅ Complete PRD document analyzed for scope implications
|
||||
✅ Strategic MVP approach defined and justified
|
||||
✅ Clear MVP feature boundaries established
|
||||
✅ Phased development roadmap created
|
||||
✅ Clear feature boundaries established (phased or single-release, per user preference)
|
||||
✅ All user-specified requirements accounted for — none silently removed or deferred
|
||||
✅ Any scope reduction recommendations presented to user with rationale and explicit confirmation obtained
|
||||
✅ Key risks identified and mitigation strategies defined
|
||||
✅ User explicitly agrees to scope decisions
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
@@ -202,8 +246,11 @@ When user selects 'C', append the content directly to the document using the str
|
||||
❌ Making scope decisions without strategic rationale
|
||||
❌ Not getting explicit user agreement on MVP boundaries
|
||||
❌ Missing critical risk analysis
|
||||
❌ Not creating clear phased development approach
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ **CRITICAL**: Silently de-scoping or deferring requirements that the user explicitly included in their input documents
|
||||
❌ **CRITICAL**: Inventing phasing (MVP/Growth/Vision) when the user did not request phased delivery
|
||||
❌ **CRITICAL**: Making consequential scoping decisions (what is in/out of scope) without explicit user confirmation
|
||||
❌ **CRITICAL**: Creating phase-based artifacts (tags, labels, follow-on prompts) without explicit user approval
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
|
||||
@@ -138,7 +138,7 @@ Make targeted improvements:
|
||||
- All user success criteria
|
||||
- All functional requirements (capability contract)
|
||||
- All user journey narratives
|
||||
- All scope decisions (MVP, Growth, Vision)
|
||||
- All scope decisions (whether phased or single-release), including consent-critical evidence (explicit user confirmations and rationales for any scope changes from step 8)
|
||||
- All non-functional requirements
|
||||
- Product differentiator and vision
|
||||
- Domain-specific requirements
|
||||
|
||||
@@ -113,3 +113,9 @@ PRD complete. Invoke the `bmad-help` skill.
|
||||
The polished PRD serves as the foundation for all subsequent product development activities. All design, architecture, and development work should trace back to the requirements and vision documented in this PRD - update it also as needed as you continue planning.
|
||||
|
||||
**Congratulations on completing the Product Requirements Document for {{project_name}}!** 🎉
|
||||
|
||||
## On Complete
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
|
||||
|
||||
If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.
|
||||
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
main_config: '{project-root}/_bmad/bmm/config.yaml'
|
||||
outputFile: '{planning_artifacts}/prd.md'
|
||||
---
|
||||
|
||||
# PRD Create Workflow
|
||||
|
||||
**Goal:** Create comprehensive PRDs through structured workflow facilitation.
|
||||
|
||||
**Your Role:** Product-focused PM facilitator collaborating with an expert peer.
|
||||
|
||||
You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **step-file architecture** for disciplined execution:
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
|
||||
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
||||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
||||
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
||||
6. **LOAD NEXT**: When directed, read fully and follow the next step file
|
||||
|
||||
### Critical Rules (NO EXCEPTIONS)
|
||||
|
||||
- 🛑 **NEVER** load multiple step files simultaneously
|
||||
- 📖 **ALWAYS** read entire step file before execution
|
||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
||||
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
||||
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||
- 📋 **NEVER** create mental todo lists from future steps
|
||||
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Configuration Loading
|
||||
|
||||
Load and read full config from {main_config} and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
||||
- `date` as system-generated current datetime
|
||||
|
||||
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
||||
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
||||
|
||||
### 2. Route to Create Workflow
|
||||
|
||||
"**Create Mode: Creating a new PRD from scratch.**"
|
||||
|
||||
Read fully and follow: `./steps-c/step-01-init.md`
|
||||
Reference in New Issue
Block a user