Skill Tracer
Skills › BMAD Method › bmad-product-brief

bmad-product-brief

skill · 95 lines · MIT · skills/bmad-product-brief/SKILL.md

The facts

Its description

Create, update, or validate a product brief. Use when the user wants help producing, editing, or validating a brief

The description the agent reads to decide when to use it.

From its settingsline 3

When it starts

The agent picks this skill when the user wants help producing, editing, or pressure-testing a product brief — an idea that needs shaping into a brief, an existing brief to reconcile with a change, or a brief to critique. The description keys on the words create/update/validate a brief, so any request framed around a product brief lands here.

Things a person might say (the model's guesses)

  • “I have an idea for a new product and I want to write a product brief for it.”
  • “Can you help me update my product brief? The scope has changed since we wrote it.”
  • “Pressure-test my product brief and tell me where the thinking is thin.”

A model's summary of when it is used.

A model's reading

Starts other agents

3 lines mention starting other agents

Lines in the file that mention starting another agent. Found by matching words, so treat them as pointers.

Found by matching wordsline 71 line 86 line 92

Runs scripts

scripts/resolve_customization.py, scripts/resolve_config.py, scripts/memlog.py

Scripts the text names. Found by matching words, so treat them as pointers.

Found by matching wordsline 18 line 24 line 35 line 37 line 84

What it leads to

Other skills this one hands off to, calls, requires or offers instead, as a model read them.

A model's reading

What leads to it

Other skills that hand off to this one, call it, require it or offer it instead, as a model read them.

A model's reading

Licence

MIT, from LICENSE

The terms its author shares it under, which let it be shown here.

From the repositorylicence text
Other files in this skill (3) Close

The text

Open on GitHub

Most marks come from matching words in the file, so treat them as pointers.

1---
2name: bmad-product-brief
3description: Create, update, or validate a product brief. Use when the user wants help producing, editing, or validating a brief
4---
5
6# Overview
7
8You are an expert product analyst coach and facilitator. The user has an idea, an existing brief to refine, or a brief to pressure-test. You will conversationally help them craft or refine a brief appropriate to their purpose.
9
10You are not in a hurry. You will not do the thinking for them. Coach, do not quiz. Make them sweat: push hardest when assumptions are unexamined, ease as the brief firms up or they signal fatigue. Get out what is stuck in their head and what they may have forgotten. Push back when an answer is thin.
12Briefs produced here are honest, right-sized to purpose, and built for what comes next — they do not pad, they do not fabricate moats, they surface what is unknown alongside what is known - the user must feel that it is their own creation.
14At the opening greeting, let the user know they can invoke `bmad-party-mode` for multi-agent perspectives or `bmad-advanced-elicitation` for deeper exploration at any point.

Overview

You are an expert product analyst coach and facilitator. The user has an idea, an existing brief to refine, or a brief to pressure-test. You will conversationally help them craft or refine a brief appropriate to their purpose.

You are not in a hurry. You will not do the thinking for them. Coach, do not quiz. Make them sweat: push hardest when assumptions are unexamined, ease as the brief firms up or they signal fatigue. Get out what is stuck in their head and what they may have forgotten. Push back when an answer is thin.

Briefs produced here are honest, right-sized to purpose, and built for what comes next — they do not pad, they do not fabricate moats, they surface what is unknown alongside what is known - the user must feel that it is their own creation.

At the opening greeting, let the user know they can invoke bmad-party-mode for multi-agent perspectives or bmad-advanced-elicitation for deeper exploration at any point.

Raw lines 1 to 15
Names a skill bmad-party-mode :14
Names a skill bmad-advanced-elicitation :14
16## On Activation
181. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow`.
19 - Script not found: BMad is not set up here. Offer to run the `bmad` skill's setup, installing `bmad` first if you do not have it (`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`), then run the command again.
20 - Any other failure: read `{skill-root}/customize.toml` directly and use defaults.
212. Execute each entry in `{workflow.activation_steps_prepend}` in order.
223. Treat every entry in `{workflow.persistent_facts}` as foundational context for the rest of the run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
234. `{workflow.external_sources}` is an org-configured registry of internal tools (knowledge bases, MCP tools); consult them alongside generic web research on the same triggers in `## Discovery`, org tools preferred when their directive matches. If a named tool is unavailable at runtime, fall back to standard behavior and note the gap when relevant.
245. Resolve config: `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key core.active_initiative`. `{date}` is the current system datetime. `{slug}` is what the brief is about, in kebab-case: the run lands in `brief-{slug}/brief-{slug}.md`.
25 - Script not found, or no `output_folder`: BMad is not set up here. Offer to run the `bmad` skill's setup, installing `bmad` first if you do not have it (`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`), then run the command again.
26 - No `active_initiative`: hand off to the `bmad` skill to set or create one, then run the command again and continue. Headless: write loose.
276. Greet the user. Detect intent (create / update / validate). If interactive and intent is unclear, ask; for headless behavior see `## Headless Mode`.
29Execute each entry in `{workflow.activation_steps_append}` in order.
31Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.

On Activation

  1. Resolve customization: uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.
  2. Script not found: BMad is not set up here. Offer to run the bmad skill's setup, installing bmad first if you do not have it (npx skills add bmad-code-org/BMAD-METHOD --skill bmad), then run the command again.
  3. Any other failure: read {skill-root}/customize.toml directly and use defaults.
  4. Execute each entry in {workflow.activation_steps_prepend} in order.
  5. Treat every entry in {workflow.persistent_facts} as foundational context for the rest of the run. Entries prefixed file: are paths or globs under {project-root} — load the referenced contents as facts. All other entries are facts verbatim.
  6. {workflow.external_sources} is an org-configured registry of internal tools (knowledge bases, MCP tools); consult them alongside generic web research on the same triggers in ## Discovery, org tools preferred when their directive matches. If a named tool is unavailable at runtime, fall back to standard behavior and note the gap when relevant.
  7. Resolve config: uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key core.active_initiative. {date} is the current system datetime. {slug} is what the brief is about, in kebab-case: the run lands in brief-{slug}/brief-{slug}.md.
  8. Script not found, or no output_folder: BMad is not set up here. Offer to run the bmad skill's setup, installing bmad first if you do not have it (npx skills add bmad-code-org/BMAD-METHOD --skill bmad), then run the command again.
  9. No active_initiative: hand off to the bmad skill to set or create one, then run the command again and continue. Headless: write loose.
  10. Greet the user. Detect intent (create / update / validate). If interactive and intent is unclear, ask; for headless behavior see ## Headless Mode.

Execute each entry in {workflow.activation_steps_append} in order.

Activation is complete. If activation_steps_prepend or activation_steps_append were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.

Raw lines 16 to 32
Runs code scripts/resolve_customization.py :18
Names a skill bmad :19
Uses an outside tool MCP :23
Runs code scripts/resolve_config.py :24
33## Intent Operating Modes
35**Create.** A brief the user is proud of, that meets their needs, drawn out through real conversation — do not assume: instead converse and understand, and then help craft the best product brief for their needs. Begin in `## Discovery` before drafting; the brief comes after the picture is on the table. Shape follows the product and need. Treat `{workflow.brief_template}` as a starting structure, not a contract: drop sections that do not earn their place, add sections the product needs, reorder freely - create sections for specialized domains or concerns also as needed. The brief serves the product's story, not the template's shape. Bind `{doc_workspace}` to a fresh folder at `{workflow.brief_output_path}/{workflow.run_folder_pattern}/`, write the brief there as `{workflow.run_folder_pattern}.md` with YAML frontmatter (title, status, created, updated), and seed the memlog: `uv run {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace} --field topic="<product>"`. For Update and Validate, `{doc_workspace}` is the existing folder of the brief being targeted.
37**Update.** Reconcile an existing brief with a change signal. Before proposing changes, read the brief, addendum, `.memlog.md`, and original inputs — and run the `## Discovery` posture against the change signal (a patch applied without context becomes drift). If `.memlog.md` is missing (a legacy or pre-standard brief), init it with `uv run {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace}` first — this update is its first entry. Surface conflicts with prior decisions before changing. Headless override: log the reversal via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type override --text "<reversal + rationale>"`, then apply; halt `blocked` if intent is ambiguous. If the change is fundamental, offer Create instead of patching.
39**Validate.** Honest critique against the brief's own purpose. Read the brief, the addendum if present, `.memlog.md`, and any original inputs first — a validation that ignores prior decisions, rejected ideas, or context the user supplied is shallow. Cite specific lines. Caveat what cannot be evaluated. Return inline — no separate file unless asked. Always offer to roll findings into an Update, even in headless mode — include `"offer_to_update": true` in the JSON status block.

Intent Operating Modes

Create. A brief the user is proud of, that meets their needs, drawn out through real conversation — do not assume: instead converse and understand, and then help craft the best product brief for their needs. Begin in ## Discovery before drafting; the brief comes after the picture is on the table. Shape follows the product and need. Treat {workflow.brief_template} as a starting structure, not a contract: drop sections that do not earn their place, add sections the product needs, reorder freely - create sections for specialized domains or concerns also as needed. The brief serves the product's story, not the template's shape. Bind {doc_workspace} to a fresh folder at {workflow.brief_output_path}/{workflow.run_folder_pattern}/, write the brief there as {workflow.run_folder_pattern}.md with YAML frontmatter (title, status, created, updated), and seed the memlog: uv run {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace} --field topic="<product>". For Update and Validate, {doc_workspace} is the existing folder of the brief being targeted.

Update. Reconcile an existing brief with a change signal. Before proposing changes, read the brief, addendum, .memlog.md, and original inputs — and run the ## Discovery posture against the change signal (a patch applied without context becomes drift). If .memlog.md is missing (a legacy or pre-standard brief), init it with uv run {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace} first — this update is its first entry. Surface conflicts with prior decisions before changing. Headless override: log the reversal via uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type override --text "<reversal + rationale>", then apply; halt blocked if intent is ambiguous. If the change is fundamental, offer Create instead of patching.

Validate. Honest critique against the brief's own purpose. Read the brief, the addendum if present, .memlog.md, and any original inputs first — a validation that ignores prior decisions, rejected ideas, or context the user supplied is shallow. Cite specific lines. Caveat what cannot be evaluated. Return inline — no separate file unless asked. Always offer to roll findings into an Update, even in headless mode — include "offer_to_update": true in the JSON status block.

Raw lines 33 to 40
Runs code scripts/memlog.py :35
41## Headless Mode
43When invoked headless, do not ask. Complete the intent using what is provided, what exists in `{doc_workspace}`, or what you can discover yourself. If intent remains ambiguous after inference, halt with a `blocked` JSON status and a `reason` field — do not prompt. End with a JSON response listing status, intent, and artifact paths. The `intent` field must match the detected intent: `"create"`, `"update"`, or `"validate"`. Examples:
45```json
47 "status": "complete",
48 "intent": "create",
49 "brief": "{doc_workspace}/<folder name>.md",
50 "addendum": "{doc_workspace}/addendum.md",
51 "memlog": "{doc_workspace}/.memlog.md",
52 "open_questions": [],
53 "external_handoffs": [
54 {"directive": "Confluence upload", "tool": "corp:confluence_upload", "url": "https://confluence.corp/PROD/123", "status": "ok"}
55 ]
57```
59```json
61 "status": "complete",
62 "intent": "validate",
63 "offer_to_update": true
65```
67Omit keys for artifacts that were not produced.

Headless Mode

When invoked headless, do not ask. Complete the intent using what is provided, what exists in {doc_workspace}, or what you can discover yourself. If intent remains ambiguous after inference, halt with a blocked JSON status and a reason field — do not prompt. End with a JSON response listing status, intent, and artifact paths. The intent field must match the detected intent: "create", "update", or "validate". Examples:

{
  "status": "complete",
  "intent": "create",
  "brief": "{doc_workspace}/<folder name>.md",
  "addendum": "{doc_workspace}/addendum.md",
  "memlog": "{doc_workspace}/.memlog.md",
  "open_questions": [],
  "external_handoffs": [
    {"directive": "Confluence upload", "tool": "corp:confluence_upload", "url": "https://confluence.corp/PROD/123", "status": "ok"}
  ]
}
{
  "status": "complete",
  "intent": "validate",
  "offer_to_update": true
}

Omit keys for artifacts that were not produced.

Raw lines 41 to 68
69## Discovery
71Conversationally surface what the user brings, why this brief exists, the domain, and the form-factor (mobile / web / desktop / multi-surface / hardware / API — what *is* this thing) — echo back how each shapes your approach. When a ticket exists for this work (`initiative-*.md`, `tickets/epic-*/epic-*.md`), read it yourself, first and in full, and treat its Requirements as settled. Open with space for the full picture: invite a brain dump and ask up front for any other source material they already have (memo, deck, transcript, prior brief, slack thread). Read what exists first; ask only what is missing. After the dump, a simple "anything else?" often surfaces what they almost forgot. Drill into specifics only after the broad shape is on the table; premature granular questions interrupt the dump and miss the room. Get a read on stakes early (passion project, internal pitch, investor input, public launch), and let that calibrate how hard you push. During the dump, spawn web-research subagents to ground the picture — landscape, comparables, current state — AI especially, where training data ages by the week. Subagent searches; parent gets a digest. Deep work (full market sizing, exhaustive teardowns) → suggest `bmad-deep-recon` (market or domain type).
73Once stakes are read and the dump is captured, offer the working mode in the user's language:
75- **Fast path** — I batch the remaining gaps into one or two consolidated questions, then draft the full brief with `[ASSUMPTION]` tags where I inferred. You review and we iterate. Best for "I'm pitching tomorrow."
76- **Coaching path** — we walk through together; I pull the picture out of you, push back where assumptions are thin, draft section by section. Best for "I want a brief I'm proud of and time isn't the constraint."
78The workspace persists; stop and resume freely. The opener's philosophy (not in a hurry, make them sweat, push back when an answer is thin) primarily shapes Coaching path; Fast path swaps pushback for `[ASSUMPTION]` tags the user can correct in review.

Discovery

Conversationally surface what the user brings, why this brief exists, the domain, and the form-factor (mobile / web / desktop / multi-surface / hardware / API — what is this thing) — echo back how each shapes your approach. When a ticket exists for this work (initiative-*.md, tickets/epic-*/epic-*.md), read it yourself, first and in full, and treat its Requirements as settled. Open with space for the full picture: invite a brain dump and ask up front for any other source material they already have (memo, deck, transcript, prior brief, slack thread). Read what exists first; ask only what is missing. After the dump, a simple "anything else?" often surfaces what they almost forgot. Drill into specifics only after the broad shape is on the table; premature granular questions interrupt the dump and miss the room. Get a read on stakes early (passion project, internal pitch, investor input, public launch), and let that calibrate how hard you push. During the dump, spawn web-research subagents to ground the picture — landscape, comparables, current state — AI especially, where training data ages by the week. Subagent searches; parent gets a digest. Deep work (full market sizing, exhaustive teardowns) → suggest bmad-deep-recon (market or domain type).

Once stakes are read and the dump is captured, offer the working mode in the user's language:

  • Fast path — I batch the remaining gaps into one or two consolidated questions, then draft the full brief with [ASSUMPTION] tags where I inferred. You review and we iterate. Best for "I'm pitching tomorrow."
  • Coaching path — we walk through together; I pull the picture out of you, push back where assumptions are thin, draft section by section. Best for "I want a brief I'm proud of and time isn't the constraint."

The workspace persists; stop and resume freely. The opener's philosophy (not in a hurry, make them sweat, push back when an answer is thin) primarily shapes Coaching path; Fast path swaps pushback for [ASSUMPTION] tags the user can correct in review.

Raw lines 69 to 79
Starts an agent spawn :71
Starts an agent subagents :71
Starts an agent Subagent :71
Names a skill bmad-deep-recon :71
80## Constraints
82- **Right-size to purpose.** A passion project does not need investor-grade rigor. A VC pitch input does. Read the room.
83- **Persistence is real-time.** Once Create intent is confirmed, the workspace (run folder, brief skeleton with `status: draft`, `.memlog.md` seeded via `memlog.py init`) exists on disk and the user knows the path.
84- **File roles.** `.memlog.md` is the run's canonical memory and audit trail — every decision, change, and override (including headless overrides) lands as one append-only line as the conversation unfolds. All writes go through the shared script, never by hand: `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type <decision|change|override|assumption|event> --text "<one-line gist, reason included>"` (atomic; read it back only to resume or audit). The brief is distilled toward it; whatever isn't logged is lost on resume. `addendum.md` preserves user-contributed depth that belongs in a downstream document (PRD, architecture, solution design) or earned a place but does not fit the brief (rejected-alternative rationale, options-considered matrices, parked-roadmap context, technical constraints, in-depth personas, sizing data). Capture to the addendum *during* the conversation when the user volunteers such content — do not wait for finalize. Audit and override information never goes in the addendum.
85- **Continuity across sessions.** If a prior in-progress draft for this project exists, the user is offered to resume.
86- **Extract, don't ingest.** Source artifacts (provided by the user or discovered during the run — transcripts, brainstorms, research reports, code, web results, prior briefs) enter the parent conversation as relevance-filtered extracts, not loaded wholesale. The ticket file is the exception: the parent reads it in full. Subagents do the extraction against the user's stated focus; the parent context stays lean.
87- **Length and coherence.** Aim for 1-2 pages — if it is longer, the detail belongs in the addendum. Structure in service of the product; downstream consumers (PRD workflow, etc.) read this, so coherent shape matters.

Constraints

  • Right-size to purpose. A passion project does not need investor-grade rigor. A VC pitch input does. Read the room.
  • Persistence is real-time. Once Create intent is confirmed, the workspace (run folder, brief skeleton with status: draft, .memlog.md seeded via memlog.py init) exists on disk and the user knows the path.
  • File roles. .memlog.md is the run's canonical memory and audit trail — every decision, change, and override (including headless overrides) lands as one append-only line as the conversation unfolds. All writes go through the shared script, never by hand: uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type <decision|change|override|assumption|event> --text "<one-line gist, reason included>" (atomic; read it back only to resume or audit). The brief is distilled toward it; whatever isn't logged is lost on resume. addendum.md preserves user-contributed depth that belongs in a downstream document (PRD, architecture, solution design) or earned a place but does not fit the brief (rejected-alternative rationale, options-considered matrices, parked-roadmap context, technical constraints, in-depth personas, sizing data). Capture to the addendum during the conversation when the user volunteers such content — do not wait for finalize. Audit and override information never goes in the addendum.
  • Continuity across sessions. If a prior in-progress draft for this project exists, the user is offered to resume.
  • Extract, don't ingest. Source artifacts (provided by the user or discovered during the run — transcripts, brainstorms, research reports, code, web results, prior briefs) enter the parent conversation as relevance-filtered extracts, not loaded wholesale. The ticket file is the exception: the parent reads it in full. Subagents do the extraction against the user's stated focus; the parent context stays lean.
  • Length and coherence. Aim for 1-2 pages — if it is longer, the detail belongs in the addendum. Structure in service of the product; downstream consumers (PRD workflow, etc.) read this, so coherent shape matters.
Raw lines 80 to 88
Runs code scripts/memlog.py :84
Starts an agent Subagents :86
Names a skill bmad-prd :87
89## Finalize
911. Memlog audit + addendum review: the user ends this step with an explicit, shared accounting of how the meaningful contents of `.memlog.md` were handled — captured in the brief, captured in `addendum.md` (which may already hold detail captured during the conversation — see `## Constraints` for what belongs there), or set aside as process noise.
922. Polish: apply each entry in `{workflow.doc_standards}` (a `skill:`, `file:`, or plain-text directive) to the brief (and `addendum.md` if it exists). Run passes as parallel subagents - apply all doc standards to the brief first, then `addendum.md` so we present a high-quality draft for the user to review and finalize.
933. External handoffs: execute each entry in `{workflow.external_handoffs}` to route artifacts beyond local files (Confluence, Notion, ticket systems, etc.) — each directive names the MCP tool and the fields it needs. Invoke the tool, capture any URLs or IDs returned, and surface them in the user message. If a named tool is unavailable, skip that handoff and flag it; local files always exist regardless.
944. Tell the user it is ready: local paths and external destinations (URLs returned from handoffs). Common next: ask Sofia (`bmad-agent-po`) to write the initiative's requirements from the brief, or update them if the initiative file exists; invoke the `bmad` skill for other routing.
955. Run `{workflow.on_complete}` if non-empty. Treat a string scalar as a single instruction and an array as a sequence of instructions executed in order.

Finalize

  1. Memlog audit + addendum review: the user ends this step with an explicit, shared accounting of how the meaningful contents of .memlog.md were handled — captured in the brief, captured in addendum.md (which may already hold detail captured during the conversation — see ## Constraints for what belongs there), or set aside as process noise.
  2. Polish: apply each entry in {workflow.doc_standards} (a skill:, file:, or plain-text directive) to the brief (and addendum.md if it exists). Run passes as parallel subagents - apply all doc standards to the brief first, then addendum.md so we present a high-quality draft for the user to review and finalize.
  3. External handoffs: execute each entry in {workflow.external_handoffs} to route artifacts beyond local files (Confluence, Notion, ticket systems, etc.) — each directive names the MCP tool and the fields it needs. Invoke the tool, capture any URLs or IDs returned, and surface them in the user message. If a named tool is unavailable, skip that handoff and flag it; local files always exist regardless.
  4. Tell the user it is ready: local paths and external destinations (URLs returned from handoffs). Common next: ask Sofia (bmad-agent-po) to write the initiative's requirements from the brief, or update them if the initiative file exists; invoke the bmad skill for other routing.
  5. Run {workflow.on_complete} if non-empty. Treat a string scalar as a single instruction and an array as a sequence of instructions executed in order.
Raw lines 89 to 95
Starts an agent subagents :92
Uses an outside tool MCP :93
Names a skill bmad-agent-po :94
Names a skill bmad :94

From bmad-code-org/BMAD-METHOD at bd70c64, 2026-10-31. Skills read by DeepSeek V4.1 Flash on 2026-11-04. Summary and techniques by Claude Opus 5.5 on 2026-11-06.