Merge d0bd379bd8 into 48c2324b28

Skills are self-contained in IDE directories, so _bmad/ only needs
module-level files (config.yaml, _config/). After all IDE setups
complete, remove skill directories from _bmad/ via skill-manifest.csv.
Also cleans up skill dirs left by older installer versions.

.claude-plugin/marketplace.json

@@ -60,7 +60,6 @@
         "./src/bmm-skills/3-solutioning/bmad-generate-project-context",
         "./src/bmm-skills/4-implementation/bmad-agent-dev",
         "./src/bmm-skills/4-implementation/bmad-agent-sm",
-        "./src/bmm-skills/4-implementation/bmad-agent-qa",
         "./src/bmm-skills/4-implementation/bmad-dev-story",
         "./src/bmm-skills/4-implementation/bmad-quick-dev",
         "./src/bmm-skills/4-implementation/bmad-sprint-planning",

docs/explanation/checkpoint-preview.md

@@ -0,0 +1,92 @@
+---
+title: "Checkpoint Preview"
+description: LLM-assisted human-in-the-loop review that guides you through a change from purpose to details
+sidebar:
+  order: 3
+---
+
+`bmad-checkpoint-preview` is an interactive, LLM-assisted human-in-the-loop review workflow. It walks you through a code change — from purpose and context into details — so you can make an informed decision about whether to ship, rework, or dig deeper.
+
+![Checkpoint Preview workflow diagram](/diagrams/checkpoint-preview-diagram.png)
+
+## The Typical Flow
+
+You run `bmad-quick-dev`. It clarifies your intent, builds a spec, implements the change, and when it's done it appends a review trail to the spec file and opens it in your editor. You look at the spec and see the change touched 20 files across several modules.
+
+You could eyeball the diff. But 20 files is where eyeballing starts to fail — you lose the thread, miss a connection between two distant changes, or approve something you didn't fully understand. So instead, you say "checkpoint" and the LLM walks you through it.
+
+That handoff — from autonomous implementation back to human judgment — is the primary use case. Quick-dev runs long with minimal supervision. Checkpoint Preview is where you take back the wheel.
+
+## Why It Exists
+
+Code review has two failure modes. In one, the reviewer skims the diff, nothing jumps out, and they approve. In the other, they methodically read every file but lose the thread — they see the trees and miss the forest. Both result in the same outcome: the review didn't catch the thing that mattered.
+
+The underlying issue is sequencing. A raw diff presents changes in file order, which is almost never the order that builds understanding. You see a helper function before you know why it exists. You see a schema change before you understand what feature it supports. The reviewer has to reconstruct the author's intent from scattered clues, and that reconstruction is where attention fails.
+
+Checkpoint Preview solves this by making the LLM do the reconstruction work. It reads the diff, the spec (if one exists), and the surrounding codebase, then presents the change in an order designed for comprehension — not for `git diff`.
+
+## How It Works
+
+The workflow has five steps. Each step builds on the previous one, progressively shifting from "what is this?" toward "should we ship it?"
+
+### 1. Orientation
+
+The workflow identifies the change (from a PR, commit, branch, spec file, or the current git state) and produces a one-line intent summary plus surface area stats: files changed, modules touched, lines of logic, boundary crossings, and new public interfaces.
+
+This is the "is this what I think it is?" moment. Before reading any code, the reviewer confirms they're looking at the right thing and calibrates their expectations for scope.
+
+### 2. Walkthrough
+
+The change is organized by **concern** — cohesive design intents like "input validation" or "API contract" — not by file. Each concern gets a short explanation of *why* this approach was chosen, followed by clickable `path:line` stops that the reviewer can follow through the code.
+
+This is the design judgment step. The reviewer evaluates whether the approach is right for the system, not whether the code is correct. Concerns are sequenced top-down: the highest-level intent first, then supporting implementation. The reviewer never encounters a reference to something they haven't seen yet.
+
+### 3. Detail Pass
+
+After the reviewer understands the design, the workflow surfaces 2-5 spots where a mistake would have the highest blast radius. These are tagged by risk category — `[auth]`, `[schema]`, `[billing]`, `[public API]`, `[security]`, and others — and ordered by how much breaks if they're wrong.
+
+This is not a bug hunt. Automated tests and CI handle correctness. The detail pass activates risk awareness: "here are the places where being wrong costs the most." If the reviewer wants to go deeper on a specific area, they can say "dig into [area]" for a targeted correctness-focused re-review.
+
+If the spec went through adversarial review loops (machine hardening), those findings are surfaced here too — not the bugs that were fixed, but the decisions that the review loop flagged that the reviewer should be aware of.
+
+### 4. Testing
+
+Suggests 2-5 ways to manually observe the change working. Not automated test commands — manual observations that build confidence no test suite provides. A UI interaction to try, a CLI command to run, an API request to send, with expected results for each.
+
+If the change has no user-visible behavior, it says so. No invented busywork.
+
+### 5. Wrap-Up
+
+The reviewer makes the call: approve, rework, or keep discussing. If approving a PR, the workflow can help with `gh pr review --approve`. If reworking, it helps diagnose whether the problem was the approach, the spec, or the implementation, and helps draft actionable feedback tied to specific code locations.
+
+## It's a Conversation, Not a Report
+
+The workflow presents each step as a starting point, not a final word. Between steps — or in the middle of one — you can talk to the LLM, ask questions, challenge its framing, or pull in other skills to get a different perspective:
+
+- **"run advanced elicitation on the error handling"** — push the LLM to reconsider and refine its analysis of a specific area
+- **"party mode on whether this schema migration is safe"** — bring multiple agent perspectives into a focused debate
+- **"run code review"** — generate structured agentic findings with adversarial and edge-case analysis
+
+The checkpoint workflow doesn't lock you into a linear path. It gives you structure when you want it and gets out of the way when you want to explore. The five steps are there to make sure you see the whole picture, but how deep you go at each step — and what tools you bring in — is entirely up to you.
+
+## The Review Trail
+
+The walkthrough step works best when it has a **Suggested Review Order** — a list of stops the spec author wrote to guide reviewers through the change. When a spec includes this, the workflow uses it directly.
+
+When no author-produced trail exists, the workflow generates one from the diff and codebase context. A generated trail is lower quality than an author-produced one, but far better than reading changes in file order.
+
+## When to Use It
+
+The primary scenario is the handoff from `bmad-quick-dev`: the implementation is done, the spec file is open in your editor with a review trail appended, and you need to decide whether to ship. Say "checkpoint" and go.
+
+It also works standalone:
+
+- **Reviewing a PR** — especially one with more than a handful of files or cross-cutting changes
+- **Onboarding to a change** — when you need to understand what happened on a branch you didn't write
+- **Sprint review** — the workflow can pick up stories marked `review` in your sprint status file
+
+Invoke it by saying "checkpoint" or "walk me through this change." It works in any terminal, but you'll get more out of it inside an IDE — VS Code, Cursor, or similar — because the workflow produces `path:line` references at every step. In an IDE-embedded terminal those are clickable, so you can jump from file to file as you follow the review trail.
+
+## What It Is Not
+
+Checkpoint Preview is not a substitute for automated review. It does not run linters, type checkers, or test suites. It does not assign severity scores or produce pass/fail verdicts. It is a reading guide that helps a human apply their judgment where it matters most.

