ma-agents 3.13.2 → 3.14.1

package/lib/bmad-extension-plugin/skills/bmad-dev-epic/customize.toml

@@ -0,0 +1,54 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-dev-epic. Mirrors the workflow
+# customization shape under the [workflow] namespace. Override in
+# {project-root}/_bmad/custom/bmad-dev-epic.toml (team) or
+# {project-root}/_bmad/custom/bmad-dev-epic.user.toml (personal).
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
+
+# ── Orchestration defaults ──────────────────────────────────────────────────
+# These are PROPOSED defaults the intake step shows the user; the user can
+# override every one of them at runtime. They are tier-abstract on purpose so
+# the skill works on disconnected networks and with non-Claude runtimes.
+#
+# All keys below are scalars, so a team/user override TOML replaces them by the
+# normal scalar-override merge rule (override wins over base).
+
+[workflow.defaults]
+
+# Model tiers are ABSTRACT. The intake step maps each tier to a concrete model
+# that the runtime actually exposes (Claude Opus/Sonnet, Gemini, a local model,
+# etc.). If only one model is available, both tiers collapse to it.
+#   review_tier  → deep reasoning: create-story, code-review, edge-case-hunter,
+#                  epic adversarial review.
+#   exec_tier    → implementation: dev-story, fix loops, e2e generation.
+review_tier_model = "claude-opus"          # proposed; ask at runtime
+exec_tier_model   = "claude-sonnet"        # proposed; ask at runtime
+
+# Max story pipelines running concurrently within a single wave.
+max_parallel_stories = 3
+
+# Max review→fix→re-review rounds before a story is escalated as blocked.
+fix_loop_cap = 2
+
+# Parallelization strategy: "waves" (dependency-aware) | "sequential" | "full".
+parallelism_strategy = "waves"
+
+# Human gates. Dev + review run unattended; these two are always confirmed.
+gate_before_publish = true
+gate_before_pr      = true
+
+# Release behavior at the publish gate.
+npm_dist_tag        = "beta"
+version_bump        = "prerelease"         # npm version <bump> --preid=beta
+pack_ignore_scripts = true                 # avoid Windows prepare tarball leak

package/lib/bmad-extension-plugin/skills/bmad-dev-epic/references/story-pipeline.md

@@ -0,0 +1,112 @@
+# Per-Story Pipeline Contract
+
+This is the self-contained instruction set handed to each story subagent. The
+orchestrator fills the `<…>` placeholders before spawning. The subagent owns
+exactly one story, in exactly one worktree, and never touches the epic branch.
+
+---
+
+## Inputs (filled by the orchestrator)
+
+```
+STORY_ID        = <id>
+STORY_TITLE     = <title>
+EPIC_ID         = <epic-id>
+EPIC_BRANCH     = feature/epic-<epic-id>
+STORY_BRANCH    = feature/epic-<epic-id>-story-<id>
+WORKTREE        = .worktrees/epic-<epic-id>-story-<id>
+SPRINT_STATUS   = <path to sprint-status.yaml>
+EXEC_MODEL      = <execution-tier model | "host-default">
+REVIEW_MODEL    = <review-tier model | "host-default">
+FIX_LOOP_CAP    = <n>
+TEST_CMD        = <project test/build gate>
+```
+
+## Setup
+
+All git follows `git-workflow-skill`; the only override is the base branch
+(the story branch is cut from `<EPIC_BRANCH>`, not `dev`).
+
+1. Create the worktree off the epic branch, per `git-workflow-skill` (manual
+   form shown, base overridden to the epic branch):
+   ```bash
+   git worktree add <WORKTREE> -b <STORY_BRANCH> <EPIC_BRANCH>
+   ```
+2. Work **only** inside `<WORKTREE>`. Use the Conventional Commit format the
+   skill enforces (`feat`, `fix`, `test`, `docs`, `refactor`, `chore`, `ci`),
+   scoped to the story. Honor the skill's git hooks.
+
+## Pipeline
+
+### 1. Create story spec — `bmad-create-story` [REVIEW_MODEL]
+Produce the context-filled spec for `<STORY_ID>`. If the spec already exists and
+is complete, validate it instead of regenerating. The spec's acceptance criteria
+(ACs) are the contract for the Definition of Done.
+
+**INVEST & size gate (before implementing).** Once the spec is fleshed out,
+re-check it against INVEST and the sizing/focus heuristics (same criteria as
+step-02): one focused goal, small enough to reach Definition of Done in this
+single pass, testable ACs. A spec often only reveals its true size here. **If
+the story is too large or pursues more than one goal, do NOT implement it** —
+return immediately with `status: needs-split` and a `split_proposal` (the
+smallest set of INVEST-compliant sub-stories, each with a focused goal, derived
+ids, and refined dependencies). The orchestrator owns the split because it
+affects the epic-wide wave plan (see step-04). Only proceed to step 2 when the
+story passes the gate.
+
+### 2. Implement — `bmad-dev-story` [EXEC_MODEL]
+Implement strictly against the spec. Follow the repo's always-load skills
+(language best-practices, logging, test-accompanied-development, etc.). Commit.
+
+### 3. Adversarial + edge-case review (PARALLEL) [REVIEW_MODEL]
+Run both, ideally as parallel sub-subagents, each seeing the story diff:
+- `bmad-code-review` — full adversarial review against spec + context.
+- `bmad-review-edge-case-hunter` — exhaustive boundary/branch analysis.
+Collect both findings sets.
+
+### 4. Triage & fix loop [EXEC_MODEL]
+Classify findings as **blocking** (correctness, security, AC miss, broken build)
+vs **non-blocking** (style, nits). For blocking findings:
+- Run `bmad-dev-story` to fix them. Commit.
+- Re-review **only the changed surface**.
+- Repeat until no blocking findings remain OR `FIX_LOOP_CAP` rounds are used.
+- If the cap is hit with blocking findings remaining → return `status: blocked`
+  with the unresolved findings. Do not merge, do not paper over.
+Record non-blocking findings in the return notes (not fixed, by design).
+
+### 5. E2E tests — `bmad-qa-generate-e2e-tests` [EXEC_MODEL]
+Generate e2e/automated tests for the story's behavior and **run them**. Also run
+`<TEST_CMD>` to confirm the story didn't break the package build. If e2e cannot
+be made green within the fix budget, return `status: blocked` with details.
+
+### 6. Definition of Done (gate before returning ready)
+ALL must hold, or the story is `blocked`:
+- [ ] All spec acceptance criteria implemented.
+- [ ] No blocking findings remain from either reviewer.
+- [ ] E2E tests written and passing.
+- [ ] `<TEST_CMD>` passes on the story branch (modulo known pre-existing failures).
+- [ ] All work committed with Conventional Commit messages.
+
+## Return value (structured)
+
+```
+{
+  "story_id":            "<STORY_ID>",
+  "status":              "merged-ready" | "blocked" | "needs-split",
+  "branch":              "<STORY_BRANCH>",
+  "worktree":            "<WORKTREE>",
+  "commits":             [ "<sha> <subject>", … ],
+  "e2e_status":          "passing" | "failing" | "not-created",
+  "unresolved_findings": [ "<blocking finding>", … ],
+  "split_proposal":      [ { "id": "<S3a>", "goal": "<focused goal>", "acs": [ … ], "depends_on": [ … ] }, … ],
+  "fix_rounds_used":     <n>,
+  "notes":               "<non-blocking findings, decisions, caveats>"
+}
+```
+
+`split_proposal` is populated only when `status: needs-split` (empty/omitted
+otherwise). On `needs-split` the subagent has done **no** implementation — it
+returns the proposal and stops.
+
+**Do NOT** merge into `<EPIC_BRANCH>`. The orchestrator serializes all
+integration into the epic branch (step-04) to avoid parallel-merge races.

