Fstrent qa
Skill wrm3/ai_project_template/plugins/fstrent-spec-tasks/skills/fstrent-qa
Track bugs, manage quality assurance, and document fixes in .fstrent_spec_tasks/ folder. Use when reporting bugs, tracking issues, documenting fixes, or managing quality processes. Triggers on requests mentioning bugs, issues, quality, fixes, or QA.From its SKILL.md
npx -y skills add wrm3/ai_project_template --skill fstrent-qaAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
14.6 KB, ~3.5k tokens by cl100k_base, as published. Nobody here has run it
fstrent 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.
What ships with it: 9 files
67.8 KB alongside SKILL.md
examples/
- bug_fix_workflow.md9.2 KB
- BUGS.md5.3 KB
- critical_bug_entry.md5.3 KB
- quality_metrics_report.md9.3 KB
reference/
- bug_classification.md7.4 KB
- cursor_rules_comparison.md3.2 KB
- quality_metrics.md7.6 KB
- retroactive_documentation.md7.8 KB
- rules.md12.7 KB
Gives 0 of the 12 instructions most docs writing skills give in ~3.5k tokens
Counted across 1,637 of the 3,044 authors here whose files we hold, read 2026-08-07
- Announce the skill at startin 54 of 1637, across 26 files
- Convert legacy doc files before editingin 45 of 1637, across 7 files
- Predict questions readers might askin 42 of 1637, across 4 files
- Generate clarifying questions for initial contextin 42 of 1637, across 3 files
- Create document scaffold with placeholder textin 42 of 1637, across 3 files
- Brainstorm content options for each sectionin 42 of 1637, across 3 files
- Test the document with a fresh context-less instancein 42 of 1637, across 3 files
- Include exact file paths in every taskin 42 of 1637, across 15 files
- Ask interview questions one at a timein 42 of 1637, across 27 files
- Apply surgical edits during refinementin 41 of 1637, across 2 files
- Offer structured workflow or freeformin 40 of 1637, across 1 file
- Ask for document meta-contextin 40 of 1637, across 2 files
Said here and by no other author read
- create a bug entry in BUGS.md
- create a corresponding bug fix task file
- update TASKS.md with bug fix tasks
- determine the next available bug ID
- link bugs to affected features
- move resolved bugs to the closed section
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.