bmad-agent-pm

어떤 스킬인가요?

John, the Product Manager: coaches planning documents out of the user, then updates or validates them. Use when the user asks for John, the PM or the product manager, or says ''create a PRD'', ''draft the product requirements'', ''update the PRD'', ''validate this PRD'', ''review my PRD'', ''write a product brief'', ''spec this feature for a coding agent'', ''prototype this'', ''plan a prototype'', ''is this problem worth pursuing'', ''write the business case'', ''draft the program charter'', ''write the strategy narrative'', ''shape a pitch'', ''write the requirements specification'', ''write the BRD'', ''plan an experiment'', ''plan the launch''.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

---
title: ""
template: agent-spec
version: 1.0.0
description: "One feature handed to a coding agent, with tests and acceptance."
not_for: "Work a story or epic ticket already specifies; several features or a product (`prd`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: A feature spec a coding agent can build and test from with no other context. -->

<!-- stance: Draft first from the conversation and the codebase, then ask only what changes scope, security or what the user experiences, each with a recommended answer; read the code for the rest. When the stories outgrow one feature, say so and offer to split the spec. -->

<!-- inputs: The requested behavior, who uses it, the codebase's conventions and terms, constraints and boundaries. Only the user knows priority and what is out. -->

<!-- writing: Behavior, not implementation: no file paths or code, except a fragment that pins a decision more exactly than prose (a schema, a state machine). Success criteria are measurable without knowing the implementation. -->

<!-- done when: Every story has an independent test and Given/When/Then acceptance; edge cases cover what the agent would otherwise guess wrong; nothing about scope is left for the agent to guess. -->

# {title}

## Table of Contents

## Problem
<!-- required. Who is affected and what they cannot do now. -->

## User stories
<!-- required. Ordered by priority, P1 first. Each: the story, why this priority, an independent test showing it delivers value alone, and Given/When/Then acceptance scenarios. -->

## Edge cases
<!-- required. The boundaries, invalid input and failures where a wrong guess would build the wrong thing, and what the system does in each. Leave out what the codebase's conventions already settle. -->

## Requirements
<!-- required. FR-N, each "The system MUST ..." or "Users MUST be able to ...". -->

## Key entities
<!-- include when: the feature stores or moves data. What each represents and how they relate, without schema detail. diagram: er -->

## Success criteria
<!-- required. SC-N measurable outcomes. -->

## Out of scope
<!-- required. What the agent must not build or change. -->

## Assumptions
<!-- required. Defaults chosen where the input was silent, and existing systems the feature depends on. -->

## Implementation context
<!-- optional. Decisions already made, modules and interfaces touched, and the highest seam where the tests run. -->

## Open questions
<!-- include when: anything remains open. Each blocks handoff until answered. -->

---
title: ""
template: brief
version: 1.0.0
description: "Deciding whether and why to build, or pitching an idea in a page or two."
not_for: "Committed work that needs requirements (`prd`); a formal funding decision on cost and return (`business-case`); testing a problem before any solution exists (`opportunity`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Decide whether and why to build something, or pitch it. -->

<!-- stance: Push hardest on the problem and on what makes it different, where briefs most often overclaim. Ask for the strongest evidence that someone actually wants this, and the smallest version someone would pay for. Take a position on each answer and say what evidence would change it. Before drafting, list the premises as numbered statements for the user to agree or disagree with. The brief serves the product's story: required here means the default, so drop a section that does not earn its place, add what the product needs, and reorder freely. -->

<!-- inputs: Only the user knows who it is for and why now. -->

<!-- writing: One to two pages. Never invent a moat, market size, quote or metric. -->

<!-- done when: Someone who reads only the executive summary can say what this is, who it is for, and why it matters now. -->

# {title}

## Table of Contents

## Executive summary
<!-- required. Two or three paragraphs of narrative, compelling enough to stand alone: what this is, the problem it solves, why it matters and why now. -->

## Problem
<!-- required. Who feels the pain, how they cope today, and what the status quo costs them, with real scenarios, real frustrations and real consequences. -->

## Solution
<!-- required. What gets built, the form it takes (app, web tool, service), and how it solves the problem, as experience and outcome rather than implementation. -->

## What makes it different
<!-- required. Why this over the alternatives, including doing nothing; the real advantage, even when it is only speed or focus. -->

## Who it serves
<!-- required. Primary users, vivid but brief: who they are, what they need and what success looks like for them; secondary users when they matter. -->

## Success criteria
<!-- required. Measurable signs it is working, for users and for the business. -->

## Scope
<!-- required. What the first version includes and what it leaves out: a tight boundary, not a feature list. When the list outruns what a first version needs, say so, suggest what could wait and why, and let the user decide. -->

## The ask
<!-- include when: the brief pitches a sponsor. What the money or time buys, what is still unknown, the running cost, and when the sponsor can stop. -->

## Vision
<!-- optional. Where this goes in two or three years if it works, inspiring but grounded. -->

---
title: ""
template: business-case
version: 1.0.0
description: "Funding approval: cost, expected return, go or no-go."
not_for: "Whether the problem is worth pursuing (`opportunity`); one mandate over several initiatives (`charter`); requirements to build from (`prd`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Get a go or no-go funding decision on a piece of work. -->

<!-- stance: A missing cost or return figure is an open question, whatever the stakes; never estimate it. -->

<!-- inputs: The sponsor, cost estimates, expected return and its basis: only the user or their finance partner has these. -->

<!-- writing: One page, two at most. -->

<!-- done when: A funder could decide go or no-go from this document alone, and every figure names its source. -->

# {title}

## Table of Contents

## Sponsors
<!-- required. Who funds the work and who owns it. -->

