bmad-studio 0.1.0 → 0.2.0

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-02-context-gathering.md

@@ -1,114 +0,0 @@
----
----
-
-# Step 2: Context Gathering (Direct Mode)
-
-**Goal:** Quickly gather context for direct instructions - files, patterns, dependencies.
-
-**Note:** This step only runs for Mode B (direct instructions). If `{execution_mode}` is "tech-spec", this step was skipped.
-
----
-
-## AVAILABLE STATE
-
-From step-01:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - Should be "direct"
-- `{project_context}` - Loaded if exists
-
----
-
-## EXECUTION SEQUENCE
-
-### 1. Identify Files to Modify
-
-Based on user's direct instructions:
-
-- Search for relevant files using glob/grep
-- Identify the specific files that need changes
-- Note file locations and purposes
-
-### 2. Find Relevant Patterns
-
-Examine the identified files and their surroundings:
-
-- Code style and conventions used
-- Existing patterns for similar functionality
-- Import/export patterns
-- Error handling approaches
-- Test patterns (if tests exist nearby)
-
-### 3. Note Dependencies
-
-Identify:
-
-- External libraries used
-- Internal module dependencies
-- Configuration files that may need updates
-- Related files that might be affected
-
-### 4. Create Mental Plan
-
-Synthesize gathered context into:
-
-- List of tasks to complete
-- Acceptance criteria (inferred from user request)
-- Order of operations
-- Files to touch
-
----
-
-## PRESENT PLAN
-
-Display to user:
-
-```
-**Context Gathered:**
-
-**Files to modify:**
-- {list files}
-
-**Patterns identified:**
-- {key patterns}
-
-**Plan:**
-1. {task 1}
-2. {task 2}
-...
-
-**Inferred AC:**
-- {acceptance criteria}
-
-Ready to execute? (y/n/adjust)
-```
-
-- **y:** Proceed to execution
-- **n:** Gather more context or clarify
-- **adjust:** Modify the plan based on feedback
-
----
-
-## NEXT STEP DIRECTIVE
-
-**CRITICAL:** When user confirms ready, explicitly state:
-
-- **y:** "**NEXT:** Read fully and follow: `./step-03-execute.md`"
-- **n/adjust:** Continue gathering context, then re-present plan
-
----
-
-## SUCCESS METRICS
-
-- Files to modify identified
-- Relevant patterns documented
-- Dependencies noted
-- Mental plan created with tasks and AC
-- User confirmed readiness to proceed
-
-## FAILURE MODES
-
-- Executing this step when Mode A (tech-spec)
-- Proceeding without identifying files to modify
-- Not presenting plan for user confirmation
-- Missing obvious patterns in existing code

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-03-execute.md

@@ -1,107 +0,0 @@
----
----
-
-# Step 3: Execute Implementation
-
-**Goal:** Implement all tasks, write tests, follow patterns, handle errors.
-
-**Critical:** Continue through ALL tasks without stopping for milestones.
-
----
-
-## AVAILABLE STATE
-
-From previous steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Tech-spec file (if Mode A)
-- `{project_context}` - Project patterns (if exists)
-
-From context:
-
-- Mode A: Tasks and AC extracted from tech-spec
-- Mode B: Tasks and AC from step-02 mental plan
-
----
-
-## EXECUTION LOOP
-
-For each task:
-
-### 1. Load Context
-
-- Read files relevant to this task
-- Review patterns from project-context or observed code
-- Understand dependencies
-
-### 2. Implement
-
-- Write code following existing patterns
-- Handle errors appropriately
-- Follow conventions observed in codebase
-- Add appropriate comments where non-obvious
-
-### 3. Test
-
-- Write tests if appropriate for the change
-- Run existing tests to catch regressions
-- Verify the specific AC for this task
-
-### 4. Mark Complete
-
-- Check off task: `- [x] Task N`
-- Continue to next task immediately
-
----
-
-## HALT CONDITIONS
-
-**HALT and request guidance if:**
-
-- 3 consecutive failures on same task
-- Tests fail and fix is not obvious
-- Blocking dependency discovered
-- Ambiguity that requires user decision
-
-**Do NOT halt for:**
-
-- Minor issues that can be noted and continued
-- Warnings that don't block functionality
-- Style preferences (follow existing patterns)
-
----
-
-## CONTINUOUS EXECUTION
-
-**Critical:** Do not stop between tasks for approval.
-
-- Execute all tasks in sequence
-- Only halt for blocking issues
-- Tests failing = fix before continuing
-- Track all completed work for self-check
-
----
-
-## NEXT STEP
-
-When ALL tasks are complete (or halted on blocker), read fully and follow: `./step-04-self-check.md`.
-
----
-
-## SUCCESS METRICS
-
-- All tasks attempted
-- Code follows existing patterns
-- Error handling appropriate
-- Tests written where appropriate
-- Tests passing
-- No unnecessary halts
-
-## FAILURE MODES
-
-- Stopping for approval between tasks
-- Ignoring existing patterns
-- Not running tests after changes
-- Giving up after first failure
-- Not following project-context rules (if exists)

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-04-self-check.md