docs/fr/reference/testing.md

@@ -24,9 +24,9 @@ La plupart des projets devraient commencer avec le workflow QA intégré. Si vou
 
 ## Workflow QA Intégré
 
-Le workflow QA intégré est inclus dans le module BMM (suite Agile). Il génère rapidement des tests fonctionnels en utilisant le framework de test existant de votre projet — aucune configuration ni installation supplémentaire requise.
+Le workflow QA intégré (`bmad-qa-generate-e2e-tests`) fait partie du module BMM (suite Agile), disponible via l'agent Developer. Il génère rapidement des tests fonctionnels en utilisant le framework de test existant de votre projet — aucune configuration ni installation supplémentaire requise.
 
-**Déclencheur :** `QA` ou `bmad-qa-generate-e2e-tests`
+**Déclencheur :** `QA` (via l'agent Developer) ou `bmad-qa-generate-e2e-tests`
 
 ### Ce que le Workflow QA Fait
 
@@ -98,7 +98,7 @@ TEA supporte également la priorisation basée sur les risques P0-P3 et des int
 Le workflow Automate du QA intégré apparaît dans la Phase 4 (Implémentation) de la carte de workflow méthode BMad. Il est conçu pour s'exécuter **après qu'un epic complet soit terminé** — une fois que toutes les stories d'un epic ont été implémentées et revues. Une séquence typique :
 
 1. Pour chaque story de l'epic : implémenter avec Dev Story (`DS`), puis valider avec Code Review (`CR`)
-2. Après la fin de l'epic : générer les tests avec le workflow QA (`QA`) ou le workflow Automate de TEA
+2. Après la fin de l'epic : générer les tests avec `QA` (via l'agent Developer) ou le workflow Automate de TEA
 3. Lancer la rétrospective (`bmad-retrospective`) pour capturer les leçons apprises
 
 Le workflow QA travaille directement à partir du code source sans charger les documents de planification (PRD, architecture). Les workflows TEA peuvent s'intégrer avec les artefacts de planification en amont pour la traçabilité.

docs/reference/agents.md

@@ -13,7 +13,7 @@ This page lists the default BMM (Agile suite) agents that install with BMad Meth
 
 - Each agent is available as a skill, generated by the installer. The skill ID (e.g., `bmad-dev`) is used to invoke the agent.
 - Triggers are the short menu codes (e.g., `CP`) and fuzzy matches shown in each agent menu.
-- QA (Quinn) is the lightweight test automation agent in BMM. The full Test Architect (TEA) lives in its own module.
+- QA test generation is handled by the `bmad-qa-generate-e2e-tests` workflow skill, available through the Developer agent. The full Test Architect (TEA) lives in its own module.
 
 | Agent                       | Skill ID             | Triggers                           | Primary workflows                                                                                   |
 | --------------------------- | -------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
@@ -21,8 +21,7 @@ This page lists the default BMM (Agile suite) agents that install with BMad Meth
 | Product Manager (John)      | `bmad-pm`            | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Create/Validate/Edit PRD, Create Epics and Stories, Implementation Readiness, Correct Course        |
 | Architect (Winston)         | `bmad-architect`     | `CA`, `IR`                         | Create Architecture, Implementation Readiness                                                       |
 | Scrum Master (Bob)          | `bmad-sm`            | `SP`, `CS`, `ER`, `CC`             | Sprint Planning, Create Story, Epic Retrospective, Correct Course                                   |
-| Developer (Amelia)          | `bmad-dev`           | `DS`, `QD`, `CR`                   | Dev Story, Quick Dev, Code Review                                                                   |
+| Developer (Amelia)          | `bmad-dev`           | `DS`, `QD`, `QA`, `CR`             | Dev Story, Quick Dev, QA Test Generation, Code Review                                               |
-| QA Engineer (Quinn)         | `bmad-qa`            | `QA`                               | Automate (generate tests for existing features)                                                     |
 | UX Designer (Sally)         | `bmad-ux-designer`   | `CU`                               | Create UX Design                                                                                    |
 | Technical Writer (Paige)    | `bmad-tech-writer`   | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
 

docs/reference/testing.md

@@ -1,15 +1,15 @@
 ---
 title: Testing Options
-description: Comparing the built-in QA agent (Quinn) with the Test Architect (TEA) module for test automation.
+description: Comparing the built-in QA workflow with the Test Architect (TEA) module for test automation.
 sidebar:
   order: 5
 ---
 
-BMad provides two testing paths: a built-in QA agent for fast test generation and an installable Test Architect module for enterprise-grade test strategy.
+BMad provides two testing paths: a built-in QA workflow for fast test generation and an installable Test Architect module for enterprise-grade test strategy.
 
 ## Which Should You Use?
 
-| Factor | Quinn (Built-in QA) | TEA Module |
+| Factor | Built-in QA | TEA Module |
 | --- | --- | --- |
 | **Best for** | Small-medium projects, quick coverage | Large projects, regulated or complex domains |
 | **Setup** | Nothing to install -- included in BMM | Install separately via `npx bmad-method install` |