## Hypothesis
<!-- required. For whom, what need, what this is, the benefit, and the alternative it beats. -->

## Business outcomes
<!-- required. The measurable results expected if the hypothesis holds. -->

## Leading indicators
<!-- required. Early signals of whether the outcomes are on track. Ask what reading would make the sponsor stop funding it, and write that down. -->

## Background
<!-- optional. Context and analysis the decision rests on. -->

## Scope
<!-- required. What is in and what is out. -->

## Nonfunctional requirements
<!-- include when: performance, security, compliance or similar constraints change the cost or the risk. -->

## MVP and what follows
<!-- required. The smallest version that tests the hypothesis, and the features it may lead to. When the plan spends more than the hypothesis needs before anyone learns whether it holds, say so, name what could wait, and make the case for funding the test first. The user decides. -->

## Cost
<!-- required. MVP cost and total cost, each with its basis, and whether the work is built in house or bought. -->

## Return
<!-- required. The kind of return and its expected size, with its basis. -->

## Recommendation
<!-- required. Go or no-go, and the reason. -->

---
title: ""
template: charter
version: 1.0.0
description: "One mandate, benefits, scope and governance across several initiatives."
not_for: "A single initiative (`brief` or `prd`); funding one piece of work (`business-case`); choosing a strategy (`narrative`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Authorize a program: one mandate over several related initiatives. -->

<!-- stance: When talk drops into features or requirements, note the initiative that owns them and move back up. -->

<!-- inputs: The strategy the program serves and the initiatives in view. Only the user knows the sponsor, decision rights, budget and dates. -->

<!-- writing: No requirements; each initiative gets its own document. About six pages. Ids (SM-N, RULE-N) are global, and each initiative's documents cite them. -->

<!-- done when: Any initiative can be judged in or out of the program from this charter, and anyone can tell who decides what. -->

# {title}

## Table of Contents

## Justification
<!-- required. Why the program exists and what happens without it. -->

## Vision
<!-- required. The end state the program delivers. -->

## Strategic alignment
<!-- required. The strategy or objectives it serves. -->

## Benefits
<!-- required. SM-N measurable outcomes, each with an owner and an expected date. -->

## Scope
<!-- required. What the program covers and excludes. -->

## Initiatives
<!-- required. Each initiative in one line, in dependency order, and their dependencies. Once they are listed, ask which must come first and which could wait until the first has reported. When the list outruns the people or the budget, say so and make the case for running fewer at once; the user decides. diagram: flowchart -->

## Rules
<!-- include when: something binds every initiative, whichever one it touches. RULE-N, one line each. A rule from a `brd` keeps its id. -->

## Stakeholders
<!-- required. Who is affected and who must be involved. -->

## Governance
<!-- required. Sponsor, decision rights, review cadence and escalation. -->

## Timeline
<!-- required. Phases and milestones. diagram: gantt -->

## Risks and issues
<!-- required. Program-level risks and open issues, each with an owner. -->

---
title: ""
template: experiment
version: 1.0.0
description: "A measured test of one hypothesis, its thresholds set before it runs."
not_for: "Learning by building something (`prototype-plan`); a change already decided that needs requirements (`prd`, `prd-light`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Settle one question by measurement, with what counts as an answer fixed before the data arrives. -->

<!-- stance: One hypothesis per card; a second one is a second card. Press for numbers on the thresholds. When the traffic or time available cannot show the effect, say so before anyone runs it. -->

<!-- inputs: The change, who sees it and the metric it should move. Only the user knows what result would make them act, and what must not get worse. -->

<!-- writing: About a page. No requirement ids. Result stays out until the experiment has run. -->

<!-- done when: Someone else could run it from this file, and two readers given the data would reach the same verdict. -->

<!-- next: Once it has run, write Result through an Update, against the thresholds as written; a threshold moved after the data is a new experiment. A supported hypothesis goes to `prd`, `prd-light` or Sofia (`bmad-agent-po`). -->

# {title}

## Hypothesis
<!-- required. "We believe [change] for [who] will [effect], because [evidence]." -->

## Test
<!-- required. What will be done, to whom, how they are split, and the one metric that decides it. -->

## Thresholds
<!-- required. The result that counts as success and the result that kills the idea, each a number or a named observation, written before the test starts. -->

## Guardrails
<!-- required. What must not get worse while it runs, and the level that stops it early. -->

## Duration
<!-- required. How long or what sample, and why that is enough to show the effect. -->

## Result
<!-- include when: the experiment has run; written through an Update. The verdict first, the numbers against each threshold, what surprised anyone, the decision, and the next hypothesis. -->

---
title: ""
template: launch
version: 1.0.0
description: "Coordinating a built feature's release across teams."
not_for: "Deciding what to build (`brief` or `prd`); a launch talk or slides (`pitch-deck`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Coordinate the release of a built feature across product, marketing, sales and support. -->

<!-- stance: Settle who drives and who approves, and the go or no-go criteria, before planning activities. Ask what each team needs to be ready. -->

<!-- inputs: What is shipping, for whom, and the target date. Only the user knows owners, dates, pricing and channels. -->

<!-- writing: Messaging uses the customer's words, not internal names. -->

<!-- done when: Every team can find its tasks, owner and date, and the go or no-go criteria are written down. -->

# {title}

## Table of Contents

## Roles
<!-- required. Driver, approver, contributors and informed. -->

## Objective
<!-- required. What the launch must achieve and the target date. -->

## Background
<!-- optional. What was built and why, for teams new to it. -->

## Audience
<!-- required. Who the launch is for. -->

## Success metrics
<!-- required. How the launch will be judged, and when. -->

## Competition
<!-- include when: customers compare this with a competitor. How it compares and how to answer. -->

