Dev

Dev is the default path (help menu DEV, skill bglad-dev). One person, one spec. Same entry as stock BMad Build: take the ticket as-is, investigate first, ask only what evidence cannot settle. Then three gates Build does not require: Problem and Acceptance before code, required review, required write-and-run unit and e2e tests.

The spec stays in the Spec location from install (Jira, Confluence, or local markdown — not a BMad PRD).

flowchart TD
  inv[Investigate] --> settle{Problem and Acceptance explicit?}
  settle -->|no| oq[Open questions on the spec]
  oq --> halt[HALT]
  halt --> resume[Answers on the spec]
  resume --> settle
  settle -->|yes| impl[Implement]
  impl --> askR{Review now or hand off?}
  askR --> rev[Required review]
  rev --> askQ{Tests now or hand off?}
  askQ --> qa[Write missing tests then unit and e2e]
  qa --> mr[Merge request or pull request]
  mr --> kn[Distilled knowledge]

1. Investigate the ticket and the repo (like Build). Prefer evidence, then the operator. What neither can settle becomes numbered Open questions on the spec the reporter already uses. HALT. Do not implement. Do not switch to Analysis because a stakeholder must answer.
2. After answers (or if the ticket was already a spec), write Problem, Acceptance, Design, and Test notes on the same spec (ticket spec). Fill Design yourself unless someone asked for a Design (DS) session. Set Open questions to None.
3. Implement against Acceptance.
4. Required review (bglad-review). One person runs it in this chat. ASK whether to run it now or hand it off.
5. Required unit tests and end-to-end tests (bglad-qa). Add them if they do not exist. Stop if they fail.
6. Open a merge request or pull request on the git host in your overlay.
7. Knowledge — distill decisions so later work can start from them. Not a copy of the spec.

Analysis and Design are how incoming stories get prepared, only if a product owner is doing that work. Overlay work uses DEV, not stock Build (BD).