@@ -18,19 +18,19 @@ BMad provides two testing paths: a built-in QA agent for fast test generation an
 | **Strategy** | Happy path + critical edge cases | Risk-based prioritization (P0-P3) |
 | **Workflow count** | 1 (Automate) | 9 (design, ATDD, automate, review, trace, and others) |
 
-:::tip[Start with Quinn]
+:::tip[Start with built-in QA]
-Most projects should start with Quinn. If you later need test strategy, quality gates, or requirements traceability, install TEA alongside it.
+Most projects should start with the built-in QA workflow. If you later need test strategy, quality gates, or requirements traceability, install TEA alongside it.
 :::
 
-## Built-in QA Agent (Quinn)
+## Built-in QA Workflow
 
-Quinn is the built-in QA agent in the BMM (Agile suite) module. It generates working tests quickly using your project's existing test framework -- no configuration or additional installation required.
+The built-in QA workflow (`bmad-qa-generate-e2e-tests`) is part of the BMM (Agile suite) module, available through the Developer agent. It generates working tests quickly using your project's existing test framework -- no configuration or additional installation required.
 
-**Trigger:** `QA` or `bmad-qa-generate-e2e-tests`
+**Trigger:** `QA` (via the Developer agent) or `bmad-qa-generate-e2e-tests`
 
-### What Quinn Does
+### What It Does
 
-Quinn runs a single workflow (Automate) that walks through five steps:
+The QA workflow (Automate) walks through five steps:
 
 1. **Detect test framework** -- scans `package.json` and existing test files for your framework (Jest, Vitest, Playwright, Cypress, or any standard runner). If none exists, analyzes the project stack and suggests one.
 2. **Identify features** -- asks what to test or auto-discovers features in the codebase.
@@ -38,7 +38,7 @@ Quinn runs a single workflow (Automate) that walks through five steps:
 4. **Generate E2E tests** -- covers user workflows with semantic locators and visible-outcome assertions.
 5. **Run and verify** -- executes the generated tests and fixes failures immediately.
 
-Quinn produces a test summary saved to your project's implementation artifacts folder.
+The workflow produces a test summary saved to your project's implementation artifacts folder.
 
 ### Test Patterns
 
@@ -51,10 +51,10 @@ Generated tests follow a "simple and maintainable" philosophy:
 - **Clear descriptions** that read as feature documentation
 
 :::note[Scope]
-Quinn generates tests only. For code review and story validation, use the Code Review workflow (`CR`) instead.
+The QA workflow generates tests only. For code review and story validation, use the Code Review workflow (`CR`) instead.
 :::
 
-### When to Use Quinn
+### When to Use Built-in QA
 
 - Quick test coverage for a new or existing feature
 - Beginner-friendly test automation without advanced setup
@@ -91,16 +91,16 @@ TEA also supports P0-P3 risk-based prioritization and optional integrations with
 - Teams that need risk-based test prioritization across many features
 - Enterprise environments with formal quality gates before release
 - Complex domains where test strategy must be planned before tests are written
-- Projects that have outgrown Quinn's single-workflow approach
+- Projects that have outgrown the built-in QA's single-workflow approach
 
 ## How Testing Fits into Workflows
 
-Quinn's Automate workflow appears in Phase 4 (Implementation) of the BMad Method workflow map. It is designed to run **after a full epic is complete** — once all stories in an epic have been implemented and code-reviewed. A typical sequence:
+The QA Automate workflow appears in Phase 4 (Implementation) of the BMad Method workflow map. It is designed to run **after a full epic is complete** — once all stories in an epic have been implemented and code-reviewed. A typical sequence:
 
 1. For each story in the epic: implement with Dev (`DS`), then validate with Code Review (`CR`)
-2. After the epic is complete: generate tests with Quinn (`QA`) or TEA's Automate workflow
+2. After the epic is complete: generate tests with `QA` (via the Developer agent) or TEA's Automate workflow
 3. Run retrospective (`bmad-retrospective`) to capture lessons learned
 
-Quinn works directly from source code without loading planning documents (PRD, architecture). TEA workflows can integrate with upstream planning artifacts for traceability.
+The built-in QA workflow works directly from source code without loading planning documents (PRD, architecture). TEA workflows can integrate with upstream planning artifacts for traceability.
 
 For more on where testing fits in the overall process, see the [Workflow Map](./workflow-map.md).

docs/zh-cn/reference/agents.md

@@ -15,8 +15,7 @@ sidebar:
 | Product Manager (John) | `bmad-pm` | `CP`、`VP`、`EP`、`CE`、`IR`、`CC` | Create/Validate/Edit PRD、Create Epics and Stories、Implementation Readiness、Correct Course |
 | Architect (Winston) | `bmad-architect` | `CA`、`IR` | Create Architecture、Implementation Readiness |
 | Scrum Master (Bob) | `bmad-sm` | `SP`、`CS`、`ER`、`CC` | Sprint Planning、Create Story、Epic Retrospective、Correct Course |
-| Developer (Amelia) | `bmad-dev` | `DS`、`QD`、`CR` | Dev Story、Quick Dev、Code Review |
+| Developer (Amelia) | `bmad-dev` | `DS`、`QD`、`QA`、`CR` | Dev Story、Quick Dev、QA Test Generation、Code Review |
-| QA Engineer (Quinn) | `bmad-qa` | `QA` | Automate（为既有功能生成测试） |
 | UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
 | Technical Writer (Paige) | `bmad-tech-writer` | `DP`、`WD`、`US`、`MG`、`VD`、`EC` | Document Project、Write Document、Update Standards、Mermaid Generate、Validate Doc、Explain Concept |
 
@@ -24,7 +23,7 @@ sidebar:
 
 - `Skill ID` 是直接调用该智能体的名称（例如 `bmad-dev`）
 - 触发器是进入智能体会话后可使用的菜单短码
-- QA（Quinn）是 BMM 内置轻量测试角色；完整 TEA 能力位于独立模块
+- QA 测试生成由 `bmad-qa-generate-e2e-tests` workflow skill 处理，通过 Developer 智能体调用；完整 TEA 能力位于独立模块
 
 ## 触发器类型
 

docs/zh-cn/reference/testing.md

@@ -1,17 +1,17 @@
 ---
 title: "测试选项"
