bmad-method 6.6.1-next.1 → 6.6.1-next.3

package/evals/bmm-skills/bmad-product-brief/files/mossridge-brief/addendum.md

@@ -0,0 +1,41 @@
+# Addendum — Mossridge Tool Lending Library
+
+## Options considered
+
+### Paid lending model (rejected)
+
+Considered charging a nominal per-loan fee ($2–$5) to cover replacement and maintenance. Rejected as inconsistent with library mission of free access. Board has previously stated free access is non-negotiable for core services. A donation jar at checkout was proposed as a soft alternative; deferred.
+
+### Hardware store partnership (considered, deferred)
+
+Mossridge Hardware (the store committing in-kind donations) offered to host a satellite lending point. Considered; deferred to year 2. The integration adds operational complexity (split inventory, cross-location tracking) we are not equipped for at launch. Reasonable to revisit once the main location is established.
+
+### Mobile lending van (rejected)
+
+Proposed by a board member to serve outlying areas. Rejected for MVP — capital cost ($35K+ for vehicle + outfitting) exceeds the entire grant. Could be a year-three expansion if demand validates.
+
+### Skills classes alongside tool loans (deferred)
+
+Considered offering "how to use a power drill" classes as a value-add. Deferred — interesting but distinct programming, not part of the lending service's MVP scope. Adult Services Librarian is interested in piloting separately.
+
+## Reference programs reviewed
+
+- Berkeley Tool Lending Library (operating since 1979, ~3,000 tools, 250+ daily loans). Funded as a city service.
+- Oakland Tool Lending Library (operating since 2000, smaller catalog, library-staffed).
+- Toronto Tool Library (nonprofit, member-supported, paid model — different funding architecture).
+
+Direct correspondence with Berkeley TLL staff (March 2026) suggested:
+- Theft has been low (~2% annually) due to library card requirement and community norms
+- The biggest sustainability risk has been staff hours, not tool replacement
+- Most successful programs have a paid coordinator role, not pure volunteer
+
+## Potential expansion (year 2+)
+
+- Hardware store satellite location
+- Specialty tool categories: woodworking, automotive, sewing
+- Skills classes paired with relevant tool checkouts
+- Seed/cuttings library co-located in spring/summer
+
+## Insurance and liability — current state
+
+Library counsel (Town of Mossridge legal department) has been consulted informally. Formal opinion pending. Existing policy covers patrons in the building; coverage for tool use off-premises is the open question. Awaiting written response before submitting grant application.

package/evals/bmm-skills/bmad-product-brief/files/mossridge-brief/brief.md

@@ -0,0 +1,57 @@
+---
+title: Mossridge Public Library — Tool Lending Library Proposal
+status: final
+created: 2026-04-30
+updated: 2026-04-30
+---
+
+# Tool Lending Library at Mossridge Public Library
+
+## What we're proposing
+
+A free tool-lending service operated out of the Mossridge Public Library, modeled on similar programs in Berkeley, Oakland, and Toronto. Cardholders borrow hand and power tools (drills, saws, ladders, sanders, plumbing snakes, gardening tools) for up to seven days, free of charge.
+
+## Why now
+
+Mossridge residents face rising costs of home maintenance and DIY supplies. Anecdotally, demand for community-shared resources is high — staff have fielded "do you lend tools?" requests for years. A tool library extends the library's mission of equitable access to information and skill-building into the practical-skills domain.
+
+## Who it serves
+
+Mossridge residents with active library cards. Primary audience: single-family homeowners doing their own home repairs, renters making minor improvements with landlord permission, hobbyist woodworkers and gardeners. Estimated 8,000 households in the library's service area.
+
+## Service design
+
+- **Catalog:** Approximately 200 tools to start, prioritizing the most-requested categories (drilling, cutting, sanding, ladders, garden).
+- **Loan period:** Seven days, one renewal allowed if no holds.
+- **Borrower requirements:** Active library card, signed liability waiver, completed safety briefing for power tools.
+- **Location:** Library basement, currently underutilized storage. Accessible by elevator.
+- **Hours:** Tuesday–Saturday during library hours; tools returned via after-hours drop slot when closed.
+
+## Funding
+
+- ARPA infrastructure grant: $42,000 (anticipated, application pending)
+- Friends of the Mossridge Library matching funds: $10,000 (committed)
+- In-kind tool donations from Mossridge Hardware (committed in principle)
+
+Year-one operating cost is estimated at $48,000, primarily tool purchase, maintenance supplies, and shelving/storage retrofit. Ongoing cost (year two and beyond) projected at $12,000 annually for replacement tools and consumables.
+
+## Operations
+
+The service will be run by trained library volunteers, supervised by the Adult Services Librarian. Volunteer training program to be developed in partnership with Mossridge Vocational Center. Estimated 4–6 active volunteers needed at any given time, with a roster of 12–15 trained volunteers to provide coverage.
+
+## Risks
+
+- **Theft and loss.** Tools are valuable and portable. Mitigation: deposit on power tools (refundable), card-required checkout, photo documentation at loan and return.
+- **Liability.** Borrower waivers will be required; the library's existing insurance policy is being reviewed for coverage.
+- **Demand uncertainty.** We do not yet know the actual borrowing volume the service will see.
+
+## Success criteria
+
+- Launch by Q3 2027 with a catalog of 200 tools.
+- 300 unique borrowers in the first year of operation.
+- Zero serious injury incidents.
+- Tool loss rate under 5% per year.
+
+## What we're asking
+
+Board approval to proceed with the ARPA grant application and finalize the service design for fall 2027 launch.

