@delorenj/pjangler 1.2.25 → 1.3.0

package/templates/commonproject/_bmad/bmm/workflows/4-implementation/sprint-status/workflow.yaml

@@ -1,35 +0,0 @@
-# Sprint Status - Implementation Tracker
-name: sprint-status
-description: "Summarize sprint-status.yaml, surface risks, and route to the right implementation workflow."
-author: "BMad"
-
-# Critical variables from config
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-user_name: "{config_source}:user_name"
-communication_language: "{config_source}:communication_language"
-document_output_language: "{config_source}:document_output_language"
-date: system-generated
-implementation_artifacts: "{config_source}:implementation_artifacts"
-planning_artifacts: "{config_source}:planning_artifacts"
-
-# Workflow components
-installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-status"
-instructions: "{installed_path}/instructions.md"
-
-# Inputs
-variables:
-  sprint_status_file: "{implementation_artifacts}/sprint-status.yaml"
-  tracking_system: "file-system"
-
-# Smart input file references
-input_file_patterns:
-  sprint_status:
-    description: "Sprint status file generated by sprint-planning"
-    whole: "{implementation_artifacts}/sprint-status.yaml"
-    load_strategy: "FULL_LOAD"
-
-# Standalone so IDE commands get generated
-standalone: true
-
-# No web bundle needed

package/templates/commonproject/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-01-mode-detection.md

@@ -1,156 +0,0 @@
----
-name: 'step-01-mode-detection'
-description: 'Determine execution mode (tech-spec vs direct), handle escalation, set state variables'
-
-workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-01-mode-detection.md'
-nextStepFile_modeA: './step-03-execute.md'
-nextStepFile_modeB: './step-02-context-gathering.md'
----
-
-# Step 1: Mode Detection
-
-**Goal:** Determine execution mode, capture baseline, handle escalation if needed.
-
----
-
-## STATE VARIABLES (capture now, persist throughout)
-
-These variables MUST be set in this step and available to all subsequent steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start (or "NO_GIT" if not a git repo)
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Path to tech-spec file (if Mode A)
-
----
-
-## EXECUTION SEQUENCE
-
-### 1. Capture Baseline
-
-First, check if the project uses Git version control:
-
-**If Git repo exists** (`.git` directory present or `git rev-parse --is-inside-work-tree` succeeds):
-
-- Run `git rev-parse HEAD` and store result as `{baseline_commit}`
-
-**If NOT a Git repo:**
-
-- Set `{baseline_commit}` = "NO_GIT"
-
-### 2. Load Project Context
-
-Check if `{project_context}` exists (`**/project-context.md`). If found, load it as a foundational reference for ALL implementation decisions.
-
-### 3. Parse User Input
-
-Analyze the user's input to determine mode:
-
-**Mode A: Tech-Spec**
-
-- User provided a path to a tech-spec file (e.g., `quick-dev tech-spec-auth.md`)
-- Load the spec, extract tasks/context/AC
-- Set `{execution_mode}` = "tech-spec"
-- Set `{tech_spec_path}` = provided path
-- **NEXT:** Load `step-03-execute.md`
-
-**Mode B: Direct Instructions**
-
-- User provided task description directly (e.g., `refactor src/foo.ts...`)
-- Set `{execution_mode}` = "direct"
-- **NEXT:** Evaluate escalation threshold, then proceed
-
----
-
-## ESCALATION THRESHOLD (Mode B only)
-
-Evaluate user input with minimal token usage (no file loading):
-
-**Triggers escalation (if 2+ signals present):**
-
-- Multiple components mentioned (dashboard + api + database)
-- System-level language (platform, integration, architecture)
-- Uncertainty about approach ("how should I", "best way to")
-- Multi-layer scope (UI + backend + data together)
-- Extended timeframe ("this week", "over the next few days")
-
-**Reduces signal:**
-
-- Simplicity markers ("just", "quickly", "fix", "bug", "typo", "simple")
-- Single file/component focus
-- Confident, specific request
-
-Use holistic judgment, not mechanical keyword matching.
-
----
-
-## ESCALATION HANDLING
-
-### No Escalation (simple request)
-
-Present choice:
-
-```
-**[t] Plan first** - Create tech-spec then implement
-**[e] Execute directly** - Start now
-```
-
-- **[t]:** Direct user to `{quick_spec_workflow}`. **EXIT Quick Dev.**
-- **[e]:** Ask for any additional guidance, then **NEXT:** Load `step-02-context-gathering.md`
-
-### Escalation Triggered - Level 0-2
-
-```
-This looks like a focused feature with multiple components.
-
-**[t] Create tech-spec first** (recommended)
-**[w] Seems bigger than quick-dev** - see what BMad Method recommends
-**[e] Execute directly**
-```
-
-- **[t]:** Direct to `{quick_spec_workflow}`. **EXIT Quick Dev.**
-- **[w]:** Direct to `{workflow_init}`. **EXIT Quick Dev.**
-- **[e]:** Ask for guidance, then **NEXT:** Load `step-02-context-gathering.md`
-
-### Escalation Triggered - Level 3+
-
-```
-This sounds like platform/system work.
-
-**[w] Start BMad Method** (recommended)
-**[t] Create tech-spec** (lighter planning)
-**[e] Execute directly** - feeling lucky
-```
-
-- **[w]:** Direct to `{workflow_init}`. **EXIT Quick Dev.**
-- **[t]:** Direct to `{quick_spec_workflow}`. **EXIT Quick Dev.**
-- **[e]:** Ask for guidance, then **NEXT:** Load `step-02-context-gathering.md`
-
----
-
-## NEXT STEP DIRECTIVE
-
-**CRITICAL:** When this step completes, explicitly state which step to load:
-
-- Mode A (tech-spec): "**NEXT:** Loading `step-03-execute.md`"
-- Mode B (direct, [e] selected): "**NEXT:** Loading `step-02-context-gathering.md`"
-- Escalation ([t] or [w]): "**EXITING Quick Dev.** Follow the directed workflow."
-
----
-
-## SUCCESS METRICS
-
-- `{baseline_commit}` captured and stored
-- `{execution_mode}` determined ("tech-spec" or "direct")
-- `{tech_spec_path}` set if Mode A
-- Project context loaded if exists
-- Escalation evaluated appropriately (Mode B)
-- Explicit NEXT directive provided
-
-## FAILURE MODES
-
-- Proceeding without capturing baseline commit
-- Not setting execution_mode variable
-- Loading step-02 when Mode A (tech-spec provided)
-- Attempting to "return" after escalation instead of EXIT
-- No explicit NEXT directive at step completion

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