-description: 内置 QA（Quinn）与 TEA 模块对比：何时用哪个、各自边界是什么
+description: 内置 QA workflow 与 TEA 模块对比：何时用哪个、各自边界是什么
 sidebar:
   order: 5
 ---
 
 BMad 有两条测试路径：
-- **Quinn（内置 QA）**：快速生成可运行测试
+- **内置 QA workflow**：快速生成可运行测试
 - **TEA（可选模块）**：企业级测试策略与治理能力
 
-## 该选 Quinn 还是 TEA？
+## 该选内置 QA 还是 TEA？
 
-| 维度 | Quinn（内置 QA） | TEA 模块 |
+| 维度 | 内置 QA | TEA 模块 |
 | --- | --- | --- |
 | 最适合 | 中小项目、快速补覆盖 | 大型项目、受监管或复杂业务 |
 | 安装成本 | 无需额外安装（BMM 内置） | 需通过安装器单独选择 |
@@ -21,20 +21,20 @@ BMad 有两条测试路径：
 | workflow 数量 | 1（Automate） | 9（设计/自动化/审查/追溯等） |
 
 :::tip[默认建议]
-大多数项目先用 Quinn。只有当你需要质量门控、合规追溯或系统化测试治理时，再引入 TEA。
+大多数项目先用内置 QA workflow。只有当你需要质量门控、合规追溯或系统化测试治理时，再引入 TEA。
 :::
 
-## 内置 QA（Quinn）
+## 内置 QA Workflow
 
-Quinn 是 BMM 内置 agent，目标是用你现有测试栈快速落地测试，不要求额外配置。
+内置 QA workflow（`bmad-qa-generate-e2e-tests`）是 BMM 模块的一部分，通过 Developer 智能体调用。目标是用你现有测试栈快速落地测试，不要求额外配置。
 
 **触发方式：**
-- 菜单触发器：`QA`
+- 菜单触发器：`QA`（通过 Developer 智能体）
 - skill：`bmad-qa-generate-e2e-tests`
 
-### Quinn 会做什么
+### QA Workflow 会做什么
 
-Quinn 的 Automate 流程通常包含 5 步：
+QA Automate 流程通常包含 5 步：
 1. 检测现有测试框架（如 Jest、Vitest、Playwright、Cypress）
 2. 确认待测功能（手动指定或自动发现）
 3. 生成 API 测试（状态码、结构、主路径与错误分支）
@@ -48,10 +48,10 @@ Quinn 的 Automate 流程通常包含 5 步：
 - 避免硬编码等待/休眠
 
 :::note[范围边界]
-Quinn 只负责“生成测试”。如需实现质量评审与故事验收，请配合代码审查 workflow（`CR` / `bmad-code-review`）。
+QA workflow 只负责”生成测试”。如需实现质量评审与故事验收，请配合代码审查 workflow（`CR` / `bmad-code-review`）。
 :::
 
-### 何时用 Quinn
+### 何时用内置 QA
 
 - 要快速补齐某个功能的测试覆盖
 - 团队希望先获得可运行基线，再逐步增强
@@ -93,10 +93,10 @@ TEA 提供专家测试 agent（Murat）与 9 个结构化 workflow，覆盖策
 按 BMad workflow-map，测试位于阶段 4（实施）：
 
 1. epic 内逐个 story：开发（`DS` / `bmad-dev-story`）+ 代码审查（`CR` / `bmad-code-review`）
-2. epic 完成后：用 Quinn 或 TEA 的 Automate 统一生成/补齐测试
+2. epic 完成后：用 `QA`（通过 Developer 智能体）或 TEA 的 Automate 统一生成/补齐测试
 3. 最后执行复盘（`bmad-retrospective`）
 
-Quinn 主要依据代码直接生成测试；TEA 可结合上游规划产物（如 PRD、architecture）实现更强追溯。
+内置 QA workflow 主要依据代码直接生成测试；TEA 可结合上游规划产物（如 PRD、architecture）实现更强追溯。
 
 ## 相关参考
 

src/bmm-skills/2-plan-workflows/bmad-edit-prd/data/prd-purpose.md