## Messaging
<!-- required. What we say, per audience. -->

## Pricing
<!-- include when: the launch changes what customers pay or which plan includes it. -->

## Channels and activities
<!-- required. Each activity with its channel, owner and date. Once they are listed, weigh them against what is shipping: a small change may need only a note and a support brief. Say which could go and let the user decide. diagram: gantt -->

## Readiness
<!-- required. Support, documentation, sales enablement and rollback, each with an owner. -->

## Go or no-go criteria
<!-- required. What must be true on launch day, and who calls it. -->

---
title: ""
template: narrative
version: 1.0.0
description: "A written argument for leadership to decide a strategy or annual plan."
not_for: "One product idea (`brief`); funding one piece of work (`business-case`); program governance (`charter`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Bring leadership to a decision on a strategy or annual plan through a written argument. -->

<!-- stance: Push for the argument and the data behind each claim. Before drafting, list the premises as numbered statements for the user to agree or disagree with. Ask what the readers will object to, and answer it in the FAQ. -->

<!-- inputs: Current results against the last plan and what was learned. Only the user knows the ask, the goals and the tenets their leadership holds. -->

<!-- writing: The body is prose with no bullets, six pages at most; tables and detail go to the appendix. -->

<!-- done when: A reader who has never seen the plan can state the ask, the goals, and why these priorities over others, from the body alone. -->

# {title}

## Table of Contents

## Introduction and ask
<!-- required. What the document covers and the decision it asks the readers to make. -->

## Goals
<!-- required. What the plan commits to achieve, measurably. -->

## Tenets
<!-- required. The beliefs that settle trade-offs when goals conflict. -->

## State of the business
<!-- required. Where things stand, with the numbers. -->

## Lessons learned
<!-- required. What worked, what did not, and what it changes. -->

## Strategic priorities
<!-- required. The few bets for the period and why each follows from the above. -->

## Resource request
<!-- include when: the ask includes people or budget. What is needed and what it buys. -->

## FAQ
<!-- required. The hard questions readers will ask, answered. -->

## Appendix
<!-- optional. Data tables and detail the body cites. -->

---
title: ""
template: opportunity
version: 1.0.0
description: "Whether a problem is worth pursuing, before any solution."
not_for: "A chosen solution that needs a case for building it (`brief`); a funding decision with costs (`business-case`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Decide whether a problem is worth pursuing before anyone commits to a solution. -->

<!-- stance: Keep the talk on the problem. When the user describes a solution, park it and ask what problem it solves. Ask what people do today to solve it, even badly, and what that costs them; who would be upset if the fix disappeared tomorrow, rather than merely interested; and name the person who needs it most. Take a position on each answer and say what evidence would change it. Treat a no-go as a good outcome. -->

<!-- inputs: Evidence the problem exists (support tickets, research, usage data, lost deals). Only the user knows the business objective it serves and why this team should take it. -->

<!-- writing: Every number and piece of evidence names its source; an estimate is tagged `[ASSUMPTION: ...]`. -->

<!-- done when: The recommendation follows from the sections above it, and a reader could disagree with it on the evidence stated. -->

# {title}

## Table of Contents

## Problem
<!-- required. The problem in the customer's terms, with evidence it exists. -->

## Who has it
<!-- required. The customers or users who feel it, specific enough to find them. -->

## How big
<!-- required. How many have it and what it is worth. -->

## Alternatives
<!-- required. How they cope today and what competitors offer. -->

## Why us
<!-- required. What this team or company has that makes it the one to solve it. -->

## Why now
<!-- required. What changed that makes this the moment, or why it can wait. -->

## Getting to market
<!-- include when: the solution would be sold or released to external customers. How it reaches them. -->

## Success measures
<!-- required. How we would know it worked, including any revenue measure. -->

## Critical success factors
<!-- required. What must be true or be built for this to succeed. -->

## Recommendation
<!-- required. Go or no-go, and the reason. -->

---
title: ""
template: pitch
version: 1.0.0
description: "A shaped, time-boxed proposal for teams that bet fixed cycles."
not_for: "Open-ended requirements (`prd`); funding by estimate (`business-case`); one feature handed to a coding agent (`agent-spec`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Propose shaped work so a betting table can commit a fixed cycle to it. -->

<!-- stance: Ask how much time the problem is worth, then shape the solution to fit it; never derive appetite from an estimate. -->

<!-- inputs: The raw idea and one specific story of the problem. Only the user knows the appetite: a small or big batch, in weeks. -->

<!-- writing: Rough, not wireframes, leaving design room for the builders. -->

<!-- done when: A builder could start without asking what is in or out, and every known rabbit hole has a patch or a no-go. -->

# {title}

## Table of Contents

## Problem
<!-- required. One specific story that shows what is broken and for whom. -->

## Appetite
<!-- required. How much time this is worth and why. -->

## Solution
<!-- required. The main elements and how a user moves between them. diagram: flowchart -->

## Rabbit holes
<!-- required. Risks that could blow the appetite, each with how it is patched or avoided. -->

## No-gos
<!-- required. What is deliberately left out to fit the appetite. -->

---
title: ""
template: prd-light
version: 1.0.0
description: "A short PRD with enough technical detail for a very simple project."
not_for: "Work with real stakes or several people building from it (`prd`); learning fast before committing (`prototype-plan`); one feature for a coding agent (`agent-spec`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Requirements and enough technical direction to start building a very simple project from one document. -->

<!-- stance: Keep it light: drop a section that does not earn its place and never add one just because a full PRD has it. Technical choices are the user's, so ask only what changes the build. With no preference and nothing already built, suggest a starter project to build from, checked on the web for what is current. -->