@@ -1,120 +0,0 @@
----
-name: 'step-02-context-gathering'
-description: 'Quick context gathering for direct mode - identify files, patterns, dependencies'
-
-workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-02-context-gathering.md'
-nextStepFile: './step-03-execute.md'
----
-
-# 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:** Loading `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/templates/commonproject/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-03-execute.md

@@ -1,113 +0,0 @@
----
-name: 'step-03-execute'
-description: 'Execute implementation - iterate through tasks, write code, run tests'
-
-workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-03-execute.md'
-nextStepFile: './step-04-self-check.md'
----
-
-# 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), load `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/templates/commonproject/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-04-self-check.md

@@ -1,113 +0,0 @@
----
-name: 'step-04-self-check'
-description: 'Self-audit implementation against tasks, tests, AC, and patterns'
-
-workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-04-self-check.md'
-nextStepFile: './step-05-adversarial-review.md'
----
-
-# 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/templates/commonproject/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-05-adversarial-review.md

@@ -1,106 +0,0 @@
----
-name: 'step-05-adversarial-review'
-description: 'Construct diff and invoke adversarial review task'
-
-workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-05-adversarial-review.md'
-nextStepFile: './step-06-resolve-findings.md'
----
-
-# Step 5: Adversarial Code Review
-
-**Goal:** Construct diff of all changes, invoke adversarial review task, 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 review task. If possible, use information asymmetry: run this step, and only it, in a separate subagent or process with read access to the project, but no context except the `{diff_output}`.
-
-```xml
-<invoke-task>Review {diff_output} using {project-root}/_bmad/core/tasks/review-adversarial-general.xml</invoke-task>
-```
-
-**Platform fallback:** If task invocation not available, load the task file and execute its instructions inline, passing `{diff_output}` as the content.
-
-The task should: review `{diff_output}` and return a list of findings.
-
----
-
-### 3. Process Findings
-
-Capture the findings from the task 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, load `step-06-resolve-findings.md` for user to choose resolution approach.
-
----
-
-## SUCCESS METRICS
-
-- Diff constructed from baseline_commit
-- New files included in diff
-- Task 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 task without providing diff input
-- Accepting zero findings without questioning
-- Presenting fewer findings than the review task returned without explicit instruction to do so