@@ -0,0 +1,197 @@
+# BMAD PRD Purpose
+
+**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
+
+---
+
+## What is a BMAD PRD?
+
+A dual-audience document serving:
+1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
+2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
+
+Each successive document becomes more AI-tailored and granular.
+
+---
+
+## Core Philosophy: Information Density
+
+**High Signal-to-Noise Ratio**
+
+Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
+
+**Anti-Patterns (Eliminate These):**
+- ❌ "The system will allow users to..." → ✅ "Users can..."
+- ❌ "It is important to note that..." → ✅ State the fact directly
+- ❌ "In order to..." → ✅ "To..."
+- ❌ Conversational filler and padding → ✅ Direct, concise statements
+
+**Goal:** Maximum information per word. Zero fluff.
+
+---
+
+## The Traceability Chain
+
+**PRD starts the chain:**
+```
+Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
+```
+
+**In the PRD, establish:**
+- Vision → Success Criteria alignment
+- Success Criteria → User Journey coverage
+- User Journey → Functional Requirement mapping
+- All requirements traceable to user needs
+
+**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
+
+---
+
+## What Makes Great Functional Requirements?
+
+### FRs are Capabilities, Not Implementation
+
+**Good FR:** "Users can reset their password via email link"
+**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
+
+**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
+**Bad FR:** "Fast loading time" (subjective, unmeasurable)
+
+### SMART Quality Criteria
+
+**Specific:** Clear, precisely defined capability
+**Measurable:** Quantifiable with test criteria
+**Attainable:** Realistic within constraints
+**Relevant:** Aligns with business objectives
+**Traceable:** Links to source (executive summary or user journey)
+
+### FR Anti-Patterns
+
+**Subjective Adjectives:**
+- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
+- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
+
+**Implementation Leakage:**
+- ❌ Technology names, specific libraries, implementation details
+- ✅ Focus on capability and measurable outcomes
+
+**Vague Quantifiers:**
+- ❌ "multiple users", "several options", "various formats"
+- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
+
+**Missing Test Criteria:**
+- ❌ "The system shall provide notifications"
+- ✅ "The system shall send email notifications within 30 seconds of trigger event"
+
+---
+
+## What Makes Great Non-Functional Requirements?
+
+### NFRs Must Be Measurable
+
+**Template:**
+```
+"The system shall [metric] [condition] [measurement method]"
+```
+
+**Examples:**
+- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
+- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
+- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
+
+### NFR Anti-Patterns
+
+**Unmeasurable Claims:**
+- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
+- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
+
+**Missing Context:**
+- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
+
+---
+
+## Domain-Specific Requirements
+
+**Auto-Detect and Enforce Based on Project Context**
+
+Certain industries have mandatory requirements that must be present:
+
+- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
+- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
+- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
+- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
+
+**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
+
+---
+
+## Document Structure (Markdown, Human-Readable)
+
+### Required Sections
+1. **Executive Summary** - Vision, differentiator, target users
+2. **Success Criteria** - Measurable outcomes (SMART)
+3. **Product Scope** - MVP, Growth, Vision phases
+4. **User Journeys** - Comprehensive coverage
+5. **Domain Requirements** - Industry-specific compliance (if applicable)
+6. **Innovation Analysis** - Competitive differentiation (if applicable)
+7. **Project-Type Requirements** - Platform-specific needs
+8. **Functional Requirements** - Capability contract (FRs)
+9. **Non-Functional Requirements** - Quality attributes (NFRs)
+
+### Formatting for Dual Consumption
+
+**For Humans:**
+- Clear, professional language
+- Logical flow from vision to requirements
+- Easy for stakeholders to review and approve
+
+**For LLMs:**
+- ## Level 2 headers for all main sections (enables extraction)
+- Consistent structure and patterns
+- Precise, testable language
+- High information density
+
+---
+
+## Downstream Impact
+
+**How the PRD Feeds Next Artifacts:**
+
+**UX Design:**
+- User journeys → interaction flows
+- FRs → design requirements
+- Success criteria → UX metrics
+
+**Architecture:**
+- FRs → system capabilities
+- NFRs → architecture decisions
+- Domain requirements → compliance architecture
+- Project-type requirements → platform choices
+
+**Epics & Stories (created after architecture):**
+- FRs → user stories (1 FR could map to 1-3 stories potentially)
+- Acceptance criteria → story acceptance tests
+- Priority → sprint sequencing
+- Traceability → stories map back to vision
+
+**Development AI Agents:**
+- Precise requirements → implementation clarity
+- Test criteria → automated test generation
+- Domain requirements → compliance enforcement
+- Measurable NFRs → performance targets
+
+---
+
+## Summary: What Makes a Great BMAD PRD?
+
+✅ **High Information Density** - Every sentence carries weight, zero fluff
+✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
+✅ **Clear Traceability** - Each requirement links to user need and business objective
+✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
+✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
+✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
+✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
+
+---
+
+**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.

src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-01-discovery.md

@@ -1,6 +1,6 @@
 ---
 # File references (ONLY variables used in this step)
-prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
+prdPurpose: '../data/prd-purpose.md'
 ---
 
 # Step E-1: Discovery & Understanding

src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-01b-legacy-conversion.md

@@ -1,7 +1,7 @@
 ---
 # File references (ONLY variables used in this step)
 prdFile: '{prd_file_path}'
-prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
+prdPurpose: '../data/prd-purpose.md'
 ---
 
 # Step E-1B: Legacy PRD Conversion Assessment

src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-02-review.md

@@ -2,7 +2,7 @@
 # File references (ONLY variables used in this step)
 prdFile: '{prd_file_path}'
 validationReport: '{validation_report_path}'  # If provided
-prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
+prdPurpose: '../data/prd-purpose.md'
 ---
 
 # Step E-2: Deep Review & Analysis

src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-03-edit.md

@@ -1,7 +1,7 @@
 ---
 # File references (ONLY variables used in this step)
 prdFile: '{prd_file_path}'
-prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
+prdPurpose: '../data/prd-purpose.md'
 ---
 
 # Step E-3: Edit & Update

src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-04-complete.md

@@ -1,7 +1,6 @@
 ---
 # File references (ONLY variables used in this step)
 prdFile: '{prd_file_path}'
-validationWorkflow: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-validate-prd/steps-v/step-v-01-discovery.md'
 ---
 
 # Step E-4: Complete & Validate
@@ -117,8 +116,7 @@ Display:
   - Display: "This will run all 13 validation checks on the updated PRD."
   - Display: "Preparing to validate: {prd_file_path}"
   - Display: "**Proceeding to validation...**"
-  - Read fully and follow: {validationWorkflow} (steps-v/step-v-01-discovery.md)
+  - Invoke the `bmad-validate-prd` skill to run the complete validation workflow
-  - Note: This hands off to the validation workflow which will run its complete 13-step process
 
 - **IF E (Edit More):**
   - Display: "**Additional Edits**"

src/bmm-skills/4-implementation/bmad-agent-dev/SKILL.md

@@ -43,6 +43,7 @@ When you are in this persona and the user calls a skill, this persona must carry
 |------|-------------|-------|
 | DS | Write the next or specified story's tests and code | bmad-dev-story |
 | QD | Unified quick flow — clarify intent, plan, implement, review, present | bmad-quick-dev |
+| QA | Generate API and E2E tests for existing features | bmad-qa-generate-e2e-tests |
 | CR | Initiate a comprehensive code review across multiple quality facets | bmad-code-review |
 
 ## On Activation

src/bmm-skills/4-implementation/bmad-agent-qa/SKILL.md

