refactor(bmm): convert quick-dev workflow to sharded format
Convert Quick Dev from monolithic (workflow.yaml + instructions.md) to sharded architecture (workflow.md + steps/) to combat "lost in the middle" problem during long implementation sessions. Changes: - Add 6 step files for focused execution (mode-detection, context-gathering, execute, self-check, adversarial-review, resolve-findings) - Add checkpoint handlers for [a] Advanced Elicitation and [p] Party Mode - Create review-adversarial-general.xml as reusable core task - Remove CLI fallback (claude --print) for platform-agnostic design 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Alex Verkhovsky
parent
642d5f8365
commit
6c56a28e7c
|
|
@ -0,0 +1,82 @@
|
|||
<task id="_bmad/core/tasks/review-adversarial-general.xml" name="Adversarial Review (General)">
|
||||
<objective>Cynically review content and produce numbered findings with severity and classification</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>Find at least five issues to fix or improve - be skeptical of everything</i>
|
||||
<i>Zero findings is suspicious - if you find nothing, halt and question your analysis</i>
|
||||
</llm>
|
||||
|
||||
<flow>
|
||||
<step n="1" title="Receive Content">
|
||||
<action>Load the content to review from provided input or context</action>
|
||||
<action>Identify content type (diff, spec, story, doc, etc.) to calibrate review approach</action>
|
||||
</step>
|
||||
|
||||
<step n="2" title="Adversarial Analysis" critical="true">
|
||||
<mandate>Review with extreme skepticism - assume problems exist</mandate>
|
||||
|
||||
<analysis-areas>
|
||||
<area>Correctness - Is it actually right? Look for logic errors, bugs, gaps</area>
|
||||
<area>Completeness - What's missing? Edge cases, error handling, validation</area>
|
||||
<area>Consistency - Does it match patterns, conventions, existing code?</area>
|
||||
<area>Clarity - Is it understandable? Naming, structure, documentation</area>
|
||||
<area>Quality - Is it good enough? Performance, security, maintainability</area>
|
||||
</analysis-areas>
|
||||
|
||||
<action>Find at least 5 issues - dig deep, don't accept surface-level "looks good"</action>
|
||||
</step>
|
||||
|
||||
<step n="3" title="Classify Findings">
|
||||
<action>For each finding, assign:</action>
|
||||
|
||||
<finding-id>F1, F2, F3... (sequential)</finding-id>
|
||||
|
||||
<severity>
|
||||
<level name="critical">Must fix - blocks ship, causes failures</level>
|
||||
<level name="high">Should fix - significant issue, notable risk</level>
|
||||
<level name="medium">Consider fixing - minor issue, small improvement</level>
|
||||
<level name="low">Nitpick - optional, stylistic, nice-to-have</level>
|
||||
</severity>
|
||||
|
||||
<classification>
|
||||
<type name="real">Confirmed issue - should address</type>
|
||||
<type name="noise">False positive - no action needed</type>
|
||||
<type name="uncertain">Needs discussion - could go either way</type>
|
||||
</classification>
|
||||
</step>
|
||||
|
||||
<step n="4" title="Present Findings">
|
||||
<action>Output findings in structured format</action>
|
||||
</step>
|
||||
</flow>
|
||||
|
||||
<findings-format>
|
||||
**Adversarial Review Findings**
|
||||
|
||||
| ID | Severity | Classification | Finding |
|
||||
|----|----------|----------------|---------|
|
||||
| F1 | {severity} | {classification} | {description} |
|
||||
| F2 | {severity} | {classification} | {description} |
|
||||
| ... | | | |
|
||||
|
||||
**Summary:** {count} findings - {critical_count} critical, {high_count} high, {medium_count} medium, {low_count} low
|
||||
</findings-format>
|
||||
|
||||
<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>
|
||||
|
||||
<critical-rules>
|
||||
<rule>NEVER accept "looks good" without deep analysis</rule>
|
||||
<rule>ALWAYS find at least 5 issues - if you can't, you're not looking hard enough</rule>
|
||||
<rule>ALWAYS assign ID, severity, and classification to each finding</rule>
|
||||
<rule>Be cynical but fair - classify noise as noise, real as real</rule>
|
||||
</critical-rules>
|
||||
</task>
|
||||
|
|
@ -1,33 +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
|
||||
|
||||
## Adversarial Review
|
||||
|
||||
- [ ] Diff constructed (tracked changes from {baseline_commit} + new untracked files)
|
||||
- [ ] Adversarial review executed (subagent preferred)
|
||||
- [ ] Findings presented with severity and classification
|
||||
- [ ] User chose handling approach (walk through / auto-fix / skip)
|
||||
- [ ] Findings resolved or acknowledged
|
||||
|
|
@ -1,276 +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>Record current HEAD as baseline for later review. Run `git rev-parse HEAD` and store the result as {baseline_commit}.</action>
|
||||
|
||||
<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 transition to review">
|
||||
|
||||
<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}}
|
||||
|
||||
Running adversarial code review...
|
||||
</output>
|
||||
|
||||
<action>Proceed immediately to step 5</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Adversarial code review (automatic)">
|
||||
|
||||
<action>Construct diff of all changes since workflow started and capture as {diff_output}:
|
||||
|
||||
**Tracked file changes:**
|
||||
|
||||
```bash
|
||||
git diff {baseline_commit}
|
||||
```
|
||||
|
||||
**New files created by this workflow:**
|
||||
Only include untracked files that YOU actually created during steps 2-4. Do not include pre-existing untracked files. For each new file you created, include its full content as a "new file" addition.
|
||||
|
||||
Combine both into {diff_output} for review. Do NOT `git add` anything - this is read-only inspection.</action>
|
||||
|
||||
<action>Execute adversarial review using this hierarchy (try in order until one succeeds):
|
||||
|
||||
1. **Spawn subagent** (preferred) - pass the diff output along with this prompt:
|
||||
|
||||
```
|
||||
You are a cynical, jaded code reviewer with zero patience for sloppy work. This diff was submitted by a clueless weasel and you expect to find problems. Find at least five issues to fix or improve. Number them. Be skeptical of everything.
|
||||
|
||||
<diff>
|
||||
{diff_output}
|
||||
</diff>
|
||||
```
|
||||
|
||||
2. **CLI fallback** - pipe diff to `claude --print` with same prompt
|
||||
|
||||
3. **Inline self-review** - Review the diff output yourself using the cynical reviewer persona above
|
||||
</action>
|
||||
|
||||
<check if="zero findings returned">
|
||||
<action>HALT - Zero findings is suspicious. Adversarial review should always find something. Request user guidance.</action>
|
||||
</check>
|
||||
|
||||
<action>Process findings:
|
||||
|
||||
- Assign IDs: F1, F2, F3...
|
||||
- Assign severity: 🔴 Critical | 🟠 High | 🟡 Medium | 🟢 Low
|
||||
- Classify each: **real** (confirmed issue) | **noise** (false positive) | **uncertain** (needs discussion)
|
||||
</action>
|
||||
|
||||
<output>**Adversarial Review Findings**
|
||||
|
||||
| ID | Severity | Classification | Finding |
|
||||
| --- | -------- | -------------- | ------- |
|
||||
| F1 | 🟠 | real | ... |
|
||||
| F2 | 🟡 | noise | ... |
|
||||
| ... |
|
||||
|
||||
</output>
|
||||
|
||||
<ask>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</ask>
|
||||
|
||||
<check if="1">
|
||||
<action>Present each finding one by one. For each, ask: fix now / skip / discuss</action>
|
||||
<action>Apply fixes as approved</action>
|
||||
</check>
|
||||
|
||||
<check if="2">
|
||||
<action>Automatically fix all findings classified as "real"</action>
|
||||
<action>Report what was fixed</action>
|
||||
</check>
|
||||
|
||||
<check if="3">
|
||||
<action>Acknowledge findings were reviewed and user chose to skip</action>
|
||||
</check>
|
||||
|
||||
<output>**Review complete. Ready to commit.**</output>
|
||||
|
||||
<action>Explain what was implemented based on {user_skill_level}</action>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,148 @@
|
|||
---
|
||||
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
|
||||
- `{execution_mode}` - "tech-spec" or "direct"
|
||||
- `{tech_spec_path}` - Path to tech-spec file (if Mode A)
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Capture Baseline
|
||||
|
||||
Run `git rev-parse HEAD` and store result as `{baseline_commit}`.
|
||||
|
||||
### 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,117 @@
|
|||
---
|
||||
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
|
||||
|
||||
When user confirms ready, load `step-03-execute.md`.
|
||||
|
||||
---
|
||||
|
||||
## 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,96 @@
|
|||
---
|
||||
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)
|
||||
|
||||
---
|
||||
|
||||
## STEP 1: CONSTRUCT DIFF
|
||||
|
||||
Build complete diff of all changes since workflow started.
|
||||
|
||||
### 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.
|
||||
|
||||
### Capture as {diff_output}
|
||||
|
||||
Merge tracked changes and new files into `{diff_output}`.
|
||||
|
||||
**Note:** Do NOT `git add` anything - this is read-only inspection.
|
||||
|
||||
---
|
||||
|
||||
## STEP 2: INVOKE ADVERSARIAL REVIEW
|
||||
|
||||
With `{diff_output}` constructed, invoke the review task:
|
||||
|
||||
```xml
|
||||
<invoke-task input="{diff_output}">{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 input.
|
||||
|
||||
The task will:
|
||||
|
||||
- Review with cynical skepticism
|
||||
- Find at least 5 issues
|
||||
- Assign IDs (F1, F2...), severity (critical/high/medium/low), classification (real/noise/uncertain)
|
||||
- Return structured findings table
|
||||
|
||||
---
|
||||
|
||||
## STEP 3: RECEIVE FINDINGS
|
||||
|
||||
Capture the findings from the task output.
|
||||
|
||||
**If zero findings:** HALT - this is suspicious. Re-analyze or request user guidance.
|
||||
|
||||
---
|
||||
|
||||
## 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 with IDs, severity, classification
|
||||
- Zero-findings case handled appropriately
|
||||
|
||||
## 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
|
||||
|
|
@ -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,62 @@
|
|||
---
|
||||
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`
|
||||
|
||||
---
|
||||
|
||||
## CHECKPOINT HANDLERS
|
||||
|
||||
At any checkpoint throughout this workflow, the following options are available:
|
||||
|
||||
- **[a] Advanced Elicitation** - Invoke `{advanced_elicitation}` for deeper analysis using First Principles, Pre-mortem, or other techniques
|
||||
- **[p] Party Mode** - Invoke `{party_mode_exec}` to bring in multiple agent perspectives for complex decisions
|
||||
|
||||
These are optional power tools - use when stuck, facing ambiguity, or wanting diverse input.
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
|
||||
Load and execute `steps/step-01-mode-detection.md` to begin the workflow.
|
||||
|
|
@ -1,33 +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"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_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