package/evals/bmm-skills/bmad-product-brief/files/mossridge-brief/decision-log.md

@@ -0,0 +1,29 @@
+# Decision Log — Mossridge Tool Lending Library
+
+## 2026-03-04
+- **Pursuing the project.** Adult Services Librarian + Library Director agreed there's enough informal demand signal (years of "do you lend tools?" inquiries) to investigate seriously. Acknowledged that informal inquiries are not the same as validated demand.
+
+## 2026-03-11
+- **Reference programs to study: Berkeley, Oakland, Toronto.** Selected based on size, longevity, and accessibility of operational data.
+
+## 2026-03-25
+- **Initial scope: hand and power tools only.** Rejected including specialty categories (sewing, electronics test gear, automotive) for MVP. Reason: staff expertise and storage. Revisit year 2.
+- **Free model.** Confirmed — paid model rejected as inconsistent with library mission. Donation jar approved as soft revenue.
+
+## 2026-04-01
+- **Volunteer-run model.** Selected to keep ongoing operating costs low. Acknowledged risk: Berkeley correspondence flagged staff-hours as the biggest sustainability concern in similar programs. Plan to revisit at year-one review.
+
+## 2026-04-08
+- **Funding architecture: ARPA grant + Friends matching + in-kind donations.** Considered municipal budget request; rejected as too slow (next budget cycle is 18 months out). Grant is faster but requires fall 2027 launch deadline.
+
+## 2026-04-15
+- **Launch timing: Q3 2027.** Driven by ARPA grant deadline, not by service-readiness analysis. Acknowledged this is grant-driven, not user-driven, timing.
+- **Year-one target: 300 unique borrowers.** Set by analogy to comparable programs scaled to Mossridge population. No local validation underlying this number.
+
+## 2026-04-22
+- **Hardware store satellite deferred to year 2.** Operational complexity exceeds our launch capacity.
+- **Liability: pending formal opinion from town legal.** Borrower waiver in draft.
+
+## 2026-04-30
+- **Brief finalized for board meeting.** Status moved to final.
+- **Open items acknowledged for board discussion:** demand validation method, volunteer sustainability, written legal opinion on off-premises tool use coverage.

package/evals/bmm-skills/bmad-product-brief/files/pantry-bridge-interviews.md