@@ -1,61 +0,0 @@
----
-name: bmad-agent-qa
-description: QA engineer for test automation and coverage. Use when the user asks to talk to Quinn or requests the QA engineer.
----
-
-# Quinn
-
-## Overview
-
-This skill provides a QA Engineer who generates tests quickly for existing features using standard test framework patterns. Act as Quinn — pragmatic, ship-it-and-iterate, focused on getting coverage fast without overthinking.
-
-## Identity
-
-Pragmatic test automation engineer focused on rapid test coverage. Specializes in generating tests quickly for existing features using standard test framework patterns. Simpler, more direct approach than the advanced Test Architect module.
-
-## Communication Style
-
-Practical and straightforward. Gets tests written fast without overthinking. "Ship it and iterate" mentality. Focuses on coverage first, optimization later.
-
-## Principles
-
-- Generate API and E2E tests for implemented code.
-- Tests should pass on first run.
-
-## Critical Actions
-
-- Never skip running the generated tests to verify they pass
-- Always use standard test framework APIs (no external utilities)
-- Keep tests simple and maintainable
-- Focus on realistic user scenarios
-
-**Need more advanced testing?** For comprehensive test strategy, risk-based planning, quality gates, and enterprise features, install the Test Architect (TEA) module.
-
-You must fully embody this persona so the user gets the best experience and help they need, therefore its important to remember you must not break character until the users dismisses this persona.
-
-When you are in this persona and the user calls a skill, this persona must carry through and remain active.
-
-## Capabilities
-
-| Code | Description | Skill |
-|------|-------------|-------|
-| QA | Generate API and E2E tests for existing features | bmad-qa-generate-e2e-tests |
-
-## On Activation
-
-1. 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
-
-2. **Continue with steps below:**
-   - **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
-   - **Greet and present capabilities** — Greet `{user_name}` warmly by name, always speaking in `{communication_language}` and applying your persona throughout the session.
-
-3. Remind the user they can invoke the `bmad-help` skill at any time for advice and then present the capabilities table from the Capabilities section above.
-
-   **STOP and WAIT for user input** — Do NOT execute menu items automatically. Accept number, menu code, or fuzzy command match.
-
-**CRITICAL Handling:** When user responds with a code, line number or skill, invoke the corresponding skill by its exact registered name from the Capabilities table. DO NOT invent capabilities on the fly.

src/bmm-skills/4-implementation/bmad-agent-qa/bmad-skill-manifest.yaml

@@ -1,11 +0,0 @@
-type: agent
-name: bmad-agent-qa
-displayName: Quinn
-title: QA Engineer
-icon: "🧪"
-capabilities: "test automation, API testing, E2E testing, coverage analysis"
-role: QA Engineer
-identity: "Pragmatic test automation engineer focused on rapid test coverage. Specializes in generating tests quickly for existing features using standard test framework patterns. Simpler, more direct approach than the advanced Test Architect module."
-communicationStyle: "Practical and straightforward. Gets tests written fast without overthinking. 'Ship it and iterate' mentality. Focuses on coverage first, optimization later."
-principles: "Generate API and E2E tests for implemented code. Tests should pass on first run."
-module: bmm

src/bmm-skills/4-implementation/bmad-checkpoint-preview/step-05-wrapup.md

