ros/BMAD-METHOD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: transform QA agent into Test Architect with advanced quality ca… (#433)

Browse Source 
* feat: transform QA agent into Test Architect with advanced quality capabilities

  - Add 6 specialized quality assessment commands
  - Implement risk-based testing with scoring
  - Create quality gate system with deterministic decisions
  - Add comprehensive test design and NFR validation
  - Update documentation with stage-based workflow integration

* feat: transform QA agent into Test Architect with advanced quality capabilities

  - Add 6 specialized quality assessment commands
  - Implement risk-based testing with scoring
  - Create quality gate system with deterministic decisions
  - Add comprehensive test design and NFR validation
  - Update documentation with stage-based workflow integration

* docs: refined the docs for test architect

* fix: addressed review comments from manjaroblack, round 1

* fix: addressed review comments from manjaroblack, round 1

---------

Co-authored-by: Murat Ozcan <murat@mac.lan>
Co-authored-by: Brian <bmadcode@gmail.com>
This commit is contained in:
Murat K Ozcan
2025-08-15 21:02:37 -05:00
committed by GitHub
parent 33269c888d
commit 0b61175d98
76 changed files with 9245 additions and 1442 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
dist/agents/po.txt vendored
View File

@@ -110,7 +110,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
@@ -123,14 +122,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
@@ -139,7 +136,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
@@ -147,7 +143,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
@@ -161,7 +156,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
@@ -171,7 +165,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
@@ -288,13 +281,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
For each extracted section:
1. **Generate filename**: Convert the section heading to lowercase-dash-case
- Remove special characters
- Replace spaces with dashes
- Example: "## Tech Stack" → `tech-stack.md`
2. **Adjust heading levels**:
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
- All subsection levels decrease by 1:
@@ -745,12 +736,10 @@ PROJECT TYPE DETECTION:
First, determine the project type by checking:
1. Is this a GREENFIELD project (new from scratch)?
- Look for: New project initialization, no existing codebase references
- Check for: prd.md, architecture.md, new project setup stories
2. Is this a BROWNFIELD project (enhancing existing system)?
- Look for: References to existing codebase, enhancement/modification language
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
@@ -1084,7 +1073,6 @@ Ask the user if they want to work through the checklist:
Generate a comprehensive validation report that adapts to project type:
1. Executive Summary
- Project type: [Greenfield/Brownfield] with [UI/No UI]
- Overall readiness (percentage)
- Go/No-Go recommendation
@@ -1094,42 +1082,36 @@ Generate a comprehensive validation report that adapts to project type:
2. Project-Specific Analysis
FOR GREENFIELD:
- Setup completeness
- Dependency sequencing
- MVP scope appropriateness
- Development timeline feasibility
FOR BROWNFIELD:
- Integration risk level (High/Medium/Low)
- Existing system impact assessment
- Rollback readiness
- User disruption potential
3. Risk Assessment
- Top 5 risks by severity
- Mitigation recommendations
- Timeline impact of addressing issues
- [BROWNFIELD] Specific integration risks
4. MVP Completeness
- Core features coverage
- Missing essential functionality
- Scope creep identified
- True MVP vs over-engineering
5. Implementation Readiness
- Developer clarity score (1-10)
- Ambiguous requirements count
- Missing technical details
- [BROWNFIELD] Integration point clarity
6. Recommendations
- Must-fix before development
- Should-fix for quality
- Consider for improvement