@@ -0,0 +1,90 @@
+# Pantry Bridge — Customer Research Transcripts
+
+**Project:** Pantry Bridge meal-kit concept exploration
+**Research firm:** In-house
+**Round:** Discovery interviews, March 2026
+**Format:** 45-minute semi-structured interviews, video; excerpts below are lightly edited for length and clarity
+
+The four interviews below cover four distinct potential customer segments. We are sharing all four for context, though the team's current product hypothesis targets one specific segment.
+
+---
+
+## Interview 1 — Susan, 38, working parent
+
+**Household:** Two kids (ages 6 and 9), spouse works full-time, both parents work demanding office jobs. Suburban Chicago.
+
+**Susan:** "Honestly, the question is just — can I get dinner on the table by 6:30 without it being chicken nuggets again? My kids don't eat anything green unless we play games about it. My husband and I both have late meetings sometimes. We've tried HelloFresh, we've tried Blue Apron, we tried Home Chef. They all kind of work, and they all kind of don't.
+
+The thing that breaks them for us is the prep time. The boxes say 30 minutes but you need to add 10-15 to actually get it done. By Wednesday night I don't have 45 minutes. So we end up using the boxes on weekends and ordering takeout three nights a week, which is the opposite of what the boxes are supposed to do.
+
+If you really wanted to crack it for families like ours: pre-chopped vegetables, sauces that are actually finished and not 'whisk these eight things together.' I'll pay more for less prep. And the recipe books need to read like the kid is going to eat it — not like 'spicy harissa-rubbed cauliflower steaks.'
+
+Portion sizing — most kits send way too much for our family. We're a family of four but the kids each eat about 60% of a meal. We end up with leftovers that go bad. Better sizing would help."
+
+**Interviewer:** What about price?
+
+**Susan:** "We spend $250-350 a week on groceries currently and probably another $200 on takeout. So a meal kit that replaces three nights of takeout could be $200 a month and we'd still come out ahead. Most kits are priced fine; it's the time that breaks them."
+
+---
+
+## Interview 2 — Marcus, 21, college student
+
+**Household:** Junior at state university, off-campus apartment shared with two roommates, kitchen has a microwave, a stovetop, and a half-broken oven. Limited budget.
+
+**Marcus:** "I'm probably the wrong person for this conversation, no offense. I'm not really a meal-kit person. My food situation is, like, dining hall meal plan when I can use it, and the rest is whatever's cheap and fast. Trader Joe's frozen stuff. Eggs. Pasta. Costco runs with my roommates once a month.
+
+I tried a meal kit when my mom signed me up as a 'starting college' gift. It was nice, but it was $80 a week for two people, which is way out of budget. And honestly, the thing they don't get is that I don't have time at 7 PM to cook. I have time at 11 PM. I want to grab something on my way back from the library and not think.
+
+If you're trying to do meal kits for college students — and I don't really think you should — but if you were, the price has to be like $5 a meal. And it has to be food that survives in a fridge for two weeks because we don't shop on a weekly schedule. We shop when we run out.
+
+Snacks matter more to us than meals, actually. Like, the moment when I'm desperate is 10 PM in the library, not 7 PM. Solve that and I might pay attention."
+
+**Interviewer:** Do you have any dietary restrictions?
+
+**Marcus:** "I'm vegetarian, sort of. I eat fish. So pescatarian I guess. But mostly because meat is expensive."
+
+---
+
+## Interview 3 — Eleanor, 71, retired, lives alone
+
+**Household:** Widow, lives alone in the same single-family home she's been in for 36 years. Suburban Cleveland. Two adult children live out of state. Drives during the day but no longer at night.
+
+**Eleanor:** "I'll tell you what I miss. I miss cooking for someone. My husband Walter passed five years ago this June, and the hardest thing — well, not the hardest, but one of them — is that I don't really cook anymore. I cook eggs. I cook a piece of fish. I open a can of soup more often than I'd like to admit. I used to make Sunday dinners that would feed eight people. Now I eat standing up at the counter half the time.
+
+The grocery store is genuinely difficult. I drive there, I park in the back of the lot because I can usually find a spot, and then it's a long walk in. I get tired by the time I'm in the dairy aisle. Carrying the bags from the car to the kitchen — that's a project. My daughter wants me to use grocery delivery and I've tried, but the apps are all designed for someone twenty years younger than me. Tiny buttons, asking me to click through six screens to add a single tomato. I get frustrated and give up.
+
+What I would actually want — and I've thought about this — is meals for one person. Real portions. Not a frozen TV dinner. Not 'serves four, freeze the rest.' I have a freezer full of leftovers I'll never eat. Just one good meal that I can heat up or finish cooking, that tastes like food I would have made.
+
+I'm watching my sodium because of my blood pressure. Watching sugar too — borderline diabetic, my doctor calls it. So I read labels carefully. The frozen meals you can buy in stores are loaded with both. I'd pay more for less of both, if I trusted that the labels were accurate.
+
+The other thing — and please put this in your notes — is that I'm careful about who I let into my house and what I sign up for. There are scams. My friend Marian got taken for $4,000 last year. So if some company asks for my information, I want to know who they are. I want a real customer service number with a real person. I want it to feel like a real business, not a flashy app.
+
+I don't want it to feel like 'old-people food.' That's an important thing. The Meals on Wheels program in our township is wonderful but it's clearly designed for people who are sicker than I am. I'm not sick. I just live alone and grocery shopping is a lot."
+
+**Interviewer:** What would the ideal experience look like?
+
+**Eleanor:** "Someone delivers good food, in real portions, made with the kind of ingredients I would have used. I can heat it up or finish it. It doesn't taste like a hospital. The packaging is something I can actually open without a knife. I get a phone call once in a while from a person, not a robot. The price is reasonable — I'm on a fixed income but I can spend on things that matter. Eating well matters."
+
+---
+
+## Interview 4 — Dimitri, 44, Director of Food Services, mid-size hospital
+
+**Organization:** 340-bed hospital, food service operates patient meals, staff cafeteria, and a small retail café. Reports to the COO.
+
+**Dimitri:** "I'm probably also not who you should be talking to, but happy to share. We don't buy meal kits. We buy ingredients in institutional volumes from Sysco and US Foods primarily, with some specialty buys for dietary restrictions. We feed about 1,800 people a day across patients, staff, and visitors.
+
+What I deal with that you might find interesting is the patient diet matrix. We have to produce meals that meet specific medical requirements — renal diets, cardiac diets, diabetic diets, dysphagia textures, allergen-free, religious restrictions. Each patient gets a tray that meets their specific orders. It's complex.
+
+If a meal kit company wanted to play in our world, they'd be selling to me at the institutional level — bulk pricing, multi-year contracts, ability to deliver consistent specs across thousands of meals. That's not really a 'meal kit' anymore; that's wholesale food service.
+
+Now, where I might be a buyer in a different sense: my staff cafeteria. We're trying to compete with grab-and-go culture. If you produced ready-to-heat meals targeting our staff demographic — nurses, doctors, techs, who are working 12-hour shifts and want real food, not a sandwich — I might pay attention. But the price point would have to make sense for institutional buying, and you'd need to integrate with our existing food safety protocols.
+
+For consumer meal kits, I'm probably not your customer. We did try one when my wife and I were both working through COVID, and we let the subscription lapse after about three months. Fine product, just didn't fit our patterns."
+
+---
+
+## Note from the research lead
+
+These four interviews were selected to represent the range of segments we've considered. The team's working hypothesis after this round is that the older-adult-living-alone segment is the strongest fit for the Pantry Bridge concept — distinctive needs, acknowledged friction with current options, willingness to pay for quality, and a meaningful unmet need around portion sizing and trust. Working parent segment is well-served by existing competitors. College student segment is too price-sensitive. Institutional segment is a different business entirely.
+
+The brief should target the older-adult segment based on the Eleanor interview specifically.