@@ -15,6 +15,8 @@ Review complete. What's the call on this {change_type}?
 - **Discuss** — something's still on your mind
 ```
 
+HALT — do not proceed until the user makes their choice.
+
 ## ACT ON DECISION
 
 - **Approve**: Acknowledge briefly. If the human wants to patch something before shipping, help apply the fix interactively. If reviewing a PR, offer to approve via `gh pr review --approve` — but confirm with the human before executing, since this is a visible action on a shared resource.

src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/checklist.md

@@ -1,4 +1,4 @@
-# Quinn Automate - Validation Checklist
+# QA Automate - Validation Checklist
 
 ## Test Generation
 

src/core-skills/bmad-party-mode/SKILL.md

@@ -102,7 +102,7 @@ The user drives what happens next. Common patterns:
 |---|---|
 | Continues the general discussion | Pick fresh agents, repeat the loop |
 | "Winston, what do you think about what Sally said?" | Spawn just Winston with Sally's response as context |
-| "Bring in Quinn on this" | Spawn Quinn with a summary of the discussion so far |
+| "Bring in Amelia on this" | Spawn Amelia with a summary of the discussion so far |
 | "I agree with John, let's go deeper on that" | Spawn John + 1-2 others to expand on John's point |
 | "What would Mary and Bob think about Winston's approach?" | Spawn Mary and Bob with Winston's response as context |
 | Asks a question directed at everyone | Back to step 1 with all agents |

test/test-install-to-bmad.js

@@ -1,154 +0,0 @@
-/**
- * install_to_bmad Flag — Design Contract Tests
- *
- * Unit tests against the functions that implement the install_to_bmad flag.
- * These nail down the 4 core design decisions:
- *
- * 1. true/omitted → skill stays in _bmad/ (default behavior)
- * 2. false → skill removed from _bmad/ after IDE install
- * 3. No platform → no cleanup runs (cleanup lives in installVerbatimSkills)
- * 4. Mixed flags → each skill evaluated independently
- *
- * Usage: node test/test-install-to-bmad.js
- */
-
-const path = require('node:path');
-const os = require('node:os');
-const fs = require('fs-extra');
-const { loadSkillManifest, getInstallToBmad } = require('../tools/installer/ide/shared/skill-manifest');
-
-// ANSI colors
-const colors = {
-  reset: '\u001B[0m',
-  green: '\u001B[32m',
-  red: '\u001B[31m',
-  yellow: '\u001B[33m',
-  cyan: '\u001B[36m',
-  dim: '\u001B[2m',
-};
-
-let passed = 0;
-let failed = 0;
-
-function assert(condition, testName, errorMessage = '') {
-  if (condition) {
-    console.log(`${colors.green}✓${colors.reset} ${testName}`);
-    passed++;
-  } else {
-    console.log(`${colors.red}✗${colors.reset} ${testName}`);
-    if (errorMessage) {
-      console.log(`  ${colors.dim}${errorMessage}${colors.reset}`);
-    }
-    failed++;
-  }
-}
-
-async function runTests() {
-  console.log(`${colors.cyan}========================================`);
-  console.log('install_to_bmad — Design Contract Tests');
-  console.log(`========================================${colors.reset}\n`);
-
-  // ============================================================
-  // 1. true/omitted → getInstallToBmad returns true (keep in _bmad/)
-  // ============================================================
-  console.log(`${colors.yellow}Design decision 1: true or omitted → skill stays in _bmad/${colors.reset}\n`);
-
-  // Null manifest (no bmad-skill-manifest.yaml) → true
-  assert(getInstallToBmad(null, 'workflow.md') === true, 'null manifest defaults to true');
-
-  // Single-entry, flag omitted → true
-  assert(
-    getInstallToBmad({ __single: { type: 'skill' } }, 'workflow.md') === true,
-    'single-entry manifest with flag omitted defaults to true',
-  );
-
-  // Single-entry, explicit true → true
-  assert(
-    getInstallToBmad({ __single: { type: 'skill', install_to_bmad: true } }, 'workflow.md') === true,
-    'single-entry manifest with explicit true returns true',
-  );
-
-  console.log('');
-
-  // ============================================================
-  // 2. false → getInstallToBmad returns false (remove from _bmad/)
-  // ============================================================
-  console.log(`${colors.yellow}Design decision 2: false → skill removed from _bmad/${colors.reset}\n`);
-
-  // Single-entry, explicit false → false
-  assert(
-    getInstallToBmad({ __single: { type: 'skill', install_to_bmad: false } }, 'workflow.md') === false,
-    'single-entry manifest with explicit false returns false',
-  );
-
-  // loadSkillManifest round-trip: YAML with false is preserved through load
-  {
-    const tmpDir = await fs.mkdtemp(path.join(os.tmpdir(), 'bmad-itb-'));
-    await fs.writeFile(path.join(tmpDir, 'bmad-skill-manifest.yaml'), 'type: skill\ninstall_to_bmad: false\n');
-    const loaded = await loadSkillManifest(tmpDir);
-    assert(getInstallToBmad(loaded, 'workflow.md') === false, 'loadSkillManifest preserves install_to_bmad: false through round-trip');
-    await fs.remove(tmpDir);
-  }
-
-  console.log('');
-
-  // ============================================================
-  // 3. No platform → cleanup only runs inside installVerbatimSkills
-  //    (This is a design invariant: getInstallToBmad is only consulted
-  //     during IDE install. Without a platform, the flag has no effect.)
-  // ============================================================
-  console.log(`${colors.yellow}Design decision 3: flag is a per-skill property, not a pipeline gate${colors.reset}\n`);
-
-  // The flag value is stored but doesn't trigger any side effects by itself.
-  // Cleanup is driven by reading the CSV column inside installVerbatimSkills.
-  // We verify the flag is just data — getInstallToBmad doesn't touch the filesystem.
-  {
-    const manifest = { __single: { type: 'skill', install_to_bmad: false } };
-    const result = getInstallToBmad(manifest, 'workflow.md');
-    assert(typeof result === 'boolean', 'getInstallToBmad returns a boolean (pure data, no side effects)');
-    assert(result === false, 'false value is faithfully returned for consumer to act on');
-  }
-
-  console.log('');
-
-  // ============================================================
-  // 4. Mixed flags → each skill evaluated independently
-  // ============================================================
-  console.log(`${colors.yellow}Design decision 4: mixed flags — each skill independent${colors.reset}\n`);
-
-  // Multi-entry manifest: different files can have different flags
-  {
-    const manifest = {
-      'workflow.md': { type: 'skill', install_to_bmad: false },
-      'other.md': { type: 'skill', install_to_bmad: true },
-    };
-    assert(getInstallToBmad(manifest, 'workflow.md') === false, 'multi-entry: workflow.md with false returns false');
-    assert(getInstallToBmad(manifest, 'other.md') === true, 'multi-entry: other.md with true returns true');
-    assert(getInstallToBmad(manifest, 'unknown.md') === true, 'multi-entry: unknown file defaults to true');
-  }
-
-  console.log('');
-
-  // ============================================================
-  // Summary
-  // ============================================================
-  console.log(`${colors.cyan}========================================`);
-  console.log('Results:');
-  console.log(`  Passed: ${colors.green}${passed}${colors.reset}`);
-  console.log(`  Failed: ${colors.red}${failed}${colors.reset}`);
-  console.log(`========================================${colors.reset}\n`);
-
-  if (failed === 0) {
-    console.log(`${colors.green}All install_to_bmad contract tests passed!${colors.reset}\n`);
-    process.exit(0);
-  } else {
-    console.log(`${colors.red}Some install_to_bmad contract tests failed${colors.reset}\n`);
-    process.exit(1);
-  }
-}
-
-runTests().catch((error) => {
-  console.error(`${colors.red}Test runner failed:${colors.reset}`, error.message);
-  console.error(error.stack);
-  process.exit(1);
-});

test/test-installation-components.js

@@ -59,8 +59,8 @@ async function createTestBmadFixture() {
   await fs.writeFile(
     path.join(fixtureDir, '_config', 'skill-manifest.csv'),
     [
-      'canonicalId,name,description,module,path,install_to_bmad',
+      'canonicalId,name,description,module,path',
-      '"bmad-master","bmad-master","Minimal test agent fixture","core","_bmad/core/bmad-master/SKILL.md","true"',
+      '"bmad-master","bmad-master","Minimal test agent fixture","core","_bmad/core/bmad-master/SKILL.md"',
       '',
     ].join('\n'),
   );
@@ -103,8 +103,8 @@ async function createSkillCollisionFixture() {
   await fs.writeFile(
     path.join(configDir, 'skill-manifest.csv'),
     [
-      'canonicalId,name,description,module,path,install_to_bmad',
+      'canonicalId,name,description,module,path',
-      '"bmad-help","bmad-help","Native help skill","core","_bmad/core/tasks/bmad-help/SKILL.md","true"',
+      '"bmad-help","bmad-help","Native help skill","core","_bmad/core/tasks/bmad-help/SKILL.md"',
       '',
     ].join('\n'),
   );

tools/installer/core/installer.js

@@ -67,6 +67,10 @@ class Installer {
 
       await this._setupIdes(config, allModules, paths, addResult);
 
+      // Skills are now in IDE directories — remove redundant copies from _bmad/.
+      // Also cleans up skill dirs left by older installer versions.
+      await this._cleanupSkillDirs(paths.bmadDir);
+
       const restoreResult = await this._restoreUserFiles(paths, updateState);
 
       // Render consolidated summary
@@ -346,6 +350,33 @@ class Installer {
     }
   }
 
+  /**
+   * Remove skill directories from _bmad/ after IDE installation.
+   * Skills are self-contained in IDE directories, so _bmad/ only needs
+   * module-level files (config.yaml, _config/, etc.).
+   * Also cleans up skill dirs left by older installer versions.
+   * @param {string} bmadDir - BMAD installation directory
+   */
+  async _cleanupSkillDirs(bmadDir) {
+    const csv = require('csv-parse/sync');
+    const csvPath = path.join(bmadDir, '_config', 'skill-manifest.csv');
+    if (!(await fs.pathExists(csvPath))) return;
+
+    const csvContent = await fs.readFile(csvPath, 'utf8');
+    const records = csv.parse(csvContent, { columns: true, skip_empty_lines: true });
+    const bmadFolderName = path.basename(bmadDir);
+    const bmadPrefix = bmadFolderName + '/';
+
+    for (const record of records) {
+      if (!record.path) continue;
+      const relativePath = record.path.startsWith(bmadPrefix) ? record.path.slice(bmadPrefix.length) : record.path;
+      const sourceDir = path.dirname(path.join(bmadDir, relativePath));
+      if (await fs.pathExists(sourceDir)) {
+        await fs.remove(sourceDir);
+      }
+    }
+  }
+
   /**
    * Restore custom and modified files that were backed up before the update.
    * No-op for fresh installs (updateState is null).

tools/installer/core/manifest-generator.js

@@ -9,7 +9,6 @@ const {
   loadSkillManifest: loadSkillManifestShared,
   getCanonicalId: getCanonicalIdShared,
   getArtifactType: getArtifactTypeShared,
-  getInstallToBmad: getInstallToBmadShared,
 } = require('../ide/shared/skill-manifest');
 
 // Load package.json for version info
@@ -42,11 +41,6 @@ class ManifestGenerator {
     return getArtifactTypeShared(manifest, filename);
   }
 
-  /** Delegate to shared skill-manifest module */
-  getInstallToBmad(manifest, filename) {
-    return getInstallToBmadShared(manifest, filename);
-  }
-
   /**
    * Clean text for CSV output by normalizing whitespace.
    * Note: Quote escaping is handled by escapeCsv() at write time.
@@ -127,7 +121,7 @@ class ManifestGenerator {
    * Recursively walk a module directory tree, collecting native SKILL.md entrypoints.
    * A directory is discovered as a skill when it contains a SKILL.md file with
    * valid name/description frontmatter (name must match directory name).
-   * Manifest YAML is loaded only when present — for install_to_bmad and agent metadata.
+   * Manifest YAML is loaded only when present — for agent metadata.
    * Populates this.skills[] and this.skillClaimedDirs (Set of absolute paths).
    */
   async collectSkills() {
@@ -156,7 +150,7 @@ class ManifestGenerator {
         const skillMeta = await this.parseSkillMd(skillMdPath, dir, dirName, debug);
 
         if (skillMeta) {
-          // Load manifest when present (for install_to_bmad and agent metadata)
+          // Load manifest when present (for agent metadata)
           const manifest = await this.loadSkillManifest(dir);
           const artifactType = this.getArtifactType(manifest, skillFile);
 
@@ -182,7 +176,6 @@ class ManifestGenerator {
             module: moduleName,
             path: installPath,
             canonicalId,
-            install_to_bmad: this.getInstallToBmad(manifest, skillFile),
           });
 
           // Add to files list
@@ -472,7 +465,7 @@ class ManifestGenerator {
     const csvPath = path.join(cfgDir, 'skill-manifest.csv');
     const escapeCsv = (value) => `"${String(value ?? '').replaceAll('"', '""')}"`;
 
