diff --git a/CHANGELOG.md b/CHANGELOG.md index 1b3cc99734..1e1e40db8c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -8,6 +8,7 @@ * `planning_artifacts` and `implementation_artifacts` are no longer read or seeded. Run `bmad migrate method` on a v6 project. * The ticketing store's `root` key is gone; the ticket tree is `{output_folder}/{active_initiative}`. To move the store, set `core.output_folder` in `_bmad/custom/config.toml`. +* `bmad-preview-ticketing` is now `bmad-ticket`. `npx skills update` does not install the new name: run `npx skills add bmad-code-org/BMAD-METHOD --skill bmad-ticket`, and rename `_bmad/custom/bmad-preview-ticketing.toml` to `bmad-ticket.toml` if you have one. Until the v7 release, the old name is a forwarder that says this. ## v6.12.0 - 2026-09-03 diff --git a/docs-site/astro.config.mjs b/docs-site/astro.config.mjs index 4944850891..4e9b18ac0e 100644 --- a/docs-site/astro.config.mjs +++ b/docs-site/astro.config.mjs @@ -31,6 +31,7 @@ export default defineConfig({ '/how-to/quick-fixes': `${basePath}build/build-a-change/`, '/explanation/build': `${basePath}build/build-a-change/`, '/explanation/checkpoint-preview': `${basePath}build/walk-through-a-change/`, + '/plan/help-test-v7-previews': `${basePath}plan/set-up-the-ticket-tree/`, '/build/review-a-completed-change': `${basePath}build/walk-through-a-change/`, '/build/checkpoint-a-change': `${basePath}build/walk-through-a-change/`, '/fr/explanation/checkpoint-preview': `${basePath}fr/build/walk-through-a-change/`, @@ -352,8 +353,8 @@ export default defineConfig({ slug: 'plan/break-work-into-stories-and-track-it', }, { - label: 'Help Test v7 Previews', - slug: 'plan/help-test-v7-previews', + label: 'Set Up the Ticket Tree', + slug: 'plan/set-up-the-ticket-tree', }, ], }, diff --git a/docs-site/locale-coverage-baseline.json b/docs-site/locale-coverage-baseline.json index a531ec54fb..715ca3346d 100644 --- a/docs-site/locale-coverage-baseline.json +++ b/docs-site/locale-coverage-baseline.json @@ -17,7 +17,7 @@ "plan/define-requirements-and-a-specification", "plan/design-ux-and-architecture", "plan/explore-and-validate-an-idea", - "plan/help-test-v7-previews", + "plan/set-up-the-ticket-tree", "plan/plan-inside-an-organization", "plan/research-a-decision", "reference/skills-and-agents", @@ -43,7 +43,7 @@ "plan/define-requirements-and-a-specification", "plan/design-ux-and-architecture", "plan/explore-and-validate-an-idea", - "plan/help-test-v7-previews", + "plan/set-up-the-ticket-tree", "plan/plan-inside-an-organization", "plan/research-a-decision", "reference/skills-and-agents", @@ -71,7 +71,7 @@ "plan/define-requirements-and-a-specification", "plan/design-ux-and-architecture", "plan/explore-and-validate-an-idea", - "plan/help-test-v7-previews", + "plan/set-up-the-ticket-tree", "plan/plan-inside-an-organization", "plan/research-a-decision", "reference/skills-and-agents", @@ -99,7 +99,7 @@ "plan/define-requirements-and-a-specification", "plan/design-ux-and-architecture", "plan/explore-and-validate-an-idea", - "plan/help-test-v7-previews", + "plan/set-up-the-ticket-tree", "plan/plan-inside-an-organization", "plan/research-a-decision", "reference/skills-and-agents", @@ -128,7 +128,7 @@ "plan/define-requirements-and-a-specification", "plan/design-ux-and-architecture", "plan/explore-and-validate-an-idea", - "plan/help-test-v7-previews", + "plan/set-up-the-ticket-tree", "plan/plan-inside-an-organization", "plan/research-a-decision", "reference/skills-and-agents", diff --git a/docs-site/src/diagrams/planning-skills.labels.json b/docs-site/src/diagrams/planning-skills.labels.json index 39039d2d25..a40f543826 100644 --- a/docs-site/src/diagrams/planning-skills.labels.json +++ b/docs-site/src/diagrams/planning-skills.labels.json @@ -23,7 +23,7 @@ "design-md-experience-md": "ux-.md, DESIGN.md, EXPERIENCE.md", "bmad-spec": "bmad-spec", "spec-md-companions": "spec-.md + companions", - "ticketing-handoff": "ticketing handoff", + "ticketing-handoff": "bmad-ticket handoff", "spec-when-needed": "Use a spec when needed.", "one-session-of-work-goes": "One session of work goes", "straight-from-the-spec-to-build": "straight from the spec to Build.", @@ -31,8 +31,7 @@ "decide-how-divide-the-work": "decide how, divide the work", "bmad-architecture": "bmad-architecture", "architecture-spine-md": "architecture-.md", - "bmad-preview": "bmad-preview-", - "ticketing": "ticketing", + "bmad-ticket": "bmad-ticket", "ordered-entries": "ordered tickets.toml entries", "bmad-build": "bmad-build", "build-output": "one session per unit · built → user marks done · keep plans" diff --git a/docs-site/src/diagrams/planning-skills.svg b/docs-site/src/diagrams/planning-skills.svg index 937a840e61..f8a577da60 100644 --- a/docs-site/src/diagrams/planning-skills.svg +++ b/docs-site/src/diagrams/planning-skills.svg @@ -1,6 +1,6 @@ Planning skills and what they produce - Three columns of skills and their artifacts. Analysis: bmad-brainstorming, bmad-forge-idea, bmad-deep-recon, bmad-product-brief, bmad-prfaq. Planning: bmad-prd, bmad-ux, bmad-spec. Solutioning: bmad-architecture and bmad-preview-ticketing. The columns flow left to right and hand off to bmad-build, one session per unit. Build finishes at built; the user marks done and retains the plan. + Three columns of skills and their artifacts. Analysis: bmad-brainstorming, bmad-forge-idea, bmad-deep-recon, bmad-product-brief, bmad-prfaq. Planning: bmad-prd, bmad-ux, bmad-spec. Solutioning: bmad-architecture and bmad-ticket. The columns flow left to right and hand off to bmad-build, one session per unit. Build finishes at built; the user marks done and retains the plan. @@ -65,7 +65,7 @@ bmad-spec spec-<slug>.md + companions - ticketing handoff + bmad-ticket handoff Use a spec when needed. One session of work goes @@ -84,10 +84,9 @@ architecture-<slug>.md - - bmad-preview- - ticketing - ordered tickets.toml entries + + bmad-ticket + ordered tickets.toml entries diff --git a/docs/build/autonomous-development-loops.md b/docs/build/autonomous-development-loops.md index 9f0f650691..e1d9ccf96f 100644 --- a/docs/build/autonomous-development-loops.md +++ b/docs/build/autonomous-development-loops.md @@ -51,10 +51,10 @@ Supported intent shapes include: ### Tickets from the Tree Build Auto reads the tree through `{project-root}/_bmad/method/scripts/tickets.py`, -the script the [ticketing skill](../plan/break-work-into-stories-and-track-it.md) installs. +the script [`bmad-ticket`](../plan/break-work-into-stories-and-track-it.md) installs. This page describes the repo store, where a ticket's status lives in its plan. On a tracker store, `tickets.py mark` refuses to run, so move the ticket on -the tracker through the ticketing skill. +the tracker through `bmad-ticket`. - A named ticket goes through `tickets.py find`. When `find` fails, for example on a reference that matches no ticket or more than one, the run halts with `ticket not resolved`. - It builds from the entry in `tickets.toml`, its epic file and what that file's References name, and the entry's story file when it has one. It never writes a ticket file and never runs `tickets.py pull`. @@ -140,7 +140,7 @@ The plan frontmatter `status` is the main machine-readable state for orchestrati | `built` | The run finished; nobody has called the ticket done yet | `review` | | `done` | The user or an orchestrator called the ticket done | `done` | | `blocked` | The run cannot safely continue unattended | `in-progress` | -| `dropped` | The ticketing skill dropped the ticket, on the user's word | `dropped` | +| `dropped` | `bmad-ticket` dropped the ticket, on the user's word | `dropped` | Build Auto never moves a ticket to `done`. The user or an orchestrator marks a ticket done with `tickets.py mark done`. A follow-up pass on a diff --git a/docs/build/build-a-change.md b/docs/build/build-a-change.md index f4c38b22b1..a7a5e6ba85 100644 --- a/docs/build/build-a-change.md +++ b/docs/build/build-a-change.md @@ -199,7 +199,7 @@ decisions may set patterns for later work. Once those patterns are stable, | `bmad-retrospective` | Review a completed epic against the evidence it left behind ([Finish an Epic](./finish-an-epic.md)) | Retro document, action items, acceptance verdict | Clear one-session work enters `bmad-build` directly. Larger work is sliced -into a ticket tree with `bmad-preview-ticketing`, from a spec or any other +into a ticket tree with `bmad-ticket`, from a spec or any other intent, and each build takes one ticket. `bmad-build-auto` does not orchestrate those tickets: an AI coding session or another orchestrator, such as bmad-loop, dispatches one worker per ticket. See diff --git a/docs/build/finish-an-epic.md b/docs/build/finish-an-epic.md index 516d59e779..d72bdbcbba 100644 --- a/docs/build/finish-an-epic.md +++ b/docs/build/finish-an-epic.md @@ -49,7 +49,7 @@ show. It won't invent a root cause or a pattern the code doesn't back up. ## What It Reads The retrospective works on one epic folder in the ticket tree that -`bmad-preview-ticketing` keeps (see +`bmad-ticket` keeps (see [Break Work into Stories](../plan/break-work-into-stories-and-track-it.md)): - **`tickets.toml`**: the epic's tickets, in build order. diff --git a/docs/existing-codebases/getting-deeper.md b/docs/existing-codebases/getting-deeper.md index 431532d5ce..ec43158e17 100644 --- a/docs/existing-codebases/getting-deeper.md +++ b/docs/existing-codebases/getting-deeper.md @@ -158,7 +158,7 @@ documentation. Do not add another Django documentation file or an external service. Use diffsettings-audit as the spec folder slug. ``` -BMad Spec first has you pick or create an initiative, then writes `_bmad-output/initiative-/spec-diffsettings-audit/spec-diffsettings-audit.md`. Hand it to `bmad-preview-ticketing` to create `epic-diffsettings-audit` and its three ordered entries in `tickets.toml`. Read the spec and entries and answer any questions. Continue when they match the requirements above; note the epic folder the skill creates. +BMad Spec first has you pick or create an initiative, then writes `_bmad-output/initiative-/spec-diffsettings-audit/spec-diffsettings-audit.md`. Hand it to `bmad-ticket` to create `epic-diffsettings-audit` and its three ordered entries in `tickets.toml`. Read the spec and entries and answer any questions. Continue when they match the requirements above; note the epic folder the skill creates. ## 9. Build the Three Stories diff --git a/docs/existing-codebases/start-in-an-existing-codebase.md b/docs/existing-codebases/start-in-an-existing-codebase.md index 9194f38128..f8657832a2 100644 --- a/docs/existing-codebases/start-in-an-existing-codebase.md +++ b/docs/existing-codebases/start-in-an-existing-codebase.md @@ -17,7 +17,7 @@ ordinary change — an agent doing a small request should not even be able to find it by accident. For a small change, use `[bmad-build](../build/build-a-change.md)`. -For one that needs several coding sessions, run `bmad-spec`, plan its entries with `bmad-preview-ticketing`, and Build each entry directly. Then run `bmad-retrospective` on the epic. Keep its joined plans as live status and evidence. If it is bigger than that, treat it as a project and follow [Choose a Planning Path](../plan/choose-a-planning-path.md). +For one that needs several coding sessions, run `bmad-spec`, plan its entries with `bmad-ticket`, and Build each entry directly. Then run `bmad-retrospective` on the epic. Keep its joined plans as live status and evidence. If it is bigger than that, treat it as a project and follow [Choose a Planning Path](../plan/choose-a-planning-path.md). Too little planning costs one Build run: Build looks at the code first, and stops to ask when it cannot settle the intent. Too much diff --git a/docs/plan/break-work-into-stories-and-track-it.md b/docs/plan/break-work-into-stories-and-track-it.md index 4155c4ecfd..c0ea057c05 100644 --- a/docs/plan/break-work-into-stories-and-track-it.md +++ b/docs/plan/break-work-into-stories-and-track-it.md @@ -5,7 +5,7 @@ sidebar: order: 7 --- -Use `bmad-preview-ticketing` to split and track work. It accepts described intent, a spec, or a PRD. One small story or bug can go straight to [Build](../build/build-a-change.md) without ticketing. +Use `bmad-ticket` to split and track work. It accepts described intent, a spec, or a PRD. One small story or bug can go straight to [Build](../build/build-a-change.md) without ticketing. ## Plan the Work @@ -13,7 +13,7 @@ For several epics, create an initiative and ask the skill to slice it. Each epic The initiative's `tickets.toml` lists epics. Each epic's `tickets.toml` lists entries with stable numeric ids. A planned entry needs no story file. Standalone tracked stories and bugs have files in `backlog/`; they do not need an invented epic. -See [Set Up the Ticket Tree](./help-test-v7-previews.md) for store and tracker configuration. +See [Set Up the Ticket Tree](./set-up-the-ticket-tree.md) for store and tracker configuration. ## Build an Entry @@ -25,14 +25,14 @@ For unattended work, explicitly dispatch a ticket to `bmad-build-auto`, one invo ## Track Progress -Ask ticketing “what's next?” or “show status.” Plans carry build progress. A build finishes at `built`, shown in the review column; the user or orchestrator decides when to mark it `done`. A tracker card's status remains separate from build status. +Ask `bmad-ticket` “what's next?” or “show status.” Plans carry build progress. A build finishes at `built`, shown in the review column; the user or orchestrator decides when to mark it `done`. A tracker card's status remains separate from build status. Keep completed plans. Deleting one removes the state and evidence later builds, review, and retrospective read. ## Review and Close -`bmad-code-review` reads a ticket's plan and baseline and appends a dated `Code Review` block. It never changes ticket status. When the epic is finished, run [Retrospective](../build/finish-an-epic.md) with its folder, id, or slug. Retrospective writes its evidence and verdict directly in the epic folder; ticketing handles confirmed closure. +`bmad-code-review` reads a ticket's plan and baseline and appends a dated `Code Review` block. It never changes ticket status. When the epic is finished, run [Retrospective](../build/finish-an-epic.md) with its folder, id, or slug. Retrospective writes its evidence and verdict directly in the epic folder; `bmad-ticket` handles confirmed closure. ## Correct Course -Run `bmad-correct-course` when a requirement, architecture choice, or dependency changes significantly. It requires a PRD and your description of the affected work and dependencies. For standalone spec work without a PRD, update the spec with `bmad-spec` instead. Correct-course assesses the available planning documents and writes its proposal as `change-/change-.md` in the active initiative's folder, or in the output folder when none is active, with the edits and a ticketing handoff. It does not read or edit the ticket tree. Apply the approved changes through the owning skills, then use ticketing to revise the remaining breakdown. +Run `bmad-correct-course` when a requirement, architecture choice, or dependency changes significantly. It requires a PRD and your description of the affected work and dependencies. For standalone spec work without a PRD, update the spec with `bmad-spec` instead. Correct-course assesses the available planning documents and writes its proposal as `change-/change-.md` in the active initiative's folder, or in the output folder when none is active, with the edits and a `bmad-ticket` handoff. It does not read or edit the ticket tree. Apply the approved changes through the owning skills, then use `bmad-ticket` to revise the remaining breakdown. diff --git a/docs/plan/choose-a-planning-path.md b/docs/plan/choose-a-planning-path.md index 789c0283bf..4f63a49c78 100644 --- a/docs/plan/choose-a-planning-path.md +++ b/docs/plan/choose-a-planning-path.md @@ -30,7 +30,7 @@ says the input is too thin, you are not done on this chapter yet. - **Well-defined intent**: run `bmad-spec` with it. A spec that fits one Build session goes straight to `bmad-build`; an epic-sized one goes to - `bmad-preview-ticketing` for stories, then a Build per story. See + `bmad-ticket` for stories, then a Build per story. See [Define Requirements and a Specification](./define-requirements-and-a-specification.md). - **Anything else**: the intent is not ready yet. Use the pages below until it is, then run `bmad-spec`. The spec skill writes the contract; it does not @@ -83,15 +83,15 @@ is active. | `bmad-prfaq` | Stress-test a product concept customer-first, working backwards from the press release | `prfaq-.md` + a distillate | | `bmad-prd` | Create, update, or validate a PRD | Create/update: `prd-.md`, `addendum.md`, `.memlog.md`; validate: HTML + `.md` report | | `bmad-ux` | Record how the product looks and behaves ([Design UX and Architecture](./design-ux-and-architecture.md)) | `DESIGN.md`, `EXPERIENCE.md`, `ux-.md`, `.memlog.md` | -| `bmad-spec` | Condense any intent into a short contract; hand it to `bmad-preview-ticketing` for stories on request | `spec-.md` + companions | +| `bmad-spec` | Condense any intent into a short contract; hand it to `bmad-ticket` for stories on request | `spec-.md` + companions | | `bmad-architecture` | Make the technical decisions that keep separately built parts consistent | `architecture-.md` by default | -| `bmad-preview-ticketing` | [Plan and track entries](./break-work-into-stories-and-track-it.md) | Epic envelopes, ordered `tickets.toml`, and optional leaf files | +| `bmad-ticket` | [Plan and track entries](./break-work-into-stories-and-track-it.md) | Epic envelopes, ordered `tickets.toml`, and optional leaf files | `bmad-prd` has three intents, create, update, and validate; say which one you want when you invoke it, or it will ask. `bmad-product-brief` feeds `bmad-prd`, which reads the brief during discovery, but neither requires the other. -![Three columns of planning skills and the files each writes: analysis (brainstorming, forge idea, deep recon, product brief, PRFAQ), planning (PRD, UX, spec), and solutioning (architecture and ticketing), all handing off to bmad-build, one session per unit](/diagrams/planning-skills.svg) +![Three columns of planning skills and the files each writes: analysis (brainstorming, forge idea, deep recon, product brief, PRFAQ), planning (PRD, UX, spec), and solutioning (architecture and ticket), all handing off to bmad-build, one session per unit](/diagrams/planning-skills.svg) ## Size Follows the Intent @@ -120,7 +120,7 @@ coherent outcome. 1. Run `bmad-spec` with the epic intent. See [Define Requirements and a Specification](./define-requirements-and-a-specification.md) for what a spec contains and when it is enough on its own. -2. Run `bmad-preview-ticketing` with the spec folder. It plans the epic with +2. Run `bmad-ticket` with the spec folder. It plans the epic with you and records the stories in build order in the epic's `tickets.toml`. 3. Review the proposed order and decide which stories need a checkpoint. 4. Build each story from its entry when you are ready; no story file is @@ -141,7 +141,7 @@ before automating repetitions of them. Run Build once per story, naming the story. Build writes its plan beside the epic's `tickets.toml` and leaves the plan at `built` until you mark it done -through the ticketing skill. To run stories unattended instead, give +through `bmad-ticket`. To run stories unattended instead, give `bmad-build-auto` the story as its intent, one run per story; see [Autonomous Development Loops](../build/autonomous-development-loops.md). diff --git a/docs/plan/define-requirements-and-a-specification.md b/docs/plan/define-requirements-and-a-specification.md index 3fdb63385e..75a860653c 100644 --- a/docs/plan/define-requirements-and-a-specification.md +++ b/docs/plan/define-requirements-and-a-specification.md @@ -116,15 +116,15 @@ order and feed the same spec. After every run it reports assumptions it made and open questions it could not answer, for you to resolve. `bmad-spec` does not split a spec into stories. When a spec it writes reads as -several slices, it offers once to hand off to `bmad-preview-ticketing`. To -split a spec at any time, run `bmad-preview-ticketing` with the spec folder. +several slices, it offers once to hand off to `bmad-ticket`. To +split a spec at any time, run `bmad-ticket` with the spec folder. It plans one epic with you in build order and records the stories in the epic's `tickets.toml`. Each story cites the spec's capability IDs. A constraint or design decision that comes up while slicing goes back into the spec as an update. See [Choose a Planning Path](./choose-a-planning-path.md#1-start-epic-sized-work) for how the epic then runs. -`bmad-spec` delegates story breakdown to ticketing. To run +`bmad-spec` delegates story breakdown to `bmad-ticket`. To run the planned stories unattended, explicitly dispatch each ticket to [`bmad-build-auto`](../build/autonomous-development-loops.md) as `ticket `, one run per ticket. No leaf file needs to be pulled first. @@ -144,6 +144,6 @@ skill; see With a PRD in hand for multi-epic work, decide whether the work needs shared design decisions: [Design UX and Architecture](./design-ux-and-architecture.md). -With a spec in hand for one epic, run `bmad-preview-ticketing` with the spec +With a spec in hand for one epic, run `bmad-ticket` with the spec folder and go to [Break Work into Stories and Track It](./break-work-into-stories-and-track-it.md). diff --git a/docs/plan/plan-inside-an-organization.md b/docs/plan/plan-inside-an-organization.md index 548869df3b..e08a83832e 100644 --- a/docs/plan/plan-inside-an-organization.md +++ b/docs/plan/plan-inside-an-organization.md @@ -41,7 +41,7 @@ is derived from it: decisions that keep independently built epics compatible. - `bmad-spec` writes one spec per epic from the PRD, pointing at the spine and the UX documents rather than copying them. -- `bmad-preview-ticketing` turns the specs into ordered entries and tracks their joined plans. +- `bmad-ticket` turns the specs into ordered entries and tracks their joined plans. Nothing downstream reinterprets the PRD. If a spec needs an answer the PRD does not give, the answer goes into the PRD first; the spec is re-run after. @@ -67,7 +67,7 @@ Linear, and a review cadence, and all of it stays. skill reads the code and records the conventions already there rather than proposing new ones. - **Your tracker stays your tracker.** Jira remains where the organization - plans, reports, and reviews. Ticketing publishes leaf files when needed; build status lives in local joined plans. Tracker status is mirrored separately and never makes a build skip work. + plans, reports, and reviews. `bmad-ticket` publishes leaf files when needed; build status lives in local joined plans. Tracker status is mirrored separately and never makes a build skip work. - **Your reviews stay your reviews.** The five sign-off moments below are where the skills produce something reviewable. Put your existing approvals at those points and the documents the skills write become the material @@ -84,8 +84,8 @@ regenerated from it. | Product manager | Brainstorming, Forge Idea, Deep Recon, then `bmad-product-brief` or `bmad-prfaq`, then `bmad-prd` | The PRD and its update cycle; the one-pager the steering committee reads | | Designer | `bmad-ux` | `DESIGN.md`, `EXPERIENCE.md` | | Tech lead or architect | `bmad-architecture` | The architecture spine | -| One engineer, per epic | `bmad-spec`, `bmad-preview-ticketing`, Build per story, `bmad-retrospective` | That epic: its spec, its `tickets.toml`, its verdict | -| Whoever tracks the whole | `bmad-preview-ticketing` | The ticket tree and plan statuses | +| One engineer, per epic | `bmad-spec`, `bmad-ticket`, Build per story, `bmad-retrospective` | That epic: its spec, its `tickets.toml`, its verdict | +| Whoever tracks the whole | `bmad-ticket` | The ticket tree and plan statuses | The rows are roles, not headcount. One person can hold several; what matters is that each document has exactly one owner, because each has exactly one @@ -143,7 +143,7 @@ They will. The path for a change is the same as the path for the original: and keeps capability IDs stable, so stories that are unaffected stay unaffected. 4. For the affected epics, re-slice the stories `bmad-spec` names as no longer - matching, then revise the remaining breakdown with `bmad-preview-ticketing`. Keep historical plans and completed states. + matching, then revise the remaining breakdown with `bmad-ticket`. Keep historical plans and completed states. For a change large enough to threaten the plan itself, run `bmad-correct-course` before touching documents. diff --git a/docs/plan/help-test-v7-previews.md b/docs/plan/set-up-the-ticket-tree.md similarity index 85% rename from docs/plan/help-test-v7-previews.md rename to docs/plan/set-up-the-ticket-tree.md index 598333ea8a..b3ca5f6b8b 100644 --- a/docs/plan/help-test-v7-previews.md +++ b/docs/plan/set-up-the-ticket-tree.md @@ -1,21 +1,21 @@ --- title: 'Set Up the Ticket Tree' -description: Try proposed BMad v7 planning changes as they arrive — set up an initiative store, configure it, and use the ticketing preview skill. +description: Set up an initiative store, choose where tickets are tracked, and plan and track work with bmad-ticket. sidebar: order: 8 --- -Use `bmad-preview-ticketing` to plan and track work in the shared ticket tree. Build, Build Auto, code review, and retrospective consume that tree. The skill keeps its preview name while tracker integrations continue to mature. +`bmad-ticket` is how BMad plans and tracks work: it breaks work into epics and stories in the shared ticket tree. Build, Build Auto, code review, and retrospective consume that tree. ## Install the Skills -Preview skills install with the skills CLI. `npx bmad-method install`, with or without `@next`, does not install them. Run this in your project: +Install with the skills CLI. Run this in your project: ```bash -npx skills add bmad-code-org/BMAD-METHOD --skill bmad --skill bmod-core-tools --skill bmod-method --skill bmad-preview-ticketing +npx skills add bmad-code-org/BMAD-METHOD --skill bmad --skill bmod-core-tools --skill bmod-method --skill bmad-ticket ``` -Add `--skill bmad-build` and any other skill you want in the same command. Then open your AI tool in the project, ask the `bmad` skill to run `bmad setup`, and check that the tool lists `bmad-preview-ticketing`. Update later with `npx skills update`. +Add `--skill bmad-build` and any other skill you want in the same command. Then open your AI tool in the project, ask the `bmad` skill to run `bmad setup`, and check that the tool lists `bmad-ticket`. Update later with `npx skills update`. :::note[Prerequisites] You need Node.js with npm, Git, and [uv](https://docs.astral.sh/uv/). BMad setup and the ticketing scripts run through `uv`. @@ -73,7 +73,7 @@ Set the initiative you are working on in `_bmad/custom/config.user.toml`, which active_initiative = "initiative-checkout" ``` -The value is the initiative's folder name in the store. When it is unset, the ticketing skill offers to create the folder and record the setting for you. You can also ask the `bmad` skill to show, switch, create, or clear the active initiative at any time. +The value is the initiative's folder name in the store. When it is unset, `bmad-ticket` offers to create the folder and record the setting for you. You can also ask the `bmad` skill to show, switch, create, or clear the active initiative at any time. :::tip[One workspace, many projects] If one workspace holds unrelated projects, tell your coding agent to follow the active initiative. Put a short rule in `AGENTS.md`, or whatever instruction file your tool reads, that names the setting and says which folders belong to which initiative: @@ -109,7 +109,7 @@ UX is the exception to the naming: `bmad-ux` writes two peer documents, `DESIGN. ## Configure Where Tickets Are Tracked -The first time you use the ticketing skill, it asks where tickets are tracked and writes your choice to `_bmad/custom/ticketing-store-config.toml`. That file is yours to edit, and edits survive skill updates. +The first time you use `bmad-ticket`, it asks where tickets are tracked and writes your choice to `_bmad/custom/ticketing-store-config.toml`. That file is yours to edit, and edits survive skill updates. | Choice | What it means | | ------------- | ------------------------------------------------------------------------------------ | @@ -128,7 +128,7 @@ Repo is the default and the choice that has been tested most. The tracker option Hooks are not integrated yet, so nothing syncs on its own: a tracker and the ticket files are brought in line only when you run the skill. Hooks may be added later. ::: -## Use the Ticketing Skill +## Use `bmad-ticket` The skill turns intent into tickets a coding agent can build from, at three levels. An initiative holds epics. An epic holds stories, spikes, and bugs. An initiative or an epic is itself the specification at its level: it holds the requirements, and its children are cut from them. @@ -150,7 +150,7 @@ A story's `after` can name a story in another epic, or a whole epic. Ask "what's ### How epics are cut -An epic is one capability that one owner delivers to production. A module, service, or bounded context can be an epic when it is also the ownership or deployment boundary. A unit the work only consumes or configures gets no epic. It is a touch point, named in the initiative's Boundaries with the epic that owns the work there. If your team cuts epics by its own rule, tell the skill and it offers to save the rule to `_bmad/custom/bmad-preview-ticketing.toml`. +An epic is one capability that one owner delivers to production. A module, service, or bounded context can be an epic when it is also the ownership or deployment boundary. A unit the work only consumes or configures gets no epic. It is a touch point, named in the initiative's Boundaries with the epic that owns the work there. If your team cuts epics by its own rule, tell the skill and it offers to save the rule to `_bmad/custom/bmad-ticket.toml`. After the epics are agreed, the skill lists the decisions that more than one epic must adopt, such as a contract, a data format, or a shared value list. It offers `bmad-architecture` to settle them in the architecture spine. If you decline, each becomes a story in the opening epic that the other epics wait on. Work in one repo or one unit needs no architecture pass. It is needed from the second unit that must adopt a decision. @@ -161,11 +161,11 @@ When your source contradicts the code, the skill records a `Source conflict:` li Name the story to `bmad-build`, for example "build story 1.2" for the second story of the first epic. There is no file to write first. Build reads the story's entry and its epic, plus the story file when you refined one. It plans the story's acceptance criteria from the epic's Requirements and Done when, the entry's description, and its `Verify:` check. :::note[Refining is optional] -A story needs no refining before `bmad-build`. Build refines it as part of the build: it questions you and writes the acceptance criteria itself. If you will build unattended, with `bmad-build-auto`, a loop, or a factory, nobody answers questions during the build, so review the sequence and each story with the ticketing skill first. The ticketing skill writes full acceptance criteria only for a bug, a ticket with no epic, or when you ask. +A story needs no refining before `bmad-build`. Build refines it as part of the build: it questions you and writes the acceptance criteria itself. If you will build unattended, with `bmad-build-auto`, a loop, or a factory, nobody answers questions during the build, so review the sequence and each story with `bmad-ticket` first. `bmad-ticket` writes full acceptance criteria only for a bug, a ticket with no epic, or when you ask. ::: -The story's `status` lives in the build's plan. Build moves it as it works and stops at `built`; only you, or an orchestrator, mark a story done. When you have checked the work, say "mark story 1.2 done" to the ticketing skill. On the repo store that is an edit to the plan that you commit with your work. With a tracker, say "start story 1.2" before you build, so the ticket publishes if it has not and its card moves to in progress. The tracker's status is read into the story's file as `tracker_status`, so moving a card on the board never makes build skip planning. +The story's `status` lives in the build's plan. Build moves it as it works and stops at `built`; only you, or an orchestrator, mark a story done. When you have checked the work, say "mark story 1.2 done" to `bmad-ticket`. On the repo store that is an edit to the plan that you commit with your work. With a tracker, say "start story 1.2" before you build, so the ticket publishes if it has not and its card moves to in progress. The tracker's status is read into the story's file as `tracker_status`, so moving a card on the board never makes build skip planning. ## Tell Us What You Find -Feedback helps improve the ticketing integrations. The most useful reports say what you gave the skill, what you asked for, what it produced, and what you expected instead. Open a [GitHub issue](https://github.com/bmad-code-org/BMAD-METHOD/issues) with "v7 preview" in the title, or post in [Discord](https://discord.gg/gk8jAdXWmj). +Feedback helps improve `bmad-ticket` and its tracker integrations. The most useful reports say what you gave the skill, what you asked for, what it produced, and what you expected instead. Open a [GitHub issue](https://github.com/bmad-code-org/BMAD-METHOD/issues) with "bmad-ticket" in the title, or post in [Discord](https://discord.gg/gk8jAdXWmj). diff --git a/docs/reference/skills-and-agents.md b/docs/reference/skills-and-agents.md index a8fdf18000..fd53c3ed1d 100644 --- a/docs/reference/skills-and-agents.md +++ b/docs/reference/skills-and-agents.md @@ -157,10 +157,10 @@ The BMad Method module adds the five agents above and these workflow skills. The | `bmad-product-brief` | Create, update, or validate a product brief | [Define Requirements and a Specification](../plan/define-requirements-and-a-specification.md) | | `bmad-prfaq` | Stress-test a product concept with the Working Backwards PRFAQ method | [Define Requirements and a Specification](../plan/define-requirements-and-a-specification.md) | | `bmad-prd` | Create, update, or validate a PRD | [Define Requirements and a Specification](../plan/define-requirements-and-a-specification.md) | -| `bmad-spec` | Condense input into a short spec; hand story breakdown to `bmad-preview-ticketing` | [Define Requirements and a Specification](../plan/define-requirements-and-a-specification.md) | +| `bmad-spec` | Condense input into a short spec; hand story breakdown to `bmad-ticket` | [Define Requirements and a Specification](../plan/define-requirements-and-a-specification.md) | | `bmad-ux` | Capture the UX vision as `DESIGN.md` and `EXPERIENCE.md` | [Design UX and Architecture](../plan/design-ux-and-architecture.md) | | `bmad-architecture` | Record the architecture decisions that keep separately built parts consistent | [Design UX and Architecture](../plan/design-ux-and-architecture.md) | -| `bmad-preview-ticketing` | Plan and track initiatives, epics, and entries | [Break Work into Stories and Track It](../plan/break-work-into-stories-and-track-it.md) | +| `bmad-ticket` | Plan and track initiatives, epics, and entries | [Break Work into Stories and Track It](../plan/break-work-into-stories-and-track-it.md) | | `bmad-correct-course` | Assess a significant mid-sprint change and produce a change proposal | [Break Work into Stories and Track It](../plan/break-work-into-stories-and-track-it.md#correct-course) | | `bmad-project-context` | Set up, refresh, or audit the repository's agent instructions | [Set and Maintain Project Context](../existing-codebases/set-and-maintain-project-context.md) | | `bmad-build` | Turn a work item into working code, reviewed and verified | [Build a Change](../build/build-a-change.md) | diff --git a/docs/start/install-bmad.md b/docs/start/install-bmad.md index 0920a47bb2..8d6657487b 100644 --- a/docs/start/install-bmad.md +++ b/docs/start/install-bmad.md @@ -20,7 +20,7 @@ npx skills add bmad-code-org/BMAD-METHOD Select your coding tool and skills. Include `bmad` for setup and help, and the module records `bmod-core-tools` and `bmod-method` for the modules you use. To install a small set by name: ```bash -npx skills add bmad-code-org/BMAD-METHOD --skill bmad --skill bmod-core-tools --skill bmod-method --skill bmad-build --skill bmad-preview-ticketing +npx skills add bmad-code-org/BMAD-METHOD --skill bmad --skill bmod-core-tools --skill bmod-method --skill bmad-build --skill bmad-ticket ``` Add review, retrospective, or other skills as needed. Keep project and global installation scopes consistent. diff --git a/removals.txt b/removals.txt index f6bc28f53e..a7c988175e 100644 --- a/removals.txt +++ b/removals.txt @@ -87,6 +87,9 @@ bmad-agent-tech-writer # generating tracking. The IR agent menu trigger dispatches sprint-planning. bmad-check-implementation-readiness -# Removed planning route: replaced by bmad-preview-ticketing. +# Removed planning route: replaced by bmad-ticket. bmad-create-epics-and-stories bmad-sprint-planning + +# Renamed: bmad-preview-ticketing is now bmad-ticket. +bmad-preview-ticketing diff --git a/skills/bmad-agent-architect/bmod.toml b/skills/bmad-agent-architect/bmod.toml index ef33f5afc6..1b5f8942cc 100644 --- a/skills/bmad-agent-architect/bmod.toml +++ b/skills/bmad-agent-architect/bmod.toml @@ -3,5 +3,5 @@ bmod = "bmod-method" source = "github:bmad-code-org/BMAD-METHOD/skills" recommended_skills = [ "bmad-architecture", - "bmad-preview-ticketing", + "bmad-ticket", ] diff --git a/skills/bmad-agent-architect/customize.toml b/skills/bmad-agent-architect/customize.toml index eb3b6d7977..477147116f 100644 --- a/skills/bmad-agent-architect/customize.toml +++ b/skills/bmad-agent-architect/customize.toml @@ -60,4 +60,4 @@ skill = "bmad-architecture" [[agent.menu]] code = "TK" description = "Plan work and dependencies through the ticket tree" -skill = "bmad-preview-ticketing" +skill = "bmad-ticket" diff --git a/skills/bmad-agent-dev/bmod.toml b/skills/bmad-agent-dev/bmod.toml index 461e54011b..01adf02fe4 100644 --- a/skills/bmad-agent-dev/bmod.toml +++ b/skills/bmad-agent-dev/bmod.toml @@ -6,5 +6,5 @@ recommended_skills = [ "bmad-code-review", "bmad-qa-generate-e2e-tests", "bmad-retrospective", - "bmad-preview-ticketing", + "bmad-ticket", ] diff --git a/skills/bmad-agent-dev/customize.toml b/skills/bmad-agent-dev/customize.toml index 1189e45593..b087752672 100644 --- a/skills/bmad-agent-dev/customize.toml +++ b/skills/bmad-agent-dev/customize.toml @@ -78,4 +78,4 @@ skill = "bmad-retrospective" [[agent.menu]] code = "TK" description = "Plan and track work through the ticket tree" -skill = "bmad-preview-ticketing" +skill = "bmad-ticket" diff --git a/skills/bmad-agent-pm/bmod.toml b/skills/bmad-agent-pm/bmod.toml index cb1ba9547b..ad3b392fad 100644 --- a/skills/bmad-agent-pm/bmod.toml +++ b/skills/bmad-agent-pm/bmod.toml @@ -3,6 +3,6 @@ bmod = "bmod-method" source = "github:bmad-code-org/BMAD-METHOD/skills" recommended_skills = [ "bmad-correct-course", - "bmad-preview-ticketing", + "bmad-ticket", "bmad-prd", ] diff --git a/skills/bmad-agent-pm/customize.toml b/skills/bmad-agent-pm/customize.toml index 17b295318f..fe817b6424 100644 --- a/skills/bmad-agent-pm/customize.toml +++ b/skills/bmad-agent-pm/customize.toml @@ -65,4 +65,4 @@ skill = "bmad-correct-course" [[agent.menu]] code = "TK" description = "Slice initiatives, plan epics, and manage tickets" -skill = "bmad-preview-ticketing" +skill = "bmad-ticket" diff --git a/skills/bmad-architecture/SKILL.md b/skills/bmad-architecture/SKILL.md index d946239ecf..5cdb3d5116 100644 --- a/skills/bmad-architecture/SKILL.md +++ b/skills/bmad-architecture/SKILL.md @@ -58,7 +58,7 @@ Writes go through the shared script (don't read the file back except on resume): 2. Resolve config: `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key modules.bmm.active_initiative`. `{date}` is the current system datetime. `{slug}` is what the architecture is about, in kebab-case: the run lands in `architecture-{slug}/architecture-{slug}.md`. - Script not found, or no `output_folder`: BMad is not set up here. Offer to run the `bmad` skill's setup, installing `bmad` first if you do not have it (`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`), then run the command again. - No `active_initiative`: hand off to the `bmad` skill to set or create one, then run the command again and continue. Headless: write loose. -3. Headless (no interactive user) → follow `references/headless.md` for the whole run. Otherwise greet the user. Detect the intent from the conversation and input — **create** (the default), **update** an existing spine, or **validate** one (see those sections). If the real ask is requirements / UX / a capability contract / epic breakdown / an agent, invoke the `bmad-prd`, `bmad-ux`, `bmad-spec`, `bmad-preview-ticketing`, or `bmad-workflow-builder` (if the BMad Builder module is installed) skill instead. +3. Headless (no interactive user) → follow `references/headless.md` for the whole run. Otherwise greet the user. Detect the intent from the conversation and input — **create** (the default), **update** an existing spine, or **validate** one (see those sections). If the real ask is requirements / UX / a capability contract / epic breakdown / an agent, invoke the `bmad-prd`, `bmad-ux`, `bmad-spec`, `bmad-ticket`, or `bmad-workflow-builder` (if the BMad Builder module is installed) skill instead. 4. If a run folder for this target already exists under `{workflow.spine_output_path}`, offer to resume from its memlog rather than restart. 5. Interactive create: offer the working mode — **Coaching path** (default) or **Fast path** (see *How you work*) — before any drafting; default to Coaching unless the user asks for speed. 6. **Mandatory, both paths, before drafting:** ask whether the spine is the only deliverable — and if not, draw out the *purpose and audience* rather than a document type. "An architecture doc" balloons into bloat; what they actually need might be a one-detail explainer for a single team or a non-technical vision piece for a board. Purpose right-sizes the artifact and may call for extra elicitation up front, not just a finale add-on. @@ -79,7 +79,7 @@ Walk the sequence; reviewer fixes land before polish. 4. **Triage.** Open questions and `[ASSUMPTION]` tags: blockers (unsafe for what's next) resolved one at a time; the rest deferred with a revisit condition in the memlog. 5. **Renderings & polish.** The spine is the build deliverable; with it and the memlog now in place, produce any *additional* human-facing artifact the user needs, scoped to the purpose and audience drawn out up front. The up-front question already flagged whether one's needed; if it wasn't, still offer one here, seeding concrete options: an interactive HTML+SVG deck to walk a team through the architecture and drive discussion, a fuller HTML/md solution design, a C4 set, or a view of how the work splits across teams/epics. Build only what they pick, right-sized to that purpose; apply `{workflow.doc_standards}` polish to that prose only, never to the spine. 6. **External handoffs.** Run `{workflow.external_handoffs}`; surface returned URLs/IDs. Offer to invoke the `bmad-spec` skill to adopt the spine as a companion, keeping `AD` IDs stable so downstream can cite them. -7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `bmad-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `bmad-preview-ticketing` or — epic altitude — `bmad-build`; or invoke the `bmad` skill to route. +7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `bmad-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `bmad-ticket` or — epic altitude — `bmad-build`; or invoke the `bmad` skill to route. 8. Run `{workflow.on_complete}`. ## Update diff --git a/skills/bmad-correct-course/SKILL.md b/skills/bmad-correct-course/SKILL.md index d44848fe75..97ba785e93 100644 --- a/skills/bmad-correct-course/SKILL.md +++ b/skills/bmad-correct-course/SKILL.md @@ -226,7 +226,7 @@ Look in `{output_folder}/{active_initiative}/` first, then `{output_folder}/`. - Minor: Direct implementation by Developer agent - Moderate: Backlog reorganization needed (PO/DEV) - Major: Fundamental replan required (PM/Architect) -- List the epic and story changes (added, removed, resequenced, or rescoped) for the user to apply with the ticketing skill +- List the epic and story changes (added, removed, resequenced, or rescoped) for the user to apply with `bmad-ticket` - Specify handoff recipients and their responsibilities - Define success criteria for implementation diff --git a/skills/bmad-prd/SKILL.md b/skills/bmad-prd/SKILL.md index 2c05654c52..49b4184328 100644 --- a/skills/bmad-prd/SKILL.md +++ b/skills/bmad-prd/SKILL.md @@ -94,5 +94,5 @@ Tell the user the sequence in one sentence, then walk it. Polish goes last so it 4. **Triage open items.** All Open Questions, `[ASSUMPTION]` tags, `[NOTE FOR PM]` callouts. Phase-blockers (would make the PRD unsafe for UX/architecture/epics) surfaced one at a time and resolved; non-blockers deferred with owner + revisit condition logged via `memlog.py append`. If phase-blocker count is high, flag it. 5. **Polish.** Apply `{workflow.doc_standards}` to the PRD and `addendum.md` in declared order (structural passes before prose — prose should not polish soon-to-be-cut text). Parallelize across documents, sequential within. 6. **External handoffs.** Execute `{workflow.external_handoffs}`; surface returned URLs/IDs. Skip and flag unavailable tools. -7. **Close.** Set the PRD's frontmatter `status: final` and `updated` to `{date}` so future invocations distinguish this PRD from in-progress drafts. Record finalization via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type event --text "PRD finalized"`. Share artifact paths. Common next: `bmad-ux`, `bmad-architecture`, `bmad-preview-ticketing`; invoke the `bmad` skill for authoritative routing. +7. **Close.** Set the PRD's frontmatter `status: final` and `updated` to `{date}` so future invocations distinguish this PRD from in-progress drafts. Record finalization via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type event --text "PRD finalized"`. Share artifact paths. Common next: `bmad-ux`, `bmad-architecture`, `bmad-ticket`; invoke the `bmad` skill for authoritative routing. 8. Run `{workflow.on_complete}` if non-empty. diff --git a/skills/bmad-preview-ticketing/SKILL.md b/skills/bmad-preview-ticketing/SKILL.md index b893833b1b..0d7aab2414 100644 --- a/skills/bmad-preview-ticketing/SKILL.md +++ b/skills/bmad-preview-ticketing/SKILL.md @@ -1,100 +1,18 @@ --- name: bmad-preview-ticketing -description: Create and manage tickets at every level — slice an initiative into epics, break an epic into stories, write or refine a ticket, and run the board (publish, ready, move, assign, status, cancel). Use when the user says "Create a new initiative", "slice this", "split this up", "break this into stories", "incept this epic", "make a ticket", "refine this ticket", "what's ready", "status of a story", "publish ticket changes". +description: 'Renamed to bmad-ticket. Use only when the user invokes bmad-preview-ticketing by name; it tells them about the rename and hands the request to bmad-ticket.' --- -# BMad Ticket +# Renamed: bmad-preview-ticketing is now bmad-ticket -## What you are here to do +This skill tells existing installs about the rename and is removed with the v7 release. It does no ticketing itself. -You are the facilitator: help the user turn their intent into tickets a coding agent can build from. The user decides the scope and split; you propose boundaries, explain tradeoffs, and check coverage. Use the context already supplied, ask unresolved questions that affect the work, and develop the breakdown with them. When they delegate the thinking, investigate and self-review before presenting the result; keep assumptions and open questions visible. +1. Tell the user: "`bmad-preview-ticketing` is now `bmad-ticket`. It is no longer a preview. This forwarding copy is removed with the v7 release." +2. If `{project-root}/_bmad/custom/bmad-preview-ticketing.toml` or `bmad-preview-ticketing.user.toml` exists, say that `bmad-ticket` no longer reads it, and offer to rename it to `bmad-ticket.toml` or `bmad-ticket.user.toml`. If the new file already exists, show both and let the user merge them. +3. If `bmad-ticket` is not installed, give the user this command to run, then stop: -At every altitude above the leaf the ideal shape is: intent (an idea, brief, PRD, intent.md) gets a container ticket, and that container is the spec at its altitude — its Requirements hold the source's lines as stable ids, informed by what else exists (an architecture spine, UX design, research), and its children are cut from them. So at any container: create its envelope if it is missing, then complete it from the source. + ```bash + npx skills add bmad-code-org/BMAD-METHOD --skill bmad-ticket + ``` -## Terms - -- Container: an initiative or an epic — holds other tickets -- Leaf: a story, spike, or bug handed to an agent to implement. Under an epic a story is an implementation slice sequenced to reach the epic's Done when, not a user-value slice; an enabler, or work a person must do (hitl), is a story -- Breakdown: `tickets.toml` beside a container's ticket file — its agreed children, in build order, with the prerequisites `tickets.py` reads -- Entry: one planned leaf in a breakdown, with a stable `id`: description, requirement references, prerequisites (`after`), verification approach, and known uncertainty. It needs no file to be built: the build reads the entry and its epic. With no file and no plan its state is `planned` -- Pull: write an entry's leaf file with `tickets.py pull`, the first step of refining it or of publishing it to a tracker; from then on the file is truth. Starting a ticket needs no pull -- Refine: for an epic's stories, pull the file when the entry has none, then review it with the user: description, `Verify:`, references, notes, order, prerequisites. Given/When/Then is written here only for a bug, a ticket with no epic, an entry with `refine = true`, or on request; otherwise the builder plans story criteria from the epic's requirements, the entry's description, and its `Verify:` check -- Opening epic: the first `[[epic]]` in the initiative's breakdown -- Inception: plan the whole selected epic with the user and record it in the epic's breakdown -- hitl: boolean frontmatter field on a leaf; at least part needs a person -- store: the ticketing system of record — git-backed, a tracker, or both -- State: `planned`, `backlog`, `in-progress`, `review`, `done`, or `dropped` — what the board groups by and what a tracker sees; derived from a ticket's status fields as described under The ticket tree - -## On activation - -1. Resolve config: `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key modules.bmm.active_initiative`. - - Script not found: BMad is not set up here. Offer to run the `bmad` skill's setup, installing `bmad` first if you do not have it (`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`), then run the command again. - - Tickets are drafted under `{output_folder}/{active_initiative}/` — an initiative folder, or a backlog folder scoped however the user wants. Unset: offer to create the initiative folder, or a backlog folder, and record it as `active_initiative` under `[modules.bmm]` in `_bmad/custom/config.user.toml`. -2. Read the store config: `uv run {skill-root}/scripts/read_toml.py --file {project-root}/_bmad/custom/ticketing-store-config.toml -k tickets` — store guidance, access, and the type and status maps. Substitute `{output_folder}` in every value. Missing or unreadable: follow `{skill-root}/references/store-setup.md` instead of continuing. -3. Resolve `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} -k workflow.activation_steps_prepend -k workflow.activation_steps_append -k workflow.persistent_facts -k workflow.on_complete`. -4. Run `{workflow.activation_steps_prepend}`; treat `{workflow.persistent_facts}` (set with `bmad-customize`) as foundational context for the session — entries prefixed `file:` are paths or globs under `{project-root}` to load, the rest are facts verbatim — together with whatever is already in your context — registered MCP servers and CLIs, and anything injected from AGENTS.md, CLAUDE.md, or the like. Use what is known; do not ask for it again. -5. Run `{workflow.activation_steps_append}`. When the requested operation ends, run `{workflow.on_complete}`. - -## Intake - -Before routing, size the ask from what the user said and what is in context, and say which path you are taking and why; the user overrides, and an override is a `Decision:` line. Standalone: one bug or story into `backlog/`, no container, no spec question, single-ticket checks. Small epic: an epic envelope under the initiative, the spec question asked once and easy to decline, two to six entries, no learn-the-codebase subagents; the check on the draft in `validate.md` still runs. Full inception: the epic path in `slice.md`. Initiative: authored and split into epics per `slice.md`. A spec folder handed over by `bmad-spec` is the epic's requirement source: `covers` cites its `CAP-N` ids and the spec question is already answered. - -## Routing - -| The user wants | Read | -|---|---| -| an initiative started or authored, split into epics; an epic incepted into stories, re-sliced; an entry pulled to refine it | `{skill-root}/references/slice.md` | -| one ticket written or refined | `{skill-root}/references/ticket.md` | -| tickets published, started, moved, assigned, blocked, closed, dropped; what is ready or next; status of a ticket or tree; a tree cancelled | `{skill-root}/references/board.md` | -| a ticket, a set, or a tree validated | `{skill-root}/references/validate.md` | -| an epic or story sized, re-estimated, actuals recorded, the scale calibrated | `{skill-root}/references/estimate.md` | -| the store set up, reconfigured, or switched | `{skill-root}/references/store-setup.md` | -| the rules every skill that uses the tree follows: finding it, the plan file, who writes each status, the baseline, where review and retrospective write | `{skill-root}/references/tree-rules.md` | - -Save agreed work into the ticket tree. Future epics stay as envelopes until selected for inception. - -### Autonomous mode - -When the user asks you to do the thinking without the conversation, the same guidance, self-review, and subagents apply. Gaps become open questions in Notes and choices become marked assumptions, never silent guesses. The check on a draft in `validate.md` always runs. Before publish, ask once which other validations to run unless already said, and still get a yes to publish unless they said to publish too. - -## Loaded on demand - -Load each of the following when a step names it; resolve keys by script rather than opening `customize.toml`. Templates are opened directly. - -**Customization** — `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} -k workflow.` (repeat `-k`): - -| Key | Holds | -|---|---| -| `slice_to_epics` | how to propose epic boundaries | -| `container_definition` | what a container says at its altitude, and what waits for inception | -| `slice_to_tickets` | how to slice an epic into session-sized implementation steps | -| `ordering` | which tickets open and close a parent | -| `acceptance_criteria` | how acceptance criteria are written | -| `scoring` | the risk and severity scales | -| `estimation` | on/off, the point scale, rubric, and t-shirt map | -| `prose` | how ticket prose reads | -| `checks` | the validation checks, one array per scope: `checks.ticket`, `.set`, `.tree`, `.dependencies` (missing prerequisites), `.closure` | -| `refinement` | what refining means, and where full acceptance criteria are written | -| `publication` | when tickets publish to a tracker: as each starts, or the whole breakdown at inception (the default) | -| `initiative_template`, `epic_template`, `story_template`, `spike_template`, `bug_template` | the template file per type | - -**Store operations** — `uv run {skill-root}/scripts/read_toml.py --file {project-root}/_bmad/custom/ticketing-store-config.toml -k verbs.` (repeat `-k`), then follow the verb as written: - -| Verb | For | -|---|---| -| `setup` | connect the tool; create what the maps name | -| `write` | create or change a ticket — body, state, assignee, parent, blocking, fields | -| `query` | one ticket, a container's children, a search, what is ready | - -How a ticket cites a document is the `reference` global, read at activation. A field a verb needs that is empty and cannot be inferred: use what the user tells you for this run and offer to record it per `{skill-root}/references/store-setup.md`. - -## The ticket tree - -Tickets live under `{output_folder}`, beside the documents. A container is a markdown file; a leaf with a parent is an entry in the parent's `tickets.toml`, with a file once refined; a backlog leaf is a file. A leaf is built from its entry and its epic, plus its file when there is one. By default the tree is the store (git-backed, the repo starter). A tracker, when configured, is a remote: `write` pushes a ticket to it, `query` reads it back, and a ticket the tracker knows but the tree does not gets its file at first `query`. - -A container is a folder `-/` holding its same-named ticket file, its `tickets.toml`, its spec, and its children. A leaf's file is `-.md` in its parent's folder, written when its entry is pulled to refine it or published to a tracker, or in `backlog/` with no parent. Its frontmatter `id` is its entry's `id`, an integer assigned once and never reused, and the only name it has on the repo store: `3` inside its epic, `2.3` from another epic (the epic's `id` is in the initiative's `tickets.toml`). No file or folder name carries a number; a title change renames the file. A tracker adds `tracker_id` and `remote` at publish. The order of tables in `tickets.toml` is the build order; `id` is not. When an initiative has epics, every leaf is under one. A new ticket starts from its type's template. The build's plan is a separate file beside the leaf's, described below; ticketing writes it only through `tickets.py mark` on the repo store, and it is never sent to a tracker. Other skills' artifacts sit beside the ticket, named after it. Once a leaf file exists it is truth: the entry keeps `id`, `type`, `title`, `after`, and `hitl` current (a changed `after` is written to both), and its other fields are not maintained after pull. A ticket the user names — `1.2`, a tracker id, a file name, words from a title — resolves to one ticket through `tickets.py find `, which returns its row, its entry's text fields, and the paths `epic_file`, `story_file`, and `plan`. - -A leaf's `status`, `assignee`, `blocked_at`, and `blocked_reason` live in its plan, `--plan.md` beside where its file is or would be, joined by the plan's `ticket` field; a leaf file's own `status` is read only when there is no plan, and a leaf with neither has had no build started. bmad-build and bmad-build-auto write `draft`, `ready-for-dev`, `in-progress`, `in-review`, and `built` as they work, and bmad-build-auto writes `blocked` when it halts. `done` is the user's, or an orchestrator's, through `tickets.py mark`; ticketing writes `dropped` when the user says so, and runs `mark` for the user when they say a ticket is done or that they are working it by hand. No skill moves a ticket past `built`, which means the build finished and nobody has called it done. `tree-rules.md` holds the full table. `tracker_status` exists only on a tracker store: the BMad word for the tracker's current status (`backlog`, `in-progress`, `review`, `done`, `dropped`), written by `query` next to `tracker_id` and `remote`, never sent. A ticket's state, which `next` and `status` group by and which `write` sends to a tracker as `[tickets.status].`, is `planned` for an entry with no file and no plan; else `tracker_status` when present; else from `status`: none, `draft`, or `ready-for-dev` is `backlog`; `in-progress` or `blocked` is `in-progress`; `in-review` or `built` is `review`; `done` and `dropped` are themselves. A tracker's status must never drive build routing (a card moved to In Progress on the board still gets planned), and the build's own steps never need to reach the tracker. A container's `status` is ticketing's: absent until work under it starts, then `in-progress`, `done`, or `dropped`. - -Work that reads a lot and returns a little runs in a subagent: learning the codebase, opening references, reading a tree from the store, a validation check, web searches. If the harness blocks subagents, say so and continue inline. +4. Otherwise, invoke `bmad-ticket` with the user's original request, verbatim. Once `bmad-ticket` is working, the user can remove this copy with `npx skills remove bmad-preview-ticketing`. diff --git a/skills/bmad-preview-ticketing/bmod.toml b/skills/bmad-preview-ticketing/bmod.toml index 759dc9e60c..4c27cb0f81 100644 --- a/skills/bmad-preview-ticketing/bmod.toml +++ b/skills/bmad-preview-ticketing/bmod.toml @@ -1,4 +1,3 @@ [skill] bmod = "bmod-method" source = "github:bmad-code-org/BMAD-METHOD/skills" -scripts = ["scripts/tickets.py"] diff --git a/skills/bmad-retrospective/workflow.md b/skills/bmad-retrospective/workflow.md index 05230e0b49..3853dbf14f 100644 --- a/skills/bmad-retrospective/workflow.md +++ b/skills/bmad-retrospective/workflow.md @@ -98,4 +98,4 @@ Skip by default; never runs headless. When the user asks to "discuss it as a tea ### Phase 5 — Finalize -Finalize the retrospective document and stop. Read fully and follow `{{ rendered("references/retro-document.md") }}` for the document's location, frontmatter, and sections, and the terminal instruction that ends the run. The document is the run's only write: no status change, no `tickets.py mark`, and no edit to the epic file, any plan, or any story file. Closing the epic is the ticketing skill's, confirmed by the user. +Finalize the retrospective document and stop. Read fully and follow `{{ rendered("references/retro-document.md") }}` for the document's location, frontmatter, and sections, and the terminal instruction that ends the run. The document is the run's only write: no status change, no `tickets.py mark`, and no edit to the epic file, any plan, or any story file. Closing the epic is `bmad-ticket`'s, confirmed by the user. diff --git a/skills/bmad-spec/SKILL.md b/skills/bmad-spec/SKILL.md index 02bdc19827..7ace822b56 100644 --- a/skills/bmad-spec/SKILL.md +++ b/skills/bmad-spec/SKILL.md @@ -130,13 +130,13 @@ Record the verdict for each pass to `.memlog.md` (`append --type event`). In int When the user points the skill at an existing spec folder (or its spec-{slug}.md) with no change signal, offer to review assumptions or open questions, or determine what they want to do. -## Handing off to ticketing (optional, interactive-only) +## Handing off to `bmad-ticket` (optional, interactive-only) Requires `spec-{slug}.md` on disk — run the normal Operation first if it doesn't exist yet. Headless runs never do this, even when the invocation text asks for it: if mode detection (On Activation, step 4) resolved headless, skip this section entirely and proceed with the normal headless response. In interactive mode, offer the handoff at most once per run when the input reads as multiple independently shippable slices; a decline ends the offer for this run, not forever. -Hand the spec folder to `bmad-preview-ticketing` as the requirement source: it plans the work with the user as an epic whose `tickets.toml` entries cite this spec's `CAP-N` ids, and it runs the board from there. Load-bearing detail the slicing conversation surfaces (a constraint, a design decision) comes back here as a spec update, never into a ticket alone. +Hand the spec folder to `bmad-ticket` as the requirement source: it plans the work with the user as an epic whose `tickets.toml` entries cite this spec's `CAP-N` ids, and it runs the board from there. Load-bearing detail the slicing conversation surfaces (a constraint, a design decision) comes back here as a spec update, never into a ticket alone. -When a spec update runs, search the ticket root for this spec folder's path in References; where tickets cite it, name the entries and tickets whose description no longer matches and offer to re-slice them with `bmad-preview-ticketing`. The update itself never edits a ticket. +When a spec update runs, search the ticket root for this spec folder's path in References; where tickets cite it, name the entries and tickets whose description no longer matches and offer to re-slice them with `bmad-ticket`. The update itself never edits a ticket. ## Output diff --git a/skills/bmad-ticket/SKILL.md b/skills/bmad-ticket/SKILL.md new file mode 100644 index 0000000000..9655c345b0 --- /dev/null +++ b/skills/bmad-ticket/SKILL.md @@ -0,0 +1,100 @@ +--- +name: bmad-ticket +description: Create and manage tickets at every level — slice an initiative into epics, break an epic into stories, write or refine a ticket, and run the board (publish, ready, move, assign, status, cancel). Use when the user says "Create a new initiative", "slice this", "split this up", "break this into stories", "incept this epic", "make a ticket", "refine this ticket", "what's ready", "status of a story", "publish ticket changes". +--- + +# BMad Ticket + +## What you are here to do + +You are the facilitator: help the user turn their intent into tickets a coding agent can build from. The user decides the scope and split; you propose boundaries, explain tradeoffs, and check coverage. Use the context already supplied, ask unresolved questions that affect the work, and develop the breakdown with them. When they delegate the thinking, investigate and self-review before presenting the result; keep assumptions and open questions visible. + +At every altitude above the leaf the ideal shape is: intent (an idea, brief, PRD, intent.md) gets a container ticket, and that container is the spec at its altitude — its Requirements hold the source's lines as stable ids, informed by what else exists (an architecture spine, UX design, research), and its children are cut from them. So at any container: create its envelope if it is missing, then complete it from the source. + +## Terms + +- Container: an initiative or an epic — holds other tickets +- Leaf: a story, spike, or bug handed to an agent to implement. Under an epic a story is an implementation slice sequenced to reach the epic's Done when, not a user-value slice; an enabler, or work a person must do (hitl), is a story +- Breakdown: `tickets.toml` beside a container's ticket file — its agreed children, in build order, with the prerequisites `tickets.py` reads +- Entry: one planned leaf in a breakdown, with a stable `id`: description, requirement references, prerequisites (`after`), verification approach, and known uncertainty. It needs no file to be built: the build reads the entry and its epic. With no file and no plan its state is `planned` +- Pull: write an entry's leaf file with `tickets.py pull`, the first step of refining it or of publishing it to a tracker; from then on the file is truth. Starting a ticket needs no pull +- Refine: for an epic's stories, pull the file when the entry has none, then review it with the user: description, `Verify:`, references, notes, order, prerequisites. Given/When/Then is written here only for a bug, a ticket with no epic, an entry with `refine = true`, or on request; otherwise the builder plans story criteria from the epic's requirements, the entry's description, and its `Verify:` check +- Opening epic: the first `[[epic]]` in the initiative's breakdown +- Inception: plan the whole selected epic with the user and record it in the epic's breakdown +- hitl: boolean frontmatter field on a leaf; at least part needs a person +- store: the ticketing system of record — git-backed, a tracker, or both +- State: `planned`, `backlog`, `in-progress`, `review`, `done`, or `dropped` — what the board groups by and what a tracker sees; derived from a ticket's status fields as described under The ticket tree + +## On activation + +1. Resolve config: `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key modules.bmm.active_initiative`. + - Script not found: BMad is not set up here. Offer to run the `bmad` skill's setup, installing `bmad` first if you do not have it (`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`), then run the command again. + + Tickets are drafted under `{output_folder}/{active_initiative}/` — an initiative folder, or a backlog folder scoped however the user wants. Unset: offer to create the initiative folder, or a backlog folder, and record it as `active_initiative` under `[modules.bmm]` in `_bmad/custom/config.user.toml`. +2. Read the store config: `uv run {skill-root}/scripts/read_toml.py --file {project-root}/_bmad/custom/ticketing-store-config.toml -k tickets` — store guidance, access, and the type and status maps. Substitute `{output_folder}` in every value. Missing or unreadable: follow `{skill-root}/references/store-setup.md` instead of continuing. +3. Resolve `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} -k workflow.activation_steps_prepend -k workflow.activation_steps_append -k workflow.persistent_facts -k workflow.on_complete`. +4. Run `{workflow.activation_steps_prepend}`; treat `{workflow.persistent_facts}` (set with `bmad-customize`) as foundational context for the session — entries prefixed `file:` are paths or globs under `{project-root}` to load, the rest are facts verbatim — together with whatever is already in your context — registered MCP servers and CLIs, and anything injected from AGENTS.md, CLAUDE.md, or the like. Use what is known; do not ask for it again. +5. Run `{workflow.activation_steps_append}`. When the requested operation ends, run `{workflow.on_complete}`. + +## Intake + +Before routing, size the ask from what the user said and what is in context, and say which path you are taking and why; the user overrides, and an override is a `Decision:` line. Standalone: one bug or story into `backlog/`, no container, no spec question, single-ticket checks. Small epic: an epic envelope under the initiative, the spec question asked once and easy to decline, two to six entries, no learn-the-codebase subagents; the check on the draft in `validate.md` still runs. Full inception: the epic path in `slice.md`. Initiative: authored and split into epics per `slice.md`. A spec folder handed over by `bmad-spec` is the epic's requirement source: `covers` cites its `CAP-N` ids and the spec question is already answered. + +## Routing + +| The user wants | Read | +|---|---| +| an initiative started or authored, split into epics; an epic incepted into stories, re-sliced; an entry pulled to refine it | `{skill-root}/references/slice.md` | +| one ticket written or refined | `{skill-root}/references/ticket.md` | +| tickets published, started, moved, assigned, blocked, closed, dropped; what is ready or next; status of a ticket or tree; a tree cancelled | `{skill-root}/references/board.md` | +| a ticket, a set, or a tree validated | `{skill-root}/references/validate.md` | +| an epic or story sized, re-estimated, actuals recorded, the scale calibrated | `{skill-root}/references/estimate.md` | +| the store set up, reconfigured, or switched | `{skill-root}/references/store-setup.md` | +| the rules every skill that uses the tree follows: finding it, the plan file, who writes each status, the baseline, where review and retrospective write | `{skill-root}/references/tree-rules.md` | + +Save agreed work into the ticket tree. Future epics stay as envelopes until selected for inception. + +### Autonomous mode + +When the user asks you to do the thinking without the conversation, the same guidance, self-review, and subagents apply. Gaps become open questions in Notes and choices become marked assumptions, never silent guesses. The check on a draft in `validate.md` always runs. Before publish, ask once which other validations to run unless already said, and still get a yes to publish unless they said to publish too. + +## Loaded on demand + +Load each of the following when a step names it; resolve keys by script rather than opening `customize.toml`. Templates are opened directly. + +**Customization** — `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} -k workflow.` (repeat `-k`): + +| Key | Holds | +|---|---| +| `slice_to_epics` | how to propose epic boundaries | +| `container_definition` | what a container says at its altitude, and what waits for inception | +| `slice_to_tickets` | how to slice an epic into session-sized implementation steps | +| `ordering` | which tickets open and close a parent | +| `acceptance_criteria` | how acceptance criteria are written | +| `scoring` | the risk and severity scales | +| `estimation` | on/off, the point scale, rubric, and t-shirt map | +| `prose` | how ticket prose reads | +| `checks` | the validation checks, one array per scope: `checks.ticket`, `.set`, `.tree`, `.dependencies` (missing prerequisites), `.closure` | +| `refinement` | what refining means, and where full acceptance criteria are written | +| `publication` | when tickets publish to a tracker: as each starts, or the whole breakdown at inception (the default) | +| `initiative_template`, `epic_template`, `story_template`, `spike_template`, `bug_template` | the template file per type | + +**Store operations** — `uv run {skill-root}/scripts/read_toml.py --file {project-root}/_bmad/custom/ticketing-store-config.toml -k verbs.` (repeat `-k`), then follow the verb as written: + +| Verb | For | +|---|---| +| `setup` | connect the tool; create what the maps name | +| `write` | create or change a ticket — body, state, assignee, parent, blocking, fields | +| `query` | one ticket, a container's children, a search, what is ready | + +How a ticket cites a document is the `reference` global, read at activation. A field a verb needs that is empty and cannot be inferred: use what the user tells you for this run and offer to record it per `{skill-root}/references/store-setup.md`. + +## The ticket tree + +Tickets live under `{output_folder}`, beside the documents. A container is a markdown file; a leaf with a parent is an entry in the parent's `tickets.toml`, with a file once refined; a backlog leaf is a file. A leaf is built from its entry and its epic, plus its file when there is one. By default the tree is the store (git-backed, the repo starter). A tracker, when configured, is a remote: `write` pushes a ticket to it, `query` reads it back, and a ticket the tracker knows but the tree does not gets its file at first `query`. + +A container is a folder `-/` holding its same-named ticket file, its `tickets.toml`, its spec, and its children. A leaf's file is `-.md` in its parent's folder, written when its entry is pulled to refine it or published to a tracker, or in `backlog/` with no parent. Its frontmatter `id` is its entry's `id`, an integer assigned once and never reused, and the only name it has on the repo store: `3` inside its epic, `2.3` from another epic (the epic's `id` is in the initiative's `tickets.toml`). No file or folder name carries a number; a title change renames the file. A tracker adds `tracker_id` and `remote` at publish. The order of tables in `tickets.toml` is the build order; `id` is not. When an initiative has epics, every leaf is under one. A new ticket starts from its type's template. The build's plan is a separate file beside the leaf's, described below; `bmad-ticket` writes it only through `tickets.py mark` on the repo store, and it is never sent to a tracker. Other skills' artifacts sit beside the ticket, named after it. Once a leaf file exists it is truth: the entry keeps `id`, `type`, `title`, `after`, and `hitl` current (a changed `after` is written to both), and its other fields are not maintained after pull. A ticket the user names — `1.2`, a tracker id, a file name, words from a title — resolves to one ticket through `tickets.py find `, which returns its row, its entry's text fields, and the paths `epic_file`, `story_file`, and `plan`. + +A leaf's `status`, `assignee`, `blocked_at`, and `blocked_reason` live in its plan, `--plan.md` beside where its file is or would be, joined by the plan's `ticket` field; a leaf file's own `status` is read only when there is no plan, and a leaf with neither has had no build started. bmad-build and bmad-build-auto write `draft`, `ready-for-dev`, `in-progress`, `in-review`, and `built` as they work, and bmad-build-auto writes `blocked` when it halts. `done` is the user's, or an orchestrator's, through `tickets.py mark`; `bmad-ticket` writes `dropped` when the user says so, and runs `mark` for the user when they say a ticket is done or that they are working it by hand. No skill moves a ticket past `built`, which means the build finished and nobody has called it done. `tree-rules.md` holds the full table. `tracker_status` exists only on a tracker store: the BMad word for the tracker's current status (`backlog`, `in-progress`, `review`, `done`, `dropped`), written by `query` next to `tracker_id` and `remote`, never sent. A ticket's state, which `next` and `status` group by and which `write` sends to a tracker as `[tickets.status].`, is `planned` for an entry with no file and no plan; else `tracker_status` when present; else from `status`: none, `draft`, or `ready-for-dev` is `backlog`; `in-progress` or `blocked` is `in-progress`; `in-review` or `built` is `review`; `done` and `dropped` are themselves. A tracker's status must never drive build routing (a card moved to In Progress on the board still gets planned), and the build's own steps never need to reach the tracker. A container's `status` is `bmad-ticket`'s: absent until work under it starts, then `in-progress`, `done`, or `dropped`. + +Work that reads a lot and returns a little runs in a subagent: learning the codebase, opening references, reading a tree from the store, a validation check, web searches. If the harness blocks subagents, say so and continue inline. diff --git a/skills/bmad-preview-ticketing/assets/bug-template.md b/skills/bmad-ticket/assets/bug-template.md similarity index 100% rename from skills/bmad-preview-ticketing/assets/bug-template.md rename to skills/bmad-ticket/assets/bug-template.md diff --git a/skills/bmad-preview-ticketing/assets/epic-template.md b/skills/bmad-ticket/assets/epic-template.md similarity index 100% rename from skills/bmad-preview-ticketing/assets/epic-template.md rename to skills/bmad-ticket/assets/epic-template.md diff --git a/skills/bmad-preview-ticketing/assets/initiative-template.md b/skills/bmad-ticket/assets/initiative-template.md similarity index 100% rename from skills/bmad-preview-ticketing/assets/initiative-template.md rename to skills/bmad-ticket/assets/initiative-template.md diff --git a/skills/bmad-preview-ticketing/assets/spike-template.md b/skills/bmad-ticket/assets/spike-template.md similarity index 100% rename from skills/bmad-preview-ticketing/assets/spike-template.md rename to skills/bmad-ticket/assets/spike-template.md diff --git a/skills/bmad-preview-ticketing/assets/story-template.md b/skills/bmad-ticket/assets/story-template.md similarity index 100% rename from skills/bmad-preview-ticketing/assets/story-template.md rename to skills/bmad-ticket/assets/story-template.md diff --git a/skills/bmad-preview-ticketing/assets/tickets-template.toml b/skills/bmad-ticket/assets/tickets-template.toml similarity index 100% rename from skills/bmad-preview-ticketing/assets/tickets-template.toml rename to skills/bmad-ticket/assets/tickets-template.toml diff --git a/skills/bmad-ticket/bmod.toml b/skills/bmad-ticket/bmod.toml new file mode 100644 index 0000000000..759dc9e60c --- /dev/null +++ b/skills/bmad-ticket/bmod.toml @@ -0,0 +1,4 @@ +[skill] +bmod = "bmod-method" +source = "github:bmad-code-org/BMAD-METHOD/skills" +scripts = ["scripts/tickets.py"] diff --git a/skills/bmad-preview-ticketing/config/gh-ticketing.toml b/skills/bmad-ticket/config/gh-ticketing.toml similarity index 100% rename from skills/bmad-preview-ticketing/config/gh-ticketing.toml rename to skills/bmad-ticket/config/gh-ticketing.toml diff --git a/skills/bmad-preview-ticketing/config/jira-ticketing.toml b/skills/bmad-ticket/config/jira-ticketing.toml similarity index 100% rename from skills/bmad-preview-ticketing/config/jira-ticketing.toml rename to skills/bmad-ticket/config/jira-ticketing.toml diff --git a/skills/bmad-preview-ticketing/config/linear-ticketing.toml b/skills/bmad-ticket/config/linear-ticketing.toml similarity index 100% rename from skills/bmad-preview-ticketing/config/linear-ticketing.toml rename to skills/bmad-ticket/config/linear-ticketing.toml diff --git a/skills/bmad-preview-ticketing/config/notion-ticketing.toml b/skills/bmad-ticket/config/notion-ticketing.toml similarity index 100% rename from skills/bmad-preview-ticketing/config/notion-ticketing.toml rename to skills/bmad-ticket/config/notion-ticketing.toml diff --git a/skills/bmad-preview-ticketing/config/repo-ticketing.toml b/skills/bmad-ticket/config/repo-ticketing.toml similarity index 92% rename from skills/bmad-preview-ticketing/config/repo-ticketing.toml rename to skills/bmad-ticket/config/repo-ticketing.toml index 6c82ecd0e8..5c302e0fd1 100644 --- a/skills/bmad-preview-ticketing/config/repo-ticketing.toml +++ b/skills/bmad-ticket/config/repo-ticketing.toml @@ -45,7 +45,7 @@ create `backlog/` and the active initiative's folder there when they do not exis write = """ No entry yet: add an `[[entry]]` with the next unused `id` to the parent's `tickets.toml`; the file carries that `id`. Every change — body, parent (move the file and its plan, or the container folder, into the new -parent's folder, and set the plan's `ticket` to the leaf's id there), after — is an edit to the file. A leaf's `status`, `assignee`, `blocked_at`, and `blocked_reason` live in its plan beside it, and a pulled file has none: the build writes draft, ready-for-dev, in-progress, in-review, and built as it works, and build-auto writes blocked; done is the user's or an orchestrator's, and dropped is ticketing's when the user says so. No skill moves a leaf past built. Ticketing sets a leaf's status or assignee only with `tickets.py mark [] [--assignee ] [--blocked ]`, which writes the plan and creates it when there is none. A container's `status` is ticketing's: absent until work under it starts, then in-progress, done, or dropped. Build records: the plan, `--plan.md` +parent's folder, and set the plan's `ticket` to the leaf's id there), after — is an edit to the file. A leaf's `status`, `assignee`, `blocked_at`, and `blocked_reason` live in its plan beside it, and a pulled file has none: the build writes draft, ready-for-dev, in-progress, in-review, and built as it works, and build-auto writes blocked; done is the user's or an orchestrator's, and dropped is `bmad-ticket`'s when the user says so. No skill moves a leaf past built. `bmad-ticket` sets a leaf's status or assignee only with `tickets.py mark [] [--assignee ] [--blocked ]`, which writes the plan and creates it when there is none. A container's `status` is `bmad-ticket`'s: absent until work under it starts, then in-progress, done, or dropped. Build records: the plan, `--plan.md` beside the leaf, whether or not the leaf has a file. Commit only the files you wrote on the current branch. Root not in a git repo: skip the commit and say so. """ diff --git a/skills/bmad-preview-ticketing/config/trello-ticketing.toml b/skills/bmad-ticket/config/trello-ticketing.toml similarity index 100% rename from skills/bmad-preview-ticketing/config/trello-ticketing.toml rename to skills/bmad-ticket/config/trello-ticketing.toml diff --git a/skills/bmad-preview-ticketing/customize.toml b/skills/bmad-ticket/customize.toml similarity index 98% rename from skills/bmad-preview-ticketing/customize.toml rename to skills/bmad-ticket/customize.toml index 0d3e4a4d33..58e510cf15 100644 --- a/skills/bmad-preview-ticketing/customize.toml +++ b/skills/bmad-ticket/customize.toml @@ -1,8 +1,8 @@ # DO NOT EDIT -- overwritten on every update. # -# Workflow customization surface for bmad-preview-ticketing. -# Team overrides: {project-root}/_bmad/custom/bmad-preview-ticketing.toml -# Personal overrides: {project-root}/_bmad/custom/bmad-preview-ticketing.user.toml +# Workflow customization surface for bmad-ticket. +# Team overrides: {project-root}/_bmad/custom/bmad-ticket.toml +# Personal overrides: {project-root}/_bmad/custom/bmad-ticket.user.toml [workflow] diff --git a/skills/bmad-preview-ticketing/references/board.md b/skills/bmad-ticket/references/board.md similarity index 84% rename from skills/bmad-preview-ticketing/references/board.md rename to skills/bmad-ticket/references/board.md index dcdfe56908..dc2a9b3204 100644 --- a/skills/bmad-preview-ticketing/references/board.md +++ b/skills/bmad-ticket/references/board.md @@ -25,9 +25,9 @@ Before starting a candidate, read it and its source. One in `next`'s `ready_to_r | `draft`, `ready-for-dev`, `in-progress`, `in-review`, `built` | `bmad-build`, `bmad-build-auto` as they work | | `blocked` | `bmad-build-auto` when it halts, with the reason in the plan | | `done` | the user, or an orchestrator, through `tickets.py mark` | - | `dropped` | the ticketing skill, when the user says so | + | `dropped` | `bmad-ticket`, when the user says so | - No skill moves a ticket past `built`, and ticketing does not move a leaf the build is working. When the user says a ticket is done, run `mark` for them. Assignee changes, and a `status` the user asks for — `done`, `dropped`, or a person working the ticket by hand — go through `write`; on the repo store, for a leaf, that is `tickets.py --project-root {project-root} mark [] [--assignee ] [--blocked ]` followed by the commit its verb describes. `mark` takes its folder and ref as `find` does, writes the plan and never the leaf file, and creates a plan holding only frontmatter when there is none. `mark` writes what it is told; the checks above are yours. On a tracker, `write` transitions the item to `[tickets.status].` and never sends `status` as a word; the tracker's status comes back as `tracker_status` on `query`. A container's `status` is ticketing's, an edit to its file: absent until work under it starts, then `in-progress`, `done`, or `dropped`; containers never take review. On done with estimation on, ask for the actual (`estimate.md`). + No skill moves a ticket past `built`, and `bmad-ticket` does not move a leaf the build is working. When the user says a ticket is done, run `mark` for them. Assignee changes, and a `status` the user asks for — `done`, `dropped`, or a person working the ticket by hand — go through `write`; on the repo store, for a leaf, that is `tickets.py --project-root {project-root} mark [] [--assignee ] [--blocked ]` followed by the commit its verb describes. `mark` takes its folder and ref as `find` does, writes the plan and never the leaf file, and creates a plan holding only frontmatter when there is none. `mark` writes what it is told; the checks above are yours. On a tracker, `write` transitions the item to `[tickets.status].` and never sends `status` as a word; the tracker's status comes back as `tracker_status` on `query`. A container's `status` is `bmad-ticket`'s, an edit to its file: absent until work under it starts, then `in-progress`, `done`, or `dropped`; containers never take review. On done with estimation on, ask for the actual (`estimate.md`). - A ticket waiting on a person or an answer, not on a prerequisite: `mark` with `--blocked ` sets `blocked_at` (today) and `blocked_reason`; a `mark` without it clears both when the ticket moves. `next` lists it under `blocked`. - Closing every child does not close the parent. Run the closure check in `validate.md` against its requirements and Done when; the user confirms the parent is complete. - Drop only after a `Dropped:` line in Notes says why. A dropped ticket still blocks its dependents, in any epic: `status` lists them under `blocks`; remove or repoint it in each one's `after` with the user. An entry with no file and no plan is dropped by deleting it from `tickets.toml`. Cancelling a container cancels its descendants after the user confirms. diff --git a/skills/bmad-preview-ticketing/references/estimate.md b/skills/bmad-ticket/references/estimate.md similarity index 100% rename from skills/bmad-preview-ticketing/references/estimate.md rename to skills/bmad-ticket/references/estimate.md diff --git a/skills/bmad-preview-ticketing/references/slice.md b/skills/bmad-ticket/references/slice.md similarity index 99% rename from skills/bmad-preview-ticketing/references/slice.md rename to skills/bmad-ticket/references/slice.md index b6f7ecfbdc..45906d8c97 100644 --- a/skills/bmad-preview-ticketing/references/slice.md +++ b/skills/bmad-ticket/references/slice.md @@ -24,7 +24,7 @@ Where the source contradicts the code or another source, add `Source conflict: < Use what is already known. Ask the remaining questions that change the split: what is first worth demoing; what is least certain; what will the first piece teach about the rest; whether the user has a split in mind; how the team defines epics. Group related questions and say which answer you would pick and why. -When the user states how their team cuts epics, offer to save it as `slice_to_epics` under `[workflow]` in `{project-root}/_bmad/custom/bmad-preview-ticketing.toml`. It replaces the default, so keep the default lines the team still wants. +When the user states how their team cuts epics, offer to save it as `slice_to_epics` under `[workflow]` in `{project-root}/_bmad/custom/bmad-ticket.toml`. It replaces the default, so keep the default lines the team still wants. ## Initiative into epics diff --git a/skills/bmad-preview-ticketing/references/store-setup.md b/skills/bmad-ticket/references/store-setup.md similarity index 100% rename from skills/bmad-preview-ticketing/references/store-setup.md rename to skills/bmad-ticket/references/store-setup.md diff --git a/skills/bmad-preview-ticketing/references/ticket.md b/skills/bmad-ticket/references/ticket.md similarity index 100% rename from skills/bmad-preview-ticketing/references/ticket.md rename to skills/bmad-ticket/references/ticket.md diff --git a/skills/bmad-preview-ticketing/references/tree-rules.md b/skills/bmad-ticket/references/tree-rules.md similarity index 88% rename from skills/bmad-preview-ticketing/references/tree-rules.md rename to skills/bmad-ticket/references/tree-rules.md index e3071466d1..e0852854ee 100644 --- a/skills/bmad-preview-ticketing/references/tree-rules.md +++ b/skills/bmad-ticket/references/tree-rules.md @@ -1,11 +1,11 @@ # Rules for skills that use the ticket tree -Every skill that takes work from the tree, builds it, reviews it, or looks back on it follows these rules: the ticketing skill, `bmad-build`, `bmad-build-auto`, `bmad-code-review`, `bmad-retrospective`, and `bmad migrate`. +Every skill that takes work from the tree, builds it, reviews it, or looks back on it follows these rules: `bmad-ticket`, `bmad-build`, `bmad-build-auto`, `bmad-code-review`, `bmad-retrospective`, and `bmad migrate`. ## Finding the tree - The tree is `{output_folder}/{active_initiative}`: `output_folder` from `[core]` and `active_initiative` from `[modules.bmm]`, both in the merged BMad config. -- `tickets.py` is installed at `{project-root}/_bmad/method/scripts/tickets.py`. The ticketing skill declares it in its `bmod.toml`. Other skills run it from there and never open the ticketing skill's folder. +- `tickets.py` is installed at `{project-root}/_bmad/method/scripts/tickets.py`. `bmad-ticket` declares it in its `bmod.toml`. Other skills run it from there and never open `bmad-ticket`'s folder. - Called with no folder, `tickets.py next`, `status`, and `find` resolve the active initiative themselves. When no initiative is set, they exit with an error that names the missing key, and the calling skill works without the tree. - A ticket is read through `tickets.py find`: its entry's fields, its epic file, its story file when one was refined, and its plan path, whether or not the plan exists yet. The build's input is the entry and its epic, plus the story file when there is one. No skill writes a ticket file to start work. @@ -27,7 +27,7 @@ Every skill that takes work from the tree, builds it, reviews it, or looks back | `draft`, `ready-for-dev`, `in-progress`, `in-review`, `built` | `bmad-build`, `bmad-build-auto` as they work | | `blocked` | `bmad-build-auto` when it halts, with the reason in the plan | | `done` | the user, or an orchestrator, through `tickets.py mark` | -| `dropped` | the ticketing skill, when the user says so | +| `dropped` | `bmad-ticket`, when the user says so | - No skill moves a ticket past `built`: the build's last status, meaning the build finished and nobody has called it done. When the user tells a skill that a ticket is done, the skill runs `mark` for them. `bmad-code-review` never changes `status`. @@ -39,4 +39,4 @@ Every skill that takes work from the tree, builds it, reviews it, or looks back ## Where review and retrospective write - `bmad-code-review` appends a `## Code Review` section to the reviewed ticket's plan. Each run adds a dated block with that run's findings. Deferred findings go into the same block. -- `bmad-retrospective` writes `epic--retrospective.md` in the epic folder, with `verdict` in its frontmatter. It does not edit the epic file. Closing the epic is still the ticketing skill's closure check, confirmed by the user. +- `bmad-retrospective` writes `epic--retrospective.md` in the epic folder, with `verdict` in its frontmatter. It does not edit the epic file. Closing the epic is still `bmad-ticket`'s closure check, confirmed by the user. diff --git a/skills/bmad-preview-ticketing/references/validate.md b/skills/bmad-ticket/references/validate.md similarity index 100% rename from skills/bmad-preview-ticketing/references/validate.md rename to skills/bmad-ticket/references/validate.md diff --git a/skills/bmad-preview-ticketing/scripts/read_toml.py b/skills/bmad-ticket/scripts/read_toml.py similarity index 100% rename from skills/bmad-preview-ticketing/scripts/read_toml.py rename to skills/bmad-ticket/scripts/read_toml.py diff --git a/skills/bmad-preview-ticketing/scripts/tests/test_read_toml.py b/skills/bmad-ticket/scripts/tests/test_read_toml.py similarity index 100% rename from skills/bmad-preview-ticketing/scripts/tests/test_read_toml.py rename to skills/bmad-ticket/scripts/tests/test_read_toml.py diff --git a/skills/bmad-preview-ticketing/scripts/tests/test_tickets.py b/skills/bmad-ticket/scripts/tests/test_tickets.py similarity index 100% rename from skills/bmad-preview-ticketing/scripts/tests/test_tickets.py rename to skills/bmad-ticket/scripts/tests/test_tickets.py diff --git a/skills/bmad-preview-ticketing/scripts/tickets.py b/skills/bmad-ticket/scripts/tickets.py similarity index 100% rename from skills/bmad-preview-ticketing/scripts/tickets.py rename to skills/bmad-ticket/scripts/tickets.py diff --git a/skills/bmad-ux/SKILL.md b/skills/bmad-ux/SKILL.md index 6adf2cda5e..3cccb5a892 100644 --- a/skills/bmad-ux/SKILL.md +++ b/skills/bmad-ux/SKILL.md @@ -91,5 +91,5 @@ Outcomes, in order: - **Key-screen mocks rendered.** Key-screens tool → `.working/` for surfaces where layout drives behavior or anchors visual language. - **Mock coverage confirmed.** Walk every IA surface; classify *mocked* vs *spine-only*. Ask: *"These will be built from spine tables alone — any need a visual reference?"* Render more if named; log spine-only choices. - **Layout extracted, artifacts promoted.** Distill subagent re-reads each `.working/` and `imports/` artifact; lifts visual decisions into DESIGN.md and behavioral decisions into EXPERIENCE.md. Promote `.working/` keepers to `mockups/` (HTML) or `wireframes/` (Excalidraw); imports stay. Inline relative links at relevant spine sections; state spines-win-on-conflict once. -- **Polished, handed off, closed.** Apply `{workflow.doc_standards}` in order. Execute `{workflow.external_handoffs}`; surface URLs. Set both files' `status: final`, `updated: {date}`. Log finalization via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type event --text "spines finalized"`. Share paths. Common next: `bmad-architecture`, `bmad-preview-ticketing`, `bmad-build`. Run `{workflow.on_complete}`. +- **Polished, handed off, closed.** Apply `{workflow.doc_standards}` in order. Execute `{workflow.external_handoffs}`; surface URLs. Set both files' `status: final`, `updated: {date}`. Log finalization via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type event --text "spines finalized"`. Share paths. Common next: `bmad-architecture`, `bmad-ticket`, `bmad-build`. Run `{workflow.on_complete}`. diff --git a/skills/bmad/references/initiative.md b/skills/bmad/references/initiative.md index 65de9c67b2..2b424d9ee3 100644 --- a/skills/bmad/references/initiative.md +++ b/skills/bmad/references/initiative.md @@ -4,7 +4,7 @@ Work for one body of work lives in an initiative folder under `output_folder`. ` 1. Run `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key modules.bmm.active_initiative`. Script not found, or no `output_folder`: BMad is not set up here; offer `bmad setup` first. 2. Tell the user the active initiative, or none. List the `initiative-*` folders under `{output_folder}`, with `{project-root}` substituted. -3. The user picks one, asks for a new one, or clears it. For a new one, ask its name and create `{output_folder}/initiative-/initiative-.md`, `` the name in kebab-case, holding only frontmatter: `type: initiative`, `title`, `parent: none`. The ticketing skill fills it in when the user plans the work. +3. The user picks one, asks for a new one, or clears it. For a new one, ask its name and create `{output_folder}/initiative-/initiative-.md`, `` the name in kebab-case, holding only frontmatter: `type: initiative`, `title`, `parent: none`. `bmad-ticket` fills it in when the user plans the work. 4. Write `active_initiative = ""` under `[modules.bmm]` in `{project-root}/_bmad/custom/config.user.toml`, creating the file or the table when missing and keeping the rest of the file. Clearing removes the line. 5. Confirm the change in one line. diff --git a/skills/bmod-method/bmod.toml b/skills/bmod-method/bmod.toml index d446cbe185..63bda1bebf 100644 --- a/skills/bmod-method/bmod.toml +++ b/skills/bmod-method/bmod.toml @@ -21,6 +21,7 @@ skills = [ "bmad-qa-generate-e2e-tests", "bmad-retrospective", "bmad-spec", + "bmad-ticket", "bmad-ux", "bmad-walkthrough", ] diff --git a/skills/bmod-method/help/artifact-lifetime.md b/skills/bmod-method/help/artifact-lifetime.md index 015bc38ffe..bee6424172 100644 --- a/skills/bmod-method/help/artifact-lifetime.md +++ b/skills/bmod-method/help/artifact-lifetime.md @@ -2,7 +2,7 @@ Joined plans are live ticket state, including after work is done. Keep them beside their entries or backlog leaves. They preserve status, baseline revisions, implementation evidence, and review findings for later work and retrospective. -Before closing an epic, run `bmad-retrospective`, decide how to handle its findings, and close through `bmad-preview-ticketing`. Keep the epic, entries, plans, existing leaf files, and retrospective together. Deleting plans can turn completed entries back into planned work. +Before closing an epic, run `bmad-retrospective`, decide how to handle its findings, and close through `bmad-ticket`. Keep the epic, entries, plans, existing leaf files, and retrospective together. Deleting plans can turn completed entries back into planned work. Scope ordinary agent reads to the active initiative and current epic in `AGENTS.md`. Historical plans are evidence, not a replacement for the current code. Superseded planning documents can be archived once their references and requirement sources remain accessible. Never remove live plans as part of that cleanup. diff --git a/skills/bmod-method/help/help.md b/skills/bmod-method/help/help.md index 509c88ed01..04c804a788 100644 --- a/skills/bmod-method/help/help.md +++ b/skills/bmod-method/help/help.md @@ -19,7 +19,7 @@ This document should be enough to route the user and say what to do next. Each t | Topic file | Read when the user asks about | |---|---| | `help/analysis-skills.md` | `bmad-product-brief` or `bmad-prfaq` in depth: what each gives, when to pick it, when not to, how they relate. | -| `help/planning-skills.md` | `bmad-spec`, `bmad-prd`, `bmad-ux`, `bmad-architecture`, `bmad-preview-ticketing` in depth. | +| `help/planning-skills.md` | `bmad-spec`, `bmad-prd`, `bmad-ux`, `bmad-architecture`, `bmad-ticket` in depth. | | `help/implementation-skills.md` | `bmad-build`, `bmad-build-auto`, or `bmad-correct-course` in depth. | | `help/validation-skills.md` | `bmad-code-review`, `bmad-walkthrough`, `bmad-qa-generate-e2e-tests`, or `bmad-retrospective` in depth. | | `help/prototyping.md` | Prototyping or vibe coding first, what a prototype is good for (worth doing, feasibility, complexity, unknowns), non-engineers prototyping, what to do with a prototype afterwards, whether planning still matters after a good first version. | @@ -28,8 +28,8 @@ This document should be enough to route the user and say what to do next. Each t | `help/artifact-lifetime.md` | Whether to keep PRDs, specs, stories, and build records after the work is done, archiving, closing out an epic, keeping old plans from misleading agents. | | `help/monorepo-and-polyrepo.md` | Where to install BMad and keep planning when work spans one repository or several; the workspace layout for a poly repo. | | `help/working-in-an-organization.md` | A team or enterprise: an existing PRD, Jira or another tracker, approvals and sign-off, document owners, several engineers in parallel, requirements changing mid-flight. | -| `help/ticketing-and-epics.md` | How `bmad-preview-ticketing` works (initiatives, epic inception, the breakdown, building from an entry, refining), plan status, review, and retrospective. | -| `help/ticketing-setup.md` | Setting up and driving `bmad-preview-ticketing`: the store, several repos, trackers, the phrases to say, the hand-off to `bmad-build`. | +| `help/ticketing-and-epics.md` | How `bmad-ticket` works (initiatives, epic inception, the breakdown, building from an entry, refining), plan status, review, and retrospective. | +| `help/ticketing-setup.md` | Setting up and driving `bmad-ticket`: the store, several repos, trackers, the phrases to say, the hand-off to `bmad-build`. | | `help/unattended-builds.md` | `bmad-build-auto`, building stories with no human present, a blocked run and how to retry, what to check after a run. | | `help/review-choices.md` | Review depth, skipping review, another review pass, when to stop, slow reviews, customizing review. | | `help/project-context.md` | `bmad-project-context` in depth: what belongs in `AGENTS.md`, why the block is small, its intents, removing a rule. | @@ -40,7 +40,7 @@ This document should be enough to route the user and say what to do next. Each t - Obvious and low-risk (typo, formatting, config): just make the edit. No skill. - Yes → `bmad-build`. No planning skill first. - Bigger than one session: does the user already have enough to say or paste (an idea they can explain in detail, notes, intent.md, single ticket, a transcript, a brief, a PRD)? - - Yes → `bmad-spec`, then `bmad-preview-ticketing` with the spec folder to plan the stories. Then one `bmad-build` per story. + - Yes → `bmad-spec`, then `bmad-ticket` with the spec folder to plan the stories. Then one `bmad-build` per story. - No → find what is missing, run the skill that supplies it, then `bmad-spec`: - They cannot name a customer or a problem → `bmad-forge-idea` or `bmad-brainstorming` (core tools), if installed. - Unsure the idea is worth building → `bmad-prfaq`. @@ -65,11 +65,11 @@ Situations the tree above does not settle. | An inherited or brownfield codebase | A small `bmad-build` change first; `bmad-project-context` and `bmad-walkthrough` as needed | No up-front documentation pass is required (`help/existing-codebase.md`). | | "I don't know architecture, stacks, or hosting" | `bmad-architecture`, or the architect agent to talk it through | It coaches, recommends a current starter, and lays out options with reasons for the user to choose. Technical knowledge is not needed to start. | | "An app for X" and nothing more | `bmad-product-brief`, or `bmad-prd` when the stakes call for full requirements | `bmad-spec` distills and will not coach; the input is too thin for it. The brief is the lighter of the two. | -| A PRD and architecture, several epics, wants tracking | `bmad-preview-ticketing` | One tree of epics, entries, and joined plans. | +| A PRD and architecture, several epics, wants tracking | `bmad-ticket` | One tree of epics, entries, and joined plans. | | A team with an existing PRD, a tracker, approvals, or several engineers | The full path only when approvers, parallel teams, or required documents call for it | The existing PRD is input, each document has one owner, and sign-off attaches to skill results (`help/working-in-an-organization.md`). | -| "Can BMad build my stories by itself?" | `bmad-build-auto`, dispatched per story by a loop | It suits settled decisions and well specified stories, with someone reading the results. For work planned with `bmad-preview-ticketing`, give it the ticket, one run per ticket (`help/unattended-builds.md`). | -| Wants tickets or a tracker (Jira, Linear, GitHub) as the record | `bmad-preview-ticketing` | Tickets are the board. The build moves a ticket's `status` in its plan as far as `built`, and the user marks it done. | -| "Where are we?" | `bmad-preview-ticketing` status | Reads the ticket tree and joined plan statuses. | +| "Can BMad build my stories by itself?" | `bmad-build-auto`, dispatched per story by a loop | It suits settled decisions and well specified stories, with someone reading the results. For work planned with `bmad-ticket`, give it the ticket, one run per ticket (`help/unattended-builds.md`). | +| Wants tickets or a tracker (Jira, Linear, GitHub) as the record | `bmad-ticket` | Tickets are the board. The build moves a ticket's `status` in its plan as far as `built`, and the user marks it done. | +| "Where are we?" | `bmad-ticket` status | Reads the ticket tree and joined plan statuses. | | A v6 project (`epics.md`, `sprint-status.yaml`, dated folders under the planning folder) that wants the v7 layout | `bmad migrate method` | The module ships `v6-v7-migration.toml`: the rules for moving the project's artifacts into initiative folders, turning epics and sprint status into a ticket tree, and putting loose work in `inbox/`. The `bmad` skill plans it with the user, then performs it. | | A PR, a branch, a ticket in review, or code `bmad-build` did not write | `bmad-code-review` | Agent lenses over any diff. With no argument it offers the tickets in review. | | "Walk me through what changed" | `bmad-walkthrough` | The human is the reviewer. | @@ -88,15 +88,15 @@ One line per skill: what it is for and what it writes. The files it writes are h | `bmad-product-brief` | A 1-2 page brief of a product the user believes in. Lighter than a PRD, sharper than a hand-written intent file. It does not judge the idea. | `brief-/brief-.md` | | `bmad-prfaq` | Tests whether a concept survives scrutiny: press release, hard FAQs, researched claims, a verdict. | `prfaq-/prfaq-.md`, plus `-distillate.md` beside it | | **Planning** (`help/planning-skills.md`) | | | -| `bmad-spec` | The hub. Distills any input into the contract builds read, and updates it. It does not slice or coach; splitting work into stories is `bmad-preview-ticketing`. | `spec-/spec-.md` and companions | +| `bmad-spec` | The hub. Distills any input into the contract builds read, and updates it. It does not slice or coach; splitting work into stories is `bmad-ticket`. | `spec-/spec-.md` and companions | | `bmad-prd` | Coaches detailed requirements out of the user, sized to the stakes. Also updates and validates a PRD. | `prd-/prd-.md` | | `bmad-ux` | How the product looks and works. May lead, follow, or stand alone. Can produce mocks and wireframes. | `ux-/` with `DESIGN.md`, `EXPERIENCE.md`, and `ux-.md` naming them | | `bmad-architecture` | Settles only the decisions that keep separately built parts consistent. Coaches a user with no architecture knowledge, recommends a current starter, and covers hosting and deployment. | `architecture-/architecture-.md` | -| `bmad-preview-ticketing` | A ticket tree run as a board: initiatives, epics, stories planned as entries in `tickets.toml`, a file only when refined or published, one-off bugs, optional tracker. | Ticket files under `{output_folder}/{active_initiative}/` and `{output_folder}/backlog/` | +| `bmad-ticket` | A ticket tree run as a board: initiatives, epics, stories planned as entries in `tickets.toml`, a file only when refined or published, one-off bugs, optional tracker. | Ticket files under `{output_folder}/{active_initiative}/` and `{output_folder}/backlog/` | | **Implementation** (`help/implementation-skills.md`) | | | | `bmad-build` | One session of delivery: clarifies intent, plans, implements, reviews, commits. The default for any real change. Takes free text, a ticket from the tree (nothing means the next ready one), or any file as intent. | A ticket's plan beside `tickets.toml`, or `plan-.md`; `deferred-work.md` | | `bmad-build-auto` | One unattended build of one ticket, dispatched by a loop or script. Never for attended work. | The same plans as `bmad-build` | -| `bmad-correct-course` | Assesses a significant midstream change. Needs a PRD or a spec; lists epic and story changes for the ticketing skill. | `change-/change-.md` | +| `bmad-correct-course` | Assesses a significant midstream change. Needs a PRD or a spec; lists epic and story changes for `bmad-ticket`. | `change-/change-.md` | | **Validation** (`help/validation-skills.md`) | | | | `bmad-code-review` | Agent review of any diff, PR, or branch, with triaged findings. Redundant right after a full `bmad-build` review of the same change. | A dated block in the plan's `## Code Review` section, or chat | | `bmad-walkthrough` | The human reviews a change block by block, guided. Also a way to learn unfamiliar code. | `walkthrough-/` with the narrative and a `-log.md` | @@ -107,7 +107,7 @@ One line per skill: what it is for and what it writes. The files it writes are h ### Slicing and tracking the work -`bmad-preview-ticketing` plans and tracks work in one ticket tree. An initiative holds epics; each epic's `tickets.toml` holds ordered entries. Build an entry directly without making a story file. Standalone stories and bugs can be direct intent or backlog leaves. Plans own status and remain live after completion. Builds stop at `built`; the user or orchestrator marks `done`. See `help/ticketing-setup.md`. +`bmad-ticket` plans and tracks work in one ticket tree. An initiative holds epics; each epic's `tickets.toml` holds ordered entries. Build an entry directly without making a story file. Standalone stories and bugs can be direct intent or backlog leaves. Plans own status and remain live after completion. Builds stop at `built`; the user or orchestrator marks `done`. See `help/ticketing-setup.md`. ### Who reviews what @@ -140,9 +140,9 @@ An agent and its skills are two ways into the same work: a skill run directly do | `bmad-prd` | `bmad-spec` to absorb it. `bmad-ux` when the UI matters; `bmad-architecture` when parts must fit together. | | `bmad-ux` | `bmad-spec` to adopt the files as companions. When UX came first and requirements are still thin, `bmad-prd` or the lighter `bmad-product-brief` with the UX files as input. | | `bmad-architecture` | `bmad-spec` to adopt the spine as a companion. | -| `bmad-spec` | Its open questions and assumptions, if any. Then `bmad-preview-ticketing` with the spec folder to plan the stories, and `bmad-build` per story, or straight to `bmad-build` when one session can do it. | +| `bmad-spec` | Its open questions and assumptions, if any. Then `bmad-ticket` with the spec folder to plan the stories, and `bmad-build` per story, or straight to `bmad-build` when one session can do it. | | `bmad-build` | Open a PR, or `bmad-walkthrough` when a person wants to understand the change. Once the user marks the ticket done, the next ticket. `bmad-qa-generate-e2e-tests` when end-to-end coverage is wanted. | -| The last ticket of an epic | `bmad-retrospective`, then a refactoring pass over the whole changeset, which is commonly skipped (`help/preparing-a-repo-for-agents.md`). Then close the epic through ticketing and retain its plans (`help/artifact-lifetime.md`). | +| The last ticket of an epic | `bmad-retrospective`, then a refactoring pass over the whole changeset, which is commonly skipped (`help/preparing-a-repo-for-agents.md`). Then close the epic through `bmad-ticket` and retain its plans (`help/artifact-lifetime.md`). | ## Answering "what's next?" diff --git a/skills/bmod-method/help/implementation-skills.md b/skills/bmod-method/help/implementation-skills.md index bd76bd1f6c..31d198f531 100644 --- a/skills/bmod-method/help/implementation-skills.md +++ b/skills/bmod-method/help/implementation-skills.md @@ -16,8 +16,8 @@ Read this when the question is about `bmad-build`, `bmad-build-auto`, or `bmad-c - Writes: the same plans as `bmad-build`. **`bmad-correct-course`** — assesses a significant midstream change. -- Gives: a change proposal covering impact across PRD, epics, architecture, and UX; a recommended path (adjust, roll back, or cut scope); and proposed edits. It drafts the edits to the PRD, architecture, UX, and stories and does not apply them: the user applies those through the owning skills. Its handoff lists the added, removed, resequenced, or rescoped epics and stories for the user to apply with the ticketing skill. +- Gives: a change proposal covering impact across PRD, epics, architecture, and UX; a recommended path (adjust, roll back, or cut scope); and proposed edits. It drafts the edits to the PRD, architecture, UX, and stories and does not apply them: the user applies those through the owning skills. Its handoff lists the added, removed, resequenced, or rescoped epics and stories for the user to apply with `bmad-ticket`. - Pick when: a ticket exposes something that reaches across artifacts, such as a technical limit, a new or misread requirement, a pivot, or a failed approach. -- Not when: there is neither a PRD nor a spec (it halts). A change that touches only the spec → update it with `bmad-spec`. A change that only re-slices tickets → `bmad-preview-ticketing`. +- Not when: there is neither a PRD nor a spec (it halts). A change that touches only the spec → update it with `bmad-spec`. A change that only re-slices tickets → `bmad-ticket`. - Reads: the PRD or spec, plus architecture and UX when present. It reads no epics file or ticket tree; the user describes the affected epics and stories. - Writes: `{output_folder}/{active_initiative}/change-/change-.md`. diff --git a/skills/bmod-method/help/planning-skills.md b/skills/bmod-method/help/planning-skills.md index 7b82f3423b..cd7e7b7684 100644 --- a/skills/bmod-method/help/planning-skills.md +++ b/skills/bmod-method/help/planning-skills.md @@ -3,10 +3,10 @@ Read this when the question is about `bmad-spec`, `bmad-prd`, `bmad-ux`, `bmad-architecture`, or the skills that slice and track work: what each gives, when to pick it, when not to, and what it writes. **`bmad-spec`** — the hub. Condenses any input into the contract builds read. -- Gives: a spec folder with `spec-.md` (why, capabilities with stable ids, constraints, non-goals, success signal) and companions. It adopts UX files and an architecture spine as companions and absorbs a PRD or brief as a source. On request it hands the spec folder to `bmad-preview-ticketing` to be planned into stories. It also updates and validates an existing spec. +- Gives: a spec folder with `spec-.md` (why, capabilities with stable ids, constraints, non-goals, success signal) and companions. It adopts UX files and an architecture spine as companions and absorbs a PRD or brief as a source. On request it hands the spec folder to `bmad-ticket` to be planned into stories. It also updates and validates an existing spec. - Pick when: the user has anything to distill, or can explain the idea in detail; after any other analysis or planning skill finishes; when requirements change on the spec route (it appends to its log, re-derives the spec, and names the tickets that no longer match). - Not when: the input is a bare idea. It distills and does not coach → `bmad-product-brief` first, or `bmad-prd` when full requirements are needed. -- Splitting into stories is not this skill: send the user to `bmad-preview-ticketing` with the spec folder, which plans one epic whose stories cite the spec's `CAP-N` ids. After writing a spec that reads as several slices, `bmad-spec` offers that hand-off once. +- Splitting into stories is not this skill: send the user to `bmad-ticket` with the spec folder, which plans one epic whose stories cite the spec's `CAP-N` ids. After writing a spec that reads as several slices, `bmad-spec` offers that hand-off once. - Writes: `{output_folder}/{active_initiative}/spec-/` holding `spec-.md` and companions. **`bmad-prd`** — coaches detailed requirements out of the user. @@ -33,6 +33,6 @@ Read this when the question is about `bmad-spec`, `bmad-prd`, `bmad-ux`, `bmad-a ## Slicing and tracking the work -`bmad-preview-ticketing` plans and tracks work in one ticket tree. An initiative holds epics; each epic's `tickets.toml` holds ordered entries. Build an entry directly without making a story file. Standalone stories and bugs can be direct intent or backlog leaves. Plans own status and remain live after completion. Builds stop at `built`; the user or orchestrator marks `done`. See `help/ticketing-setup.md`. +`bmad-ticket` plans and tracks work in one ticket tree. An initiative holds epics; each epic's `tickets.toml` holds ordered entries. Build an entry directly without making a story file. Standalone stories and bugs can be direct intent or backlog leaves. Plans own status and remain live after completion. Builds stop at `built`; the user or orchestrator marks `done`. See `help/ticketing-setup.md`. -**`bmad-preview-ticketing`** — slices initiatives into epics, incepts each epic into entries, refines when needed, and manages the board and optional tracker publishing. A spec, PRD, or described intent is valid input. Requirements stay in the epic and entries cite them with `covers`. A file is needed for refinement or tracker publishing, not to start a build. Tracker stores are lightly tested. +**`bmad-ticket`** — slices initiatives into epics, incepts each epic into entries, refines when needed, and manages the board and optional tracker publishing. A spec, PRD, or described intent is valid input. Requirements stay in the epic and entries cite them with `covers`. A file is needed for refinement or tracker publishing, not to start a build. Tracker stores are lightly tested. diff --git a/skills/bmod-method/help/ticketing-and-epics.md b/skills/bmod-method/help/ticketing-and-epics.md index ea1f0e9e5c..5c3154230d 100644 --- a/skills/bmod-method/help/ticketing-and-epics.md +++ b/skills/bmod-method/help/ticketing-and-epics.md @@ -1,6 +1,6 @@ # The ticket tree -`bmad-preview-ticketing` plans and tracks work in one tree. An initiative holds epics; each epic's `tickets.toml` holds ordered entries with ids, coverage, prerequisites, and verification. Build an entry directly. Refinement or tracker publishing may add a leaf file. Standalone stories and bugs can be direct build intent or backlog leaves. +`bmad-ticket` plans and tracks work in one tree. An initiative holds epics; each epic's `tickets.toml` holds ordered entries with ids, coverage, prerequisites, and verification. Build an entry directly. Refinement or tracker publishing may add a leaf file. Standalone stories and bugs can be direct build intent or backlog leaves. Plans own status and baseline evidence and stay local on every store. Build stops at `built`; the user or orchestrator marks `done`. Code review appends dated findings to the plan without changing status. Retrospective writes `epic--retrospective.md` directly in the epic, proposing action items without creating tickets or closing it. Keep completed plans as live state and historical evidence. diff --git a/skills/bmod-method/help/ticketing-setup.md b/skills/bmod-method/help/ticketing-setup.md index 1f84259a69..3c478e5006 100644 --- a/skills/bmod-method/help/ticketing-setup.md +++ b/skills/bmod-method/help/ticketing-setup.md @@ -1,6 +1,6 @@ -# Setting up and using the ticketing preview +# Setting up and using bmad-ticket -Use this when a user asks how to set up or drive `bmad-preview-ticketing`. For the shared ticket-tree design, see `help/ticketing-and-epics.md`. +Use this when a user asks how to set up or drive `bmad-ticket`. For the shared ticket-tree design, see `help/ticketing-and-epics.md`. ## Where the store lives @@ -44,4 +44,4 @@ Copy a brief, PRD, UX design, or architecture into the initiative folder as `.md`, or `{output_folder}/plan-.md` with no initiative active. - A successful run ends at `built`, which the board shows as review. Only the user or an orchestrator marks the ticket done, with `tickets.py mark done`. -- This is the repo store. On a tracker store, `next` and `mark` refuse, so name the ticket and move it through the ticketing skill. +- This is the repo store. On a tracker store, `next` and `mark` refuse, so name the ticket and move it through `bmad-ticket`. ## Resume follows the plan's status diff --git a/skills/bmod-method/help/working-in-an-organization.md b/skills/bmod-method/help/working-in-an-organization.md index 827c7f3442..7a9ccd4c74 100644 --- a/skills/bmod-method/help/working-in-an-organization.md +++ b/skills/bmod-method/help/working-in-an-organization.md @@ -28,7 +28,7 @@ Each document has one skill that writes it, so give it one owner. One person can | 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-preview-ticketing` | the ticket tree | +| 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. @@ -41,7 +41,7 @@ Each moment produces a written result an approval can attach to. Advise placing | `bmad-prfaq` verdict | Writing the PRD | | `bmad-prd` validate | Design and architecture work | | Architecture spine review | Writing epic specs | -| `bmad-preview-ticketing` planning approval | Accepting the breakdown and its dependencies | +| `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. @@ -53,7 +53,7 @@ Reviewers ask for changes in whichever document they are reading. Apply the chan 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-preview-ticketing` again. Existing plans retain status. +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. @@ -61,4 +61,4 @@ For a change that threatens the plan itself, run `bmad-correct-course` first. It - 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-preview-ticketing` 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`). +- `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`). diff --git a/skills/bmod-method/v6-v7-migration.toml b/skills/bmod-method/v6-v7-migration.toml index aa2005c91a..c9684eb4ab 100644 --- a/skills/bmod-method/v6-v7-migration.toml +++ b/skills/bmod-method/v6-v7-migration.toml @@ -11,7 +11,7 @@ module = "method" from = "6" to = "7" title = "Move v6 planning and implementation artifacts into the v7 initiative layout" -summary = "v6 kept planning documents in one folder and build records in another, with the plan in epics.md and progress in sprint-status.yaml. v7 keeps everything for one body of work in one initiative folder, as a ticket tree the ticketing skill and the builder read, with an inbox for work that has no home yet. This migration moves the project's artifacts into that layout, turns epics and sprint status into tickets.toml and joined plans, sets the config that names the active initiative, and, when the user wants it, puts the store in its own repository or a workspace." +summary = "v6 kept planning documents in one folder and build records in another, with the plan in epics.md and progress in sprint-status.yaml. v7 keeps everything for one body of work in one initiative folder, as a ticket tree `bmad-ticket` and the builder read, with an inbox for work that has no home yet. This migration moves the project's artifacts into that layout, turns epics and sprint status into tickets.toml and joined plans, sets the config that names the active initiative, and, when the user wants it, puts the store in its own repository or a workspace." # Read-only signals. Any one of them makes this migration worth offering; the first two are v6 for certain. detect = """ @@ -75,7 +75,7 @@ precautions = """ - Read only what the migration rewrites: `epics.md`, `sprint-status.yaml`, `stories.yaml`, story files, and historical retrospectives, in full. Everything else is classified from its path, its frontmatter, and its first heading, and moved unchanged; a PRD, a brief, a design, a brainstorm is not read through. Rewriting paths is a search for the old paths across the store, not a read of every document. A file or folder that path, frontmatter, and first heading do not explain: ask the user what it is, in the plan, with the others. - Nothing changes before the plan is approved. The inventory and the questions are read-only; the only writes before approval are the plan file itself and the backup, and the first move comes after approval. - Commit before moving. The output folder under git: commit its current state first, and do every move with `git mv` so history follows the file. Tracked by the project repo: same, in that repo. Under no git at all: the backup and git questions in `questions` decide what comes first. -- The removed `bmad-sprint-planning` and `bmad-create-epics-and-stories` route is replaced by `bmad-preview-ticketing`. Build, review, and retrospective consume the joined plans; correct-course proposes changes from the affected work the user describes. +- The removed `bmad-sprint-planning` and `bmad-create-epics-and-stories` route is replaced by `bmad-ticket`. Build, review, and retrospective consume the joined plans; correct-course proposes changes from the affected work the user describes. """ # The conversion rules. Each names the v6 source, the v7 destination, and what changes on the way. @@ -86,7 +86,7 @@ A file joins an initiative only on evidence: it is named in the PRD's or `epics. Unattributed remnants go to `inbox/`, default yes, asked once in the plan: a `brainstorming/` folder of unrelated sessions, a `specs/` folder of specs nothing consumed, a loose idea file. Each moves as it is, folder and contents unchanged, not renamed and not given frontmatter; inbox is the pile, and its shape is the user's to tidy. Declined, they stay where they are: at the root they are unrecognized and left alone. A half-run or a stray memlog with nothing else beside it goes to `inbox/archive-v6/`. The user can move anything anywhere later, including out of the store. -An idea or intent file the initiative grew from becomes `initiative-/intent.md` when it is the one intent, else `idea-/idea-.md` inside the initiative. An intent for work not started, and any idea with no initiative, becomes `inbox/intent-.md`, flat, where the ticketing skill later turns it into a ticket, an epic, or an initiative. `inbox/` is created with its `space.md` the first time something goes there, and not otherwise. +An idea or intent file the initiative grew from becomes `initiative-/intent.md` when it is the one intent, else `idea-/idea-.md` inside the initiative. An intent for work not started, and any idea with no initiative, becomes `inbox/intent-.md`, flat, where `bmad-ticket` later turns it into a ticket, an epic, or an initiative. `inbox/` is created with its `space.md` the first time something goes there, and not otherwise. ## Planning documents @@ -109,7 +109,7 @@ A document that belongs to one epic goes in that epic's folder. Retrospectives a ## epics.md and sprint-status.yaml become the ticket tree -Read `epics.md`, `sprint-status.yaml`, and every story file in the implementation folder before writing anything. The ticketing skill's templates (`bmad-preview-ticketing/assets/`) are the shapes to write; open them. +Read `epics.md`, `sprint-status.yaml`, and every story file in the implementation folder before writing anything. `bmad-ticket`'s templates (`bmad-ticket/assets/`) are the shapes to write; open them. Initiative envelope: `initiative-/initiative-.md` from the initiative template. Title from the project name; Description and Outcome from the PRD's summary; Done when from the PRD's goals; References naming the moved PRD, architecture, and UX; `covers` the PRD's requirement ids. The initiative's `tickets.toml` gets one `[[epic]]` per `## Epic N:` in `epics.md`, in that order, `id = N`, `slug = "epic-"`, `title`, `covers` the FR ids the coverage map assigns to that epic. `after = [{ epic = , needs = "..." }]` only where `epics.md` states what one epic needs from another; that line records the need, and the gate is `after: [epic-]` in the dependent epic's own file, which holds every ticket under it until the named epic is done. Write both. @@ -147,7 +147,7 @@ A `spec-/` that holds `stories.yaml` and `stories/` represents a planned b ## Configuration -Record `active_initiative = "initiative-"` under `[modules.bmm]` in `_bmad/custom/config.user.toml`, creating the file if needed. When the store moved (`workspace`), set `output_folder` under `[core]` in `_bmad/custom/config.toml`, the committed team override, never in the installer-managed `_bmad/config.toml`. Leave `planning_artifacts` and `implementation_artifacts` alone; `bmad setup` owns the rest of `_bmad/`. Then run the ticketing skill's store setup (`bmad-preview-ticketing/references/store-setup.md`) so `_bmad/custom/ticketing-store-config.toml` exists; the repo store is the match for a migrated tree, and its root is the one the plan already settled, not a new recommendation. Empty v6 folders left behind are removed; git never held them. +Record `active_initiative = "initiative-"` under `[modules.bmm]` in `_bmad/custom/config.user.toml`, creating the file if needed. When the store moved (`workspace`), set `output_folder` under `[core]` in `_bmad/custom/config.toml`, the committed team override, never in the installer-managed `_bmad/config.toml`. Leave `planning_artifacts` and `implementation_artifacts` alone; `bmad setup` owns the rest of `_bmad/`. Then run `bmad-ticket`'s store setup (`bmad-ticket/references/store-setup.md`) so `_bmad/custom/ticketing-store-config.toml` exists; the repo store is the match for a migrated tree, and its root is the one the plan already settled, not a new recommendation. Empty v6 folders left behind are removed; git never held them. ## Order of work