package/lib/bmad-extension-plugin/skills/bmad-dev-epic/steps/step-01-intake.md

@@ -0,0 +1,59 @@
+# Step 01 — Intake & Guided Configuration
+
+**Goal:** Confirm the epic exists and is ready, then collect the run configuration through guided questions. Nothing is spawned and no branch is created until this step completes.
+
+## 1. Locate and validate the epic (PRECONDITION)
+
+This skill *runs* an epic; it does not invent one. Find the target epic:
+
+1. Read `{sprint_status}` (`{implementation_artifacts}/sprint-status.yaml`) and the epics/stories planning artifacts under `{planning_artifacts}`.
+2. If the user named an epic (id or title), select it. Otherwise list candidate epics and **HALT** for the user to choose.
+3. Enumerate the epic's stories. For each story capture: id, title, status, and declared dependencies / "depends on" / prerequisite references.
+
+**If the epic has no stories**, or stories are placeholders without acceptance criteria: STOP and tell the user to run `bmad-create-epics-and-stories` (and `bmad-sprint-planning`) first. Do not fabricate stories.
+
+**If some stories are already `done`/`merged`**: by default skip them (treat as satisfied dependencies). Confirm this with the user.
+
+## 2. Ask the guided questions
+
+Ask these as a single grouped set (use the host's structured-question UI if available; otherwise a numbered list). Show the proposed default from `{workflow.defaults}` for each and accept "use defaults".
+
+1. **Model tiers (tier-abstract — critical for disconnected/non-Claude runtimes).**
+   First ask: *what models does this runtime actually expose?* Then map:
+   - `{review_model}` — deep reasoning tier (create-story, code-review, edge-case-hunter, epic adversarial review). Default: `{workflow.defaults.review_tier_model}`.
+   - `{exec_model}` — execution tier (dev-story, fix loops, e2e). Default: `{workflow.defaults.exec_tier_model}`.
+   - If only ONE model is available (air-gapped local model, or a single-provider CLI), **collapse both tiers to it** and note that tier separation is disabled.
+   - If the runtime is not Claude (e.g. Gemini, Codex, a local model) or does not support per-subagent model selection, record the mapping anyway but note it is **best-effort**: subagents will use whatever model the host assigns. Never block on this.
+
+2. **Parallelism strategy** — default `{workflow.defaults.parallelism_strategy}`:
+   - `waves` (recommended): dependency-aware; independent stories run in parallel, dependents wait for their predecessors to merge.
+   - `sequential`: one story fully done before the next.
+   - `full`: all stories at once (warn: ignores dependencies; high merge-conflict / broken-build risk).
+
+3. **Max parallel stories per wave** — default `{workflow.defaults.max_parallel_stories}`. Cap to what the host can sanely run concurrently.
+
+4. **Fix-loop cap** — default `{workflow.defaults.fix_loop_cap}`. Max review→fix→re-review rounds before a story is escalated as `blocked`.
+
+5. **Release gates** — confirm both default to ON: pause before npm publish (`{workflow.defaults.gate_before_publish}`) and before the epic PR (`{workflow.defaults.gate_before_pr}`). Confirm `{workflow.defaults.npm_dist_tag}` (default `beta`) and the version bump (default `{workflow.defaults.version_bump}`).
+
+6. **Test command** — the project's real test/build gate for the package-integrity check (step-05). Propose `npm run build:plugin` plus the targeted test subset; confirm. (Note: bare `npm test` has a known pre-existing CRLF failure on Windows — see step-05; do not rely on its exit code alone.)
+
+## 3. Record the resolved configuration
+
+Write the resolved config into the Run Ledger header and mirror it to
+`{implementation_artifacts}/epic-runs/<epic-id>/run-ledger.md`:
+
+```
+Epic:            <id> — <title>
+Stories:         <n> ( <ids…> )   skipped(done): <ids…>
+review_model:    <model>          exec_model: <model>   (tiers collapsed: yes/no)
+strategy:        <waves|sequential|full>   max_parallel: <n>   fix_cap: <n>
+gates:           publish=<on/off>  pr=<on/off>   dist-tag=<tag>  bump=<bump>
+test_gate:       <command(s)>
+```
+
+## 4. Confirm and proceed
+
+Present the resolved config in one compact block and **HALT for a single go/no-go confirmation**. This is the last broad confirmation — after "go", stories run unattended through to the two release gates.
+
+On "go": read fully and follow `./steps/step-02-plan-waves.md`.

package/lib/bmad-extension-plugin/skills/bmad-dev-epic/steps/step-02-plan-waves.md

@@ -0,0 +1,56 @@
+# Step 02 — Right-Size Stories, Build the Dependency DAG, Compute Waves
+
+**Goal:** Make the story set sound (INVEST-compliant, focused, appropriately small) and then turn it into an ordered set of execution waves so independent stories parallelize and dependents only start once their prerequisites are merged.
+
+## 1. INVEST & story-sizing pre-pass
+
+Before graphing dependencies, assess **every** non-skipped story against **INVEST**:
+
+- **I**ndependent — minimal coupling to other stories (soft-couples become dependency edges in §2, not blockers).
+- **N**egotiable — describes intent, not a frozen implementation.
+- **V**aluable — delivers a discrete, demonstrable slice of user/system value.
+- **E**stimable — small and clear enough to estimate with confidence.
+- **S**mall — completable within a single focused pipeline run; **one** focused goal.
+- **T**estable — has acceptance criteria that can be verified (and later turned into e2e tests).
+
+**Sizing / focus heuristics — a story is "too long" and should be split if any hold:**
+- it pursues more than one distinct goal, or its title contains "and" joining separable outcomes;
+- it spans multiple unrelated modules/layers that could ship and be tested independently;
+- its acceptance criteria are so numerous that they read like several stories stapled together;
+- it cannot plausibly reach Definition of Done (implement + review + e2e) in one focused pass.
+
+**When a story is too large or multi-goal:** split it into the smallest set of INVEST-compliant sub-stories, each with one focused goal and its own acceptance criteria. Preserve the original as a parent/epic-let reference, give sub-stories derived ids (e.g. `S3` → `S3a`, `S3b`), and carry over / refine dependencies. **Present the proposed split to the user and HALT for confirmation** before committing it to `sprint-status.yaml` (splitting changes the planned scope). Record the final, right-sized story set — it is the input to §2.
+
+> This is the planning-time pass. The per-story pipeline (`references/story-pipeline.md`) re-checks INVEST after `bmad-create-story` and can still return `needs-split` if a story only reveals its true size once its spec is fleshed out — see step-04's handling.
+
+## 2. Build the dependency graph
+
+For every non-skipped story, resolve its dependencies into a directed graph (edge `A → B` means "A depends on B; B must merge first"). Sources of dependencies, in priority order:
+
+1. Explicit `depends_on` / prerequisite fields in `sprint-status.yaml` or the story spec.
+2. Stated dependencies in the epic / story prose ("requires the API from story X").
+3. Shared-file heuristics: if two stories are known to edit the same module, treat them as a soft conflict (same-wave concurrency risk) and prefer to sequence them.
+
+## 3. Detect cycles
+
+Run a topological sort. **If a cycle exists**, STOP and report the cycle to the user — a circular dependency cannot be waved automatically. Offer to (a) break the cycle by merging the stories, or (b) force a user-specified order.
+
+## 4. Compute waves by strategy
+
+- **`waves`** (default): Wave *k* = all stories whose dependencies are all satisfied by waves `< k`. Within a wave, cap concurrent pipelines at `max_parallel_stories`; if a wave is larger, run it in batches.
+- **`sequential`**: one story per wave, in topological order.
+- **`full`**: a single wave of all stories (only if the user explicitly chose this; re-warn about conflict risk).
+
+## 5. Present the plan
+
+Show the wave plan compactly and record it in the Run Ledger:
+
+```
+Wave 1:  S1, S2, S3        (independent)
+Wave 2:  S4 (needs S1), S5 (needs S2)
+Wave 3:  S6 (needs S4,S5)
+```
+
+Do **not** HALT here (the user already gave go in step-01) — but if the computed plan reveals a problem the user could not have anticipated (e.g. every story is sequential and the user expected parallelism, or a story has unresolved/dangling dependencies), surface it in one line and HALT for a decision.
+
+Then read fully and follow `./steps/step-03-epic-branch.md`.

package/lib/bmad-extension-plugin/skills/bmad-dev-epic/steps/step-03-epic-branch.md

@@ -0,0 +1,35 @@
+# Step 03 — Create the Epic Feature Branch
+
+**Goal:** Establish the integration branch for the whole epic, off the trunk, before any story work begins. This is the branch the final PR targets `main` from, and the branch every story branch merges back into.
+
+## Branch topology (the contract)
+
+```
+main
+  └── feature/epic-<epic-id>                 ← epic integration branch (this step)
+        ├── feature/epic-<epic-id>-story-<s1>   ← per-story branch (step-04, own worktree)
+        ├── feature/epic-<epic-id>-story-<s2>
+        └── …                                    each merges back into feature/epic-<epic-id>
+```
+
+- The **epic branch** is cut from `main` (this repo's trunk; confirm the trunk name — `main` here).
+- Each **story branch** is cut from the **epic branch**, developed in its own worktree, and merged back into the epic branch when it passes its Definition of Done (step-04). Stories integrate with `--no-ff` so each story is one reviewable merge commit. No PR per story (the user approves only the epic PR).
+- The single **epic PR** (step-06) is `feature/epic-<epic-id>` → `main`.
+
+## Procedure
+
+All git here follows `git-workflow-skill`. The only epic-specific override is the **base branch**: the epic branch is cut from the **trunk** (`main`), not from `dev`.
+
+1. Follow `git-workflow-skill` to create the epic worktree + feature branch, with the base overridden to the trunk. Use its `start-feature.sh` if it accepts a base argument; otherwise use the skill's documented **manual** equivalent:
+   ```bash
+   git fetch origin
+   # git-workflow-skill manual form, base overridden to the trunk:
+   git worktree add .worktrees/epic-<epic-id> -b feature/epic-<epic-id> main
+   ```
+   (`.worktrees/` is gitignored in this repo. Confirm the trunk name first — `main` here. Ensure the skill's git hooks are installed so commit-message/branch protections apply.)
+2. Record the epic worktree path and branch in the Run Ledger.
+3. Story worktrees are created later, one per story, branched from `feature/epic-<epic-id>` — see step-04.
+
+**Do not** write any non-git file outside a worktree from here on. All story output lands in story worktrees; all integration lands on the epic branch.
+
+Then read fully and follow `./steps/step-04-run-waves.md`.

package/lib/bmad-extension-plugin/skills/bmad-dev-epic/steps/step-04-run-waves.md

@@ -0,0 +1,49 @@
+# Step 04 — Run the Waves (Parallel Per-Story Pipelines)
+
+**Goal:** Execute each wave by spawning one subagent per story, each running the full per-story pipeline in its own worktree, then integrating passing stories back into the epic branch. This is the core of the orchestration.
+
+## How subagents are used
+
+- Spawn **one subagent per story** using the host's Agent/Task tool. Put all spawns for a wave (up to `max_parallel_stories`) in a **single response** so they run concurrently.
+- Each subagent is **stateless w.r.t. this conversation** — it receives a self-contained prompt (the story-pipeline contract below) plus the paths it needs. It must not assume access to the orchestrator's context.
+- Assign each subagent the model implied by the step it is running (`{review_model}` vs `{exec_model}`). Because a single subagent runs multiple BMAD skills across both tiers, prefer this split:
+  - If the host supports per-skill model switching inside one subagent, instruct it to use `{review_model}` for create-story/code-review/edge-case-hunter and `{exec_model}` for dev-story/fixes/e2e.
+  - If not, run the story as **two chained subagents**: an `{exec_model}` "builder" and a `{review_model}` "reviewer", handing the worktree between them.
+  - If model selection is unavailable (non-Claude / single-model runtime), run one subagent and note tiers are collapsed.
+
+## Per-story pipeline (the contract every story subagent runs)
+
+Give each story subagent the full contract in `references/story-pipeline.md` (skill-root–relative). The inline summary below is **illustrative only** — `references/story-pipeline.md` is the authoritative contract; if they diverge, the reference file wins. In summary, in the story's own worktree branched from the epic branch:
+
+1. `bmad-create-story` → produce the context-filled story spec.            [review tier]
+2. `bmad-dev-story` → implement against the spec.                          [exec tier]
+3. Parallel review: `bmad-code-review` **and** `bmad-review-edge-case-hunter`. [review tier]
+4. Triage findings → if any are blocking, `bmad-dev-story` fix loop (cap `fix_loop_cap`), then re-review only the changed surface. [exec tier]
+5. `bmad-qa-generate-e2e-tests` → generate e2e tests and run them.          [exec tier]
+6. Enforce the **Definition of Done** (review clean + e2e green + spec ACs met). Commit with Conventional Commits.
+
+The subagent returns a structured result: `{story_id, status: merged-ready|blocked|needs-split, branch, worktree, commits, unresolved_findings[], split_proposal[], e2e_status, notes}`. It must **not** merge to the epic branch itself — the orchestrator integrates (step below) to keep merges serialized. A `needs-split` result means the story was found too large/multi-goal at spec time and was **not** implemented — the orchestrator handles the split (see below).
+
+## Wave loop
+
+For each wave in order:
+
+1. **Spawn** the wave's story subagents in parallel (respect `max_parallel_stories`; batch if larger). Mark each story `in-progress` in the Run Ledger.
+2. **Collect** results as subagents return. Update the Ledger per story.
+3. **Handle `needs-split` results**: the story was found too large/multi-goal and was not implemented. Apply its `split_proposal`: present the proposed sub-stories to the user and **HALT for confirmation** (splitting changes planned scope), then add the confirmed sub-stories to `sprint-status.yaml`, replace the parent in the Ledger, recompute affected dependencies/waves (re-enter step-02's §2–§4 for just the new stories), and schedule the sub-stories into the current wave (if independent) or a later wave. Discard the parent's unused story worktree/branch via `git-workflow-skill` cleanup.
+4. **Integrate** each `merged-ready` story into the epic branch, **one at a time** (serialized), from the epic worktree (use the epic worktree path recorded in the Run Ledger, not a re-derived guess). Use `git-workflow-skill` conventions; the merge into the epic branch is the epic-specific manual step:
+   ```bash
+   git -C <epic-worktree> merge --no-ff feature/epic-<epic-id>-story-<sid>
+   ```
+   - On a **merge conflict**: do not guess. Spawn an `{exec_model}` subagent scoped to resolve only that conflict against both stories' intent, or HALT and report if it cannot. Re-run that story's e2e after resolution.
+   - After a successful merge, run the project build/test gate (the step-01 `test_gate`) on the epic branch to catch cross-story breakage early. If it breaks, treat as a blocking finding against the just-merged story.
+5. **Blocked stories**: a story that exhausts `fix_loop_cap` without converging, or whose e2e cannot pass, is marked `blocked` with its `unresolved_findings`. Do **not** silently drop it. Continue the epic with the rest, but record it for the step-05 report and the PR description. If a *downstream* story depends on a blocked story, mark the dependents `blocked (upstream)` and skip their wave entry.
+6. Clean up each story worktree after its merge, per `git-workflow-skill` (manual form: `git worktree remove .worktrees/epic-<epic-id>-story-<sid>`).
+
+**Persist the Run Ledger to disk** (`{implementation_artifacts}/epic-runs/<epic-id>/run-ledger.md`) after integrating each story and again at the end of each wave, so a crashed run can be resumed without redoing merged stories.
+
+Proceed to the next wave only when the current wave's stories are all `merged` or `blocked`.
+
+## After all waves
+
+Record the final tally in the Run Ledger (merged / blocked / skipped) and persist it to disk. Then read fully and follow `./steps/step-05-epic-adversarial.md`.

package/lib/bmad-extension-plugin/skills/bmad-dev-epic/steps/step-05-epic-adversarial.md

@@ -0,0 +1,31 @@
+# Step 05 — Epic-Level Adversarial Review & Package-Integrity Gate
+
+**Goal:** Before any release action, prove that the assembled epic (all merged stories on the epic branch) aligns with requirements + architecture and did **not** break the `ma-agents` package. Operate on the integrated epic branch, not individual stories.
+
+## 1. Adversarial alignment review — `bmad-review-adversarial-general` [REVIEW_MODEL]
+
+Run a cynical, whole-epic review against the full diff `main...feature/epic-<epic-id>`:
+- Does the implementation satisfy the epic's requirements and acceptance criteria?
+- Does it conform to the project architecture / `project-context.md` and the always-load standards?
+- Cross-story coherence: do the merged stories form a consistent whole, or did parallel development introduce contradictions, dead code, or duplicated abstractions?
+- Did anything regress in adjacent, untouched areas?
+
+Produce a findings report graded by severity. **Blocking** findings (requirement/architecture violation, regression, broken contract) must be remediated: spawn an `{exec_model}` fix subagent scoped to the finding, re-run the relevant story/epic tests, and re-review. Loop within reason; if blocking findings cannot be cleared, **HALT** and report to the user — do not proceed to release with known blocking findings.
+
+## 2. Package-integrity gate (the "didn't break ma-agents" check)
+
+Run the real gate on the epic branch — **not** bare `npm test` alone:
+
+1. **Plugin build must pass:** `npm run build:plugin` (assembles `lib/bmad-extension-plugin/`). A failure here is a hard stop.
+2. **Bundle-drift guard:** after building, confirm `lib/bmad-extension-plugin/` and the resolved `marketplace.json` are up to date with the source (`lib/bmad-extension/`). If this epic added/renamed skills or bumped `module.yaml`, the rebuilt bundle must be committed. CI enforces this ("Bundle Drift Guard") — catch it here first.
+3. **Targeted tests:** run the test subset relevant to what the epic changed.
+4. **Known pre-existing failure:** a full `npm test` on Windows exits non-zero due to long-standing MIL-498 template CRLF drift (halts around position 13) and also regenerates `.agents/`. **Do not** classify that specific known failure as an epic regression. Distinguish new failures from the baseline: if in doubt, run the same command on `main` and diff the failure set. Only *new* failures block.
+
+Record the gate outcome (build: pass/fail, drift: clean/committed, tests: new-failures vs baseline) in the Run Ledger.
+
+## 3. Gate decision
+
+- All blocking adversarial findings cleared **and** package-integrity gate clean (no new failures, build green, no uncommitted bundle drift) → proceed.
+- Otherwise → **HALT**, report exactly what is blocking, and let the user decide whether to fix-and-retry or stop.
+
+On pass, read fully and follow `./steps/step-06-release.md`.

package/lib/bmad-extension-plugin/skills/bmad-dev-epic/steps/step-06-release.md

@@ -0,0 +1,57 @@
+# Step 06 — Gated Beta Publish & Epic PR
+
+**Goal:** Ship a testable beta package and open the epic PR — both behind explicit human gates. These are the only two outward, hard-to-undo actions in the run.
+
+## Self-review before anything (mandatory)
+
+Per repo policy, run the `code-review` skill on the full epic diff (`main...feature/epic-<epic-id>`) and address its findings before opening the PR. This is in addition to the per-story reviews — it catches integration-level issues.
+
+## GATE A — npm beta publish
+
+Only if `{workflow.defaults.gate_before_publish}` (default ON). **HALT and ask the user to confirm** before running any publish command. Publishing is effectively irreversible (a version can be deprecated but not truly unpublished after 72h) and requires credentials/2FA.
+
+On confirmation:
+
+1. **Bump version** on the epic branch using the configured bump `{workflow.defaults.version_bump}`:
+   ```bash
+   npm version {workflow.defaults.version_bump} --preid=beta --no-git-tag-version
+   ```
+   (default bump `prerelease` → e.g. `3.14.0` → `3.14.1-beta.0`). Commit the bump.
+2. **Rebuild the bundle** so `marketplace.json` carries the new version, and commit any drift: `npm run build:plugin`.
+3. **Pack** — when `{workflow.defaults.pack_ignore_scripts}` is true (the default), pass `--ignore-scripts` to avoid the known Windows `prepare` tarball leak (a temp build dir leaking into the tarball):
+   ```bash
+   npm pack --ignore-scripts          # omit --ignore-scripts only if pack_ignore_scripts = false
+   ```
+   Inspect the tarball contents (`tar -tzf <tgz>`) — confirm no stray temp/build directory is included.
+4. **Publish** to the channel `{workflow.defaults.npm_dist_tag}` (default `beta`; requires npm auth + OTP/2FA; the user supplies the OTP at the gate — never hardcode it). Match the `--ignore-scripts` choice from the pack step:
+   ```bash
+   npm publish --tag {workflow.defaults.npm_dist_tag} --ignore-scripts
+   ```
+   If 2FA prompts, surface it to the user. Confirm the publish with `npm view <pkg> dist-tags`.
+5. Tell the user the exact install line to test, e.g. `npm i ma-agents@beta` (or the resolved `@<version>`).
+
+If the user declines GATE A: skip publish, continue to GATE B (the PR can still be opened without a published beta).
+
+## GATE B — Epic Pull Request
+
+Only if `{workflow.defaults.gate_before_pr}` (default ON). **HALT and ask the user to confirm** before opening the PR.
+
+On confirmation, push the epic branch and open ONE PR (`feature/epic-<epic-id>` → `main`) following `git-workflow-skill`'s finish flow. The two epic-specific overrides vs. the skill's `finish-feature.sh` defaults: the PR **base is the trunk (`main`), not `dev`**, and there is **exactly one** PR for the whole epic (no per-story PRs). Use the skill's documented manual finish equivalent:
+
+```bash
+git -C <epic-worktree> push -u origin feature/epic-<epic-id>   # <epic-worktree> = path from the Run Ledger
+gh pr create --base main --head feature/epic-<epic-id> --title "feat(epic-<id>): <epic title>" --body-file <generated-body>
+```
+
+The PR body (generated from the Run Ledger) must include:
+- Epic summary and link to the planning artifacts.
+- Per-story table: status (merged / **blocked** / skipped), e2e status, fix rounds, any unresolved non-blocking findings.
+- Adversarial review summary + package-integrity gate outcome.
+- The published beta version + install line (if GATE A ran).
+- An explicit **"Blocked / follow-up"** section if any story did not converge — never hide this.
+
+Credential note: if the default git/`gh` token is rejected, a working PAT may live in the location recorded in memory ("GitHub push credentials location"); use it masked. Never echo tokens.
+
+Do **not** merge the PR — the user approves and merges the epic PR themselves.
+
+Then read fully and follow `./steps/step-07-report.md`.

package/lib/bmad-extension-plugin/skills/bmad-dev-epic/steps/step-07-report.md

@@ -0,0 +1,40 @@
+# Step 07 — Final Report & Cleanup
+
+**Goal:** Leave the user with a complete, honest picture of the run and a clean working tree.
+
+## 1. Present the run summary
+
+From the Run Ledger, present (in `{communication_language}`):
+
+```
+Epic <id> — <title>   |   <merged>/<total> stories merged
+
+Stories
+  ✓ S1  merged    e2e: pass   fixes: 1
+  ✓ S2  merged    e2e: pass   fixes: 0
+  ⚠ S3  BLOCKED   <one-line reason + unresolved findings>
+  ⏭ S4  skipped (already done)
+
+Epic adversarial review : <pass | findings cleared: n>
+Package-integrity gate  : build ✓  drift ✓  tests: <new-failures: 0 vs baseline>
+Beta publish            : <version + install line | skipped/declined>
+Epic PR                 : <url | not opened>
+```
+
+## 2. Surface anything that needs the human
+
+- List every `blocked` story and exactly what is unresolved — these are the user's follow-ups.
+- Note any place the run HALTED and why.
+- If the beta publish or PR was declined/skipped, state the exact commands to do it manually.
+
+## 3. Cleanup
+
+- Remove any remaining story worktrees: `git worktree remove .worktrees/epic-<epic-id>-story-<sid>` (and `git worktree prune`).
+- Leave the **epic worktree and branch in place** until the user merges the PR — they may want to push fixes. After merge, the epic worktree can be removed with `git worktree remove .worktrees/epic-<epic-id>`.
+- Persist the final Run Ledger to `{implementation_artifacts}/epic-runs/<epic-id>/run-ledger.md`.
+
+## 4. Suggest next steps
+
+Recommend `bmad-retrospective` for the epic once the PR merges, and (if any stories were blocked) `bmad-correct-course` to re-plan them.
+
+This completes the workflow.

package/lib/bmad-extension-plugin/skills/ma-agent-sqa/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: ma-agent-sqa
-description: SQA Agent (Gad) — Software Quality Assurance and MIL-STD-498 expert for project auditing, compliance verification, quality reporting, and defense documentation generation
+description: SQA Agent (Gadi) — Software Quality Assurance and MIL-STD-498 expert for project auditing, compliance verification, quality reporting, and defense documentation generation
 ---
 
-# Agent: Gad — Software Quality Assurance & Standards Expert
+# Agent: Gadi — Software Quality Assurance & Standards Expert
 
 You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
 
@@ -35,7 +35,7 @@ You must fully embody this agent's persona and follow all activation instruction
 | # | Cmd | Action | Trigger | Skill |
 |---|-----|--------|---------|-------|
 | 1 | MH | Redisplay Menu Help | "menu", "help" | _(built-in)_ |
-| 2 | CH | Chat with Gad about quality assurance or MIL-STD-498 | "chat", "quality" | _(built-in)_ |
+| 2 | CH | Chat with Gadi about quality assurance or MIL-STD-498 | "chat", "quality" | _(built-in)_ |
 | **— SQA Workflows —** | | | | |
 | 3 | AU | Audit Project: Comprehensive quality audit across all project dimensions | "audit", "audit project", "run audit" | sqa-audit |
 | 4 | IC | IEEE 12207 Compliance: Evaluate the project against IEEE/ISO/IEC 12207 software lifecycle processes | "ieee", "12207", "lifecycle compliance", "iso 12207" | sqa-ieee12207 |

package/lib/bmad-extension-plugin/skills/ma-agent-sqa/bmad-skill-manifest.yaml

@@ -1,6 +1,6 @@
 type: agent
 name: ma-agent-sqa
-displayName: Gad
+displayName: Gadi
 title: Software Quality Assurance & Standards Expert
 icon: "🔍"
 capabilities: "Software quality assurance, project auditing, process compliance, requirements traceability, sprint health, release validation, IEEE/ISO/IEC 12207 compliance, MIL-STD-498 document generation (SRS, SDD, SDP, OCD, SSS, STD, SSDD)"

package/lib/bmad-extension-plugin/skills/module-help.csv

@@ -3,7 +3,7 @@ ma-skills,anytime,SRE Agent,ma-agent-sre,,skill:ma-agent-sre,ma-agent-sre,false,
 ma-skills,anytime,DevOps Agent,ma-agent-devops,,skill:ma-agent-devops,ma-agent-devops,false,bmm-devops,,"DevOps Engineer agent for CI/CD pipeline automation, Infrastructure as Code, and cloud-native technologies.",output_folder,"agent customization",
 ma-skills,anytime,Cyber Agent,ma-agent-cyber,,skill:ma-agent-cyber,ma-agent-cyber,false,bmm-cyber,,"Cyber Security Analyst agent for vulnerability assessment, threat modeling, and system hardening.",output_folder,"agent customization",
 ma-skills,anytime,ML Scientist Agent,ma-agent-ml,,skill:ma-agent-ml,ma-agent-ml,false,bmm-demerzel,,"Machine Learning Scientist agent for hypothesis-driven ML lifecycle with scientific rigor.",output_folder,"agent customization",
-ma-skills,anytime,SQA Agent,ma-agent-sqa,,skill:ma-agent-sqa,ma-agent-sqa,false,bmm-qa,,"Software Quality Assurance agent (Gad) for project auditing, compliance verification, and quality reporting.",output_folder,"agent customization",
+ma-skills,anytime,SQA Agent,ma-agent-sqa,,skill:ma-agent-sqa,ma-agent-sqa,false,bmm-qa,,"Software Quality Assurance agent (Gadi) for project auditing, compliance verification, and quality reporting.",output_folder,"agent customization",
 ma-skills,4-implementation,Generate SSS,mil498-sss,,skill:mil498-sss,bmad-mil-generate-sss,false,bmm-mil498,,"Generate a MIL-STD-498 System/Subsystem Specification (SSS).",output_folder,"MIL-498 document",
 ma-skills,4-implementation,Generate SSDD,mil498-ssdd,,skill:mil498-ssdd,bmad-mil-generate-ssdd,false,bmm-mil498,,"Generate a MIL-STD-498 System/Subsystem Design Description (SSDD).",output_folder,"MIL-498 document",
 ma-skills,4-implementation,Generate OCD,mil498-ocd,,skill:mil498-ocd,bmad-mil-generate-ocd,false,bmm-mil498,,"Generate a MIL-STD-498 Operational Concept Description (OCD).",output_folder,"MIL-498 document",
@@ -47,6 +47,7 @@ ma-skills,4-implementation,SQA Audit,sqa-audit,,skill:sqa-audit,sqa-audit,false,
 ma-skills,4-implementation,IEEE 12207 Compliance,sqa-ieee12207,,skill:sqa-ieee12207,sqa-ieee12207,false,bmm-qa,,"Evaluate the project against IEEE/ISO/IEC 12207:2017 software lifecycle processes — produces a compliance matrix and gap analysis report.",_bmad-output,"compliance report",
 ma-skills,4-implementation,Create Bug Story,create-bug-story,,skill:create-bug-story,create-bug-story,false,bmm-dev,,"Create a structured bug story from a detected defect and add to backlog.",_bmad-output/implementation-artifacts,"bug story",
 ma-skills,4-implementation,Dev Story,bmad-dev-story,,skill:bmad-dev-story,bmad-dev-story,false,bmm-dev,,"Execute story implementation following a context filled story spec file.",_bmad-output/implementation-artifacts,"story implementation",
+ma-skills,4-implementation,Dev Epic,bmad-dev-epic,,skill:bmad-dev-epic,bmad-dev-epic,false,bmm-dev,,"Orchestrate a full epic end-to-end with parallel subagents — per-story create/dev/review/edge-case/fix/e2e pipeline, dependency-aware waves, configurable model tiers, an epic-level adversarial + package-integrity gate, and gated beta publish + PR.",_bmad-output/implementation-artifacts,"epic run ledger + PR",
 ma-skills,4-implementation,Sprint Planning,bmad-sprint-planning,,skill:bmad-sprint-planning,bmad-sprint-planning,false,bmm-sm,,"Bootstrap or update the unified sprint-status.yaml from epics with three sections (epics, backlog, sprints).",_bmad-output/implementation-artifacts,"sprint plan",
 ma-skills,4-implementation,Generate Backlog,generate-backlog,,skill:generate-backlog,generate-backlog,false,bmm-sm,,"Generate or refresh the backlog section of sprint-status.yaml from epics and bug stories.",_bmad-output/implementation-artifacts,"backlog",
 ma-skills,4-implementation,Add Sprint,add-sprint,,skill:add-sprint,add-sprint,false,bmm-sm,,"Create a new sprint entry in the sprints section of sprint-status.yaml with capacity limits, optional ISO dates, and auto-incremented ID.",_bmad-output/implementation-artifacts,"sprint plan",

package/lib/bmad-extension-plugin/skills/module.yaml

@@ -15,6 +15,6 @@
 code: ma-skills
 name: "MA-Agents Skills & Agents"
 description: "Enterprise methodology enforcement, specialized agents, and operational workflows"
-module_version: "3.6.2"
+module_version: "3.7.0"
 extends-module: bmm
 default_selected: false

package/lib/bmad-extension-plugin/skills/sqa-audit/SKILL.md

@@ -172,7 +172,7 @@ After running all selected dimensions, compile a full audit report.
 ```
 # SQA Audit Report
 **Date:** {today's date}
-**Auditor:** Gad (SQA Agent)
+**Auditor:** Gadi (SQA Agent)
 **Scope:** {list of audited dimensions}
 **Overall Status:** PASS | WARNING | FAIL
 
@@ -246,7 +246,7 @@ If yes, generate and save a remediation plan to:
 ```
 # SQA Remediation Plan
 **Date:** {today's date}
-**Auditor:** Gad (SQA Agent)
+**Auditor:** Gadi (SQA Agent)
 **Source Report:** sqa-audit-report-{YYYY-MM-DD}.md
 **Scope:** {audited dimensions}
 

package/lib/bmad-extension-plugin/skills/sqa-ieee12207/SKILL.md

@@ -193,7 +193,7 @@ Evaluate each selected process group. For each process area, assign a compliance
 
 ### Group 4 — Organizational Project-Enabling Processes
 
-Note to Gad: For Group 4 items, briefly assess based on available evidence only. These are primarily organizational-scope and marked accordingly.
+Note to Gadi: For Group 4 items, briefly assess based on available evidence only. These are primarily organizational-scope and marked accordingly.
 
 #### 4.1 Life Cycle Model Management (6.2.1)
 - Is a defined software life cycle model being followed?
@@ -216,7 +216,7 @@ Compile the full compliance report.
 ```
 # IEEE/ISO/IEC 12207:2017 Compliance Report
 **Date:** {today's date}
-**Auditor:** Gad (SQA Agent)
+**Auditor:** Gadi (SQA Agent)
 **Standard:** IEEE/ISO/IEC 12207:2017 — Systems and software engineering — Software life cycle processes
 **Scope:** {selected process groups}
 **Overall Compliance Level:** COMPLIANT | PARTIAL | NON-COMPLIANT
@@ -332,7 +332,7 @@ If yes, generate and save a remediation plan to:
 ```
 # IEEE/ISO/IEC 12207 Remediation Plan
 **Date:** {today's date}
-**Auditor:** Gad (SQA Agent)
+**Auditor:** Gadi (SQA Agent)
 **Source Report:** sqa-ieee12207-report-{YYYY-MM-DD}.md
 **Standard:** IEEE/ISO/IEC 12207:2017
 

package/lib/bmad-extension-plugin/skills/sqa-requirements-quality/SKILL.md

@@ -157,7 +157,7 @@ Compile the full report in this structure:
 ```
 # Requirements Quality Audit Report
 **Date:** {today's date}
-**Auditor:** Gad (SQA Agent)
+**Auditor:** Gadi (SQA Agent)
 **Scope:** {selected document sources}
 **Requirements Audited:** {total count}
 **Overall Quality Score:** {X}/{Y} ({P}%)
@@ -216,7 +216,7 @@ If yes, save a remediation plan to:
 ```
 # Requirements Quality Remediation Plan
 **Date:** {today's date}
-**Auditor:** Gad (SQA Agent)
+**Auditor:** Gadi (SQA Agent)
 **Source Report:** sqa-requirements-quality-report-{YYYY-MM-DD}.md
 
 ---