-    let csvContent = 'canonicalId,name,description,module,path,install_to_bmad\n';
+    let csvContent = 'canonicalId,name,description,module,path\n';
 
     for (const skill of this.skills) {
       const row = [
@@ -481,7 +474,6 @@ class ManifestGenerator {
         escapeCsv(skill.description),
         escapeCsv(skill.module),
         escapeCsv(skill.path),
-        escapeCsv(skill.install_to_bmad),
       ].join(',');
       csvContent += row + '\n';
     }

tools/installer/ide/_config-driven.js

@@ -183,18 +183,6 @@ class ConfigDrivenIdeSetup {
       count++;
     }
 
-    // Post-install cleanup: remove _bmad/ directories for skills with install_to_bmad === "false"
-    for (const record of records) {
-      if (record.install_to_bmad === 'false') {
-        const relativePath = record.path.startsWith(bmadPrefix) ? record.path.slice(bmadPrefix.length) : record.path;
-        const sourceFile = path.join(bmadDir, relativePath);
-        const sourceDir = path.dirname(sourceFile);
-        if (await fs.pathExists(sourceDir)) {
-          await fs.remove(sourceDir);
-        }
-      }
-    }
-
     return count;
   }
 

tools/installer/ide/shared/skill-manifest.js

@@ -54,19 +54,4 @@ function getArtifactType(manifest, filename) {
   return null;
 }
 
-/**
+module.exports = { loadSkillManifest, getCanonicalId, getArtifactType };
- * Get the install_to_bmad flag for a specific file from a loaded skill manifest.
- * @param {Object|null} manifest - Loaded manifest (from loadSkillManifest)
- * @param {string} filename - Source filename to look up
- * @returns {boolean} install_to_bmad value (defaults to true)
- */
-function getInstallToBmad(manifest, filename) {
-  if (!manifest) return true;
-  // Single-entry manifest applies to all files in the directory
-  if (manifest.__single) return manifest.__single.install_to_bmad !== false;
-  // Multi-entry: look up by filename directly
-  if (manifest[filename]) return manifest[filename].install_to_bmad !== false;
-  return true;
-}
-
-module.exports = { loadSkillManifest, getCanonicalId, getArtifactType, getInstallToBmad };

tools/validate-file-refs.js

@@ -156,8 +156,15 @@ function mapInstalledToSource(refPath) {
   // Skip install-only paths (generated at install time, not in source)
   if (isInstallOnly(cleaned)) return null;
 
-  // core/, bmm/, and utility/ are directly under src/
+  // Map installed module names to their source directory names
-  if (cleaned.startsWith('core/') || cleaned.startsWith('bmm/') || cleaned.startsWith('utility/')) {
+  // _bmad/core/ → src/core-skills/, _bmad/bmm/ → src/bmm-skills/
+  if (cleaned.startsWith('core/')) {
+    return path.join(SRC_DIR, 'core-skills', cleaned.slice('core/'.length));
+  }
+  if (cleaned.startsWith('bmm/')) {
+    return path.join(SRC_DIR, 'bmm-skills', cleaned.slice('bmm/'.length));
+  }
+  if (cleaned.startsWith('utility/')) {
     return path.join(SRC_DIR, cleaned);
   }