refactor(bmm): convert quick-dev workflow to sharded format with adversarial review (#1182)
convert quick-dev workflow to sharded format with adversarial review
This commit is contained in:
Alex Verkhovsky
GitHub
parent
00a380a03f
commit
dcaa892ce1
|
|
@ -0,0 +1,41 @@
|
|||
<!-- if possible, run this in a separate subagent or process with read access to the project,
|
||||
but no context except the content to review -->
|
||||
|
||||
<task id="_bmad/core/tasks/review-adversarial-general.xml" name="Adversarial Review (General)">
|
||||
<objective>Cynically review content and produce findings</objective>
|
||||
|
||||
<inputs>
|
||||
<input name="content" desc="Content to review - diff, spec, story, doc, or any artifact" />
|
||||
</inputs>
|
||||
|
||||
<llm critical="true">
|
||||
<i>You are a cynical, jaded reviewer with zero patience for sloppy work</i>
|
||||
<i>The content was submitted by a clueless weasel and you expect to find problems</i>
|
||||
<i>Be skeptical of everything</i>
|
||||
<i>Look for what's missing, not just what's wrong</i>
|
||||
<i>Use a precise, professional tone - no profanity or personal attacks</i>
|
||||
</llm>
|
||||
|
||||
<flow>
|
||||
<step n="1" title="Receive Content">
|
||||
<action>Load the content to review from provided input or context</action>
|
||||
<action>If content to review is empty, ask for clarification and abort task</action>
|
||||
<action>Identify content type (diff, branch, uncommitted changes, document, etc.)</action>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Adversarial Analysis" critical="true">
|
||||
<mandate>Review with extreme skepticism - assume problems exist</mandate>
|
||||
<action>Find at least ten issues to fix or improve in the provided content</action>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Present Findings">
|
||||
<action>Output findings as a Markdown list (descriptions only)</action>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
<halt-conditions>
|
||||
<condition>HALT if zero findings - this is suspicious, re-analyze or ask for guidance</condition>
|
||||
<condition>HALT if content is empty or unreadable</condition>
|
||||
</halt-conditions>
|
||||
|
||||
</task>
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
# Quick-Dev Checklist
|
||||
|
||||
## Before Implementation
|
||||
|
||||
- [ ] Context loaded (tech-spec or user guidance)
|
||||
- [ ] Files to modify identified
|
||||
- [ ] Patterns understood
|
||||
|
||||
## Implementation
|
||||
|
||||
- [ ] All tasks completed
|
||||
- [ ] Code follows existing patterns
|
||||
- [ ] Error handling appropriate
|
||||
|
||||
## Testing
|
||||
|
||||
- [ ] Tests written (where appropriate)
|
||||
- [ ] All tests passing
|
||||
- [ ] No regressions
|
||||
|
||||
## Completion
|
||||
|
||||
- [ ] Acceptance criteria satisfied
|
||||
- [ ] Tech-spec updated (if applicable)
|
||||
- [ ] Summary provided to user
|
||||
|
|
@ -1,202 +0,0 @@
|
|||
# Quick-Dev - Flexible Development Workflow
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>Communicate in {communication_language}, tailored to {user_skill_level}</critical>
|
||||
<critical>Execute continuously until COMPLETE - do not stop for milestones</critical>
|
||||
<critical>Flexible - handles tech-specs OR direct instructions</critical>
|
||||
<critical>ALWAYS respect {project_context} if it exists - it defines project standards</critical>
|
||||
|
||||
<checkpoint-handlers>
|
||||
<on-select key="a">Load and execute {advanced_elicitation}, then return</on-select>
|
||||
<on-select key="p">Load and execute {party_mode_workflow}, then return</on-select>
|
||||
<on-select key="t">Load and execute {create_tech_spec_workflow}</on-select>
|
||||
</checkpoint-handlers>
|
||||
|
||||
<step n="1" goal="Load project context and determine execution mode">
|
||||
|
||||
<action>Check if {project_context} exists. If yes, load it - this is your foundational reference for ALL implementation decisions (patterns, conventions, architecture).</action>
|
||||
|
||||
<action>Parse user input:
|
||||
|
||||
**Mode A: Tech-Spec** - e.g., `quick-dev tech-spec-auth.md`
|
||||
→ Load spec, extract tasks/context/AC, goto step 3
|
||||
|
||||
**Mode B: Direct Instructions** - e.g., `refactor src/foo.ts...`
|
||||
→ Offer planning choice
|
||||
</action>
|
||||
|
||||
<check if="Mode A">
|
||||
<action>Load tech-spec, extract tasks/context/AC</action>
|
||||
<goto>step_3</goto>
|
||||
</check>
|
||||
|
||||
<check if="Mode B">
|
||||
|
||||
<!-- Escalation Threshold: Lightweight check - should we invoke scale-adaptive? -->
|
||||
|
||||
<action>Evaluate escalation threshold against user input (minimal tokens, no file loading):
|
||||
|
||||
**Triggers escalation** (if 2+ signals present):
|
||||
|
||||
- Multiple components mentioned (e.g., dashboard + api + database)
|
||||
- System-level language (e.g., platform, integration, architecture)
|
||||
- Uncertainty about approach (e.g., "how should I", "best way to")
|
||||
- Multi-layer scope (e.g., UI + backend + data together)
|
||||
- Extended timeframe (e.g., "this week", "over the next few days")
|
||||
|
||||
**Reduces signal:**
|
||||
|
||||
- Simplicity markers (e.g., "just", "quickly", "fix", "bug", "typo", "simple", "basic", "minor")
|
||||
- Single file/component focus
|
||||
- Confident, specific request
|
||||
|
||||
Use holistic judgment, not mechanical keyword matching.</action>
|
||||
|
||||
<!-- No Escalation: Simple request, offer existing choice -->
|
||||
<check if="escalation threshold NOT triggered">
|
||||
<ask>**[t] Plan first** - Create tech-spec then implement
|
||||
**[e] Execute directly** - Start now</ask>
|
||||
|
||||
<check if="t">
|
||||
<action>Load and execute {create_tech_spec_workflow}</action>
|
||||
<action>Continue to implementation after spec complete</action>
|
||||
</check>
|
||||
|
||||
<check if="e">
|
||||
<ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
|
||||
<goto>step_2</goto>
|
||||
</check>
|
||||
|
||||
</check>
|
||||
|
||||
<!-- Escalation Triggered: Load scale-adaptive and evaluate level -->
|
||||
<check if="escalation threshold triggered">
|
||||
<action>Load {project_levels} and evaluate user input against detection_hints.keywords</action>
|
||||
<action>Determine level (0-4) using scale-adaptive definitions</action>
|
||||
|
||||
<!-- Level 0: Scale-adaptive confirms simple, fall back to standard choice -->
|
||||
<check if="level 0">
|
||||
<ask>**[t] Plan first** - Create tech-spec then implement
|
||||
|
||||
**[e] Execute directly** - Start now</ask>
|
||||
|
||||
<check if="t">
|
||||
<action>Load and execute {create_tech_spec_workflow}</action>
|
||||
<action>Continue to implementation after spec complete</action>
|
||||
</check>
|
||||
|
||||
<check if="e">
|
||||
<ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
|
||||
<goto>step_2</goto>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="level 1 or 2 or couldn't determine level">
|
||||
<ask>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 (workflow-init)
|
||||
**[e] Execute directly**</ask>
|
||||
|
||||
<check if="t">
|
||||
<action>Load and execute {create_tech_spec_workflow}</action>
|
||||
<action>Continue to implementation after spec complete</action>
|
||||
</check>
|
||||
|
||||
<check if="w">
|
||||
<action>Load and execute {workflow_init}</action>
|
||||
<action>EXIT quick-dev - user has been routed to BMad Method</action>
|
||||
</check>
|
||||
|
||||
<check if="e">
|
||||
<ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
|
||||
<goto>step_2</goto>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<!-- Level 3+: BMad Method territory, recommend workflow-init -->
|
||||
<check if="level 3 or higher">
|
||||
<ask>This sounds like platform/system work.
|
||||
|
||||
**[w] Start BMad Method** (recommended) (workflow-init)
|
||||
**[t] Create tech-spec** (lighter planning)
|
||||
**[e] Execute directly** - feeling lucky</ask>
|
||||
|
||||
<check if="w">
|
||||
<action>Load and execute {workflow_init}</action>
|
||||
<action>EXIT quick-dev - user has been routed to BMad Method</action>
|
||||
</check>
|
||||
|
||||
<check if="t">
|
||||
<action>Load and execute {create_tech_spec_workflow}</action>
|
||||
<action>Continue to implementation after spec complete</action>
|
||||
</check>
|
||||
|
||||
<check if="e">
|
||||
<ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
|
||||
<goto>step_2</goto>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
</check>
|
||||
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Quick context gathering (direct mode)">
|
||||
|
||||
<action>Identify files to modify, find relevant patterns, note dependencies</action>
|
||||
|
||||
<action>Create mental plan: tasks, acceptance criteria, files to touch</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Execute implementation" id="step_3">
|
||||
|
||||
<action>For each task:
|
||||
|
||||
1. **Load Context** - read files from spec or relevant to change
|
||||
2. **Implement** - follow patterns, handle errors, follow conventions
|
||||
3. **Test** - write tests, run existing tests, verify AC
|
||||
4. **Mark Complete** - check off task [x], continue
|
||||
</action>
|
||||
|
||||
<action if="3 failures">HALT and request guidance</action>
|
||||
<action if="tests fail">Fix before continuing</action>
|
||||
|
||||
<critical>Continue through ALL tasks without stopping</critical>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Verify and complete">
|
||||
|
||||
<action>Verify: all tasks [x], tests passing, AC satisfied, patterns followed</action>
|
||||
|
||||
<check if="using tech-spec">
|
||||
<action>Update tech-spec status to "Completed", mark all tasks [x]</action>
|
||||
</check>
|
||||
|
||||
<output>**Implementation Complete!**
|
||||
|
||||
**Summary:** {{implementation_summary}}
|
||||
**Files Modified:** {{files_list}}
|
||||
**Tests:** {{test_summary}}
|
||||
**AC Status:** {{ac_status}}
|
||||
|
||||
---
|
||||
|
||||
**Before committing (Recommended): Copy this code review prompt to a different LLM**
|
||||
|
||||
```
|
||||
You are a cynical, jaded code reviewer with zero patience for sloppy work. These uncommitted changes were submitted by a clueless weasel and you expect to find problems. Find at least five issues to fix or improve in it. Number them. Be skeptical of everything.
|
||||
```
|
||||
|
||||
</output>
|
||||
|
||||
<action>You must explain what was implemented based on {user_skill_level}</action>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,156 @@
|
|||
---
|
||||
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: '{workflow_path}/steps/step-01-mode-detection.md'
|
||||
nextStepFile_modeA: '{workflow_path}/steps/step-03-execute.md'
|
||||
nextStepFile_modeB: '{workflow_path}/steps/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 - this is 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 `{create_tech_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 `{create_tech_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 `{create_tech_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
|
||||
|
|
@ -0,0 +1,120 @@
|
|||
---
|
||||
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: '{workflow_path}/steps/step-02-context-gathering.md'
|
||||
nextStepFile: '{workflow_path}/steps/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
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
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: '{workflow_path}/steps/step-03-execute.md'
|
||||
nextStepFile: '{workflow_path}/steps/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)
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
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: '{workflow_path}/steps/step-04-self-check.md'
|
||||
nextStepFile: '{workflow_path}/steps/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)
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
---
|
||||
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: '{workflow_path}/steps/step-05-adversarial-review.md'
|
||||
nextStepFile: '{workflow_path}/steps/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 WriteTodos 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
|
||||
|
|
@ -0,0 +1,140 @@
|
|||
---
|
||||
name: 'step-06-resolve-findings'
|
||||
description: 'Handle review findings interactively, apply fixes, update tech-spec with final status'
|
||||
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
|
||||
thisStepFile: '{workflow_path}/steps/step-06-resolve-findings.md'
|
||||
---
|
||||
|
||||
# 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 choice to user:
|
||||
|
||||
```
|
||||
How would you like to handle these findings?
|
||||
|
||||
**[1] Walk through** - Discuss each finding individually
|
||||
**[2] Auto-fix** - Automatically fix issues classified as "real"
|
||||
**[3] Skip** - Acknowledge and proceed to commit
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## OPTION 1: WALK THROUGH
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## OPTION 2: AUTO-FIX
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## OPTION 3: SKIP
|
||||
|
||||
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
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
name: quick-dev
|
||||
description: 'Flexible development - execute tech-specs OR direct instructions with optional planning.'
|
||||
---
|
||||
|
||||
# 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`
|
||||
- `output_folder`, `sprint_artifacts`
|
||||
- `date` as system-generated current datetime
|
||||
|
||||
### Paths
|
||||
|
||||
- `installed_path` = `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev`
|
||||
- `project_context` = `**/project-context.md` (load if exists)
|
||||
- `project_levels` = `{project-root}/_bmad/bmm/workflows/workflow-status/project-levels.yaml`
|
||||
|
||||
### Related Workflows
|
||||
|
||||
- `create_tech_spec_workflow` = `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/workflow.yaml`
|
||||
- `workflow_init` = `{project-root}/_bmad/bmm/workflows/workflow-status/init/workflow.yaml`
|
||||
- `party_mode_exec` = `{project-root}/_bmad/core/workflows/party-mode/workflow.md`
|
||||
- `advanced_elicitation` = `{project-root}/_bmad/core/tasks/advanced-elicitation.xml`
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
|
||||
Load and execute `steps/step-01-mode-detection.md` to begin the workflow.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
# Quick-Flow: Quick-Dev
|
||||
name: quick-dev
|
||||
description: "Flexible development - execute tech-specs OR direct instructions with optional planning."
|
||||
author: "BMad"
|
||||
|
||||
# Config
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
planning_artifacts: "{config_source}:planning_artifacts"
|
||||
project_knowledge: "{config_source}:project_knowledge"
|
||||
output_folder: "{implementation_artifacts}"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Project context
|
||||
project_context: "**/project-context.md"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
checklist: "{installed_path}/checklist.md"
|
||||
|
||||
# Related workflows
|
||||
create_tech_spec_workflow: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/workflow.yaml"
|
||||
party_mode_exec: "{project-root}/_bmad/core/workflows/party-mode/workflow.md"
|
||||
advanced_elicitation: "{project-root}/_bmad/core/tasks/advanced-elicitation.xml"
|
||||
|
||||
# Routing resources (lazy-loaded)
|
||||
project_levels: "{project-root}/_bmad/bmm/workflows/workflow-status/project-levels.yaml"
|
||||
workflow_init: "{project-root}/_bmad/bmm/workflows/workflow-status/init/workflow.yaml"
|
||||
|
||||
standalone: true
|
||||
web_bundle: false
|
||||
Loading…
Reference in New Issue