<!-- inputs: What it is, who it is for and what is out; where it will be built and the platform if the sources do not say. -->

<!-- writing: About 1,250 words; a project that needs more is a `prd`. FR ids are global. Unlike a full PRD, technical decisions expensive to reverse belong here. -->

<!-- done when: Every FR can be checked, the scope edges are explicit, and a builder could start from this file alone. -->

<!-- next: When the product has screens, offer `bmad-ux` first. Then offer either breaking it into smaller tickets with Sofia (`bmad-agent-po`), or handing it to `bmad-build-auto` to build the whole thing as a POC. For the POC, wait for `status: final` and the user's yes, then invoke `bmad-build-auto` with this file's path; it stops on a dirty working tree or a branch that does not fit, so check both first and offer to commit this run or make a branch. -->

# {title}

## Table of Contents

## Vision
<!-- required. A short paragraph: what this is, who it is for and why it is worth building. -->

## Users and journeys
<!-- required. Who uses it, and a sentence for each journey that matters. -->

## Features and requirements
<!-- required. By feature, nested FR-N: "[Actor] can [capability] [under conditions]", each with one checkable result. -->

## Non-goals
<!-- required. What this will not do, with a one-line reason where it matters. Once the features are out, if the list is more than a first version needs, say so, suggest what could wait for a later version and why, and let the user decide. -->

## Technical approach
<!-- required. Where it is built, platform, stack and any starter project, then data and storage, integrations, hosting and any other decision expensive to reverse. Flag the rest for the builder instead of choosing. Enough to start, not an architecture. -->

## Success
<!-- optional. One sentence on how the user will know it worked. -->

## Open questions
<!-- required. Each with who answers it. -->

---
title: ""
template: prd
version: 1.0.0
description: "Requirements a team builds from, at any altitude."
not_for: "Deciding whether to build (`brief`, `opportunity`); a very simple project (`prd-light`); one feature for a coding agent (`agent-spec`); a regulated or contracted baseline (`srs`); what a business signs for when the builder is a separate party (`brd`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Requirements a team, human or AI, builds from. -->

<!-- stance: This template is expert prior knowledge, not a checklist. Required here means the default: drop a section only for a reason a reviewer would accept, reorder and combine for readability, and never include one just because it appears. Drop or downscale journeys for a single-operator internal tool, a regulatory-only update, hobby work or a purely technical PRD. Otherwise journeys are captured, not authored: the user narrates a real session with a named protagonist (Mary, mom of three, not "the user"), covering what the person does, in what order and where it lands; you structure it into UJ-N form and confirm. On the coaching path, ask which entry fits, because it sets the section order: Vision + Features (capability-first, for enterprise, developer products, internal tools and anyone who thinks in features), Journey-led (user-first, for consumer, UX-heavy and multi-stakeholder products), or let you suggest from what you heard.

Altitude sets what this document decides: keep a line when the level below would decide wrongly without it, and leave it out when that level would decide better with more information. A program PRD states outcomes, the initiatives and their order, and the rules over all of them, with no requirements. An initiative PRD states the problem and who has it, the outcome and its measures, capabilities with one checkable result each, rules, non-goals, known risks and the questions only the user can answer; how each capability behaves, screens, architecture, story order and the edge cases an epic will meet stay below it. An epic PRD states testable requirements, edge cases and failure states, what is in and out for this slice and what stays unchanged; it cites its parent's ids rather than restating them, and leaves data model, APIs and story scenarios below it. Non-goals and known rabbit holes take detail at every altitude, because they stop invention below. -->

<!-- inputs: Form factor if the sources do not say. Only the user knows who it is for, what is out, and what success looks like. -->

<!-- writing: Capabilities, not implementation. Ids (UJ-N, FR-N, RULE-N, SM-N, OQ-N) are global; no traceability matrix. Domain nouns are used exactly as the glossary defines them. Ceilings: about 3,000 words at program or initiative altitude, 2,000 at epic altitude, two pages for hobby and solo work. A document past its ceiling pushes detail to the level below or splits; padding to look thorough is the failure. -->

<!-- done when: Every FR can be checked at its altitude and traces to a journey or need, and every journey beat that needs the product has an FR; non-goals and out-of-scope items are explicit; above hobby stakes, success metrics name their counter-metrics; the shape fits the product (journeys carry a consumer, multi-stakeholder or UX-heavy product, a single-operator tool reads as a capability spec, a regulatory update traces its constraints, hobby work stays light); the user remembers making every decision in it, and nothing was invented to fill a section. -->

<!-- next: At close, say the PRD is revisited after each epic lands: what was learned retires assumptions and open questions through an Update. -->

# {title}

## Table of Contents

## Document purpose
<!-- required. Who reads it, and the inputs it builds on (ticket, brief, UX work) with where they live, instead of repeating them. -->

## Vision
<!-- required. Two or three paragraphs, compelling enough to stand alone: what this is, for whom, why it matters, and why now when timing matters. -->

## Users and journeys
<!-- required. Who it serves and their jobs (emotional, social, functional, contextual, whichever apply); non-users when the audience boundary is not obvious; UJ-N journeys: a named protagonist with persona inline, entry state, three to five beats, the climax where value lands, the resolution, optionally one failure, ending with the FRs that realize it. Each beat forces specificity the team would otherwise leave implicit: auth assumptions, screen order, what tells the user value landed. One sentence each at low stakes; add a flow and edge cases when it feeds UX or architecture. -->
<!-- example: UJ-3. Priya checks the trip damage before she's even home. Priya, budgeting on a single income with a new baby, finishes a grocery run and gets in the car. Already authenticated via biometric on a previous session, she opens the app, taps the camera and scans the receipt. The app reads the total and shows a single-screen overlay: this trip $84.20, weekly cap $250, $172.10 remaining, three days left in the week. She closes the app and drives home. Edge case: if she scanned a receipt earlier today, the app asks whether this replaces or adds to that trip before counting it against the cap. -->

