basic BMAD setup

2026-10-15 08:57:23 +02:00
parent 44029127dc
commit 5e747654b9
438 changed files with 41818 additions and 0 deletions
@@ -0,0 +1,64 @@
+# Working in an organization
+
+Use this when the work belongs to a team or enterprise: a PRD already exists, a tracker such as Jira is the record, people must approve, several engineers build in parallel, or requirements change mid-flight.
+
+## When the full path is warranted
+
+A single builder, or a small team that already agrees, goes straight to `bmad-spec` and needs no PRD. Recommend the full path (PRD, architecture, one spec per epic, tracking) only when one of these is true:
+
+- People who did not do the thinking must approve what the product is.
+- Several epics, teams, or agents build against the same decisions and must not diverge.
+- A regulator, steering committee, or company process requires named documents.
+
+Before any of this, a product manager, designer, or analyst can prototype the idea (`help/prototyping.md`).
+
+## An existing PRD is input
+
+- Point `bmad-prd` at the existing PRD. Validate gives a findings report and changes nothing. Create rewrites the same requirements in the shape later skills read, with `[ASSUMPTION]` tags on what it filled in.
+- When the source PRD changes, run `bmad-prd` update. Tell the user never to hand-edit `prd-<slug>.md`.
+- `bmad-ux` and `bmad-architecture` start from the existing design system, architecture document, or codebase.
+
+## One owner per document
+
+Each document has one skill that writes it, so give it one owner. One person can hold several roles.
+
+| Role | Runs | Owns |
+|---|---|---|
+| Product manager | `bmad-prd` | `prd-<slug>.md` and its updates |
+| Designer | `bmad-ux` | `DESIGN.md`, `EXPERIENCE.md` |
+| Tech lead | `bmad-architecture` | The architecture spine |
+| One engineer per epic | `bmad-spec`, `bmad-build`, `bmad-retrospective` | That epic's spec, stories, verdict |
+| Whoever tracks the whole | `bmad-ticket` | the ticket tree |
+
+Several engineers can each take an epic at once. An epic-level spine inherits the parent spine's decisions as binding.
+
+## Where sign-off happens
+
+Each moment produces a written result an approval can attach to. Advise placing existing approvals here.
+
+| Moment | What it holds back |
+|---|---|
+| `bmad-prfaq` verdict | Writing the PRD |
+| `bmad-prd` validate | Design and architecture work |
+| Architecture spine review | Writing epic specs |
+| `bmad-ticket` planning approval | Accepting the breakdown and its dependencies |
+| `bmad-retrospective` verdict | Starting the next epic |
+
+`bmad-prfaq` and `bmad-retrospective` accept `-H` to run without a conversation.
+
+## When requirements change
+
+Reviewers ask for changes in whichever document they are reading. Apply the change to the document that owns it, then re-run the later skills.
+
+1. `bmad-prd` update. It surfaces conflicts with earlier decisions before applying anything.
+2. `bmad-architecture` update when a decision shared across epics changes.
+3. `bmad-spec` for each affected epic. Capability ids stay stable, and it says which stories no longer match.
+4. Story breakdown or `bmad-ticket` again. Existing plans retain status.
+
+For a change that threatens the plan itself, run `bmad-correct-course` first. It needs a PRD or a spec.
+
+## Tracker integration
+
+- Nothing syncs with Jira or any tracker automatically, in either direction.
+- Repo-store status lives in each joined plan. Builds stop at `built`; the user or orchestrator marks `done`.
+- `bmad-ticket` can publish tickets to Jira, Linear, or GitHub. When the skill runs, the tracker's status is read into the leaf file as `tracker_status`. The build's own `status` stays in its separate joined plan; tracker status never drives the build (`help/ticketing-and-epics.md`).