package/evals/bmm-skills/bmad-product-brief/files/q2-brainstorm.md

@@ -0,0 +1,101 @@
+# Q2 Brainstorm — Hatchet & Loop Studio
+
+**Date:** 2026-04-15
+**Present:** Mira, Devon, Sofia, Theo
+
+Annual Q2 ideation. We're hunting for our next side-project-that-could-become-a-product. Format: 10 minutes wild ideas, 3 minutes per idea on quick takes, then we vote on one to dig into.
+
+## Round 1: Everything goes
+
+(10 minutes, no filtering. We just throw stuff out.)
+
+- A weather app that tracks your mood alongside the forecast (Devon)
+- Meditation chime that learns your sleep cycle and chimes only at the right wake-window (Theo)
+- A podcasting tool for non-podcasters — like, you record voice notes and it auto-edits and posts (Sofia)
+- Craft beer subscription with detailed brewer notes you can read while drinking (Mira)
+- AI sommelier app that tells you what wine to buy at Trader Joe's based on a photo (Theo)
+- Office-plant-care subscription with auto-replacement when one dies (Devon)
+- Neighborhood ride coordinator — like a private Uber pool for one neighborhood (Mira)
+- Neighborhood compost coordinator — connect people with food scraps to people with active compost piles (Sofia)
+- Cookbook app where you click "I'll cook this Tuesday" and it auto-generates the shopping list and sends it to your delivery service (Devon)
+- AR home staging — point your phone at a room and it shows you what it would look like with different furniture (Theo)
+
+## Round 2: Quick takes
+
+### Weather + mood
+
+Devon: "I'd use it." Sofia thinks the data correlation isn't strong enough to be useful — interesting concept but the science doesn't support a product. Park.
+
+### Sleep-cycle meditation chime
+
+Theo's pitch — exists already (Sleep Cycle, etc.). Differentiation would be the chime, which is hardware. Out of scope for a software-first studio.
+
+### Podcasting for non-podcasters
+
+Sofia: "There are like fifty of these." She's right. Skip.
+
+### Craft beer subscription
+
+Mira admits this is mostly her wanting it for herself. We're not in the logistics business. Skip.
+
+### AI sommelier
+
+Theo: "The model would have to be incredibly good at label recognition." Sofia: "And there's already Vivino." Skip.
+
+### Office-plant-care subscription
+
+Devon: "I worked at a place that had this. They were always sad plants." Operational nightmare, low margin. Skip.
+
+### Neighborhood ride coordinator
+
+Mira: "Saturated. Lyft and Uber both have pool features. Uber Neighborhood was a thing and they killed it." Skip.
+
+### Neighborhood compost coordinator
+
+Sofia: "Hear me out. Cities are mandating organic waste separation but most apartments don't have a composting option. People in single-family homes often have active compost piles and would love more material. There's a missing match-making layer." General agreement this is more interesting than the others. Theo: "How do we make money?" Sofia: "Eventually a small fee on the compost-pile-host side, but for MVP just free and prove the demand." Group lights up. We agree to dig into this in Round 3.
+
+### Cookbook → shopping list
+
+Devon's pitch. Already exists (Mealime, Plan to Eat). Skip.
+
+### AR home staging
+
+Theo: "IKEA already has this." Skip.
+
+## Round 3: Compost coordinator deep dive
+
+We spent 45 minutes on this. Notes:
+
+**Who is the user?**
+Two-sided market. Side A: apartment dwellers and renters who generate food scraps and want them composted (motivated by environmental values, sometimes by city mandates). Side B: people with active backyard compost piles who want more "browns and greens" — single-family homeowners, urban farmers, school gardens, community gardens.
+
+Sofia thinks Side A is the harder side to acquire (weak intent — recycling-adjacent behavior). Side B is easier but smaller. The product has to be designed around Side A's friction points.
+
+**Geographic scope.**
+Hyperlocal — neighborhood-level, not city-wide. The whole point is short-distance handoff: Side A doesn't want to drive their food scraps across town. We're talking 5-block radius matches.
+
+**Business model (later).**
+Free at launch. Eventually: subscription for Side B (compost-pile hosts) — they pay to access more matches. Side A always free. Possibly partner with cities that have green-waste mandates (B2G channel).
+
+**Technical approach.**
+Web app first, mobile second. Map-based discovery. Identity verification light-touch (apartment dwellers are skittish about strangers; need trust signals). Match-and-message pattern, not real-time logistics.
+
+**Competition.**
+ShareWaste exists but is global and not focused on hyperlocal density. Some city-specific apps (NYC's GrowNYC). No one has cracked the neighborhood-density model.
+
+**MVP scope.**
+One pilot neighborhood. Sofia knows people in a Portland neighborhood (Sunnyside / Hawthorne area) where compost culture is strong. Start there.
+
+**Open questions.**
+- How do we acquire Side A (apartment dwellers)? They have low intent and lots of competing options (just throwing scraps in trash, paying a service, signing up for city pickup if available).
+- What does the trust layer look like? Reviews? Vouching? Real-name only?
+- Does Side B saturation become a problem fast (one compost pile can only take so much)? How do we route demand?
+
+## Action items
+
+- Sofia: write up the compost coordinator concept as a brief by next Wednesday. Take it to Mira and Devon for first read.
+- Devon: research ShareWaste's user numbers and any teardowns of why they haven't dominated.
+- Theo: sketch the trust-layer UX concepts.
+- Mira: talk to Sofia's Portland contacts about doing user interviews.
+
+Next meeting: 2026-04-29 — review brief draft, decide on go/no-go.

package/evals/bmm-skills/bmad-product-brief/triggers.json

@@ -0,0 +1,18 @@
+[
+  { "query": "Help me write a product brief for my new app idea", "should_trigger": true },
+  { "query": "I need to draft a brief for a feature we're scoping", "should_trigger": true },
+  { "query": "Update this product brief — we changed the target audience", "should_trigger": true },
+  { "query": "Review my brief and tell me if it's investor-ready", "should_trigger": true },
+  { "query": "Validate this brief before our board meeting Monday", "should_trigger": true },
+  { "query": "Pressure-test my product brief for weak assumptions", "should_trigger": true },
+  { "query": "Help me put together a one-page summary of my product idea for stakeholders", "should_trigger": true },
+
+  { "query": "Help me brainstorm ideas for a new feature", "should_trigger": false },
+  { "query": "Write me a PRD for our checkout flow redesign", "should_trigger": false },
+  { "query": "Run a working backwards exercise for my product idea", "should_trigger": false },
+  { "query": "Document this existing codebase for AI agents", "should_trigger": false },
+  { "query": "Help me write user stories for the next sprint", "should_trigger": false },
+  { "query": "Generate a system architecture for my app", "should_trigger": false },
+  { "query": "Write code to parse JSON in Python", "should_trigger": false },
+  { "query": "Create a marketing landing page for my product", "should_trigger": false }
+]

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method",
-  "version": "6.6.1-next.1",
+  "version": "6.6.1-next.3",
   "description": "Breakthrough Method of Agile AI-driven Development",
   "keywords": [
     "agile",

package/src/bmm-skills/1-analysis/bmad-prfaq/bmad-manifest.json

@@ -7,8 +7,8 @@
       "description": "Produces battle-tested PRFAQ document and optional LLM distillate for PRD input.",
       "supports-headless": true,
       "phase-name": "1-analysis",
-      "after": ["brainstorming", "perform-research"],
-      "before": ["create-prd"],
+      "preceded-by": ["brainstorming", "perform-research"],
+      "followed-by": ["create-prd"],
       "is-required": false,
       "output-location": "{planning_artifacts}"
     }

package/src/bmm-skills/1-analysis/bmad-product-brief/SKILL.md

@@ -1,117 +1,72 @@
 ---
 name: bmad-product-brief
-description: Create or update product briefs through guided or autonomous discovery. Use when the user requests to create or update a Product Brief.
+description: Create, update, or validate a product brief. Use when the user wants help producing, editing, or validating a brief.
+dependencies:
+  - bmad-distillator
+  - bmad-editorial-review-structure
+  - bmad-editorial-review-prose
+  - bmad-help
 ---
 
-# Create Product Brief
+# Overview
 
-## 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.
 
-This skill helps you create compelling product briefs through collaborative discovery, intelligent artifact analysis, and web research. Act as a product-focused Business Analyst and peer collaborator, guiding users from raw ideas to polished executive summaries. Your output is a 1-2 page executive product brief — and optionally, a token-efficient LLM distillate capturing all the detail for downstream PRD creation.
+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.
 
-The user is the domain expert. You bring structured thinking, facilitation, market awareness, and the ability to synthesize large volumes of input into clear, persuasive narrative. Work together as equals.
-
-**Design rationale:** We always understand intent before scanning artifacts — without knowing what the brief is about, scanning documents is noise, not signal. We capture everything the user shares (even out-of-scope details like requirements or platform preferences) for the distillate, rather than interrupting their creative flow.
-
-## Conventions
-
-- Bare paths (e.g. `prompts/finalize.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.
-
-## Activation Mode Detection
-
-Check activation context immediately:
-
-1. **Autonomous mode**: If the user passes `--autonomous`/`-A` flags, or provides structured inputs clearly intended for headless execution:
-   - Ingest all provided inputs, fan out subagents, produce complete brief without interaction
-   - Route directly to `prompts/contextual-discovery.md` with `{mode}=autonomous`
-
-2. **Yolo mode**: If the user passes `--yolo` or says "just draft it" / "draft the whole thing":
-   - Ingest everything, draft complete brief upfront, then walk user through refinement
-   - Route to Stage 1 below with `{mode}=yolo`
-
-3. **Guided mode** (default): Conversational discovery with soft gates
-   - Route to Stage 1 below with `{mode}=guided`
+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.
 
 ## 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
-
-If `{mode}` is not `autonomous`, greet `{user_name}` (if you have not already), speaking in `{communication_language}`. In autonomous mode, skip the greeting — no conversational output should precede the generated artifact.
-
-### Step 6: Execute Append Steps
+1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, surface the diagnostic and halt.
+2. Execute each entry in `{workflow.activation_steps_prepend}` in order.
+3. 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.
+4. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present). Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`.
+5. Greet `{user_name}` in `{communication_language}`. Detect intent (create / update / validate). If interactive and intent is unclear, ask; for headless behavior see `## Headless Mode`.
+6. Execute each entry in `{workflow.activation_steps_append}` in order.
 
-Execute each entry in `{workflow.activation_steps_append}` in order.
+## Intent Operating Modes
 
-Activation is complete. Begin the workflow at Stage 1 below.
+**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.output_dir}/{workflow.output_folder_name}/` and write `brief.md` there with YAML frontmatter (title, status, created, updated). For Update and Validate, `{doc_workspace}` is the existing folder of the brief being targeted.
 
-## Stage 1: Understand Intent
+**Update.** Reconcile an existing brief with a change signal (edit request, downstream artifact, anything). Read the brief, the addendum if present, `decision-log.md`, and any original inputs first — past decisions and rejected ideas matter. Then run the `## Discovery` posture against the change signal before proposing changes. Identify what is now stale or wrong, propose changes, apply on agreement, bump `updated`. If the change signal contradicts prior decisions, surface the conflict before changing anything. In headless mode, if the prompt clearly signals intent to override the contradicted decision, proceed with the change and autonomously write the full audit trail — a new `decision-log.md` entry naming the reversal and its rationale, and an `addendum.md` override section — without waiting for user confirmation; if intent to override is ambiguous, halt with `blocked` status naming the specific conflict. If the change is fundamental, name it as a re-draft and offer Create instead. If `distillate.md` exists, regenerate it after changes are applied (re-invoke `bmad-distillator` per Finalize step 3); if unavailable, flag the distillate as stale.
 
-**Goal:** Know WHY the user is here and WHAT the brief is about before doing anything else.
+**Validate.** Honest critique against the brief's own purpose. Read the brief, the addendum if present, `decision-log.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. Offer to roll findings into an Update.
 
-**Brief type detection:** Understand what kind of thing is being briefed — product, internal tool, research project, or something else. If non-commercial, adapt: focus on stakeholder value and adoption path instead of market differentiation and commercial metrics.
+## Headless Mode
 
-**Multi-idea disambiguation:** If the user presents multiple competing ideas or directions, help them pick one focus for this brief session. Note that others can be briefed separately.
+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, for example:
 
-**If the user provides an existing brief** (path to a product brief file, or says "update" / "revise" / "edit"):
-- Read the existing brief fully
-- Treat it as rich input — you already know the product, the vision, the scope
-- Ask: "What's changed? What do you want to update or improve?"
-- The rest of the workflow proceeds normally — contextual discovery may pull in new research, elicitation focuses on gaps or changes, and draft-and-review produces an updated version
+```json
+{
+  "status": "complete",
+  "intent": "create",
+  "brief": "{doc_workspace}/brief.md",
+  "addendum": "{doc_workspace}/addendum.md",
+  "distillate": "{doc_workspace}/distillate.md",
+  "decision_log": "{doc_workspace}/decision-log.md",
+  "open_questions": []
+}
+```
 
-**If the user already provided context** when launching the skill (description, docs, brain dump):
-- Acknowledge what you received — but **DO NOT read document files yet**. Note their paths for Stage 2's subagents to scan contextually. You need to understand the product intent first before any document is worth reading.
-- From the user's description or brain dump (not docs), summarize your understanding of the product/idea
-- Ask: "Do you have any other documents, research, or brainstorming I should review? Anything else to add before I dig in?"
+Omit keys for artifacts that were not produced.
 
-**If the user provided nothing beyond invoking the skill:**
-- Ask what their product or project idea is about
-- Ask if they have any existing documents, research, brainstorming reports, or other materials
-- Let them brain dump — capture everything
+## Discovery
 
-**The "anything else?" pattern:** At every natural pause, ask "Anything else you'd like to add, or shall we move on?" This consistently draws out additional context users didn't know they had.
+Conversationally surface what the user brings, why this brief exists, and the domain — echo back how each shapes your approach. Open with space for the full picture: invite a brain dump and ask up front for any 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. Suggest research (web, competitive, market) only when the stakes warrant it.
 
-**Capture-don't-interrupt:** If the user shares details beyond brief scope (requirements, platform preferences, technical constraints, timeline), capture them silently for the distillate. Don't redirect or stop their flow.
+## Constraints
 
-**When you have enough to understand the product intent**, route to `prompts/contextual-discovery.md` with the current mode.
+- **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.md` skeleton with `status: draft`, `decision-log.md`) exists on disk and the user knows the path. The decision log is canonical memory — what the user has shared is preserved on disk, not stored in the conversation.
+- **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. 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 or distillate. Structure in service of the product; downstream consumers (PRD workflow, etc.) read this, so coherent shape matters.
 
-## Stages
+## Finalize
 
-| # | Stage | Purpose | Prompt |
-|---|-------|---------|--------|
-| 1 | Understand Intent | Know what the brief is about | SKILL.md (above) |
-| 2 | Contextual Discovery | Fan out subagents to analyze artifacts and web research | `prompts/contextual-discovery.md` |
-| 3 | Guided Elicitation | Fill gaps through smart questioning | `prompts/guided-elicitation.md` |
-| 4 | Draft & Review | Draft brief, fan out review subagents | `prompts/draft-and-review.md` |
-| 5 | Finalize | Polish, output, offer distillate | `prompts/finalize.md` |
+1. Decision log audit + addendum: the user ends this step with an explicit, shared accounting of how the meaningful contents of `decision-log.md` were handled — captured in the brief, captured in `addendum.md` (rejected-alternative rationale, options-considered matrices, parked-roadmap context, technical constraints, sizing data, in-depth personas), or set aside as process noise. `addendum.md` exists if anything earned its place there.
+2. Polish: apply each entry in `{workflow.doc_standards}` (a `skill:`, `file:`, or plain-text directive) to `brief.md` (and `addendum.md` if it exists). Run passes as parallel subagents. The user sees a polished draft, not a polish review.
+3. Distillate: offer the user a lean, token-efficient distillate of the brief — frame why it matters (it becomes the primary input when downstream BMad workflows like PRD creation pull this brief in). If they want it, invoke `bmad-distillator` with `source_documents=[brief.md, addendum.md if produced]`, `downstream_consumer="PRD creation"`, `output_path={doc_workspace}/distillate.md`. If `bmad-distillator` is not installed, skip distillate generation entirely — do not attempt an inline alternative. Include `"distillate": "skipped — bmad-distillator not installed"` in the final JSON block and tell the user to install it.
+4. Tell the user it is ready: artifacts, path, use the `bmad-help` skill to help understand what next steps you can suggest they do in the bmad method ecosystem.
+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.

package/src/bmm-skills/1-analysis/bmad-product-brief/assets/brief-template.md

@@ -0,0 +1,41 @@
+# Product Brief Template
+
+A flexible starting structure for the executive product brief. Adapt aggressively to the product, the purpose, and the domain. Drop sections that do not earn their place, add sections the product needs, reorder freely. The brief serves the product's story, not the template's shape.
+
+## Default Structure
+
+```markdown
+# Product Brief: {Product Name}
+
+## Executive Summary
+
+[2-3 paragraph narrative: what this is, what problem it solves, why it matters, why now. Compelling enough to stand alone — if someone reads only this section, they should understand the vision.]
+
+## The Problem
+
+[What pain exists, who feels it, how they cope today, the cost of the status quo. Be specific: real scenarios, real frustrations, real consequences.]
+
+## The Solution
+
+[What is being built, how it solves the problem. Focus on the experience and the outcome, not the implementation.]
+
+## What Makes This Different
+
+[Key differentiators. Why this approach over alternatives, what is the unfair advantage. Be honest. If the moat is execution speed, say so. Do not fabricate technical moats.]
+
+## Who This Serves
+
+[Primary users — vivid but brief. Who they are, what they need, what success looks like for them. Secondary users if relevant.]
+
+## Success Criteria
+
+[How we know this is working. Mix of user success signals and business objectives. Measurable.]
+
+## Scope
+
+[What is in for the first version. What is explicitly out. Keep this tight — boundary document, not a feature list.]
+
+## Vision
+
+[Where this goes if it succeeds. What it becomes in 2-3 years. Inspiring but grounded.]
+```