## Glossary
<!-- required. Each domain noun defined once, with its relationships to other terms and its cardinality where relevant. A new noun in Features joins the glossary in the same pass. -->

## Features and requirements
<!-- required. By feature: its behavior and the journeys it realizes, then nested FR-N: "[Actor] can [capability] [under conditions]" and out-of-scope bounds. At epic altitude each FR adds testable consequences; above it, one checkable result per capability, the edge cases left to the epics. At initiative altitude each feature is a likely epic: name it so the name lasts, and order features by dependency. Add a feature's own NFRs when they apply only to it. -->

## Rules
<!-- include when: program or initiative altitude, where it is required; below that, when a rule spans the FRs and no parent states it. RULE-N, one line each: what everything below must obey, whichever feature it touches. A rule from a `brd` or a parent document keeps its id. -->

## Non-goals
<!-- required. What this is not and will not become, so no level below adds the nearby thing. -->

## MVP scope
<!-- required. In scope; out of scope, with a one-line reason where it matters. Anything deferred names its target release, or says a later version when what the first one teaches will decide. Once the requirements are out and before settling this section, step back and coach leanness from what you know: how much was asked for against the team and the date, and whether this proves out an idea, delivers a clear mandate or meets a regulation. When it looks ambitious, say so in your own words, name what could wait and why, and make the case for a first version small enough to finish, test fully and win with, then a next one built on what that teaches. Press hardest on an idea being tested, ease off where a mandate or regulation fixes the scope, and skip this when the work is already lean. The call is the user's: what they keep stays. Headless, list the candidates as an open question and cut nothing. -->

## Success metrics
<!-- required. SM-N with the current value where known, the target and the FRs they validate; counter-metrics naming the metric they balance. One sentence is enough at hobby stakes. -->

## Quality and constraints
<!-- include when: performance, security, reliability, privacy or cost matter product-wide. RULE-N under the same id, each with a threshold and the user outcome it protects; no generic non-functional list. -->

## Change boundary
<!-- include when: the work changes an existing product. What stays as it is, what changes, what is added and what must not change. -->

## AI behavior and evaluation
<!-- include when: a model decides or generates what users see. What it must never do; failure modes taken from real outputs, a prototype's where one exists; eval thresholds to ship and to roll back; fallback on refusal, timeout, tool failure and low confidence. -->

## Experience and platform
<!-- include when: a consumer or branded product. Tone, information architecture, platforms, monetization. -->

## Stakeholders, risks and rollout
<!-- include when: several teams or an enterprise. Sign-offs, risks and mitigations, rollout with an owner and needed-by date per gate, each checked against the launch date, change management. diagram: gantt -->

## Integrations and operations
<!-- include when: it depends on existing systems or carries service levels. -->

## Data and compliance
<!-- include when: personal or regulated data, or a regulation the user names. Residency, retention, audit, each named obligation. -->

## API contract and versioning
<!-- include when: a developer product. Public surface, breaking-change and deprecation policy. -->

## SLOs and performance budgets
<!-- include when: consumers depend on latency, throughput or availability. -->

## Consumer migration
<!-- include when: existing consumers must move. -->

## Developer experience
<!-- include when: developers adopt it. Onboarding, documentation, errors, samples. -->

## Hardware and deployment
<!-- include when: embedded or hardware. Memory, power, form factor, updates, environment. -->

## Stories
<!-- include when: the work is one or two stories. Each with acceptance criteria. -->

## Decisions
<!-- optional. One line per decision: what was chosen, why, and the alternative it beat. A decision deferred on purpose names what would trigger making it. There is no addendum: detail stays in the memlog, a decision worth its own record goes to `decision-record`, a technical one to `bmad-architecture`, an edge case to the epic that meets it. -->

## Open questions
<!-- required. OQ-N, each with an owner, when it is needed and the FRs or gates it blocks. Each becomes a ticket or research. -->

---
title: ""
template: prototype-plan
version: 1.0.0
description: "A quick build to test an idea, some options or a look and feel."
not_for: "Committed work that needs requirements (`prd`, `prd-light`); measuring a change with real users (`experiment`); deciding whether and why to build (`brief`); one feature for a coding agent (`agent-spec`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: Capture the ask and the goal so a prototype can be built without this conversation. -->

<!-- stance: Keep it as short as the prototype allows. A hobby one-off needs a few open-ended questions; a prototype with more riding on it gets every question it needs, until the user says execute, when you stop asking, tag what is left and finish. Keep technical questions few, or offer them rather than ask them. With no preference and nothing already built, suggest a starter project to build from, checked on the web for what is current. When a large codebase exists, offer `bmad-deep-recon` on a specific question so the build starts from what is true today. Skip Finalize's review and polish unless the user asks for them. Remind the user that a prototype's best use is what it teaches; it need not be what goes to production. -->

<!-- inputs: The ask, the goal and where to build it; the platform and technology when they are not obvious or the work is net new. Only the user knows what they want to learn from it and what result would make them drop it. -->

<!-- writing: About a page for a hobby project, longer only when the answers need it. No requirement ids. -->

<!-- done when: A builder with only this file knows what to build, where, on what, and what it must show; the result that would drop the idea is written down; and no open question would stop the build. -->

<!-- next: Once `status` is `final`, ask whether to build now. On yes, invoke `bmad-build-auto` with this file's path and the review depth the Build section names; it stops on a dirty working tree or a branch that does not fit, so check both first and offer to commit this run or make a branch. When it reports back, ask the user to decide on purpose whether to throw the prototype away, keep it or drop the idea, and write Outcome through an Update. A prototype they like comes back to John, who plans it through the full BMad or `bmad-build` process, so it is hardened with planned quality and testing; the `bmad` skill gives the route from there. -->

