bmad-product-manager
Scannednpx machina-cli add skill xmm/codex-bmad-skills/bmad-product-manager --openclawBMAD Product Manager
Trigger Intents
bmad:prdbmad:tech-specbmad:prioritize
Workflow Variants
prd
- Default for level 2-4 initiatives and multi-epic scope.
tech-spec
- Default for level 0-1 changes or tightly scoped features.
prioritize
- Use to rank backlog items and resolve scope pressure.
Decision rule:
- Level 0-1 -> start with
tech-spec - Level 2-4 -> start with
prd
Inputs
- discovery artifacts from analyst (
product-brief, research) bmad/project.yamlproject level and constraints- known business goals and delivery timeline
Language Guard (Mandatory)
Enforce language selection separately for chat responses and generated artifacts.
Chat language (communication_language) fallback order:
language.communication_languagefrombmad/project.yamlEnglish
Rules for chat responses:
- Use the resolved chat language for all assistant responses (questions, status updates, summaries, and handoff notes).
- Do not switch chat language unless the user explicitly requests a different language in the current thread.
Artifact language (document_output_language) fallback order:
language.document_output_languagefrombmad/project.yamlEnglish
Rules for generated artifacts:
- Use the resolved artifact language for all generated BMAD documents and structured artifacts.
- write prose and field values in the resolved document language
- avoid mixed-language requirement clauses with English modal verbs (for example,
System shallfollowed by non-English text) - allow English acronyms/abbreviations in non-English sentences (for example,
API,SLA,KPI,OAuth,WCAG) - keep
Given,when,thenin English as notation tokens and format them in bold (**Given**,**when**,**then**) - localize field values such as
Compliance,Load Profile, andMeasurement Method - Keep code snippets, CLI commands, file paths, and identifiers in their original technical form.
Mandatory Reference Load
Before executing prd, tech-spec, or prioritize, read REFERENCE.md first.
Treat REFERENCE.md as required context for requirement quality and handoff discipline.
Output Contract
prd->docs/bmad/prd.mdtech-spec->docs/bmad/tech-spec.mdprioritize->docs/bmad/prioritization.md
Core Workflow
- Select planning artifact by project level and uncertainty.
- Define functional and non-functional requirements.
- Break requirements into epics and candidate stories.
- Attach acceptance criteria and priorities.
- Provide architecture-ready handoff notes.
Script Selection
- Prioritization helper:
python3 scripts/prioritize.py - PRD quality check:
bash scripts/validate-prd.sh docs/bmad/prd.md
Template Map
-
templates/prd.template.md -
Why: complete requirements structure for medium/large scope.
-
templates/tech-spec.template.md -
Why: compact requirements for low-complexity scope.
Reference Map
-
REFERENCE.md -
Must read first for requirement quality rules, workflow guidance, and handoff practices.
-
resources/prioritization-frameworks.md -
Use when selecting MoSCoW, RICE, or alternative prioritization methods.
Quality Gates
- requirements are specific, testable, and unambiguous
- FR/NFR coverage is explicit
- acceptance criteria exist for planned stories
- priorities and trade-offs are justified
- next intent is explicit (
bmad:architectureorbmad:sprint-plan)
Source
git clone https://github.com/xmm/codex-bmad-skills/blob/main/skills/bmad-product-manager/SKILL.mdView on GitHub Overview
BMAD Product Manager helps convert discovery artifacts into concrete requirements for BMAD projects. It supports three artifacts (prd, tech-spec, prioritization) and leverages project constraints, business goals, and delivery timelines to produce actionable epics, stories, and handoff notes. It enforces language rules and references REFERENCE.md for quality and handoff discipline.
How This Skill Works
Inputs include discovery artifacts like product briefs and research, plus the bmad/project.yaml constraints and known business goals. It defines functional and non-functional requirements, breaks them into epics and candidate stories with acceptance criteria and priorities, and outputs architecture-ready handoff notes. The planning artifact is chosen by project level (0-1 starts with tech-spec; 2-4 starts with prd) and results are written to docs/bmad/prd.md, docs/bmad/tech-spec.md, or docs/bmad/prioritization.md.
When to Use It
- Starting a new BMAD initiative at levels 0-4 and needing a structured plan
- Drafting a tight scope tech-spec for low-complexity changes (level 0-1)
- Prioritizing backlog to relieve scope pressure and align with deadlines
- Transforming discovery artifacts into a documented roadmap with acceptance criteria
- Preparing architecture-ready handoff notes for engineering and delivery teams
Quick Start
- Step 1: Gather discovery artifacts (product-brief, research) and bmad/project.yaml constraints
- Step 2: Decide the starting artifact based on project level (0-1 → tech-spec; 2-4 → prd)
- Step 3: Break requirements into epics and candidate stories with acceptance criteria, output to docs/bmad/prd.md or docs/bmad/tech-spec.md or docs/bmad/prioritization.md
Best Practices
- Align requirements with the constraints in bmad/project.yaml and the known business goals
- Read REFERENCE.md before creating PRD/tech-spec or prioritization outputs
- Ensure explicit FR/NFR coverage and testable acceptance criteria for each story
- Justify priorities and trade-offs; clearly state the next intended artifact (bmad:architecture or bmad:sprint-plan)
- Use MoSCoW, RICE, or other prioritization methods from resources/prioritization-frameworks.md when ranking work
Example Use Cases
- Example: Level 3 initiative converts a discovery brief into a full PRD with epics, stories, and acceptance criteria for a multi-epic feature
- Example: Level 0-1 feature described via a tech-spec to outline tightly scoped changes and required specs
- Example: Prioritization pass to resolve backlog pressure for a 6-week sprint window
- Example: Architecture-ready handoff notes created for an API integration and data export enhancement
- Example: PRD quality check run with the included scripts to verify completeness and traceability