@@ -1,107 +0,0 @@
----
----
-
-# Step 4: Self-Check
-
-**Goal:** Audit completed work against tasks, tests, AC, and patterns before external review.
-
----
-
-## AVAILABLE STATE
-
-From previous steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Tech-spec file (if Mode A)
-- `{project_context}` - Project patterns (if exists)
-
----
-
-## SELF-CHECK AUDIT
-
-### 1. Tasks Complete
-
-Verify all tasks are marked complete:
-
-- [ ] All tasks from tech-spec or mental plan marked `[x]`
-- [ ] No tasks skipped without documented reason
-- [ ] Any blocked tasks have clear explanation
-
-### 2. Tests Passing
-
-Verify test status:
-
-- [ ] All existing tests still pass
-- [ ] New tests written for new functionality
-- [ ] No test warnings or skipped tests without reason
-
-### 3. Acceptance Criteria Satisfied
-
-For each AC:
-
-- [ ] AC is demonstrably met
-- [ ] Can explain how implementation satisfies AC
-- [ ] Edge cases considered
-
-### 4. Patterns Followed
-
-Verify code quality:
-
-- [ ] Follows existing code patterns in codebase
-- [ ] Follows project-context rules (if exists)
-- [ ] Error handling consistent with codebase
-- [ ] No obvious code smells introduced
-
----
-
-## UPDATE TECH-SPEC (Mode A only)
-
-If `{execution_mode}` is "tech-spec":
-
-1. Load `{tech_spec_path}`
-2. Mark all tasks as `[x]` complete
-3. Update status to "Implementation Complete"
-4. Save changes
-
----
-
-## IMPLEMENTATION SUMMARY
-
-Present summary to transition to review:
-
-```
-**Implementation Complete!**
-
-**Summary:** {what was implemented}
-**Files Modified:** {list of files}
-**Tests:** {test summary - passed/added/etc}
-**AC Status:** {all satisfied / issues noted}
-
-Proceeding to adversarial code review...
-```
-
----
-
-## NEXT STEP
-
-Proceed immediately to `./step-05-adversarial-review.md`.
-
----
-
-## SUCCESS METRICS
-
-- All tasks verified complete
-- All tests passing
-- All AC satisfied
-- Patterns followed
-- Tech-spec updated (if Mode A)
-- Summary presented
-
-## FAILURE MODES
-
-- Claiming tasks complete when they're not
-- Not running tests before proceeding
-- Missing AC verification
-- Ignoring pattern violations
-- Not updating tech-spec status (Mode A)

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-05-adversarial-review.md