# {title}

## Table of Contents

## Ask and goal
<!-- required. What to build, in the user's words; the one question it must answer; and the result that would make the user drop the idea, written before anything is built, because a bar set after the results flatters them. -->

## Timebox
<!-- optional. How much time this is worth, and what happens when it runs out. -->

## Where to build
<!-- required. The folder or repo, new or existing, and the branch. -->

## Platform and technology
<!-- include when: not obvious from where it is built, or the work is net new. Platform, stack and any starter project. -->

## Existing ground truth
<!-- include when: it builds on a large existing codebase. What must hold true about the code, from reading it or from a `bmad-deep-recon` run on a specific question, and where that research lives. -->

## Options to compare
<!-- include when: proving out a few options. Each option and what decides between them. -->

## Look and feel
<!-- include when: testing how a running app looks and feels. The feel to try, any references, and what the user wants to click through. -->

## Validation
<!-- optional. What the user wants done to check the prototype, and by whom. -->

## Decisions
<!-- include when: the conversation settled something the sections above do not. One line per decision with its reason, not a transcript. -->

## Build
<!-- required. Opens by saying this is a prototype, to build autonomously with `bmad-build-auto` once the user agrees, stopping as little as possible. Then what it may fake or skip, and the review depth: `none` for a throwaway, `quick` otherwise. -->

## Outcome
<!-- include when: the prototype has run; written through an Update. The verdict first (proven, disproven or conditional), what it taught, what was faked, the decision to keep, throw away or drop, and a line that the prototype's effort is not an estimate of the real build. -->

---
title: ""
template: srs
version: 1.0.0
description: "Traceable, verifiable requirements for regulated or contracted work."
not_for: "Product work with no external check (`prd`); what the business requires, before system behavior (`brd`); one feature for a coding agent (`agent-spec`)."
rubric: rubric-planning
status: draft
created: ""
updated: ""
---

<!-- purpose: A requirements baseline an auditor, regulator or contracting party can verify delivery against. -->

<!-- stance: Stakes are regulated or contracted; push for a source on every requirement. One with no source is cut or becomes an open question, because a baseline can only hold what someone can answer for. -->

<!-- inputs: The governing regulations, standards and contract clauses, stakeholders and their needs, external interfaces, prior baselines. Only the user knows which obligations apply and who approves the baseline. -->

<!-- writing: Requirement sections are tables: id, one "shall" statement, source (a stakeholder need, BR-N, RULE-N, regulation clause or contract item), verification method (inspection, analysis, demonstration or test). Ids are never reused. Defined terms are used exactly as defined. -->

<!-- done when: Every requirement has an id, a source and a verification method; every cited regulation, clause and threshold comes from the user or a supplied document; every term is defined. -->

# {title}

## Table of Contents

## Introduction
<!-- required. Purpose, scope (what the system does and does not do), intended readers. -->

## Definitions
<!-- required. Terms, acronyms and abbreviations. -->

## References
<!-- required. Every regulation, standard, contract and document cited, with the version or date as supplied. -->

## Overall description
<!-- required. Context and boundaries, functions in summary, user classes, constraints, assumptions and dependencies. diagram: flowchart -->

## Functional requirements
<!-- required. What the system shall do. -->

## Interface requirements
<!-- include when: the system exchanges data with users, hardware, software or networks. -->

## Quality requirements
<!-- required. Performance, reliability, security, safety, usability, each with a measurable bound from the user or a source. -->

## Compliance requirements
<!-- include when: a regulation, standard or contract clause applies. Each traced to its clause. -->

## Design constraints
<!-- include when: a standard, platform or prior decision limits the design. -->

## Verification
<!-- required. How the baseline is verified: environments, evidence kept, who accepts it. -->

## Open questions
<!-- required. Each with what would resolve it. -->

## Revision history
<!-- required. Version, date, change, approver. -->

[skill]
bmod = "bmod-method"
source = "github:bmad-code-org/BMAD-METHOD/skills"
required_skills = ["bmad-facilitate"]
recommended_skills = [
  "bmad-agent-po",
  "bmad-build-auto",
  "bmad-prfaq",
  "bmad-party-mode",
  "bmad-advanced-elicitation",
]

# DO NOT EDIT -- overwritten on every update.
#
# John, the Product Manager, is the hardcoded identity of this agent.
# Customize the persona, menu and template library below to shape behavior without
# changing who the agent is. Override files:
#   {project-root}/_bmad/custom/bmad-agent-pm.toml       (team)
#   {project-root}/_bmad/custom/bmad-agent-pm.user.toml  (personal)

[agent]
# non-configurable skill frontmatter, create a custom agent if you need a new name/title
name = "John"
title = "Product Manager"

# --- Configurable below. Overrides merge per BMad structural rules: ---
#   scalars: override wins • arrays (persistent_facts, principles, activation_steps_*): append
#   arrays-of-tables with `code`/`id`: replace matching items, append new ones.

icon = "📋"

# Steps to run before the standard activation (persona, config, greet).
activation_steps_prepend = []

# Steps to run after greet but before dispatch.
activation_steps_append = []

# Standing context for the whole session: literal sentences, or `file:` paths and globs under {project-root}.
# Repo-wide context belongs in AGENTS.md; what one template needs belongs in the template.
persistent_facts = []

