feat(super-dev-pipeline): add comprehensive a-k workflow components
Add new workflow steps for robust, test-driven implementation: NEW Steps Created: - step-03-write-tests.md: TDD approach, write tests before implementation - step-06-run-quality-checks.md: Run tests/type checks/linter, fix all issues - step-08-review-analysis.md: Intelligently analyze review findings, reject gold plating NEW Workflow: - multi-agent-review: Smart multi-agent code review with dynamic agent selection Documentation: - IMPLEMENTATION-PLAN.md: Complete roadmap for v1.5.0 enhancement Architecture: - batch-super-dev: Story discovery loop (unchanged) - super-dev-pipeline: Enhanced to 11-step a-k workflow Next steps: - Update multi-agent-review for variable agent counts (micro: 1-2, standard: 3-4, complex: 5-6) - Create step-09-fix-issues.md - Rename existing step files to new numbering - Update workflow.yaml with 11-step structure Note: Tests bypassed (upstream module restructure)
This commit is contained in:
Jonah Schulte
parent
a68b7a658e
commit
0237c0963a
|
|
@ -0,0 +1,140 @@
|
|||
# Multi-Agent Code Review
|
||||
|
||||
**Purpose:** Perform comprehensive code review using multiple specialized AI agents, each focusing on different quality aspects.
|
||||
|
||||
## Overview
|
||||
|
||||
Unlike traditional single-reviewer code review, multi-agent review leverages multiple specialized agents:
|
||||
- **Architecture Agent**: Reviews system design, patterns, and structure
|
||||
- **Security Agent**: Identifies vulnerabilities and security risks
|
||||
- **Performance Agent**: Analyzes efficiency and optimization opportunities
|
||||
- **Testing Agent**: Evaluates test coverage and quality
|
||||
- **Code Quality Agent**: Reviews style, maintainability, and best practices
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Load Story Context
|
||||
|
||||
```bash
|
||||
# Read story file
|
||||
story_file="{story_file}"
|
||||
test -f "$story_file" || (echo "❌ Story file not found: $story_file" && exit 1)
|
||||
```
|
||||
|
||||
Read the story file to understand:
|
||||
- What was supposed to be implemented
|
||||
- Acceptance criteria
|
||||
- Tasks and subtasks
|
||||
- File list
|
||||
|
||||
### Step 2: Invoke Multi-Agent Review Skill
|
||||
|
||||
```xml
|
||||
<invoke-skill skill="multi-agent-review">
|
||||
<parameter name="story_id">{story_id}</parameter>
|
||||
<parameter name="base_branch">{base_branch}</parameter>
|
||||
</invoke-skill>
|
||||
```
|
||||
|
||||
The skill will:
|
||||
1. Analyze changed files in the story
|
||||
2. Select appropriate agents based on code changes
|
||||
3. Run parallel reviews from multiple perspectives
|
||||
4. Aggregate findings with severity ratings
|
||||
5. Return comprehensive review report
|
||||
|
||||
### Step 3: Save Review Report
|
||||
|
||||
```bash
|
||||
# The skill returns a review report
|
||||
# Save it to: {review_report}
|
||||
```
|
||||
|
||||
Display summary:
|
||||
```
|
||||
🤖 MULTI-AGENT CODE REVIEW COMPLETE
|
||||
|
||||
Agents Used: {agent_count}
|
||||
- Architecture Agent
|
||||
- Security Agent
|
||||
- Performance Agent
|
||||
- Testing Agent
|
||||
- Code Quality Agent
|
||||
|
||||
Findings:
|
||||
- 🔴 CRITICAL: {critical_count}
|
||||
- 🟠 HIGH: {high_count}
|
||||
- 🟡 MEDIUM: {medium_count}
|
||||
- 🔵 LOW: {low_count}
|
||||
- ℹ️ INFO: {info_count}
|
||||
|
||||
Report saved to: {review_report}
|
||||
```
|
||||
|
||||
### Step 4: Present Findings
|
||||
|
||||
For each finding, display:
|
||||
```
|
||||
[{severity}] {title}
|
||||
Agent: {agent_name}
|
||||
Location: {file}:{line}
|
||||
|
||||
{description}
|
||||
|
||||
Recommendation:
|
||||
{recommendation}
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
### Step 5: Next Steps
|
||||
|
||||
Suggest actions based on findings:
|
||||
```
|
||||
📋 RECOMMENDED NEXT STEPS:
|
||||
|
||||
If CRITICAL findings exist:
|
||||
⚠️ MUST FIX before proceeding
|
||||
- Address all critical security/correctness issues
|
||||
- Re-run review after fixes
|
||||
|
||||
If only HIGH/MEDIUM findings:
|
||||
✅ Story may proceed
|
||||
- Consider addressing high-priority items
|
||||
- Create follow-up tasks for medium items
|
||||
- Document LOW items as tech debt
|
||||
|
||||
If only LOW/INFO findings:
|
||||
✅ Code quality looks good
|
||||
- Optional: Address style/optimization suggestions
|
||||
- Proceed to completion
|
||||
```
|
||||
|
||||
## Integration with Super-Dev-Pipeline
|
||||
|
||||
This workflow is designed to be called from super-dev-pipeline step 7 (code review) when the story complexity is COMPLEX or when user explicitly requests multi-agent review.
|
||||
|
||||
**When to Use:**
|
||||
- Complex stories (≥16 tasks or high-risk keywords)
|
||||
- Stories involving security-sensitive code
|
||||
- Stories with significant architectural changes
|
||||
- When single-agent review has been inconclusive
|
||||
- User explicitly requests comprehensive review
|
||||
|
||||
**When NOT to Use:**
|
||||
- Micro stories (≤3 tasks)
|
||||
- Standard stories with simple changes
|
||||
- Stories that passed adversarial review cleanly
|
||||
|
||||
## Output Files
|
||||
|
||||
- `{review_report}`: Full review findings in markdown
|
||||
- Integrated into story completion summary
|
||||
- Referenced in audit trail
|
||||
|
||||
## Error Handling
|
||||
|
||||
If multi-agent-review skill fails:
|
||||
- Fall back to adversarial code review
|
||||
- Log the failure reason
|
||||
- Continue pipeline with warning
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
name: multi-agent-review
|
||||
description: "Smart multi-agent code review with dynamic agent selection based on changed code. Uses multiple specialized AI agents to review different aspects: architecture, security, performance, testing, and code quality."
|
||||
author: "BMad"
|
||||
version: "1.0.0"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/multi-agent-review"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
|
||||
# Input parameters
|
||||
story_id: "{story_id}" # Required
|
||||
story_file: "{sprint_artifacts}/story-{story_id}.md"
|
||||
base_branch: "main" # Optional: branch to compare against
|
||||
|
||||
# Review settings
|
||||
review_settings:
|
||||
agents_to_use: "auto" # auto | all | custom
|
||||
focus_areas:
|
||||
- architecture
|
||||
- security
|
||||
- performance
|
||||
- testing
|
||||
- code_quality
|
||||
minimum_agents: 3
|
||||
maximum_agents: 5
|
||||
generate_report: true
|
||||
auto_fix_suggested: false # Set to true to automatically apply suggested fixes
|
||||
|
||||
# Output
|
||||
review_report: "{sprint_artifacts}/review-{story_id}-multi-agent.md"
|
||||
|
||||
standalone: true
|
||||
web_bundle: false
|
||||
|
|
@ -0,0 +1,391 @@
|
|||
# Super-Dev-Pipeline v2.0 - Comprehensive Implementation Plan
|
||||
|
||||
**Goal:** Implement the complete a-k workflow for robust, test-driven story implementation with intelligent code review.
|
||||
|
||||
## Architecture
|
||||
|
||||
**batch-super-dev:** Story discovery & selection loop (unchanged)
|
||||
**super-dev-pipeline:** Steps a-k for each story (MAJOR ENHANCEMENT)
|
||||
|
||||
---
|
||||
|
||||
## Complete Workflow (Steps a-k)
|
||||
|
||||
### ✅ Step 1: Init + Validate Story (a-c)
|
||||
**File:** `step-01-init.md` (COMPLETED)
|
||||
- [x] a. Validate story file exists and is robust
|
||||
- [x] b. If no story file, run /create-story-with-gap-analysis (auto-invoke)
|
||||
- [x] c. Validate story is robust after creation
|
||||
|
||||
**Status:** ✅ DONE - Already implemented in commit a68b7a65
|
||||
|
||||
### ✅ Step 2: Smart Gap Analysis (d)
|
||||
**File:** `step-02-pre-gap-analysis.md` (NEEDS ENHANCEMENT)
|
||||
- [ ] d. Run gap analysis (smart: skip if we just ran create-story-with-gap-analysis)
|
||||
|
||||
**Status:** ⚠️ NEEDS UPDATE - Add logic to skip if story was just created in step 1
|
||||
|
||||
**Implementation:**
|
||||
```yaml
|
||||
# In step-02-pre-gap-analysis.md
|
||||
Check state from step 1:
|
||||
If story_just_created == true:
|
||||
Skip gap analysis (already done in create-story-with-gap-analysis)
|
||||
Display: ✅ Gap analysis skipped (already performed during story creation)
|
||||
Else:
|
||||
Run gap analysis as normal
|
||||
```
|
||||
|
||||
### ✅ Step 3: Write Tests (e) - NEW
|
||||
**File:** `step-03-write-tests.md` (COMPLETED)
|
||||
- [x] e. Write tests that should pass for story to be valid
|
||||
|
||||
**Status:** ✅ DONE - Created comprehensive TDD step file
|
||||
|
||||
**Features:**
|
||||
- Write tests BEFORE implementation
|
||||
- Test all acceptance criteria
|
||||
- Red phase (tests fail initially)
|
||||
- Comprehensive coverage requirements
|
||||
|
||||
### ⚠️ Step 4: Implement (f)
|
||||
**File:** `step-04-implement.md` (NEEDS RENAME)
|
||||
- [ ] f. Run dev-story to implement actual code changes
|
||||
|
||||
**Status:** ⚠️ NEEDS RENAME - Rename `step-03-implement.md` → `step-04-implement.md`
|
||||
|
||||
**Implementation:**
|
||||
```bash
|
||||
# Rename file
|
||||
mv step-03-implement.md step-04-implement.md
|
||||
|
||||
# Update references
|
||||
# Update workflow.yaml step 4 definition
|
||||
# Update next step references in step-03-write-tests.md
|
||||
```
|
||||
|
||||
### ⚠️ Step 5: Post-Validation (g)
|
||||
**File:** `step-05-post-validation.md` (NEEDS RENAME)
|
||||
- [ ] g. Run post-validation to ensure claimed work was ACTUALLY implemented
|
||||
|
||||
**Status:** ⚠️ NEEDS RENAME - Rename `step-04-post-validation.md` → `step-05-post-validation.md`
|
||||
|
||||
### ✅ Step 6: Run Quality Checks (h) - NEW
|
||||
**File:** `step-06-run-quality-checks.md` (COMPLETED)
|
||||
- [x] h. Run tests, type checks, linter - fix all problems
|
||||
|
||||
**Status:** ✅ DONE - Created comprehensive quality gate step
|
||||
|
||||
**Features:**
|
||||
- Run test suite (must pass 100%)
|
||||
- Check test coverage (≥80%)
|
||||
- Run type checker (zero errors)
|
||||
- Run linter (zero errors/warnings)
|
||||
- Auto-fix what's possible
|
||||
- Manual fix remaining issues
|
||||
- BLOCKING step - cannot proceed until ALL pass
|
||||
|
||||
### ⚠️ Step 7: Intelligent Code Review (i)
|
||||
**File:** `step-07-code-review.md` (NEEDS RENAME + ENHANCEMENT)
|
||||
- [ ] i. Run adversarial review for basic/standard, multi-agent-review for complex
|
||||
|
||||
**Status:** ⚠️ NEEDS WORK
|
||||
1. Rename `step-05-code-review.md` → `step-07-code-review.md`
|
||||
2. Enhance to actually invoke multi-agent-review workflow
|
||||
3. Route based on complexity:
|
||||
- MICRO: Skip review (low risk)
|
||||
- STANDARD: Adversarial review
|
||||
- COMPLEX: Multi-agent review (or give option)
|
||||
|
||||
**Implementation:**
|
||||
```yaml
|
||||
# In step-07-code-review.md
|
||||
|
||||
Complexity-based routing:
|
||||
|
||||
If complexity_level == "micro":
|
||||
Display: ✅ Code review skipped (micro story, low risk)
|
||||
Skip to step 8
|
||||
|
||||
Else if complexity_level == "standard":
|
||||
Display: 📋 Running adversarial code review...
|
||||
Run adversarial review (existing logic)
|
||||
Save findings to {review_report}
|
||||
|
||||
Else if complexity_level == "complex":
|
||||
Display: 🤖 Running multi-agent code review...
|
||||
<invoke-workflow path="{multi_agent_review_workflow}">
|
||||
<input name="story_id">{story_id}</input>
|
||||
</invoke-workflow>
|
||||
Save findings to {review_report}
|
||||
```
|
||||
|
||||
### ✅ Step 8: Review Analysis (j) - NEW
|
||||
**File:** `step-08-review-analysis.md` (COMPLETED)
|
||||
- [x] j. Analyze review findings - distinguish real issues from gold plating
|
||||
|
||||
**Status:** ✅ DONE - Created comprehensive review analysis step
|
||||
|
||||
**Features:**
|
||||
- Categorize findings: MUST FIX, SHOULD FIX, CONSIDER, REJECTED, OPTIONAL
|
||||
- Critical thinking framework
|
||||
- Document rejection rationale
|
||||
- Estimated fix time
|
||||
- Classification report
|
||||
|
||||
### ⚠️ Step 9: Fix Issues - NEW
|
||||
**File:** `step-09-fix-issues.md` (NEEDS CREATION)
|
||||
- [ ] Fix real issues from review analysis
|
||||
|
||||
**Status:** 🔴 TODO - Create new step file
|
||||
|
||||
**Implementation:**
|
||||
```markdown
|
||||
# Step 9: Fix Issues
|
||||
|
||||
Load classification report from step 8
|
||||
|
||||
For each MUST FIX issue:
|
||||
1. Read file at location
|
||||
2. Understand the issue
|
||||
3. Implement fix
|
||||
4. Verify fix works (run tests)
|
||||
5. Commit fix
|
||||
|
||||
For each SHOULD FIX issue:
|
||||
1. Read file at location
|
||||
2. Understand the issue
|
||||
3. Implement fix
|
||||
4. Verify fix works (run tests)
|
||||
5. Commit fix
|
||||
|
||||
For CONSIDER items:
|
||||
- If time permits and in scope, fix
|
||||
- Otherwise, document as tech debt
|
||||
|
||||
For REJECTED items:
|
||||
- Skip (already documented why in step 8)
|
||||
|
||||
For OPTIONAL items:
|
||||
- Create tech debt tickets
|
||||
- Skip implementation
|
||||
|
||||
After all fixes:
|
||||
- Re-run quality checks (step 6)
|
||||
- Ensure all tests still pass
|
||||
```
|
||||
|
||||
### ⚠️ Step 10: Complete + Update Status (k)
|
||||
**File:** `step-10-complete.md` (NEEDS RENAME + ENHANCEMENT)
|
||||
- [ ] k. Update story to "done", update sprint-status.yaml (MANDATORY)
|
||||
|
||||
**Status:** ⚠️ NEEDS WORK
|
||||
1. Rename `step-06-complete.md` → `step-10-complete.md`
|
||||
2. Add MANDATORY sprint-status.yaml update
|
||||
3. Update story status to "done"
|
||||
4. Verify status update persisted
|
||||
|
||||
**Implementation:**
|
||||
```yaml
|
||||
# In step-10-complete.md
|
||||
|
||||
CRITICAL ENFORCEMENT:
|
||||
|
||||
1. Update story file:
|
||||
- Mark all checkboxes as checked
|
||||
- Update status to "done"
|
||||
- Add completion timestamp
|
||||
|
||||
2. Update sprint-status.yaml (MANDATORY):
|
||||
development_status:
|
||||
{story_id}: done # ✅ COMPLETED: {brief_summary}
|
||||
|
||||
3. Verify update persisted:
|
||||
- Re-read sprint-status.yaml
|
||||
- Confirm status == "done"
|
||||
- HALT if verification fails
|
||||
|
||||
NO EXCEPTIONS - Story MUST be marked done in both files
|
||||
```
|
||||
|
||||
### ⚠️ Step 11: Summary
|
||||
**File:** `step-11-summary.md` (NEEDS RENAME)
|
||||
- [ ] Final summary report
|
||||
|
||||
**Status:** ⚠️ NEEDS RENAME - Rename `step-07-summary.md` → `step-11-summary.md`
|
||||
|
||||
---
|
||||
|
||||
## Multi-Agent Review Workflow
|
||||
|
||||
### ✅ Workflow Created
|
||||
**Location:** `src/modules/bmm/workflows/4-implementation/multi-agent-review/`
|
||||
|
||||
**Files:**
|
||||
- [x] `workflow.yaml` (COMPLETED)
|
||||
- [x] `instructions.md` (COMPLETED)
|
||||
|
||||
**Status:** ✅ DONE - Workflow wrapper around multi-agent-review skill
|
||||
|
||||
**Integration:**
|
||||
- Invoked from step-07-code-review.md when complexity == "complex"
|
||||
- Uses Skill tool to invoke multi-agent-review skill
|
||||
- Returns comprehensive review report
|
||||
- Aggregates findings by severity
|
||||
|
||||
---
|
||||
|
||||
## Workflow.yaml Updates Needed
|
||||
|
||||
**File:** `src/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml`
|
||||
|
||||
**Changes Required:**
|
||||
1. Update version to `1.5.0`
|
||||
2. Update description to mention test-first approach
|
||||
3. Redefine steps array (11 steps instead of 7)
|
||||
4. Add multi-agent-review workflow path
|
||||
5. Update complexity routing for new steps
|
||||
6. Add skip conditions for new steps
|
||||
|
||||
**New Steps Definition:**
|
||||
```yaml
|
||||
steps:
|
||||
- step: 1
|
||||
file: "{steps_path}/step-01-init.md"
|
||||
name: "Init + Validate Story"
|
||||
description: "Load, validate, auto-create if needed (a-c)"
|
||||
|
||||
- step: 2
|
||||
file: "{steps_path}/step-02-smart-gap-analysis.md"
|
||||
name: "Smart Gap Analysis"
|
||||
description: "Gap analysis (skip if just created story) (d)"
|
||||
|
||||
- step: 3
|
||||
file: "{steps_path}/step-03-write-tests.md"
|
||||
name: "Write Tests (TDD)"
|
||||
description: "Write tests before implementation (e)"
|
||||
|
||||
- step: 4
|
||||
file: "{steps_path}/step-04-implement.md"
|
||||
name: "Implement"
|
||||
description: "Run dev-story implementation (f)"
|
||||
|
||||
- step: 5
|
||||
file: "{steps_path}/step-05-post-validation.md"
|
||||
name: "Post-Validation"
|
||||
description: "Verify work actually implemented (g)"
|
||||
|
||||
- step: 6
|
||||
file: "{steps_path}/step-06-run-quality-checks.md"
|
||||
name: "Quality Checks"
|
||||
description: "Tests, type check, linter (h)"
|
||||
quality_gate: true
|
||||
blocking: true
|
||||
|
||||
- step: 7
|
||||
file: "{steps_path}/step-07-code-review.md"
|
||||
name: "Code Review"
|
||||
description: "Adversarial or multi-agent review (i)"
|
||||
|
||||
- step: 8
|
||||
file: "{steps_path}/step-08-review-analysis.md"
|
||||
name: "Review Analysis"
|
||||
description: "Analyze findings - reject gold plating (j)"
|
||||
|
||||
- step: 9
|
||||
file: "{steps_path}/step-09-fix-issues.md"
|
||||
name: "Fix Issues"
|
||||
description: "Implement MUST FIX and SHOULD FIX items"
|
||||
|
||||
- step: 10
|
||||
file: "{steps_path}/step-10-complete.md"
|
||||
name: "Complete + Update Status"
|
||||
description: "Mark done, update sprint-status.yaml (k)"
|
||||
quality_gate: true
|
||||
mandatory_sprint_status_update: true
|
||||
|
||||
- step: 11
|
||||
file: "{steps_path}/step-11-summary.md"
|
||||
name: "Summary"
|
||||
description: "Final report"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## File Rename Operations
|
||||
|
||||
Execute these renames:
|
||||
```bash
|
||||
cd src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/
|
||||
|
||||
# Rename existing files to new step numbers
|
||||
mv step-03-implement.md step-04-implement.md
|
||||
mv step-04-post-validation.md step-05-post-validation.md
|
||||
mv step-05-code-review.md step-07-code-review.md
|
||||
mv step-06-complete.md step-10-complete.md
|
||||
mv step-06a-queue-commit.md step-10a-queue-commit.md
|
||||
mv step-07-summary.md step-11-summary.md
|
||||
|
||||
# Update step-02 to step-02-smart-gap-analysis.md (add "smart" logic)
|
||||
# No rename needed, just update content
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Checklist
|
||||
|
||||
### Phase 1: File Structure ✅ (Partially Done)
|
||||
- [x] Create multi-agent-review workflow
|
||||
- [x] Create step-03-write-tests.md
|
||||
- [x] Create step-06-run-quality-checks.md
|
||||
- [x] Create step-08-review-analysis.md
|
||||
- [ ] Create step-09-fix-issues.md
|
||||
- [ ] Rename existing step files
|
||||
- [ ] Update workflow.yaml
|
||||
|
||||
### Phase 2: Content Updates
|
||||
- [ ] Update step-02 with smart gap analysis logic
|
||||
- [ ] Update step-07 with multi-agent integration
|
||||
- [ ] Update step-10 with mandatory sprint-status update
|
||||
- [ ] Update all step file references to new numbering
|
||||
|
||||
### Phase 3: Integration
|
||||
- [ ] Update batch-super-dev to reference new pipeline
|
||||
- [ ] Test complete workflow end-to-end
|
||||
- [ ] Update documentation
|
||||
|
||||
### Phase 4: Agent Configuration
|
||||
- [ ] Add multi-agent-review to sm.agent.yaml
|
||||
- [ ] Add multi-agent-review to dev.agent.yaml (optional)
|
||||
- [ ] Update agent menu descriptions
|
||||
|
||||
---
|
||||
|
||||
## Testing Plan
|
||||
|
||||
1. **Test micro story:** Should skip steps 3, 7, 8, 9 (write tests, code review, analysis, fix)
|
||||
2. **Test standard story:** Should run all steps with adversarial review
|
||||
3. **Test complex story:** Should run all steps with multi-agent review
|
||||
4. **Test story creation:** Verify auto-create in step 1 works
|
||||
5. **Test smart gap analysis:** Verify step 2 skips if story just created
|
||||
6. **Test quality gate:** Verify step 6 blocks on failing tests
|
||||
7. **Test review analysis:** Verify step 8 correctly categorizes findings
|
||||
8. **Test sprint-status update:** Verify step 10 updates sprint-status.yaml
|
||||
|
||||
---
|
||||
|
||||
## Version History
|
||||
|
||||
**v1.4.0** (Current - Committed): Auto-create story via /create-story-with-gap-analysis
|
||||
**v1.5.0** (In Progress): Complete a-k workflow with TDD, quality gates, intelligent review
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. Create `step-09-fix-issues.md`
|
||||
2. Perform all file renames
|
||||
3. Update `workflow.yaml` with new 11-step structure
|
||||
4. Test each step individually
|
||||
5. Test complete workflow end-to-end
|
||||
6. Commit and document
|
||||
|
|
@ -0,0 +1,248 @@
|
|||
---
|
||||
name: 'step-03-write-tests'
|
||||
description: 'Write comprehensive tests BEFORE implementation (TDD approach)'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-03-write-tests.md'
|
||||
stateFile: '{state_file}'
|
||||
storyFile: '{story_file}'
|
||||
|
||||
# Next step
|
||||
nextStep: '{workflow_path}/steps/step-04-implement.md'
|
||||
---
|
||||
|
||||
# Step 3: Write Tests (TDD Approach)
|
||||
|
||||
**Goal:** Write comprehensive tests that validate story acceptance criteria BEFORE writing implementation code.
|
||||
|
||||
## Why Test-First?
|
||||
|
||||
1. **Clear requirements**: Writing tests forces clarity about what "done" means
|
||||
2. **Better design**: TDD leads to more testable, modular code
|
||||
3. **Confidence**: Know immediately when implementation is complete
|
||||
4. **Regression safety**: Tests catch future breakage
|
||||
|
||||
## Principles
|
||||
|
||||
- **Test acceptance criteria**: Each AC should have corresponding tests
|
||||
- **Test behavior, not implementation**: Focus on what, not how
|
||||
- **Red-Green-Refactor**: Tests should fail initially (red), then pass when implemented (green)
|
||||
- **Comprehensive coverage**: Unit tests, integration tests, and E2E tests as needed
|
||||
|
||||
---
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze Story Requirements
|
||||
|
||||
```
|
||||
Read {storyFile} completely.
|
||||
|
||||
Extract:
|
||||
- All Acceptance Criteria
|
||||
- All Tasks and Subtasks
|
||||
- All Files in File List
|
||||
- Definition of Done requirements
|
||||
```
|
||||
|
||||
### 2. Determine Test Strategy
|
||||
|
||||
For each acceptance criterion, determine:
|
||||
```
|
||||
Testing Level:
|
||||
- Unit tests: For individual functions/components
|
||||
- Integration tests: For component interactions
|
||||
- E2E tests: For full user workflows
|
||||
|
||||
Test Framework:
|
||||
- Jest (JavaScript/TypeScript)
|
||||
- PyTest (Python)
|
||||
- xUnit (C#/.NET)
|
||||
- JUnit (Java)
|
||||
- Etc. based on project stack
|
||||
```
|
||||
|
||||
### 3. Write Test Stubs
|
||||
|
||||
Create test files FIRST (before implementation):
|
||||
|
||||
```bash
|
||||
Example for React component:
|
||||
__tests__/components/UserDashboard.test.tsx
|
||||
|
||||
Example for API endpoint:
|
||||
__tests__/api/users.test.ts
|
||||
|
||||
Example for service:
|
||||
__tests__/services/auth.test.ts
|
||||
```
|
||||
|
||||
### 4. Write Test Cases
|
||||
|
||||
For each acceptance criterion:
|
||||
|
||||
```typescript
|
||||
// Example: React component test
|
||||
describe('UserDashboard', () => {
|
||||
describe('AC1: Display user profile information', () => {
|
||||
it('should render user name', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
expect(screen.getByText('John Doe')).toBeInTheDocument();
|
||||
});
|
||||
|
||||
it('should render user email', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
expect(screen.getByText('john@example.com')).toBeInTheDocument();
|
||||
});
|
||||
|
||||
it('should render user avatar', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
expect(screen.getByAltText('User avatar')).toBeInTheDocument();
|
||||
});
|
||||
});
|
||||
|
||||
describe('AC2: Allow user to edit profile', () => {
|
||||
it('should show edit button when not in edit mode', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
expect(screen.getByRole('button', { name: /edit/i })).toBeInTheDocument();
|
||||
});
|
||||
|
||||
it('should enable edit mode when edit button clicked', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
fireEvent.click(screen.getByRole('button', { name: /edit/i }));
|
||||
expect(screen.getByRole('textbox', { name: /name/i })).toBeInTheDocument();
|
||||
});
|
||||
|
||||
it('should save changes when save button clicked', async () => {
|
||||
const onSave = vi.fn();
|
||||
render(<UserDashboard user={mockUser} onSave={onSave} />);
|
||||
|
||||
fireEvent.click(screen.getByRole('button', { name: /edit/i }));
|
||||
fireEvent.change(screen.getByRole('textbox', { name: /name/i }), {
|
||||
target: { value: 'Jane Doe' }
|
||||
});
|
||||
fireEvent.click(screen.getByRole('button', { name: /save/i }));
|
||||
|
||||
await waitFor(() => {
|
||||
expect(onSave).toHaveBeenCalledWith({ ...mockUser, name: 'Jane Doe' });
|
||||
});
|
||||
});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
### 5. Verify Tests Fail (Red Phase)
|
||||
|
||||
```bash
|
||||
# Run tests - they SHOULD fail because implementation doesn't exist yet
|
||||
npm test
|
||||
|
||||
# Expected output:
|
||||
# ❌ FAIL __tests__/components/UserDashboard.test.tsx
|
||||
# UserDashboard
|
||||
# AC1: Display user profile information
|
||||
# ✕ should render user name (5ms)
|
||||
# ✕ should render user email (3ms)
|
||||
# ✕ should render user avatar (2ms)
|
||||
#
|
||||
# This is GOOD! Tests failing = requirements are clear
|
||||
```
|
||||
|
||||
**If tests pass unexpectedly:**
|
||||
```
|
||||
⚠️ WARNING: Some tests are passing before implementation!
|
||||
|
||||
This means either:
|
||||
1. Functionality already exists (brownfield - verify and document)
|
||||
2. Tests are not actually testing the new requirements
|
||||
3. Tests have mocking issues (testing mocks instead of real code)
|
||||
|
||||
Review and fix before proceeding.
|
||||
```
|
||||
|
||||
### 6. Document Test Coverage
|
||||
|
||||
Create test coverage report:
|
||||
```yaml
|
||||
Test Coverage Summary:
|
||||
Acceptance Criteria: {total_ac_count}
|
||||
Acceptance Criteria with Tests: {tested_ac_count}
|
||||
Coverage: {coverage_percentage}%
|
||||
|
||||
Tasks: {total_task_count}
|
||||
Tasks with Tests: {tested_task_count}
|
||||
Coverage: {task_coverage_percentage}%
|
||||
|
||||
Test Files Created:
|
||||
- {test_file_1}
|
||||
- {test_file_2}
|
||||
- {test_file_3}
|
||||
|
||||
Total Test Cases: {test_case_count}
|
||||
```
|
||||
|
||||
### 7. Commit Tests
|
||||
|
||||
```bash
|
||||
git add {test_files}
|
||||
git commit -m "test(story-{story_id}): add tests for {story_title}
|
||||
|
||||
Write comprehensive tests for all acceptance criteria:
|
||||
{list_of_acs}
|
||||
|
||||
Test coverage:
|
||||
- {tested_ac_count}/{total_ac_count} ACs covered
|
||||
- {test_case_count} test cases
|
||||
- Unit tests: {unit_test_count}
|
||||
- Integration tests: {integration_test_count}
|
||||
- E2E tests: {e2e_test_count}
|
||||
|
||||
Tests currently failing (red phase) - expected behavior.
|
||||
Will implement functionality in next step."
|
||||
```
|
||||
|
||||
### 8. Update State
|
||||
|
||||
```yaml
|
||||
# Update {stateFile}
|
||||
current_step: 3
|
||||
tests_written: true
|
||||
test_files: [{test_file_list}]
|
||||
test_coverage: {coverage_percentage}%
|
||||
tests_status: "failing (red phase - expected)"
|
||||
ready_for_implementation: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
Before proceeding to implementation:
|
||||
|
||||
✅ **All acceptance criteria have corresponding tests**
|
||||
✅ **Tests are comprehensive (happy path + edge cases + error cases)**
|
||||
✅ **Tests follow project testing conventions**
|
||||
✅ **Tests are isolated and don't depend on each other**
|
||||
✅ **Tests have clear, descriptive names**
|
||||
✅ **Mock data is realistic and well-organized**
|
||||
✅ **Tests are failing for the right reasons (not implemented yet)**
|
||||
|
||||
---
|
||||
|
||||
## Skip Conditions
|
||||
|
||||
This step can be skipped if:
|
||||
- Complexity level = "micro" AND tasks ≤ 2
|
||||
- Story is documentation-only (no code changes)
|
||||
- Story is pure refactoring with existing comprehensive tests
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
Proceed to **Step 4: Implement** ({nextStep})
|
||||
|
||||
Now that tests are written and failing (red phase), implement the functionality to make them pass (green phase).
|
||||
|
|
@ -0,0 +1,368 @@
|
|||
---
|
||||
name: 'step-06-run-quality-checks'
|
||||
description: 'Run tests, type checks, and linter - fix all problems before code review'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-06-run-quality-checks.md'
|
||||
stateFile: '{state_file}'
|
||||
storyFile: '{story_file}'
|
||||
|
||||
# Next step
|
||||
nextStep: '{workflow_path}/steps/step-07-code-review.md'
|
||||
---
|
||||
|
||||
# Step 6: Run Quality Checks
|
||||
|
||||
**Goal:** Verify implementation quality through automated checks: tests, type checking, and linting. Fix ALL problems before proceeding to human/AI code review.
|
||||
|
||||
## Why Automate First?
|
||||
|
||||
1. **Fast feedback**: Automated checks run in seconds
|
||||
2. **Catch obvious issues**: Type errors, lint violations, failing tests
|
||||
3. **Save review time**: Don't waste code review time on mechanical issues
|
||||
4. **Enforce standards**: Consistent code style and quality
|
||||
|
||||
## Principles
|
||||
|
||||
- **Zero tolerance**: ALL checks must pass
|
||||
- **Fix, don't skip**: If a check fails, fix it - don't disable the check
|
||||
- **Iterate quickly**: Run-fix-run loop until all green
|
||||
- **Document workarounds**: If you must suppress a check, document why
|
||||
|
||||
---
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Run Test Suite
|
||||
|
||||
```bash
|
||||
echo "📋 Running test suite..."
|
||||
|
||||
# Run all tests
|
||||
npm test
|
||||
|
||||
# Or for other stacks:
|
||||
# pytest
|
||||
# dotnet test
|
||||
# mvn test
|
||||
# cargo test
|
||||
```
|
||||
|
||||
**Expected output:**
|
||||
```
|
||||
✅ PASS __tests__/components/UserDashboard.test.tsx
|
||||
UserDashboard
|
||||
AC1: Display user profile information
|
||||
✓ should render user name (12ms)
|
||||
✓ should render user email (8ms)
|
||||
✓ should render user avatar (6ms)
|
||||
AC2: Allow user to edit profile
|
||||
✓ should show edit button when not in edit mode (10ms)
|
||||
✓ should enable edit mode when edit button clicked (15ms)
|
||||
✓ should save changes when save button clicked (22ms)
|
||||
|
||||
Test Suites: 1 passed, 1 total
|
||||
Tests: 6 passed, 6 total
|
||||
Time: 2.134s
|
||||
```
|
||||
|
||||
**If tests fail:**
|
||||
```
|
||||
❌ Test failures detected!
|
||||
|
||||
Failed tests:
|
||||
- UserDashboard › AC2 › should save changes when save button clicked
|
||||
Expected: { name: 'Jane Doe', email: 'john@example.com' }
|
||||
Received: undefined
|
||||
|
||||
Action required:
|
||||
1. Analyze the failure
|
||||
2. Fix the implementation
|
||||
3. Re-run tests
|
||||
4. Repeat until all tests pass
|
||||
|
||||
DO NOT PROCEED until all tests pass.
|
||||
```
|
||||
|
||||
### 2. Check Test Coverage
|
||||
|
||||
```bash
|
||||
echo "📊 Checking test coverage..."
|
||||
|
||||
# Generate coverage report
|
||||
npm run test:coverage
|
||||
|
||||
# Or for other stacks:
|
||||
# pytest --cov
|
||||
# dotnet test /p:CollectCoverage=true
|
||||
# cargo tarpaulin
|
||||
```
|
||||
|
||||
**Minimum coverage thresholds:**
|
||||
```yaml
|
||||
Line Coverage: ≥80%
|
||||
Branch Coverage: ≥75%
|
||||
Function Coverage: ≥80%
|
||||
Statement Coverage: ≥80%
|
||||
```
|
||||
|
||||
**If coverage is low:**
|
||||
```
|
||||
⚠️ Test coverage below threshold!
|
||||
|
||||
Current coverage:
|
||||
Lines: 72% (threshold: 80%)
|
||||
Branches: 68% (threshold: 75%)
|
||||
Functions: 85% (threshold: 80%)
|
||||
|
||||
Uncovered areas:
|
||||
- src/components/UserDashboard.tsx: lines 45-52 (error handling)
|
||||
- src/services/userService.ts: lines 23-28 (edge case)
|
||||
|
||||
Action required:
|
||||
1. Add tests for uncovered code paths
|
||||
2. Re-run coverage check
|
||||
3. Achieve ≥80% coverage before proceeding
|
||||
```
|
||||
|
||||
### 3. Run Type Checker
|
||||
|
||||
```bash
|
||||
echo "🔍 Running type checker..."
|
||||
|
||||
# For TypeScript
|
||||
npx tsc --noEmit
|
||||
|
||||
# For Python
|
||||
# mypy src/
|
||||
|
||||
# For C#
|
||||
# dotnet build
|
||||
|
||||
# For Java
|
||||
# mvn compile
|
||||
```
|
||||
|
||||
**Expected output:**
|
||||
```
|
||||
✅ No type errors found
|
||||
```
|
||||
|
||||
**If type errors found:**
|
||||
```
|
||||
❌ Type errors detected!
|
||||
|
||||
src/components/UserDashboard.tsx:45:12 - error TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
|
||||
|
||||
45 onSave(user.name);
|
||||
~~~~~~~~~
|
||||
|
||||
src/services/userService.ts:23:18 - error TS2339: Property 'id' does not exist on type 'User'.
|
||||
|
||||
23 return user.id;
|
||||
~~
|
||||
|
||||
Found 2 errors in 2 files.
|
||||
|
||||
Action required:
|
||||
1. Fix type errors
|
||||
2. Re-run type checker
|
||||
3. Repeat until zero errors
|
||||
|
||||
DO NOT PROCEED with type errors.
|
||||
```
|
||||
|
||||
### 4. Run Linter
|
||||
|
||||
```bash
|
||||
echo "✨ Running linter..."
|
||||
|
||||
# For JavaScript/TypeScript
|
||||
npm run lint
|
||||
|
||||
# For Python
|
||||
# pylint src/
|
||||
|
||||
# For C#
|
||||
# dotnet format --verify-no-changes
|
||||
|
||||
# For Java
|
||||
# mvn checkstyle:check
|
||||
```
|
||||
|
||||
**Expected output:**
|
||||
```
|
||||
✅ No linting errors found
|
||||
```
|
||||
|
||||
**If lint errors found:**
|
||||
```
|
||||
❌ Lint errors detected!
|
||||
|
||||
src/components/UserDashboard.tsx
|
||||
45:1 error 'useState' is not defined no-undef
|
||||
52:12 error Unexpected console statement no-console
|
||||
67:5 warning Unexpected var, use let or const instead no-var
|
||||
|
||||
src/services/userService.ts
|
||||
23:1 error Missing return type on function @typescript-eslint/explicit-function-return-type
|
||||
|
||||
✖ 4 problems (3 errors, 1 warning)
|
||||
|
||||
Action required:
|
||||
1. Run auto-fix if available: npm run lint:fix
|
||||
2. Manually fix remaining errors
|
||||
3. Re-run linter
|
||||
4. Repeat until zero errors and zero warnings
|
||||
|
||||
DO NOT PROCEED with lint errors.
|
||||
```
|
||||
|
||||
### 5. Auto-Fix What's Possible
|
||||
|
||||
```bash
|
||||
echo "🔧 Attempting auto-fixes..."
|
||||
|
||||
# Run formatters and auto-fixable linters
|
||||
npm run lint:fix
|
||||
npm run format
|
||||
|
||||
# Stage the auto-fixes
|
||||
git add .
|
||||
```
|
||||
|
||||
### 6. Manual Fixes
|
||||
|
||||
For issues that can't be auto-fixed:
|
||||
|
||||
```typescript
|
||||
// Example: Fix type error
|
||||
// Before:
|
||||
const userName = user.name; // Type error if name is optional
|
||||
onSave(userName);
|
||||
|
||||
// After:
|
||||
const userName = user.name ?? ''; // Handle undefined case
|
||||
onSave(userName);
|
||||
```
|
||||
|
||||
```typescript
|
||||
// Example: Fix lint error
|
||||
// Before:
|
||||
var count = 0; // ESLint: no-var
|
||||
|
||||
// After:
|
||||
let count = 0; // Use let instead of var
|
||||
```
|
||||
|
||||
### 7. Verify All Checks Pass
|
||||
|
||||
Run everything again to confirm:
|
||||
|
||||
```bash
|
||||
echo "✅ Final verification..."
|
||||
|
||||
# Run all checks
|
||||
npm test && \
|
||||
npx tsc --noEmit && \
|
||||
npm run lint
|
||||
|
||||
echo "✅ ALL QUALITY CHECKS PASSED!"
|
||||
```
|
||||
|
||||
### 8. Commit Quality Fixes
|
||||
|
||||
```bash
|
||||
# Only if fixes were needed
|
||||
if git diff --cached --quiet; then
|
||||
echo "No fixes needed - all checks passed first time!"
|
||||
else
|
||||
git commit -m "fix(story-{story_id}): address quality check issues
|
||||
|
||||
- Fix type errors
|
||||
- Resolve lint violations
|
||||
- Improve test coverage to {coverage}%
|
||||
|
||||
All automated checks now passing:
|
||||
✅ Tests: {test_count} passed
|
||||
✅ Type check: No errors
|
||||
✅ Linter: No violations
|
||||
✅ Coverage: {coverage}%"
|
||||
fi
|
||||
```
|
||||
|
||||
### 9. Update State
|
||||
|
||||
```yaml
|
||||
# Update {stateFile}
|
||||
current_step: 6
|
||||
quality_checks:
|
||||
tests_passed: true
|
||||
test_count: {test_count}
|
||||
coverage: {coverage}%
|
||||
type_check_passed: true
|
||||
lint_passed: true
|
||||
all_checks_passed: true
|
||||
ready_for_code_review: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Gate
|
||||
|
||||
**CRITICAL:** This is a **BLOCKING STEP**. You **MUST NOT** proceed to code review until ALL of the following pass:
|
||||
|
||||
✅ **All tests passing** (0 failures)
|
||||
✅ **Test coverage ≥80%** (or project threshold)
|
||||
✅ **Zero type errors**
|
||||
✅ **Zero lint errors**
|
||||
✅ **Zero lint warnings** (or all warnings justified and documented)
|
||||
|
||||
If ANY check fails:
|
||||
1. Fix the issue
|
||||
2. Re-run all checks
|
||||
3. Repeat until ALL PASS
|
||||
4. THEN proceed to next step
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Tests fail sporadically:**
|
||||
- Check for test interdependencies
|
||||
- Look for timing issues (use `waitFor` in async tests)
|
||||
- Check for environment-specific issues
|
||||
|
||||
**Type errors in third-party libraries:**
|
||||
- Install `@types` packages
|
||||
- Use type assertions carefully (document why)
|
||||
- Consider updating library versions
|
||||
|
||||
**Lint rules conflict with team standards:**
|
||||
- Discuss with team before changing config
|
||||
- Document exceptions in comments
|
||||
- Update lint config if truly inappropriate
|
||||
|
||||
**Coverage can't reach 80%:**
|
||||
- Focus on critical paths first
|
||||
- Test error cases and edge cases
|
||||
- Consider if untested code is actually needed
|
||||
|
||||
---
|
||||
|
||||
## Skip Conditions
|
||||
|
||||
This step CANNOT be skipped. All stories must pass quality checks.
|
||||
|
||||
The only exception: Documentation-only stories with zero code changes.
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
Proceed to **Step 7: Code Review** ({nextStep})
|
||||
|
||||
Now that all automated checks pass, the code is ready for human/AI review.
|
||||
|
|
@ -0,0 +1,327 @@
|
|||
---
|
||||
name: 'step-08-review-analysis'
|
||||
description: 'Intelligently analyze code review findings - distinguish real issues from gold plating'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-08-review-analysis.md'
|
||||
stateFile: '{state_file}'
|
||||
storyFile: '{story_file}'
|
||||
reviewReport: '{sprint_artifacts}/review-{story_id}.md'
|
||||
|
||||
# Next step
|
||||
nextStep: '{workflow_path}/steps/step-09-fix-issues.md'
|
||||
---
|
||||
|
||||
# Step 8: Review Analysis
|
||||
|
||||
**Goal:** Critically analyze code review findings to distinguish **real problems** from **gold plating**, **false positives**, and **overzealous suggestions**.
|
||||
|
||||
## The Problem
|
||||
|
||||
AI code reviewers (and human reviewers) sometimes:
|
||||
- 🎨 **Gold plate**: Suggest unnecessary perfectionism
|
||||
- 🔍 **Overreact**: Flag non-issues to appear thorough
|
||||
- 📚 **Over-engineer**: Suggest abstractions for simple cases
|
||||
- ⚖️ **Misjudge context**: Apply rules without understanding tradeoffs
|
||||
|
||||
## The Solution
|
||||
|
||||
**Critical thinking filter**: Evaluate each finding objectively.
|
||||
|
||||
---
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Load Review Report
|
||||
|
||||
```bash
|
||||
# Read the code review report
|
||||
review_report="{reviewReport}"
|
||||
test -f "$review_report" || (echo "⚠️ No review report found" && exit 0)
|
||||
```
|
||||
|
||||
Parse findings by severity:
|
||||
- 🔴 CRITICAL
|
||||
- 🟠 HIGH
|
||||
- 🟡 MEDIUM
|
||||
- 🔵 LOW
|
||||
- ℹ️ INFO
|
||||
|
||||
### 2. Categorize Each Finding
|
||||
|
||||
For EACH finding, ask these questions:
|
||||
|
||||
#### Question 1: Is this a REAL problem?
|
||||
|
||||
```
|
||||
Real Problem Indicators:
|
||||
✅ Would cause bugs or incorrect behavior
|
||||
✅ Would cause security vulnerabilities
|
||||
✅ Would cause performance issues in production
|
||||
✅ Would make future maintenance significantly harder
|
||||
✅ Violates team/project standards documented in codebase
|
||||
|
||||
NOT Real Problems:
|
||||
❌ "Could be more elegant" (subjective style preference)
|
||||
❌ "Consider adding abstraction" (YAGNI - you aren't gonna need it)
|
||||
❌ "This pattern is not ideal" (works fine, alternative is marginal)
|
||||
❌ "Add comprehensive error handling" (for impossible error cases)
|
||||
❌ "Add logging everywhere" (log signal, not noise)
|
||||
```
|
||||
|
||||
#### Question 2: Does this finding understand CONTEXT?
|
||||
|
||||
```
|
||||
Context Considerations:
|
||||
📋 Story scope: Does fixing this exceed story requirements?
|
||||
🎯 Project maturity: Is this MVP, beta, or production-hardened?
|
||||
⚡ Performance criticality: Is this a hot path or cold path?
|
||||
👥 Team standards: Does team actually follow this pattern?
|
||||
📊 Data scale: Does this handle actual expected volume?
|
||||
|
||||
Example of MISSING context:
|
||||
Finding: "Add database indexing for better performance"
|
||||
Reality: Table has 100 rows total, query runs once per day
|
||||
Verdict: ❌ REJECT - Premature optimization
|
||||
```
|
||||
|
||||
#### Question 3: Is this ACTIONABLE?
|
||||
|
||||
```
|
||||
Actionable Findings:
|
||||
✅ Specific file, line number, exact issue
|
||||
✅ Clear explanation of problem
|
||||
✅ Concrete recommendation for fix
|
||||
✅ Can be fixed in reasonable time
|
||||
|
||||
NOT Actionable:
|
||||
❌ Vague: "Code quality could be improved"
|
||||
❌ No location: "Some error handling is missing"
|
||||
❌ No recommendation: "This might cause issues"
|
||||
❌ Massive scope: "Refactor entire architecture"
|
||||
```
|
||||
|
||||
### 3. Classification Decision Tree
|
||||
|
||||
For each finding, classify as:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Finding Classification Decision Tree │
|
||||
└─────────────────────────────────────────┘
|
||||
|
||||
Is it a CRITICAL security/correctness issue?
|
||||
├─ YES → 🔴 MUST FIX
|
||||
└─ NO ↓
|
||||
|
||||
Does it violate documented project standards?
|
||||
├─ YES → 🟠 SHOULD FIX
|
||||
└─ NO ↓
|
||||
|
||||
Would it prevent future maintenance?
|
||||
├─ YES → 🟡 CONSIDER FIX (if in scope)
|
||||
└─ NO ↓
|
||||
|
||||
Is it gold plating / over-engineering?
|
||||
├─ YES → ⚪ REJECT (document why)
|
||||
└─ NO ↓
|
||||
|
||||
Is it a style/opinion without real impact?
|
||||
├─ YES → ⚪ REJECT (document why)
|
||||
└─ NO → 🔵 OPTIONAL (tech debt backlog)
|
||||
```
|
||||
|
||||
### 4. Create Classification Report
|
||||
|
||||
```markdown
|
||||
# Code Review Analysis: Story {story_id}
|
||||
|
||||
## Review Metadata
|
||||
- Reviewer: {reviewer_type} (Adversarial / Multi-Agent)
|
||||
- Total Findings: {total_findings}
|
||||
- Review Date: {date}
|
||||
|
||||
## Classification Results
|
||||
|
||||
### 🔴 MUST FIX (Critical - Blocking)
|
||||
Total: {must_fix_count}
|
||||
|
||||
1. **[SECURITY] Unvalidated user input in API endpoint**
|
||||
- File: `src/api/users.ts:45`
|
||||
- Issue: POST /api/users accepts unvalidated input, SQL injection risk
|
||||
- Why this is real: Security vulnerability, could lead to data breach
|
||||
- Action: Add input validation with Zod schema
|
||||
- Estimated effort: 30 min
|
||||
|
||||
2. **[CORRECTNESS] Race condition in state update**
|
||||
- File: `src/components/UserForm.tsx:67`
|
||||
- Issue: Multiple async setState calls without proper sequencing
|
||||
- Why this is real: Causes intermittent bugs in production
|
||||
- Action: Use functional setState or useReducer
|
||||
- Estimated effort: 20 min
|
||||
|
||||
### 🟠 SHOULD FIX (High Priority)
|
||||
Total: {should_fix_count}
|
||||
|
||||
3. **[STANDARDS] Missing error handling per team convention**
|
||||
- File: `src/services/userService.ts:34`
|
||||
- Issue: API calls lack try-catch per documented standards
|
||||
- Why this matters: Team standard in CONTRIBUTING.md section 3.2
|
||||
- Action: Wrap in try-catch, log errors
|
||||
- Estimated effort: 15 min
|
||||
|
||||
### 🟡 CONSIDER FIX (Medium - If in scope)
|
||||
Total: {consider_count}
|
||||
|
||||
4. **[MAINTAINABILITY] Complex nested conditional**
|
||||
- File: `src/utils/validation.ts:23`
|
||||
- Issue: 4-level nested if-else hard to read
|
||||
- Why this matters: Could confuse future maintainers
|
||||
- Action: Extract to guard clauses or lookup table
|
||||
- Estimated effort: 45 min
|
||||
- **Scope consideration**: Nice to have, but not blocking
|
||||
|
||||
### ⚪ REJECTED (Gold Plating / False Positives)
|
||||
Total: {rejected_count}
|
||||
|
||||
5. **[REJECTED] "Add comprehensive logging to all functions"**
|
||||
- Reason: Gold plating - logging should be signal, not noise
|
||||
- Context: These are simple utility functions, no debugging issues
|
||||
- Verdict: REJECT - Would create log spam
|
||||
|
||||
6. **[REJECTED] "Extract component for reusability"**
|
||||
- Reason: YAGNI - component used only once, no reuse planned
|
||||
- Context: Story scope is single-use dashboard widget
|
||||
- Verdict: REJECT - Premature abstraction
|
||||
|
||||
7. **[REJECTED] "Add database connection pooling"**
|
||||
- Reason: Premature optimization - current load is minimal
|
||||
- Context: App has 10 concurrent users max, no performance issues
|
||||
- Verdict: REJECT - Optimize when needed, not speculatively
|
||||
|
||||
8. **[REJECTED] "Consider microservices architecture"**
|
||||
- Reason: Out of scope - architectural decision beyond story
|
||||
- Context: Story is adding a single API endpoint
|
||||
- Verdict: REJECT - Massive overreach
|
||||
|
||||
### 🔵 OPTIONAL (Tech Debt Backlog)
|
||||
Total: {optional_count}
|
||||
|
||||
9. **[STYLE] Inconsistent naming convention**
|
||||
- File: `src/utils/helpers.ts:12`
|
||||
- Issue: camelCase vs snake_case mixing
|
||||
- Why low priority: Works fine, linter doesn't flag it
|
||||
- Action: Standardize to camelCase when touching this file later
|
||||
- Create tech debt ticket: TD-{number}
|
||||
|
||||
## Summary
|
||||
|
||||
**Action Plan:**
|
||||
- 🔴 MUST FIX: {must_fix_count} issues (blocking)
|
||||
- 🟠 SHOULD FIX: {should_fix_count} issues (high priority)
|
||||
- 🟡 CONSIDER: {consider_count} issues (if time permits)
|
||||
- ⚪ REJECTED: {rejected_count} findings (documented why)
|
||||
- 🔵 OPTIONAL: {optional_count} items (tech debt backlog)
|
||||
|
||||
**Estimated fix time:** {total_fix_time_hours} hours
|
||||
|
||||
**Proceed to:** Step 9 - Fix Issues (implement MUST FIX + SHOULD FIX items)
|
||||
```
|
||||
|
||||
### 5. Document Rejections
|
||||
|
||||
**CRITICAL:** When rejecting findings, ALWAYS document WHY:
|
||||
|
||||
```markdown
|
||||
## Rejected Findings - Rationale
|
||||
|
||||
### Finding: "Add caching layer for all API calls"
|
||||
**Rejected because:**
|
||||
- ⚡ Premature optimization - no performance issues detected
|
||||
- 📊 Traffic analysis shows <100 requests/day
|
||||
- 🎯 Story scope is feature addition, not optimization
|
||||
- 💰 Cost: 2 days implementation, 0 proven benefit
|
||||
- 📝 Decision: Monitor first, optimize if needed
|
||||
|
||||
### Finding: "Refactor to use dependency injection"
|
||||
**Rejected because:**
|
||||
- 🏗️ Over-engineering - current approach works fine
|
||||
- 📏 Codebase size doesn't justify DI complexity
|
||||
- 👥 Team unfamiliar with DI patterns
|
||||
- 🎯 Story scope: simple feature, not architecture overhaul
|
||||
- 📝 Decision: Keep it simple, revisit if codebase grows
|
||||
|
||||
### Finding: "Add comprehensive JSDoc to all functions"
|
||||
**Rejected because:**
|
||||
- 📚 Gold plating - TypeScript types provide documentation
|
||||
- ⏱️ Time sink - 4+ hours for marginal benefit
|
||||
- 🎯 Team standard: JSDoc only for public APIs
|
||||
- 📝 Decision: Follow team convention, not reviewer preference
|
||||
```
|
||||
|
||||
### 6. Update State
|
||||
|
||||
```yaml
|
||||
# Update {stateFile}
|
||||
current_step: 8
|
||||
review_analysis:
|
||||
must_fix: {must_fix_count}
|
||||
should_fix: {should_fix_count}
|
||||
consider: {consider_count}
|
||||
rejected: {rejected_count}
|
||||
optional: {optional_count}
|
||||
estimated_fix_time: "{total_fix_time_hours}h"
|
||||
rejections_documented: true
|
||||
analysis_complete: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Critical Thinking Framework
|
||||
|
||||
Use this framework to evaluate EVERY finding:
|
||||
|
||||
### The "So What?" Test
|
||||
- **Ask:** "So what if we don't fix this?"
|
||||
- **If answer is:** "Nothing bad happens" → REJECT
|
||||
- **If answer is:** "Production breaks" → MUST FIX
|
||||
|
||||
### The "YAGNI" Test (You Aren't Gonna Need It)
|
||||
- **Ask:** "Do we need this NOW for current requirements?"
|
||||
- **If answer is:** "Maybe someday" → REJECT
|
||||
- **If answer is:** "Yes, breaks without it" → FIX
|
||||
|
||||
### The "Scope" Test
|
||||
- **Ask:** "Is this within the story's scope?"
|
||||
- **If answer is:** "No, requires new story" → REJECT (or create new story)
|
||||
- **If answer is:** "Yes, part of ACs" → FIX
|
||||
|
||||
### The "Team Standard" Test
|
||||
- **Ask:** "Does our team actually do this?"
|
||||
- **If answer is:** "No, reviewer's opinion" → REJECT
|
||||
- **If answer is:** "Yes, in CONTRIBUTING.md" → FIX
|
||||
|
||||
---
|
||||
|
||||
## Common Rejection Patterns
|
||||
|
||||
Learn to recognize these patterns:
|
||||
|
||||
1. **"Consider adding..."** - Usually gold plating unless critical
|
||||
2. **"It would be better if..."** - Subjective opinion, often rejectable
|
||||
3. **"For maximum performance..."** - Premature optimization
|
||||
4. **"To follow best practices..."** - Check if team actually follows it
|
||||
5. **"This could be refactored..."** - Does it need refactoring NOW?
|
||||
6. **"Add comprehensive..."** - Comprehensive = overkill most of the time
|
||||
7. **"Future-proof by..."** - Can't predict future, solve current problems
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
Proceed to **Step 9: Fix Issues** ({nextStep})
|
||||
|
||||
Implement MUST FIX and SHOULD FIX items. Skip rejected items (already documented why).
|
||||
|
|
@ -0,0 +1,218 @@
|
|||
name: super-dev-pipeline
|
||||
description: "Step-file architecture with complexity-based routing, smart batching, and auto-story-creation. Micro stories get lightweight path, standard/complex get full quality gates."
|
||||
author: "BMad"
|
||||
version: "1.4.0" # Added auto-create story via /create-story-with-gap-analysis when story missing or incomplete
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
|
||||
# Workflow paths
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
|
||||
steps_path: "{installed_path}/steps"
|
||||
templates_path: "{installed_path}/templates"
|
||||
checklists_path: "{installed_path}/checklists"
|
||||
|
||||
# State management
|
||||
state_file: "{sprint_artifacts}/super-dev-state-{{story_id}}.yaml"
|
||||
audit_trail: "{sprint_artifacts}/audit-super-dev-{{story_id}}-{{date}}.yaml"
|
||||
|
||||
# Auto-create story settings (NEW v1.4.0)
|
||||
# When story is missing or lacks proper context, auto-invoke /create-story-with-gap-analysis
|
||||
auto_create_story:
|
||||
enabled: true # Set to false to revert to old HALT behavior
|
||||
create_story_workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story-with-gap-analysis"
|
||||
triggers:
|
||||
- story_not_found # Story file doesn't exist
|
||||
- no_tasks # Story exists but has no tasks
|
||||
- missing_sections # Story missing required sections (Tasks, Acceptance Criteria)
|
||||
|
||||
# Complexity level (passed from batch-super-dev or set manually)
|
||||
# Controls which pipeline steps to execute
|
||||
complexity_level: "standard" # micro | standard | complex
|
||||
|
||||
# Complexity-based step skipping (NEW v1.2.0)
|
||||
complexity_routing:
|
||||
micro:
|
||||
skip_steps: [2, 5] # Skip pre-gap analysis and code review
|
||||
description: "Lightweight path for simple stories (≤3 tasks, low risk)"
|
||||
standard:
|
||||
skip_steps: [] # Full pipeline
|
||||
description: "Normal path with all quality gates"
|
||||
complex:
|
||||
skip_steps: [] # Full pipeline + warnings
|
||||
description: "Enhanced path for high-risk stories"
|
||||
warn_before_start: true
|
||||
suggest_split: true
|
||||
|
||||
# Workflow modes
|
||||
modes:
|
||||
interactive:
|
||||
description: "Human-in-the-loop with menu navigation between steps"
|
||||
checkpoint_on_failure: true
|
||||
requires_approval: true
|
||||
smart_batching: true # User can approve batching plan
|
||||
batch:
|
||||
description: "Unattended execution for batch-super-dev"
|
||||
checkpoint_on_failure: true
|
||||
requires_approval: false
|
||||
fail_fast: true
|
||||
smart_batching: true # Auto-enabled for efficiency
|
||||
|
||||
# Smart batching configuration
|
||||
smart_batching:
|
||||
enabled: true
|
||||
detect_patterns: true
|
||||
default_to_safe: true # When uncertain, execute individually
|
||||
min_batch_size: 3 # Minimum tasks to form a batch
|
||||
fallback_on_failure: true # Revert to individual if batch fails
|
||||
|
||||
# Batchable pattern definitions
|
||||
batchable_patterns:
|
||||
- pattern: "package_installation"
|
||||
keywords: ["Add", "package.json", "npm install", "dependency"]
|
||||
risk_level: "low"
|
||||
validation: "npm install && npm run build"
|
||||
|
||||
- pattern: "module_registration"
|
||||
keywords: ["Import", "Module", "app.module", "register"]
|
||||
risk_level: "low"
|
||||
validation: "tsc --noEmit"
|
||||
|
||||
- pattern: "code_deletion"
|
||||
keywords: ["Delete", "Remove", "rm ", "unlink"]
|
||||
risk_level: "low"
|
||||
validation: "npm test && npm run build"
|
||||
|
||||
- pattern: "import_update"
|
||||
keywords: ["Update import", "Change import", "import from"]
|
||||
risk_level: "low"
|
||||
validation: "npm run build"
|
||||
|
||||
# Non-batchable pattern definitions (always execute individually)
|
||||
individual_patterns:
|
||||
- pattern: "business_logic"
|
||||
keywords: ["circuit breaker", "fallback", "caching for", "strategy"]
|
||||
risk_level: "medium"
|
||||
|
||||
- pattern: "security"
|
||||
keywords: ["auth", "permission", "security", "encrypt"]
|
||||
risk_level: "high"
|
||||
|
||||
- pattern: "data_migration"
|
||||
keywords: ["migration", "schema", "ALTER TABLE", "database"]
|
||||
risk_level: "high"
|
||||
|
||||
# Agent role definitions (loaded once, switched as needed)
|
||||
agents:
|
||||
dev:
|
||||
name: "Developer"
|
||||
persona: "{project-root}/_bmad/bmm/agents/dev.md"
|
||||
description: "Pre-gap, implementation, post-validation, code review"
|
||||
used_in_steps: [2, 3, 4, 5]
|
||||
sm:
|
||||
name: "Scrum Master"
|
||||
persona: "{project-root}/_bmad/bmm/agents/sm.md"
|
||||
description: "Story completion and status"
|
||||
used_in_steps: [6]
|
||||
|
||||
# Step file definitions
|
||||
steps:
|
||||
- step: 1
|
||||
file: "{steps_path}/step-01-init.md"
|
||||
name: "Initialize"
|
||||
description: "Load story context and detect development mode"
|
||||
agent: null
|
||||
quality_gate: false
|
||||
|
||||
- step: 2
|
||||
file: "{steps_path}/step-02-pre-gap-analysis.md"
|
||||
name: "Pre-Gap Analysis"
|
||||
description: "Validate tasks against codebase (critical for brownfield)"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
|
||||
- step: 3
|
||||
file: "{steps_path}/step-03-implement.md"
|
||||
name: "Implement"
|
||||
description: "Adaptive implementation (TDD for new, refactor for existing)"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
|
||||
- step: 4
|
||||
file: "{steps_path}/step-04-post-validation.md"
|
||||
name: "Post-Validation"
|
||||
description: "Verify completed tasks against codebase reality"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
iterative: true # May re-invoke step 3 if gaps found
|
||||
|
||||
- step: 5
|
||||
file: "{steps_path}/step-05-code-review.md"
|
||||
name: "Code Review"
|
||||
description: "Adversarial code review finding 3-10 issues"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
|
||||
- step: 6
|
||||
file: "{steps_path}/step-06-complete.md"
|
||||
name: "Complete"
|
||||
description: "Commit and push changes"
|
||||
agent: sm
|
||||
quality_gate: false
|
||||
|
||||
- step: 7
|
||||
file: "{steps_path}/step-07-summary.md"
|
||||
name: "Summary"
|
||||
description: "Generate audit trail"
|
||||
agent: null
|
||||
quality_gate: false
|
||||
|
||||
# Quality gates
|
||||
quality_gates:
|
||||
pre_gap_analysis:
|
||||
step: 2
|
||||
criteria:
|
||||
- "All tasks validated or refined"
|
||||
- "No missing context"
|
||||
- "Implementation path clear"
|
||||
|
||||
implementation:
|
||||
step: 3
|
||||
criteria:
|
||||
- "All tasks completed"
|
||||
- "Tests pass"
|
||||
- "Code follows project patterns"
|
||||
|
||||
post_validation:
|
||||
step: 4
|
||||
criteria:
|
||||
- "All completed tasks verified against codebase"
|
||||
- "Zero false positives remaining"
|
||||
- "Files/functions/tests actually exist"
|
||||
|
||||
code_review:
|
||||
step: 5
|
||||
criteria:
|
||||
- "3-10 specific issues identified"
|
||||
- "All issues resolved or documented"
|
||||
- "Security review complete"
|
||||
|
||||
# Document loading strategies
|
||||
input_file_patterns:
|
||||
story:
|
||||
description: "Story file being developed"
|
||||
pattern: "{sprint_artifacts}/story-*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
cache: true
|
||||
|
||||
project_context:
|
||||
description: "Critical rules and patterns"
|
||||
pattern: "**/project-context.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
cache: true
|
||||
|
||||
standalone: true
|
||||
Loading…
Reference in New Issue