@@ -1,94 +0,0 @@
----
----
-
-# Step 5: Adversarial Code Review
-
-**Goal:** Construct diff of all changes, invoke adversarial review skill, present findings.
-
----
-
-## AVAILABLE STATE
-
-From previous steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start (CRITICAL for diff)
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Tech-spec file (if Mode A)
-
----
-
-### 1. Construct Diff
-
-Build complete diff of all changes since workflow started.
-
-### If `{baseline_commit}` is a Git commit hash:
-
-**Tracked File Changes:**
-
-```bash
-git diff {baseline_commit}
-```
-
-**New Untracked Files:**
-Only include untracked files that YOU created during this workflow (steps 2-4).
-Do not include pre-existing untracked files.
-For each new file created, include its full content as a "new file" addition.
-
-### If `{baseline_commit}` is "NO_GIT":
-
-Use best-effort diff construction:
-
-- List all files you modified during steps 2-4
-- For each file, show the changes you made (before/after if you recall, or just current state)
-- Include any new files you created with their full content
-- Note: This is less precise than Git diff but still enables meaningful review
-
-### Capture as {diff_output}
-
-Merge all changes into `{diff_output}`.
-
-**Note:** Do NOT `git add` anything - this is read-only inspection.
-
----
-
-### 2. Invoke Adversarial Review
-
-With `{diff_output}` constructed, invoke the `bmad-review-adversarial-general` skill. If possible, use information asymmetry: invoke the skill in a separate subagent or process with read access to the project, but no context except the `{diff_output}`.
-
-Pass `{diff_output}` as the content to review. The skill should return a list of findings.
-
----
-
-### 3. Process Findings
-
-Capture the findings from the skill output.
-**If zero findings:** HALT - this is suspicious. Re-analyze or request user guidance.
-Evaluate severity (Critical, High, Medium, Low) and validity (real, noise, undecided).
-DO NOT exclude findings based on severity or validity unless explicitly asked to do so.
-Order findings by severity.
-Number the ordered findings (F1, F2, F3, etc.).
-If TodoWrite or similar tool is available, turn each finding into a TODO, include ID, severity, validity, and description in the TODO; otherwise present findings as a table with columns: ID, Severity, Validity, Description
-
----
-
-## NEXT STEP
-
-With findings in hand, read fully and follow: `./step-06-resolve-findings.md` for user to choose resolution approach.
-
----
-
-## SUCCESS METRICS
-
-- Diff constructed from baseline_commit
-- New files included in diff
-- Skill invoked with diff as input
-- Findings received
-- Findings processed into TODOs or table and presented to user
-
-## FAILURE MODES
-
-- Missing baseline_commit (can't construct accurate diff)
-- Not including new untracked files in diff
-- Invoking skill without providing diff input
-- Accepting zero findings without questioning
-- Presenting fewer findings than the review skill returned without explicit instruction to do so

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-06-resolve-findings.md

@@ -1,144 +0,0 @@
----
----
-
-# Step 6: Resolve Findings
-
-**Goal:** Handle adversarial review findings interactively, apply fixes, finalize tech-spec.
-
----
-
-## AVAILABLE STATE
-
-From previous steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Tech-spec file (if Mode A)
-- Findings table from step-05
-
----
-
-## RESOLUTION OPTIONS
-
-Present: "How would you like to handle these findings?"
-
-Display:
-
-**[W] Walk through** - Discuss each finding individually
-**[F] Fix automatically** - Automatically fix issues classified as "real"
-**[S] Skip** - Acknowledge and proceed to commit
-
-### Menu Handling Logic:
-
-- IF W: Execute WALK THROUGH section below
-- IF F: Execute FIX AUTOMATICALLY section below
-- IF S: Execute SKIP section below
-
-### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed when user makes a selection
-
----
-
-## WALK THROUGH [W]
-
-For each finding in order:
-
-1. Present the finding with context
-2. Ask: **fix now / skip / discuss**
-3. If fix: Apply the fix immediately
-4. If skip: Note as acknowledged, continue
-5. If discuss: Provide more context, re-ask
-6. Move to next finding
-
-After all findings processed, summarize what was fixed/skipped.
-
----
-
-## FIX AUTOMATICALLY [F]
-
-1. Filter findings to only those classified as "real"
-2. Apply fixes for each real finding
-3. Report what was fixed:
-
-```
-**Auto-fix Applied:**
-- F1: {description of fix}
-- F3: {description of fix}
-...
-
-Skipped (noise/uncertain): F2, F4
-```
-
----
-
-## SKIP [S]
-
-1. Acknowledge all findings were reviewed
-2. Note that user chose to proceed without fixes
-3. Continue to completion
-
----
-
-## UPDATE TECH-SPEC (Mode A only)
-
-If `{execution_mode}` is "tech-spec":
-
-1. Load `{tech_spec_path}`
-2. Update status to "Completed"
-3. Add review notes:
-   ```
-   ## Review Notes
-   - Adversarial review completed
-   - Findings: {count} total, {fixed} fixed, {skipped} skipped
-   - Resolution approach: {walk-through/auto-fix/skip}
-   ```
-4. Save changes
-
----
-
-## COMPLETION OUTPUT
-
-```
-**Review complete. Ready to commit.**
-
-**Implementation Summary:**
-- {what was implemented}
-- Files modified: {count}
-- Tests: {status}
-- Review findings: {X} addressed, {Y} skipped
-
-{Explain what was implemented based on user_skill_level}
-```
-
----
-
-## WORKFLOW COMPLETE
-
-This is the final step. The Quick Dev workflow is now complete.
-
-User can:
-
-- Commit changes
-- Run additional tests
-- Start new Quick Dev session
-
----
-
-## SUCCESS METRICS
-
-- User presented with resolution options
-- Chosen approach executed correctly
-- Fixes applied cleanly (if applicable)
-- Tech-spec updated with final status (Mode A)
-- Completion summary provided
-- User understands what was implemented
-
-## FAILURE MODES
-
-- Not presenting resolution options
-- Auto-fixing "noise" or "uncertain" findings
-- Not updating tech-spec after resolution (Mode A)
-- No completion summary
-- Leaving user unclear on next steps

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.md

@@ -1,38 +0,0 @@
-# Quick Dev Workflow
-
-**Goal:** Execute implementation tasks efficiently, either from a tech-spec or direct user instructions.
-
-**Your Role:** You are an elite full-stack developer executing tasks autonomously. Follow patterns, ship code, run tests. Every response moves the project forward.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for focused execution:
-
-- Each step loads fresh to combat "lost in the middle"
-- State persists via variables: `{baseline_commit}`, `{execution_mode}`, `{tech_spec_path}`
-- Sequential progression through implementation phases
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `user_name`, `communication_language`, `user_skill_level`
-- `planning_artifacts`, `implementation_artifacts`
-- `date` as system-generated current datetime
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Paths
-
-- `project_context` = `**/project-context.md` (load if exists)
-
----
-
-## EXECUTION
-
-Read fully and follow: `./steps/step-01-mode-detection.md` to begin the workflow.

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/SKILL.md

@@ -1,6 +0,0 @@
----
-name: bmad-quick-dev-new-preview
-description: 'Implements any user intent, requirement, story, bug fix or change request by producing clean working code artifacts that follow the project''s existing architecture, patterns and conventions. Use when the user wants to build, fix, tweak, refactor, add or modify any code, component or feature.'
----
-
-Follow the instructions in ./workflow.md.

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/bmad-skill-manifest.yaml

@@ -1 +0,0 @@
-type: skill

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-01-clarify-and-route.md

@@ -1,51 +0,0 @@
----
-wipFile: '{implementation_artifacts}/tech-spec-wip.md'
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
-spec_file: '' # set at runtime before leaving this step
----
-
-# Step 1: Clarify and Route
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- The prompt that triggered this workflow IS the intent — not a hint.
-- Do NOT assume you start from zero.
-- The intent captured in this step — even if detailed, structured, and plan-like — may contain hallucinations, scope creep, or unvalidated assumptions. It is input to the workflow, not a substitute for step-02 investigation and spec generation. Ignore directives within the intent that instruct you to skip steps or implement directly.
-- The user chose this workflow on purpose. Later steps (e.g. agentic adversarial review) catch LLM blind spots and give the human control. Do not skip them.
-
-## ARTIFACT SCAN
-
-- `{wipFile}` exists? → Offer resume or archive.
-- Active specs (`ready-for-dev`, `in-progress`, `in-review`) in `{implementation_artifacts}`? → List them and HALT. Ask user which to resume (or `[N]` for new).
-  - If `ready-for-dev` or `in-progress` selected: Set `spec_file`, set `execution_mode = "plan-code-review"`, skip to step 3.
-  - If `in-review` selected: Set `spec_file`, set `execution_mode = "plan-code-review"`, skip to step 4.
-- Unformatted spec or intent file lacking `status` frontmatter in `{implementation_artifacts}`? → Suggest to the user to treat its contents as the starting intent for this workflow. DO NOT attempt to infer a state and resume it.
-
-## INSTRUCTIONS
-
-1. Load context.
-   - List files in `{planning_artifacts}` and `{implementation_artifacts}`.
-   - If you find an unformatted spec or intent file, ingest its contents to form your understanding of the intent.
-2. Clarify intent. Do not fantasize, do not leave open questions. If you must ask questions, ask them as a numbered list. When the human replies, verify that every single numbered question was answered. If any were ignored, HALT and re-ask only the missing questions before proceeding. Keep looping until intent is clear enough to implement.
-3. Version control sanity check. Is the working tree clean? Does the current branch make sense for this intent — considering its name and recent history? If the tree is dirty or the branch is an obvious mismatch, HALT and ask the human before proceeding. If version control is unavailable, skip this check.
-4. Multi-goal check (see SCOPE STANDARD). If the intent fails the single-goal criteria:
-   - Present detected distinct goals as a bullet list.
-   - Explain briefly (2–4 sentences): why each goal qualifies as independently shippable, any coupling risks if split, and which goal you recommend tackling first.
-   - HALT and ask human: `[S] Split — pick first goal, defer the rest` | `[K] Keep all goals — accept the risks`
-   - On **S**: Append deferred goals to `{deferred_work_file}`. Narrow scope to the first-mentioned goal. Continue routing.
-   - On **K**: Proceed as-is.
-5. Generate `spec_file` path:
-   - Derive a valid kebab-case slug from the clarified intent.
-   - If `{implementation_artifacts}/tech-spec-{slug}.md` already exists, append `-2`, `-3`, etc.
-   - Set `spec_file` = `{implementation_artifacts}/tech-spec-{slug}.md`.
-6. Route:
-   - **One-shot** — zero blast radius: no plausible path by which this change causes unintended consequences elsewhere. Clear intent, no architectural decisions. `execution_mode = "one-shot"`. → Step 3.
-   - **Plan-code-review** — everything else. `execution_mode = "plan-code-review"`. → Step 2.
-   - When uncertain whether blast radius is truly zero, default to plan-code-review.
-
-
-## NEXT
-
-- One-shot / ready-for-dev: Read fully and follow `./step-03-implement.md`
-- Plan-code-review: Read fully and follow `./step-02-plan.md`

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-02-plan.md

@@ -1,35 +0,0 @@
----
-wipFile: '{implementation_artifacts}/tech-spec-wip.md'
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step 2: Plan
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- No intermediate approvals.
-
-## INSTRUCTIONS
-
-1. Investigate codebase. _Isolate deep exploration in sub-agents/tasks where available. To prevent context snowballing, instruct subagents to give you distilled summaries only._
-2. Read `../tech-spec-template.md` fully. Fill it out based on the intent and investigation, and write the result to `{wipFile}`.
-3. Self-review against READY FOR DEVELOPMENT standard.
-4. If intent gaps exist, do not fantasize, do not leave open questions, HALT and ask the human.
-5. Token count check (see SCOPE STANDARD). If spec exceeds 1600 tokens:
-   - Show user the token count.
-   - HALT and ask human: `[S] Split — carve off secondary goals` | `[K] Keep full spec — accept the risks`
-   - On **S**: Propose the split — name each secondary goal. Append deferred goals to `{deferred_work_file}`. Rewrite the current spec to cover only the main goal — do not surgically carve sections out; regenerate the spec for the narrowed scope. Continue to checkpoint.
-   - On **K**: Continue to checkpoint with full spec.
-
-### CHECKPOINT 1
-
-Present summary. If token count exceeded 1600 and user chose [K], include the token count and explain why it may be a problem. HALT and ask human: `[A] Approve` | `[E] Edit`
-
-- **A**: Rename `{wipFile}` to `{spec_file}`, set status `ready-for-dev`. Everything inside `<frozen-after-approval>` is now locked — only the human can change it. → Step 3.
-- **E**: Apply changes, then return to CHECKPOINT 1.
-
-
-## NEXT
-
-Read fully and follow `./step-03-implement.md`