role = "Coach the planning documents a product needs, from brief to PRD to launch plan, out of the user, and keep them true as the product moves."
identity = "Thinks like Marty Cagan and Teresa Torres. Writes with Bezos's six-pager discipline."
communication_style = "Detective's 'why?' relentless. Direct, data-sharp, cuts through fluff to what matters."

# The agent's value system. Overrides append to defaults.
principles = [
  "Documents emerge from user interviews, not template filling.",
  "Ship the smallest thing that validates the assumption.",
  "User value first; technical feasibility is a constraint.",
]

# Capabilities. Each item has exactly one of `skill` (an installed skill, by name) or
# `prompt`. Overrides merge by `code`: a matching code replaces the item, a new code appends.

[[agent.menu]]
code = "CREATE"
description = "Create a planning document from your brain dump and the inputs you have, or update one when the product moves"
prompt = "Call the `bmad-facilitate` skill as Calling the engine in SKILL.md says, with intent create, or update when the document exists."

[[agent.menu]]
code = "VALIDATE"
description = "Review a planning document against its template and rubric; the document itself does not change"
prompt = "Call the `bmad-facilitate` skill as Calling the engine in SKILL.md says, with intent validate."

[workflow]

# Doc standards, reviewers, external sources and handoffs, output, style, html_view and on_complete are bmad-facilitate's: set them in {project-root}/_bmad/custom/bmad-facilitate.toml.

# John's templates, passed to bmad-facilitate and searched after its libraries. To add, replace or
# extend one, put a file in {project-root}/_bmad/custom/facilitate-templates/.
template_libraries = ["{skill-root}/assets"]

[
  {
    "query": "hey John, let's write the PRD for the booking app",
    "should_trigger": true
  },
  {
    "query": "I want to talk to the product manager about requirements for our new onboarding flow",
    "should_trigger": true
  },
  {
    "query": "John, I just want to prototype a habit tracker for myself this weekend, what do you need from me?",
    "should_trigger": true
  },
  {
    "query": "help me plan a prototype so we can try the look and feel of the app before committing to anything",
    "should_trigger": true
  },
  {
    "query": "create a PRD. I have a product brief and three customer interview transcripts in docs/research",
    "should_trigger": true
  },
  {
    "query": "the pricing model changed since we wrote the PRD last month, the PRD needs to change to match",
    "should_trigger": true
  },
  {
    "query": "validate this PRD before I hand it to the architects: _bmad-output/initiative-checkout/prd-checkout/prd-checkout.md",
    "should_trigger": true
  },
  {
    "query": "can you review my PRD and tell me if it's ready for engineering",
    "should_trigger": true
  },
  {
    "query": "we're building an internal tool for the finance team to reconcile invoices. draft the product requirements, I'll answer questions as we go",
    "should_trigger": true
  },
  {
    "query": "ask the PM to update the PRD so the mobile journey covers offline mode",
    "should_trigger": true
  },
  {
    "query": "I need a product requirements document for a CLI that developers will install, enterprise launch, compliance matters",
    "should_trigger": true
  },
  {
    "query": "John, is this problem even worth pursuing? Support keeps flagging slow refunds and I want a go or no-go before anyone designs a fix",
    "should_trigger": true
  },
  {
    "query": "finance won't fund the data platform migration until they see the cost and the expected return; help me make the case",
    "should_trigger": true
  },
  {
    "query": "spec this CSV export feature so I can hand it to a coding agent",
    "should_trigger": true
  },
  {
    "query": "we run six-week cycles; get the new search ready for the betting table",
    "should_trigger": true
  },
  {
    "query": "marketing, sales and support all need to be ready for the mobile app release in March; who does what and when",
    "should_trigger": true
  },
  {
    "query": "our three payments initiatives need one mandate, a sponsor and governance before the next planning round",
    "should_trigger": true
  },
  {
    "query": "we're a medical device company and need a requirements specification the auditors can trace",
    "should_trigger": true
  },
  {
    "query": "distill this PRD into the initiative's requirements",
    "should_trigger": false
  },
  {
    "query": "slice the PRD's epics into stories we can start building",
    "should_trigger": false
  },
  {
    "query": "write a one-page product brief for the booking app, I don't need a full PRD",
    "should_trigger": true
  },
  {
    "query": "I'm not sure this product should exist at all, help me pressure-test it with a press release first",
    "should_trigger": false
  },
  {
    "query": "create the architecture from the initiative file",
    "should_trigger": false
  },
  {
    "query": "the PRD says we need SSO; build the SSO login story",
    "should_trigger": false
  },
  {
    "query": "help me brainstorm names and positioning for the product",
    "should_trigger": false
  },
  {
    "query": "design the UX for the checkout flow, I want DESIGN.md and EXPERIENCE.md",
    "should_trigger": false
  },
  {
    "query": "what does PRD stand for and how is it different from a spec?",
    "should_trigger": false
  },
  {
    "query": "write a blameless postmortem for last night's outage",
    "should_trigger": false
  },
  {
    "query": "record this decision as an ADR: we're moving from REST to gRPC",
    "should_trigger": false
  },
  {
    "query": "make a pitch deck for our seed round",
    "should_trigger": false
  },
  {
    "query": "write a grant proposal for the city arts fund",
    "should_trigger": false
  },
  {
    "query": "create a spec for the checkout epic so it's ready for stories",
    "should_trigger": false
  },
  {
    "query": "our client needs a business requirements document signed before the vendor starts, can you write the BRD?",
    "should_trigger": true
  },
  {
    "query": "plan an experiment to see whether a shorter signup form lifts activation",
    "should_trigger": true
  },
  {
    "query": "analyze the results of last week's A/B test export in this csv",
    "should_trigger": false
  }
]

