@ikunin/sprintpilot 2.3.0 → 2.3.1

package/README.md

@@ -192,13 +192,11 @@ Full handoff report format + ledger semantics: [docs/USAGE.md](docs/USAGE.md#han
 | `/sprint-autopilot-on` | Engage autonomous sprint execution |
 | `/sprint-autopilot-off` | Disengage and show status |
 | `/sprintpilot-update` | Check for updates and install the latest version |
-| `/sprintpilot-code-review` | Parallel 3-layer adversarial code review |
 | `/sprintpilot-codebase-map` | 5-stream brownfield codebase analysis |
 | `/sprintpilot-assess` | Tech debt, dependency audit, migration assessment |
 | `/sprintpilot-reverse-architect` | Extract architecture document from existing code |
 | `/sprintpilot-migrate` | 12-step legacy migration planning |
 | `/sprintpilot-research` | Parallel web research fan-out |
-| `/sprintpilot-party-mode` | Multi-persona BMad agent discussions |
 
 Multi-agent skill internals: [docs/USAGE.md](docs/USAGE.md#multi-agent-skills).
 
@@ -348,11 +346,9 @@ Decision matrix and additional knobs: [`modules/git/branching-and-pr-strategy.md
 
 ## Multi-Agent Intelligence
 
-Beyond the autopilot, 7 multi-agent skills launch parallel subagents for tasks that benefit from diverse perspectives.
+Beyond the autopilot, multi-agent skills launch parallel subagents for tasks that benefit from diverse perspectives.
 
-**`/sprintpilot-code-review`** — 3 reviewers run simultaneously: Blind Hunter (adversarial, diff only), Edge Case Hunter (codebase access), Acceptance Auditor (story spec). Findings triaged as **PATCH / WARN / DISMISS**. PATCH findings auto-applied as separate commits.
-
-**`/sprintpilot-codebase-map`** — 5 parallel agents scan an existing codebase: stack, architecture, quality, concerns, integrations. Output under `_bmad-output/codebase-analysis/`.
+**`/sprintpilot-codebase-map`** — 5 parallel agents scan an existing codebase: stack, architecture, quality, concerns, integrations. Output under `_bmad-output/codebase-analysis/`. Inspired by [GSD's map-codebase](https://github.com/gsd-build/get-shit-done) — see [NOTICES.md](NOTICES.md).
 
 **`/sprintpilot-assess`** — Dependency auditor (CVEs), debt classifier (prioritized), migration analyzer. Output: prioritized findings with severity / confidence / effort.
 
@@ -362,8 +358,6 @@ Beyond the autopilot, 7 multi-agent skills launch parallel subagents for tasks t
 
 **`/sprintpilot-research`** — Fan out research across multiple topics in parallel; synthesized into a unified report.
 
-**`/sprintpilot-party-mode`** — 2–3 BMad personas (architect, PM, QA, dev) debate a topic over multiple rounds. Output: consensus points, disagreements, action items.
-
 Skill internals + output schemas: [docs/USAGE.md](docs/USAGE.md#multi-agent-skills).
 
 ## Requirements

package/_Sprintpilot/Sprintpilot.md

@@ -178,13 +178,11 @@ These launch parallel subagents for deeper, faster analysis:
 
 | Skill | Agents | When to use |
 |-------|--------|-------------|
-| `sprintpilot-code-review` | 3 | Parallel adversarial code review (Blind Hunter + Edge Case + Acceptance) |
 | `sprintpilot-codebase-map` | 5 | Brownfield codebase mapping (stack, architecture, quality, concerns, integrations) |
 | `sprintpilot-assess` | 3 | Tech debt assessment (dependency audit, debt classification, migration analysis) |
 | `sprintpilot-reverse-architect` | 3 | Extract architecture from existing code (components, data flow, patterns) |
 | `sprintpilot-migrate` | 4 | Full migration planning — 12 steps from current stack to target stack |
 | `sprintpilot-research` | N | Parallel research fan-out with web search |
-| `sprintpilot-party-mode` | 2-3 | Multi-persona discussion (architect, PM, QA, etc. debating in parallel) |
 
 ### Brownfield analysis pipeline
 

package/_Sprintpilot/manifest.yaml

@@ -1,6 +1,6 @@
 addon:
   name: sprintpilot
-  version: 2.3.0
+  version: 2.3.1
   description: Sprintpilot — autopilot and multi-agent addon for BMad Method (git workflow, parallel agents, autonomous story execution)
   bmad_compatibility: ">=6.2.0"
   modules:
@@ -17,13 +17,11 @@ addon:
     - sprint-autopilot-on
     - sprint-autopilot-off
     - sprintpilot-update
-    - sprintpilot-code-review
     - sprintpilot-codebase-map
     - sprintpilot-assess
     - sprintpilot-reverse-architect
     - sprintpilot-migrate
     - sprintpilot-research
-    - sprintpilot-party-mode
     - sprintpilot-plan-sprint
     - sprintpilot-sprint-progress
     - sprintpilot-dependency-graph

package/_Sprintpilot/skills/sprintpilot-codebase-map/agents/architecture-mapper.md

@@ -6,18 +6,20 @@ You are analyzing a codebase to identify system design patterns, module boundari
 
 Scan the project at `{{project_root}}` and write your findings to `{{output_file}}`.
 
-## Quality Bar
+## Output standard
 
-- **Patterns matter more than lists.** Don't just list directories — explain the architectural intent behind the structure.
-- **Be prescriptive, not descriptive.** Say "layered architecture with clean separation between API routes, services, and repositories" not "has multiple directories".
-- **Every finding needs a file path.** No claims without evidence.
+- **Show structure, don't just enumerate it.** Don't just list directories — explain the architectural intent behind the structure.
+- **Commit to a definite finding.** Say "layered architecture with clean separation between API routes, services, and repositories" not "has multiple directories".
+- **Cite the file path for every claim.** No assertion without evidence.
 - **Focus on boundaries.** What talks to what? Where are the seams?
 
-## Forbidden Files — NEVER Read
+## Off-limits files
 
-- `.env`, `.env.*` (secrets)
-- `*.key`, `*.pem`, `*.p12` (private keys)
-- `credentials.json`, `service-account.json`
+Do not open these. Note their existence in the file inventory but never read or quote their contents:
+
+- environment files (`.env`, `.env.<variant>`)
+- private keys and certs (`*.key`, `*.pem`, `*.p12`)
+- credential blobs (`credentials.json`, `service-account.json`)
 
 ## Ignore-file Awareness
 

package/_Sprintpilot/skills/sprintpilot-codebase-map/agents/concerns-hunter.md

@@ -6,19 +6,21 @@ You are scanning a codebase for tech debt, security issues, deprecated patterns,
 
 Scan the project at `{{project_root}}` and write your findings to `{{output_file}}`.
 
-## Quality Bar
+## Output standard
 
-- **Patterns matter more than lists.** Don't just count TODOs — assess systemic debt patterns.
-- **Be prescriptive, not descriptive.** Say "12 TODO comments in auth module suggest incomplete migration from session-based to JWT auth" not "found some TODOs".
-- **Every finding needs a file path and line number.**
+- **Look for systemic patterns, not isolated counts.** Don't just count TODOs — assess systemic debt patterns.
+- **Commit to a definite finding.** Say "12 TODO comments in auth module suggest incomplete migration from session-based to JWT auth" not "found some TODOs".
+- **Cite a file path and line number for every claim.**
 - **Severity must be justified.** CRITICAL = blocks features or security risk. HIGH = degrades reliability. MEDIUM = maintenance burden. LOW = cleanup opportunity.
 
-## Forbidden Files — NEVER Read
+## Off-limits files
 
-- `.env`, `.env.*` (secrets)
-- `*.key`, `*.pem`, `*.p12` (private keys)
-- `credentials.json`, `service-account.json`
-- Files in `.git/` directory
+Do not open these. Note their existence in the file inventory but never read or quote their contents:
+
+- environment files (`.env`, `.env.<variant>`)
+- private keys and certs (`*.key`, `*.pem`, `*.p12`)
+- credential blobs (`credentials.json`, `service-account.json`)
+- anything under `.git/`
 
 ## Ignore-file Awareness
 

package/_Sprintpilot/skills/sprintpilot-codebase-map/agents/integration-mapper.md

@@ -6,20 +6,22 @@ You are mapping all external dependencies, APIs, services, and data stores that
 
 Scan the project at `{{project_root}}` and write your findings to `{{output_file}}`.
 
-## Quality Bar
+## Output standard
 
-- **Patterns matter more than lists.** Don't just list env vars — explain the integration topology.
-- **Be prescriptive, not descriptive.** Say "uses Stripe via @stripe/stripe-node v13 for payment processing with webhook verification" not "appears to call Stripe".
-- **Every finding needs a file path.** No claims without evidence.
+- **Describe the topology, not just the catalog.** Don't just list env vars — explain the integration topology.
+- **Commit to a definite finding.** Say "uses Stripe via @stripe/stripe-node v13 for payment processing with webhook verification" not "appears to call Stripe".
+- **Cite the file path for every claim.** No assertion without evidence.
 - **Redact actual secrets.** Show variable names and patterns only. NEVER output real tokens, keys, or passwords.
 
-## Forbidden Files — NEVER Read Contents Of
+## Off-limits files
 
-- `.env`, `.env.local`, `.env.production` (actual secrets)
-- `*.key`, `*.pem`, `*.p12` (private keys)
-- `credentials.json`, `service-account.json`
+Do not open these. Note their existence but never quote contents:
 
-**DO read**: `.env.example`, `.env.sample`, `.env.template` (safe — contain variable names only)
+- environment files holding real values (`.env`, `.env.local`, `.env.production`)
+- private keys and certs (`*.key`, `*.pem`, `*.p12`)
+- credential blobs (`credentials.json`, `service-account.json`)
+
+**OK to read**: `.env.example`, `.env.sample`, `.env.template` — these contain variable names only, no secrets.
 
 ## Ignore-file Awareness
 

package/_Sprintpilot/skills/sprintpilot-codebase-map/agents/quality-assessor.md

@@ -6,18 +6,20 @@ You are analyzing a codebase to assess code quality, test coverage, CI/CD maturi
 
 Scan the project at `{{project_root}}` and write your findings to `{{output_file}}`.
 
-## Quality Bar
+## Output standard
 
-- **Patterns matter more than lists.** Don't just count test files — assess whether the test strategy is sound.
-- **Be prescriptive, not descriptive.** Say "unit tests cover services but not controllers — integration gap" not "some tests exist".
-- **Every finding needs a file path.** No claims without evidence.
+- **Assess strategy, don't just tally artifacts.** Don't just count test files — assess whether the test strategy is sound.
+- **Commit to a definite finding.** Say "unit tests cover services but not controllers — integration gap" not "some tests exist".
+- **Cite the file path for every claim.** No assertion without evidence.
 - **Ratios tell the story.** Test:source ratio, coverage gaps, CI stage completeness.
 
-## Forbidden Files — NEVER Read
+## Off-limits files
 
-- `.env`, `.env.*` (secrets)
-- `*.key`, `*.pem`, `*.p12` (private keys)
-- `credentials.json`, `service-account.json`
+Do not open these. Note their existence in the file inventory but never read or quote their contents:
+
+- environment files (`.env`, `.env.<variant>`)
+- private keys and certs (`*.key`, `*.pem`, `*.p12`)
+- credential blobs (`credentials.json`, `service-account.json`)
 
 ## Ignore-file Awareness
 

package/_Sprintpilot/skills/sprintpilot-codebase-map/agents/stack-analyzer.md

@@ -6,19 +6,21 @@ You are analyzing a codebase to produce a complete technology inventory.
 
 Scan the project at `{{project_root}}` and write your findings to `{{output_file}}`.
 
-## Quality Bar
+## Output standard
 
-- **Patterns matter more than lists.** Don't just list packages — explain what they're used for and how they fit together.
-- **Be prescriptive, not descriptive.** Say "uses React 18 with Server Components" not "appears to use React".
-- **Every finding needs a file path.** No claims without evidence (e.g., `package.json:15`).
+- **Show how parts connect.** Don't just list packages — explain what they're used for and how they fit together.
+- **Commit to a definite finding.** Say "uses React 18 with Server Components" not "appears to use React".
+- **Cite the file path for every claim.** No assertion without evidence (e.g., `package.json:15`).
 - **Version numbers are critical.** Always include the exact version, not "latest" or "recent".
 
-## Forbidden Files — NEVER Read
+## Off-limits files
 
-- `.env`, `.env.*` (secrets)
-- `*.key`, `*.pem`, `*.p12` (private keys)
-- `credentials.json`, `service-account.json`
-- `*.secret`, `*password*`, `*token*` (in filenames)
+Do not open these. Note their existence in the file inventory but never read or quote their contents:
+
+- environment files (`.env`, `.env.<variant>`)
+- private keys and certs (`*.key`, `*.pem`, `*.p12`)
+- credential blobs (`credentials.json`, `service-account.json`)
+- anything whose filename contains `secret`, `password`, or `token`
 
 ## Ignore-file Awareness
 

package/_Sprintpilot/skills/sprintpilot-codebase-map/workflow.md

@@ -1,6 +1,6 @@
 # Multi-Agent Codebase Map
 
-> Inspired by [GSD's map-codebase](https://github.com/gsd-build/get-shit-done). Adapted with distinct output format and enriched agent prompts.
+> Inspired by [GSD's map-codebase](https://github.com/gsd-build/get-shit-done) (MIT, Copyright (c) 2025 Lex Christopherson). Adapted with distinct output format and rewritten agent prompts. Full attribution: [NOTICES.md](../../../NOTICES.md).
 
 ## Purpose
 

package/lib/commands/install.js

@@ -1714,13 +1714,11 @@ async function runInstall(options = {}) {
   console.log('  autopilot start --no-auto-plan Skip auto-planning for one session');
   console.log('');
   console.log('Multi-agent skills — run parallel subagents for faster analysis:');
-  console.log('  /sprintpilot-code-review       Parallel 3-layer adversarial review');
   console.log('  /sprintpilot-codebase-map      5-stream brownfield codebase analysis');
   console.log('  /sprintpilot-assess            Tech debt and dependency audit');
   console.log('  /sprintpilot-reverse-architect Extract architecture from existing code');
   console.log('  /sprintpilot-migrate           Legacy migration planning');
   console.log('  /sprintpilot-research          Parallel web research');
-  console.log('  /sprintpilot-party-mode        Multi-persona agent discussions');
   console.log('');
   console.log('Documentation:');
   console.log('  Sprint planning walkthrough:   docs/USAGE.md');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ikunin/sprintpilot",
-  "version": "2.3.0",
+  "version": "2.3.1",
   "description": "Sprintpilot — autopilot and multi-agent addon for BMad Method v6: git workflow, parallel agents, autonomous story execution",
   "license": "Apache-2.0",
   "repository": {

package/_Sprintpilot/skills/sprintpilot-code-review/SKILL.md

@@ -1,6 +0,0 @@
----
-name: sprintpilot-code-review
-description: 'Parallel 3-layer code review via subagents. Launches Blind Hunter (adversarial), Edge Case Hunter, and Acceptance Auditor simultaneously. Collects results, triages findings, and produces prioritized patch list. Use instead of stock bmad-code-review for deeper, faster reviews.'
----
-
-Follow the instructions in ./workflow.md.

package/_Sprintpilot/skills/sprintpilot-code-review/agents/acceptance-auditor.md

@@ -1,51 +0,0 @@
-# Acceptance Auditor — Code Review Agent
-
-You are a QA auditor verifying that the implementation satisfies the story's acceptance criteria. You have the diff, the story file, and project access.
-
-## Rules
-
-- Every acceptance criterion (AC) must be explicitly verified against the code.
-- If an AC is NOT covered by the implementation, flag it as MISSING.
-- If an AC is partially covered, flag what's missing.
-- If the implementation does something NOT in the ACs, note it as EXTRA (not necessarily bad, but worth flagging).
-- Cap your response at 2000 tokens.
-
-## What to Check
-
-For each acceptance criterion in the story:
-1. **Implemented?** — Is there code that addresses this criterion?
-2. **Tested?** — Is there a test that verifies this criterion?
-3. **Correct?** — Does the implementation actually satisfy the criterion, or does it miss a nuance?
-
-Also check:
-4. **Task list completion** — Are all tasks and subtasks in the story file addressed?
-5. **File List accuracy** — Does the story's File List match the actual files changed?
-6. **No regressions** — Do the changes break any existing functionality visible in the diff?
-
-## Output Format
-
-```
-## AC Verification
-
-| AC | Status | Evidence | Notes |
-|----|--------|----------|-------|
-| AC-1: <text> | PASS/FAIL/PARTIAL | file:line | ... |
-| AC-2: <text> | PASS/FAIL/PARTIAL | file:line | ... |
-
-## Issues Found
-
-1. [SEVERITY] AC-N not satisfied — file:line
-   What's missing: ...
-   Suggested fix: ...
-
-2. ...
-
-## Extra (not in ACs)
-- <description of extra behavior>
-```
-
-If all ACs pass, say "All acceptance criteria verified" with the evidence table.
-
-## Story and Diff
-
-The story file content and diff follow below. Review them now.

package/_Sprintpilot/skills/sprintpilot-code-review/agents/blind-hunter.md

@@ -1,39 +0,0 @@
-# Blind Hunter — Adversarial Code Review Agent
-
-You are a ruthless code reviewer. You see ONLY the diff — no project context, no story, no acceptance criteria. Your job is to find bugs, vulnerabilities, and bad practices purely from the code changes.
-
-## Rules
-
-- You have NO project context. Do not ask for it. Review only what you see.
-- Be specific: cite exact file paths and line numbers.
-- Focus on things that will break in production, not style preferences.
-- Cap your response at 2000 tokens. Be concise.
-
-## What to Look For
-
-1. **Bugs**: null/undefined access, off-by-one, race conditions, resource leaks, incorrect logic
-2. **Security**: injection (SQL, XSS, command), auth bypass, exposed secrets, insecure defaults
-3. **Error handling**: swallowed exceptions, missing error paths, unchecked return values
-4. **Performance**: O(n²) in hot paths, unbounded allocations, missing pagination, N+1 queries
-5. **Type safety**: unchecked casts, any/unknown abuse, missing validation at boundaries
-
-## Output Format
-
-Return findings as a numbered list:
-
-```
-1. [SEVERITY] file:line — Title
-   Description of the issue.
-   Suggested fix: ...
-
-2. [SEVERITY] file:line — Title
-   ...
-```
-
-Severity: CRITICAL, HIGH, MEDIUM, LOW
-
-If the diff looks clean, say "No issues found" — do not manufacture findings.
-
-## Diff to Review
-
-The diff follows below. Review it now.

package/_Sprintpilot/skills/sprintpilot-code-review/agents/edge-case-hunter.md

@@ -1,46 +0,0 @@
-# Edge Case Hunter — Code Review Agent
-
-You are a methodical edge case analyst. You have access to the diff AND the project codebase (via Read, Grep, Glob tools). Your job is to find boundary conditions, missing validations, and scenarios the developer didn't consider.
-
-## Rules
-
-- Use Read/Grep/Glob to understand how changed code interacts with the rest of the codebase.
-- Think about inputs at the extremes: empty, null, max length, unicode, concurrent access, negative numbers.
-- Focus on cases that the tests probably DON'T cover.
-- Cap your response at 2000 tokens. Be concise.
-
-## What to Look For
-
-1. **Boundary conditions**: empty arrays, zero-length strings, max int, negative values
-2. **Missing validation**: user input not sanitized, API responses not checked, file paths not validated
-3. **State issues**: stale state after error, partial updates without rollback, cache invalidation gaps
-4. **Concurrency**: shared mutable state, missing locks, TOCTOU races
-5. **Integration boundaries**: API contract mismatches, schema drift, timezone handling, encoding issues
-6. **Error propagation**: errors swallowed at boundaries, misleading error messages, partial failure states
-
-## Method
-
-For each changed file in the diff:
-1. Read the full file (not just the diff) to understand context
-2. Grep for callers of changed functions to assess blast radius
-3. Think: "What input would make this fail?"
-4. Think: "What happens if the thing this calls fails?"
-
-## Output Format
-
-```
-1. [SEVERITY] file:line — Edge Case Title
-   Scenario: When <condition>, then <what goes wrong>
-   Impact: <what breaks>
-   Suggested fix: ...
-
-2. ...
-```
-
-Severity: CRITICAL, HIGH, MEDIUM, LOW
-
-If no edge cases found, say "No edge cases identified" — do not manufacture findings.
-
-## Diff to Review
-
-The diff follows below. Review it now, then explore the codebase as needed.

package/_Sprintpilot/skills/sprintpilot-code-review/workflow.md

@@ -1,111 +0,0 @@
-# Multi-Agent Code Review
-
-## Purpose
-
-Perform a thorough code review using 3 parallel subagents, each with a different review lens. Results are collected, deduplicated, and triaged into a prioritized action list.
-
-## When to Use
-
-Use this instead of stock `bmad-code-review` when you want deeper coverage. The autopilot can be configured to call this automatically.
-
----
-
-## Step 1 — Gather Context
-
-<action>Identify the story being reviewed from sprint-status.yaml or user input.</action>
-<action>Generate the diff to review:
-```bash
-git diff origin/main...HEAD --unified=5
-```
-If the diff exceeds 3000 lines, summarize by file and only pass relevant sections to agents.
-Save full diff to `review-diff.txt` for agent reference.
-</action>
-<action>Read the story file to extract acceptance criteria.</action>
-<action>Set `{{diff_file}}` = path to review-diff.txt</action>
-<action>Set `{{story_file}}` = path to story file</action>
-
----
-
-## Step 2 — Launch 3 Review Agents in Parallel
-
-Launch ALL THREE agents in a **single message** using the Agent tool. Each agent gets its own inlined prompt (not a Skill reference).
-
-<critical>
-All 3 Agent calls MUST be in the same message to run in parallel.
-Each agent's result is capped at ~2000 tokens via structured output instructions.
-</critical>
-
-### Agent 1: Blind Hunter (Adversarial Review)
-
-```
-Agent(
-  description: "Blind adversarial code review",
-  prompt: <read from ./agents/blind-hunter.md, append diff content or diff_file path>
-)
-```
-
-### Agent 2: Edge Case Hunter
-
-```
-Agent(
-  description: "Edge case analysis",
-  prompt: <read from ./agents/edge-case-hunter.md, append diff content or diff_file path>
-)
-```
-
-### Agent 3: Acceptance Auditor
-
-```
-Agent(
-  description: "Acceptance criteria audit",
-  prompt: <read from ./agents/acceptance-auditor.md, append diff content + story file content>
-)
-```
-
----
-
-## Step 3 — Triage Results
-
-<action>Collect all 3 agent results.</action>
-
-<action>For each finding, classify:
-- **PATCH** — concrete code fix needed, actionable
-- **WARN** — valid concern but no code change needed (document for awareness)
-- **DISMISS** — false positive, not applicable, or already handled
-
-Deduplication rules:
-- Same file + same line range + same concern → merge into one finding
-- **Contradictory findings** (Agent A says "add check", Agent B says "remove check"):
-  → If Acceptance Auditor cites an AC → Acceptance Auditor wins
-  → Otherwise → classify as `decision_needed` and flag for user
-</action>
-
-<action>Produce the triage report:
-
-```markdown
-## Code Review — Triage Report
-
-### PATCH (apply these)
-1. **[P1]** {title} — {file}:{line} — {description} — Source: {agent}
-2. **[P2]** ...
-
-### WARN (acknowledge, no code change)
-1. **[W1]** {title} — {description} — Source: {agent}
-
-### DISMISSED
-1. **[D1]** {reason} — Source: {agent}
-
-### DECISION NEEDED (contradictory or ambiguous)
-1. **[DN1]** {description} — Agent A says: ... / Agent B says: ...
-```
-</action>
-
----
-
-## Step 4 — Output
-
-<action>Present the triage report to the caller (autopilot or user).</action>
-<action>If running under autopilot: the autopilot will auto-apply all PATCH findings and commit each one.</action>
-<action>If running manually: present findings and ask user which to apply.</action>
-
-<action>Suggest next step: "Apply patches, then run full test suite."</action>

package/_Sprintpilot/skills/sprintpilot-party-mode/SKILL.md

@@ -1,6 +0,0 @@
----
-name: sprintpilot-party-mode
-description: 'Real parallel multi-agent discussions. Select 2-3 BMad Method agent personas per round, launch them simultaneously with a topic, collect responses as a discussion round. Supports multiple rounds. Use when you need diverse perspectives from BMad personas (architect, PM, QA, etc.) debating in parallel rather than sequentially.'
----
-
-Follow the instructions in ./workflow.md.

package/_Sprintpilot/skills/sprintpilot-party-mode/workflow.md

@@ -1,138 +0,0 @@
-# Multi-Agent Party Mode
-
-## Purpose
-
-Run real parallel multi-persona discussions. Instead of sequentially role-playing each persona (as stock `bmad-party-mode` does), this launches 2-3 Agent subagents simultaneously, each embodying a different BMAD persona. Results are collected and presented as a discussion round.
-
----
-
-## Step 1 — Setup
-
-<action>Get from user or context:
-- **Topic/Question**: what to discuss
-- **Personas**: which BMAD personas to include (2-3 per round)
-  Available: analyst, architect, pm, dev, qa, ux-designer, tech-writer, sm
-- **Context files**: any project artifacts to provide as context (PRD, architecture, etc.)
-- **Rounds**: how many discussion rounds (default: 2)
-
-If not specified, recommend a relevant set based on the topic:
-- Architecture decisions → architect, dev, qa
-- Product direction → pm, analyst, ux-designer
-- Implementation approach → dev, architect, qa
-- Process/workflow → sm, pm, dev
-</action>
-
----
-
-## Step 2 — Load Persona Definitions
-
-<action>For each selected persona, read the agent definition from BMAD:
-- `{project-root}/_bmad/_config/agents/` — look for persona YAML files
-- Or look in the installed skills directory for `bmad-agent-{persona}/SKILL.md`
-
-Extract the persona's:
-- Role description
-- Expertise areas
-- Communication style
-- Key concerns/priorities
-</action>
-
----
-
-## Step 3 — Run Discussion Rounds
-
-For each round (1 to {{num_rounds}}):
-
-<critical>Launch ALL persona agents for this round in a single message.</critical>
-
-For each persona in this round:
-```
-Agent(
-  description: "{persona_name} perspective on {topic}",
-  prompt: "You are the {persona_name} on a BMAD development team.
-
-  ## Your Role
-  {persona_description}
-
-  ## Your Priorities
-  {persona_priorities}
-
-  ## Discussion Topic
-  {topic}
-
-  ## Context
-  {project_context_files_content}
-
-  ## Previous Round Discussion
-  {previous_round_responses — empty for round 1}
-
-  ## Instructions
-
-  Respond to the topic from your persona's perspective.
-  - State your position clearly
-  - Raise concerns specific to your role
-  - Propose concrete actions
-  - If responding to previous round: agree, disagree, or build on other personas' points
-  - Be direct and specific, not generic
-
-  Cap response at 1000 tokens."
-)
-```
-
-<action>Collect all responses for this round.</action>
-
-<action>Present the round:
-
-```markdown
-## Round {{round_number}}
-
-### {Persona 1 Name} ({role})
-{response}
-
-### {Persona 2 Name} ({role})
-{response}
-
-### {Persona 3 Name} ({role})
-{response}
-```
-</action>
-
-<action>For subsequent rounds, include previous round responses as context so personas can respond to each other.</action>
-
----
-
-## Step 4 — Synthesis
-
-After all rounds complete:
-
-<action>Produce a synthesis:
-
-```markdown
-## Discussion Summary
-
-### Topic
-{topic}
-
-### Participants
-{persona list with roles}
-
-### Points of Agreement
-- ...
-
-### Points of Disagreement
-- {persona A} vs {persona B}: ...
-  Resolution suggestion: ...
-
-### Action Items
-1. [Owner: {persona}] {action}
-2. ...
-
-### Open Questions
-- ...
-
-### Recommendation
-[Based on the discussion, what is the recommended path forward?]
-```
-</action>
-
-<action>Ask user: "Continue with another topic, or apply these insights to the current workflow?"</action>