fstrent-qa
npx machina-cli add skill wrm3/ai_project_template/fstrent-qa --openclawfstrent Quality Assurance Skill
Track bugs, manage quality assurance processes, and document fixes using the fstrent_spec_tasks QA system. This Skill provides structured bug tracking that integrates with task management and feature documentation.
System Overview
The fstrent_spec_tasks QA system uses:
- BUGS.md:
.fstrent_spec_tasks/BUGS.md- Centralized bug tracking - Bug Tasks:
.fstrent_spec_tasks/tasks/- Bug fix task files - Task Integration: Links to TASKS.md for bug resolution tracking
- Feature Integration: Links to features/ for impact assessment
Bug Tracking System
Bug Classification
Severity Levels:
- Critical: System crashes, data loss, security vulnerabilities
- High: Major feature failures, performance degradation >50%
- Medium: Minor feature issues, usability problems
- Low: Cosmetic issues, enhancement requests
Source Attribution:
- User Reported: Issues reported by end users or stakeholders
- Development: Bugs discovered during feature development
- Testing: Issues found during QA or automated testing
- Production: Live environment issues requiring immediate attention
BUGS.md Structure
Location: .fstrent_spec_tasks/BUGS.md
Format:
# Bug Tracking
## Active Bugs
### Bug ID: BUG-001
- **Title**: [Brief description of the issue]
- **Severity**: [Critical/High/Medium/Low]
- **Source**: [User Reported/Development/Testing/Production]
- **Feature Impact**: [List affected features]
- **Status**: [Open/Investigating/Fixing/Testing/Closed]
- **Task Reference**: [Link to task in TASKS.md]
- **Created**: [Date]
- **Assigned**: [Developer/Team]
### Bug ID: BUG-002
[Additional bugs...]
## Closed Bugs
### Bug ID: BUG-XXX
[Resolved bugs for reference...]
Bug Entry Template
### Bug ID: BUG-{number}
- **Title**: {Brief description}
- **Severity**: {Critical|High|Medium|Low}
- **Source**: {User Reported|Development|Testing|Production}
- **Feature Impact**: {affected features}
- **Status**: {Open|Investigating|Fixing|Testing|Closed}
- **Task Reference**: Task {id}
- **Created**: {date}
- **Assigned**: {developer}
**Description**:
{Detailed description of the issue}
**Reproduction Steps**:
1. {Step 1}
2. {Step 2}
3. {Step 3}
**Expected Behavior**:
{What should happen}
**Actual Behavior**:
{What actually happens}
**Environment**:
- OS: {operating system}
- Version: {software version}
- Browser: {if applicable}
Bug Task Integration
When a Bug is Identified
Process:
- Create BUGS.md entry with bug details
- Create corresponding task in TASKS.md with
[BUG]prefix - Create task file in tasks/ folder with bug_fix type
- Link bug to affected features in feature documents
- Track resolution through task completion
Bug Task File Format
Filename: task{id}_fix_{bug_description}.md
YAML Frontmatter:
---
id: {next_available_id}
title: '[BUG] {Brief description of the issue}'
type: bug_fix
status: pending
priority: {critical|high|medium|low}
feature: {affected_feature}
subsystems: {affected_subsystems}
project_context: 'Resolves {bug_type} affecting {system_component}, maintaining {expected_behavior}'
bug_reference: BUG-{number}
severity: {critical|high|medium|low}
source: {user_reported|development|testing|production}
reproduction_steps: '{step_by_step_instructions}'
expected_behavior: '{what_should_happen}'
actual_behavior: '{what_actually_happens}'
---
# Task {id}: [BUG] {Description}
## Objective
Fix {bug_type} that causes {problem}
## Bug Details
**Bug Reference**: BUG-{number}
**Severity**: {level}
**Source**: {source}
## Reproduction Steps
1. {Step 1}
2. {Step 2}
3. {Step 3}
## Expected vs Actual Behavior
**Expected**: {what_should_happen}
**Actual**: {what_actually_happens}
## Fix Implementation
{Technical approach to fix}
## Acceptance Criteria
- [ ] Bug can no longer be reproduced
- [ ] Fix doesn't introduce regressions
- [ ] Tests added to prevent recurrence
- [ ] Documentation updated if needed
## Testing Plan
- Test original reproduction steps
- Test related functionality
- Run regression tests
Bug Lifecycle
- Discovery: Bug identified and reported
- Documentation: Entry created in BUGS.md
- Task Creation: Bug fix task created
- Investigation: Root cause analysis (Status: Investigating)
- Fix Implementation: Solution developed (Status: Fixing)
- Testing: Fix validated (Status: Testing)
- Closure: Bug resolved (Status: Closed)
Retroactive Fix Documentation
Purpose
Capture and document fixes, improvements, and solutions completed in chat for historical context and memory preservation.
When to Document
Document as retroactive task if:
- ✅ Fix required >15 minutes of work
- ✅ Solution affects multiple files or subsystems
- ✅ Fix provides value for future reference
- ✅ Resolution required technical analysis or debugging
Skip documentation if:
- ❌ Simple typo corrections
- ❌ Minor formatting adjustments
- ❌ Clarification-only conversations
Retroactive Task Template
Filename: task{id}_retroactive_{description}.md
YAML Frontmatter:
---
id: {next_available_id}
title: '[RETROACTIVE] {Description of fix/improvement}'
type: retroactive_fix
status: completed
priority: {original_urgency_level}
created_date: '{fix_completion_date}'
completed_date: '{fix_completion_date}'
project_context: 'Documents previously completed {solution_type} that addressed {project_need}, maintaining {system_capability}'
subsystems: {affected_subsystems}
estimated_effort: '{actual_time_spent}'
actual_effort: '{actual_time_spent}'
---
# Task {id}: [RETROACTIVE] {Description}
## Objective
Document {fix_type} that was completed in chat
## What Was Fixed
{Description of the problem that was solved}
## Solution Implemented
{Description of the solution}
## Files Changed
- {file1}
- {file2}
## Impact
{How this fix improves the system}
## Lessons Learned
{Insights for preventing similar issues}
Retroactive Documentation Workflow
- Fix Assessment: Review completed chat work against scope criteria
- Task Creation: Generate task file using retroactive template
- System Integration: Add entry to TASKS.md with completed status
- Archive: Archive to memory if task meets archival criteria
Quality Management
Quality Metrics
Bug Metrics:
- Bug Discovery Rate: Bugs found per development cycle
- Bug Resolution Time: Average time from discovery to resolution
- Bug Severity Distribution: Breakdown by severity level
- Feature Impact Analysis: Which features are most affected
- Regression Rate: Percentage of fixes that introduce new bugs
Quality Gates:
- Code review required for all changes
- Testing requirements (unit, integration, manual)
- Documentation standards
- Performance benchmarks
- Security scanning
Quality Workflows
Bug Reporting Workflow:
- User reports issue
- Assess severity and source
- Create BUGS.md entry
- Create bug fix task
- Assign to developer
- Track through resolution
Fix Verification Workflow:
- Developer implements fix
- Update task status to Testing
- Verify fix resolves issue
- Run regression tests
- Update BUGS.md status to Closed
- Mark task as completed
Quality Review Workflow:
- Review bug metrics weekly
- Identify patterns and trends
- Address high-impact areas
- Update quality processes
- Document improvements
Bug Operations
Report New Bug
Process:
- Gather bug information (title, severity, steps, expected/actual behavior)
- Determine next bug ID (read BUGS.md)
- Create bug entry in BUGS.md
- Create bug fix task file
- Update TASKS.md with bug fix task
- Link to affected features
Update Bug Status
Process:
- Read bug entry from BUGS.md
- Update Status field
- Update corresponding task status
- Add notes about progress
- Update timestamps
Status Transitions:
- Open → Investigating: Analysis started
- Investigating → Fixing: Root cause found, fix in progress
- Fixing → Testing: Fix implemented, ready for testing
- Testing → Closed: Fix verified, bug resolved
- Any → Open: Issue reopened
Close Bug
Process:
- Verify fix resolves issue
- Update BUGS.md status to Closed
- Move bug to "Closed Bugs" section
- Mark corresponding task as completed
- Document resolution details
View Bug Status
Process:
- Read BUGS.md
- Display active bugs by severity
- Show bugs by status
- Calculate bug metrics
- Identify high-priority items
Integration with Other Systems
Link to Tasks
- Every bug creates a corresponding bug fix task
- Task completion closes the bug
- Task status reflects bug resolution progress
Link to Features
- Bugs reference affected features
- Feature documents list related bugs
- Feature impact assessment through bug analysis
Link to Project Context
- Bug patterns inform architecture decisions
- Quality metrics influence project planning
- Bug fixes align with project goals
File Organization
Core QA Files
.fstrent_spec_tasks/BUGS.md- Bug tracking.fstrent_spec_tasks/tasks/- Bug fix task files.fstrent_spec_tasks/features/- Feature impact documentation
Auto-Creation
Automatically create missing files:
.fstrent_spec_tasks/BUGS.mdwith template if missing- Bug fix task files as needed
- Update TASKS.md automatically
Best Practices
Bug Reporting
- Clear, descriptive titles
- Detailed reproduction steps
- Expected vs actual behavior
- Environment information
- Screenshots or logs if helpful
Bug Fixing
- Understand root cause before fixing
- Write tests to prevent recurrence
- Consider edge cases
- Document fix rationale
- Verify no regressions
Quality Management
- Regular bug triage meetings
- Track bug metrics over time
- Address high-severity bugs first
- Learn from bug patterns
- Continuous process improvement
Documentation
- Document significant fixes retroactively
- Capture lessons learned
- Update feature documentation
- Maintain bug history
- Archive resolved bugs
Common Workflows
Workflow: Report Bug
User: "I found a bug - the login button doesn't work"
Action:
-
Ask clarifying questions:
- What happens when you click the button?
- What should happen?
- What browser/OS are you using?
- Can you reproduce it consistently?
-
Create BUGS.md entry:
### Bug ID: BUG-001
- **Title**: Login button not responding to clicks
- **Severity**: High
- **Source**: User Reported
- **Feature Impact**: User Authentication
- **Status**: Open
- **Task Reference**: Task 015
- **Created**: 2025-10-19
- **Assigned**: TBD
**Description**:
Login button on main page does not respond when clicked. No error messages displayed.
**Reproduction Steps**:
1. Navigate to homepage
2. Click "Login" button
3. Nothing happens
**Expected Behavior**:
Login modal should appear
**Actual Behavior**:
Button click has no effect
**Environment**:
- OS: Windows 11
- Browser: Chrome 118
- Version: 1.2.0
- Create bug fix task file
- Update TASKS.md:
- [ ] Task 015: [BUG] Fix login button not responding - Confirm: "Bug BUG-001 reported and task created"
Workflow: Update Bug Status
User: "I'm investigating bug 001"
Action:
- Read BUG-001 from BUGS.md
- Update Status to "Investigating"
- Update task015 status to "in-progress"
- Update TASKS.md:
[🔄] Task 015: [BUG] Fix login button not responding - Confirm: "Bug BUG-001 status updated to Investigating"
Workflow: Close Bug
User: "Bug 001 is fixed"
Action:
- Read BUG-001 from BUGS.md
- Update Status to "Closed"
- Move to "Closed Bugs" section
- Update task015 status to "completed"
- Update TASKS.md:
[✅] Task 015: [BUG] Fix login button not responding - Confirm: "Bug BUG-001 closed. Great work!"
Workflow: Document Retroactive Fix
User: "We just fixed the performance issue in chat"
Action:
- Assess scope (affects multiple files, required debugging)
- Create retroactive task file:
---
id: 016
title: '[RETROACTIVE] Fixed database query performance issue'
type: retroactive_fix
status: completed
priority: high
created_date: '2025-10-19'
completed_date: '2025-10-19'
project_context: 'Documents performance optimization that reduced query time from 5s to 0.2s'
subsystems: [database, api]
estimated_effort: '2 hours'
actual_effort: '2 hours'
---
- Update TASKS.md:
[✅] Task 016: [RETROACTIVE] Fixed database query performance issue - Confirm: "Retroactive task created to document the fix"
Examples
Example: Report Critical Bug
User: "The app crashes when saving data"
Action:
- Gather details through questions
- Create BUGS.md entry:
### Bug ID: BUG-002
- **Title**: Application crashes on data save
- **Severity**: Critical
- **Source**: Production
- **Feature Impact**: Data Persistence, User Experience
- **Status**: Open
- **Task Reference**: Task 017
- **Created**: 2025-10-19
- **Assigned**: Dev Team
**Description**:
Application crashes immediately when user attempts to save data. No error message shown, app just closes.
**Reproduction Steps**:
1. Open application
2. Make any changes to data
3. Click "Save" button
4. Application crashes
**Expected Behavior**:
Data should be saved successfully with confirmation message
**Actual Behavior**:
Application terminates unexpectedly
**Environment**:
- OS: Windows 11
- Version: 1.2.0
- Occurs on all machines tested
- Create critical priority bug fix task
- Confirm: "Critical bug BUG-002 reported. This should be addressed immediately."
Example: View Bug Status
User: "Show me all open bugs"
Action:
- Read BUGS.md
- Filter by Status: Open, Investigating, Fixing, Testing
- Display:
Active Bugs (3):
Critical (1):
- BUG-002: Application crashes on data save [Open]
High (1):
- BUG-001: Login button not responding [Investigating]
Medium (1):
- BUG-003: UI alignment issue on mobile [Fixing]
Total: 3 active bugs
Compatibility Notes
This Skill works with the same file format used by Cursor's fstrent_spec_tasks QA system. Bugs and fixes created in Claude Code can be viewed and updated in Cursor, and vice versa. The system uses:
- Standard markdown format for BUGS.md
- Consistent YAML frontmatter for bug fix tasks
- Git-friendly plain text files
- Cross-IDE compatible workflows
Teams can use both IDEs interchangeably for quality assurance activities.
Source
git clone https://github.com/wrm3/ai_project_template/blob/main/.claude/skills/fstrent-qa/SKILL.mdView on GitHub Overview
fstrent-qa provides structured bug tracking and QA workflow integrated with your task and feature docs. It centralizes issues in .fstrent_spec_tasks/BUGS.md, creates bug tasks in .fstrent_spec_tasks/tasks/, and links to TASKS.md and features docs to assess impact.
How This Skill Works
Bugs are captured as entries in .fstrent_spec_tasks/BUGS.md. For each bug, a corresponding task is created in TASKS.md with a [BUG] prefix, and a bug_fix task file is generated under .fstrent_spec_tasks/tasks/. Each artifact records severity, source, reproduction steps, and feature impact, enabling end-to-end traceability across the bug lifecycle.
When to Use It
- Reporting a new bug or issue
- Tracking ongoing issues across sprints
- Documenting fixes and resolutions
- Managing QA processes and triage
- Requests mentioning bugs, issues, quality, fixes, or QA
Quick Start
- Step 1: Identify a bug and log a BUG entry in .fstrent_spec_tasks/BUGS.md
- Step 2: Create a corresponding TASKS.md bug entry with a [BUG] prefix and assign ownership
- Step 3: Create a .fstrent_spec_tasks/tasks/ bug_fix file with reproduction steps, environment details, and feature references
Best Practices
- Log every bug in .fstrent_spec_tasks/BUGS.md with a clear title and severity
- Create a linked TASKS.md entry with a [BUG] prefix and assign ownership
- Add a task file in .fstrent_spec_tasks/tasks/ with type: bug_fix and a descriptive filename
- Link the bug to affected features in feature documents for impact assessment
- Update status and track resolution through task completion
Example Use Cases
- BUG-101: Startup crash under low-memory conditions; Severity: Critical; tied to a fix task and feature docs
- Issue: Dashboard graphics misalignment on 4K displays; Severity: High; linked to UI feature docs and a bug_fix task
- QA finding: End-to-end test failure in checkout flow; Severity: Medium; documented in BUGS.md and tracked in TASKS.md
- Production incident: Data mismatch in reports; Severity: Critical; bug task references data module features
- User-reported typo in help docs; Severity: Low; logged and scheduled for a minor fix