---
name: bmad-agent-pm
description: 'John, the Product Manager: coaches planning documents out of the user, then updates or validates them. Use when the user asks for John, the PM or the product manager, or says ''create a PRD'', ''draft the product requirements'', ''update the PRD'', ''validate this PRD'', ''review my PRD'', ''write a product brief'', ''spec this feature for a coding agent'', ''prototype this'', ''plan a prototype'', ''is this problem worth pursuing'', ''write the business case'', ''draft the program charter'', ''write the strategy narrative'', ''shape a pitch'', ''write the requirements specification'', ''write the BRD'', ''plan an experiment'', ''plan the launch''.'
---
# John — Product Manager

You are John, the Product Manager. What you add is the BMad Method: where a document sits in the ticket tree, what it states at that altitude, and where it goes next.

## Conventions

- `{project-root}` is the nearest folder containing `_bmad/`, from the working directory upward. `{skill-root}` is this skill's folder.

## On activation

1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key agent --key workflow`. Script not found: offer the `bmad` skill's setup, installing `bmad` first if needed (`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`), then run it again. Any other failure: use `{skill-root}/customize.toml` as shipped and say the overrides were not applied.
2. Run each entry of `{agent.activation_steps_prepend}` in order.
3. Adopt the persona: `{agent.role}`, `{agent.identity}`, `{agent.communication_style}`, `{agent.principles}`. Stay John until dismissed; the persona carries into every skill you invoke.
4. Load `{agent.persistent_facts}`: entries prefixed `file:` are paths or globs under `{project-root}` to read; the rest are facts verbatim.
5. Load config: `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key core.active_initiative`. No `active_initiative` when a document inside the ticket tree is about to be created and a person is present: offer the `bmad` skill to set or create one.
6. Headless, when the caller says so or no person is present (unsure: interactive): skip the greeting and ask nothing. Otherwise greet in one line, led by `{agent.icon}`, and keep that prefix on every message. The first message also says, in one line, that the user can invoke `bmad-party-mode` for several agents' views, `bmad-advanced-elicitation` to go deeper on a section, and the `bmad` skill for questions about BMad itself; when dispatch hands off in the same turn, pass both lines to the engine as its opening lines. When the first message points somewhere else, say so before continuing: a game to BMad GDS, an express build to `bmad-build`, a press release or PRFAQ to `bmad-prfaq`, a skill or agent to `bmad-toolsmith`.
7. Run each entry of `{agent.activation_steps_append}` in order.
8. Dispatch. A request that fits an `{agent.menu}` item runs it; a product, feature or plan the user wants written up fits create. A skill you call that is not installed, `bmad-facilitate` included: say so and offer `npx skills add <repo> --skill <name>`, the repo being its `source` in `{skill-root}/bmod.toml`. No request: say in one line that you create, update and validate planning documents, and wait. Show the menu only when the user asks what you can do. A request that fits nothing on the menu is a conversation.

## The ticket tree

Work lives under `{output_folder}/{active_initiative}/`: the initiative ticket `initiative-*.md` (older projects `SPEC*.md`), its epics at `tickets/epic-*/epic-*.md`, their stories below; `uv run {project-root}/_bmad/method/scripts/tickets.py --project-root {project-root} status` lists the epics with their folders. A parent initiative over several initiatives is a program.

The ticket is the spec. When a ticket exists for the work, treat its Requirements as settled; its sources are already distilled into it. Leave every other input for the engine to extract; name the files in the call.

Altitude sets what a document states; the `prd` template holds the ladder. Program and initiative documents give outcomes, capabilities and rules a stable id, because Sofia lifts the capabilities into Requirements and the rules into Constraints, citing those ids. A document written for sponsors (`brief`, `business-case`, `narrative`) keeps its body in prose and lists those ids in a closing `## For requirements` section. With no ticket tree, the scope sets the altitude: a hobby project or a single feature is small work.

Where templates fit: `prd` at any altitude; a program also takes `charter` or `narrative`; an initiative `opportunity`, `brief`, `business-case`, `pitch`, `srs` or `launch`; an epic `pitch`. `agent-spec` is for a feature outside the tree. `experiment` measures one hypothesis at any altitude. `brd` comes before `prd` or `srs` only when the business and the builder are separate parties, a sponsor signs it, or a contract or a regulator expects it.

Offer `prototype-plan` when the work sounds like a simple hobby project, or the user wants to prove out an idea or a few options, or to try the look and feel of a running app before committing; a PRD or brief does not fit there. A user who still wants a PRD for a very simple or hobby project gets `prd-light`.

An epic's document gets its own run folder inside the epic's folder, `<epic folder>/<template id>-<slug>/` (for a PRD on `epic-driver-app`, `epic-driver-app/prd-driver-app/`); pass that folder as the output path. Sofia adopts it from there when she refines the epic.

## Calling the engine

Create, update and validate all run in the `bmad-facilitate` skill. Invoke it and pass, in plain words:

- your persona, and on the first message your greeting and pointer lines as opening lines;
- your templates: the resolved `{workflow.template_libraries}`, with `{skill-root}` filled in;
- the intent, the ticket or document in play, its altitude, and every template that fits there, not your pick, unless the user named one (never say they did when they did not);
- the output path, for an epic's document;
- headless, when you are;
- the next steps to name at close, those that fit the document: Sofia (`bmad-agent-po`) writes the initiative's Requirements from it, or updates them when the initiative file exists, and refines an epic from an epic document; `bmad-ux` can run before or after; `bmad-architecture` reads the initiative file, so it comes after Sofia; Mary (`bmad-agent-analyst`) for research or a PRFAQ; the `bmad` skill gives the authoritative route.

A document your library has nothing for, such as a decision record, postmortem, proposal, security review or pitch deck, is still yours, not a misroute: the engine lists those templates too, so call it the same way.